question about serial communication
jintao.pku at gmail.com
Fri May 28 07:34:34 EDT 2010
Thanks for the response! Yes this is an open source school project.
And sorry for the typo about the link speed.
Actually i am pretty sure the latency is not on SoC. I used
oscilloscope to monitor the signal on uart link and the latency
between incoming byte and echo byte is very short.
Also I used a USB to serial adapter that connects to pc and test a
selfloop which connects the uart rx and tx pins using jump wires. I
still see the latency around 10 ms. Btw I used a user space c program
to read the ttyusb device. Any chance that may be the reason?
On May 28, 2010, at 2:39, Bas Wijnen <wijnen at debian.org> wrote:
> On Thu, May 27, 2010 at 08:15:11PM -0400, Tao Jin wrote:
>> I ran across this mailing list on the web. I have a question about
>> serial comm. in embedded system. Hopefully this is the right place
>> ask such question.
> If you're working on an open hardware project, I think this is the
> place. I'll just assume you are. :-)
>> I am working a program that has zigbee cc2530 SoC communicate with
>> host device, mobile phone, through serial interface. The baud rate
>> set as 115200 Kbps at both zigbee chip and host device.
> This is insanely high. I think you mean 115200 bps, which is a normal
>> When I ping 1 byte from host dev to zigbee, and zigbee echo back the
>> response, the RTT was around 10ms. I think this has to do with some
>> uncertain delay on the serial link. Anyone could show some guidance
>> how to get around the high overhead on serial link? Or this is
>> something unavoidable?
> The speed of the link itself is not uncertain at all. One byte using
> 8n1 is 10 bits, so with 115200 bps, that costs about 87 μs.
> It's a
> round trip, so that must be doubled; the total transfer time is then
> 0.2 ms.
> The other 9.8 ms must be lost in the logic: The SoC sending an
> interrupt and finding out that it is from the serial port, making up a
> response, and the phone doing similar things.
> One thing which may introduce a significant delay, is if you put the
> to sleep. When waking up, it will normally wait until all the clocks
> have stabalized.
> Hope this helps,
> Qi Developer Mailing List
> Mail to list (members only): developer at lists.qi-hardware.com
> Subscribe or Unsubscribe: http://en.qi-hardware.com/mailman/listinfo/developer
More information about the discussion