SIE wrote: > We have a project that will communicate with two different OS(uClinux > and uC/OS-II) through UART.
What speed are you using,what receive FIFO size does the S3C4510B's UART have and what serial driver are you using? I can't read http://www.mculand.com/sub1/mcu/arm7tdmi_device/s3c4510.htm but if the source is correct, it seems that the FIFO is 32 bytes. > However,uClinux is not a real-time OS, Well, even (hard) real-time only guarantees that you get the processing in a specified time, and not that the time is short enough to be able to handle the UART ;) With 32 byte and 115 kbps you need to service an interrupt in 2.6 ms, which should be more than enough. Is there any other hardware that might be blocking interrupts for this long? Writing to flash or something like that? > We think that it may be caused by that uClinux's > speed of handling the interrupt is not fast enough to follow OS-II. First confirm what exactly is not up to speed - is it the kernel that fails to service the interrupt in time, or is it your application that is not able to take the data? You might want to add a byte counter into the kernel and to your application, send a burst of data and compare them - if they match, it is the kernel, if not, it is the app. > Does any good solution to reduce the packet-lost? Depends on the application - you need some kind of flow control, but a software one won't work if the problem is at the interrupt servicing level. -- Stano _______________________________________________ uClinux-dev mailing list [email protected] http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by [email protected] To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
