dkinzer
Site Admin
Joined: 03 Sep 2005
Posts: 2593
Location: Portland, OR
|
|
Posted: 14 January 2007, 18:55 PM Post subject: |
 |
|
| mikep wrote: | | [A] sustained speed of 230K means only 21uS (320 CPU cycles) per byte. |
I believe that these numbers apply to 460.8K. It would be 43uS at 230.6K. Even at that speed, I suspect that very long bursts of received characters might be problematic. However, with a large enough queue and sufficient processing time between bursts it should be workable. |
|
spamiam
Joined: 13 Nov 2005
Posts: 689
|
|
Posted: 14 January 2007, 19:14 PM Post subject: |
|
|
| mikep wrote: | | I think you might be better off with a simple buffer for the application side plus a receive queue for incoming data. It is important that your messages have some kind of CRC as it is quite easy to lose bits. |
Well, if the buffer is big enough, then linear works, but in order to minimize queue/buffer manipulations, and the time it takes to manage it all, I was thinking that a single buffer would be more efficient.
| mikep wrote: | | I don't understand why you need to send data that speed. With a local processor at the LCD end you should be able to cache the data for the LCD. |
Well, I do not need that sort of speed. But, for the purposes of the software and hardware design, I wanted to test the performance limits. Any problems should be accentuated when stressed to the limit.
In my current application, I will be updating the display (16 x 2) every 200 mS. This means that I will be sending a maximum (estimated) of 32 characters + 6 control characters 5 times a second. This means I need a minimum of about 1900 baud. In order to be sure it is completed with time to spare, I would need about 3800 baud. So 4800 baud would be more than fast enough. I have selected 19200 baud for this particular application. This gives headroom for higher bandwidth if I institute ECC protocols, still without monopolizing the sender during transmissions. I decided to use RS-485 and reasonably slow data speeds to (hopefully) minimize data corruption (I can go to lower speeds if necessary). Since this particular need is for an information display only, and since it gets overwritten within 200mS, I am not too worried about rare glitches. So far none visible....
| mikep wrote: | | I don't think ZBasic can keep up with a sustained 230KBaud. You can create a buffer of say 128 bytes and then send that buffer (and receive it) at that speed. Then you need recovery time to prepare for the next send. The sustained speed of 230K means only 21uS (320 CPU cycles) per byte. Doable for an AVR but hard for a ZX. |
Well, I do not have a logic analyzer to check what the ZX is doing precisely. I am using the normal comms and queue routines. I am sending strings and a couple of bytes, and I do a byte-to-string conversion too. I am not positive that I am keeping the output buffer filled at all time, but I bet it is close because I am doing nothing else. I believe the ZX uses interrupt-driven comms for com1, so, it ought to be fairly efficient. Maybe someone with a logic analyzer can look at how well a ZX manages to maintain a throughput of 230.4Kbaud.
Whatever the speed may be, it was too much for my LCD's bandwidth, but 115.2 was comfortably within its capabilities. As you said above, why on earth would you WANT this speed for an LCD? It can write 360 full screens each second at that speed. Since the human visual system craps out at about 30 Hz, this is 10 times faster than any useful human-based interface needs to be. Most LCDs are worse than that. The liquid crystals can manage about 10Hz
To answer the bolded question above, I am thinking that maybe if there were any interest, I will sell these backpacks, and I can not predict what the needs of an end-user might be. So, I want to incorporate as much flexibility as possible. I could see a user that wants to send a lot of data, but only occasionally. If the comms are faster, then the queue will empty nearly as fast as it is filled, and a smaller queue will needed. Also, in some applications, the user may have polled comms instead of interrupt driven, and it might not have a slick multitasking operation like the ZX, so they might want to send the data as fast as possible in order to get the commsfinished and move on to the next operation.
-Tony |
|
mikep
Joined: 24 Sep 2005
Posts: 771
Location: Austin, TX
|
|
Posted: 14 January 2007, 20:13 PM Post subject: |
|
|
| dkinzer wrote: | | mikep wrote: | | [A] sustained speed of 230K means only 21uS (320 CPU cycles) per byte. |
I believe that these numbers apply to 460.8K. It would be 43uS at 230.6K. Even at that speed, I suspect that very long bursts of received characters might be problematic. However, with a large enough queue and sufficient processing time between bursts it should be workable. |
Actually I used these numbers from Don and then misquoted him. My apologies to Don. |
|
ZBasic Home
Forum Rules
Memberlist
Usergroups
RSS Feed
Site Search
Links
Download
Digests and Subscriptions
Profile
Log in to check your private messages
Log in
Register