Re: Designing a protocol for the first time
- From: Habib Bouaziz-Viallet <habib@xxxxxxxxxxxxx>
- Date: 03 Mar 2008 07:43:10 GMT
Le Sun, 02 Mar 2008 19:36:51 -0800, CC a écrit:
Greetings,
I wish to transfer binary data in the simplest way possible from a PC to
either an AVR or TMS320F2812 embedded target via USB.
The PC will be running a Python/wx.Python program and use PySerial to
send data out through the virtual COMM port produced by using a FTDI
FT245BM USB-to-FIFO parallel interface chip on the target. Ideally this
program will be useable on Linux as well as Windoze machines.
I estimate that I need up to 120kB/s (without overhead) of data
throughput to transfer 30000 points per second of 32-bit words
containing vector graphic X,Y,RGB points for a laser show project.
The FTDI chip says it can do 300kB/s with the virtual COMM driver, so
this should work unless they are fibbing.
I have gained some experience recently by writing a set of low-level
serial driver functions for the F2812. Then I wrote a command parser
for it so the F2812 can respond to text commands and send back various
reports. This is all via text terminal. That was my first foray into
communication interface programming. It was fun and not too difficult.
Now I need to transfer binary data. The project here won't need any
human readable command line. I also don't want to increase overhead by
having to reserve the 8th bit for example to distinguish control codes
from data, or use some text rendition of the data, etc. Just straight
binary.
Thus, I suspect the simplest way for the target to behave is to
implement a state machine something like this:
data: state:
<none yet> 1. wait for start code
0x1234 2. (start code received) wait for size field
0x0123 3. (16-bit size field received, specifying 291
words to follow) wait for data
0xdddddddd 4. (data incoming) count data words until 291
0xdddddddd received
0xdddddddd
...
0xdddddddd 5. (291st word received) wait for CRC state
0x3E5B 6. (16-bit CRC received) goto state 1
Now of course, each state transistion can send a code back to the sender
telling whether things are proceeding smoothly. Another state
transition path to add might be:
data:
<none yet> 1. wait for start code
0x5678 7. (request for ACK received) send ACK, goto
state 1
That way if the receiver is stuck waiting for data and the sender
doesn't know what state receiver is in, the sender can request ACK until
the data receive counter transitions things back to state 1.
Is there anything more needed than this (aside from additional fields in
the protocol)?
Since there is a specific code to tell the receiver that a data package
has begun, when the receiver is in state 1, any sort of commands can
also be issued by using any codes other than the 0x1234 example.
Any comments would be welcome regarding my budding protocol idea.
Good day!
I agree with Jim and Arlet although Jim solution is easier to implement
--
HBV
.
- References:
- Prev by Date: Re: Designing a protocol for the first time
- Next by Date: Re: Designing a protocol for the first time
- Previous by thread: Re: Designing a protocol for the first time
- Next by thread: Re: Designing a protocol for the first time
- Index(es):
Relevant Pages
|