Jim Stewart wrote:

> Brings back old memories.  My first product had X-Modem
> download capability and I wrote and debugged it in assembly
> language on a Saturday afternoon.  It was exquisitely
> ugly with software timing loops and no crc, but it
> worked for years.  I finally got sick of it and completely
> rewrote it with crc.

Jim,

Sorry to bring the thread back from the dead -- just saw your reply now.

Yeah, old memories indeed.  I co-wrote some (unpopular, basically 
unknown) BBS software years ago as a kid, and one of my tasks was 
implementing the file upload/download feature.  I remember finding 
XMODEM.TXT(the xmodem specs) on some bulletin board, and being very 
excited about it.  At the time, however, I didn't have enough RAM to 
store it, and I couldn't write real time to my tape drive.  So what I 
did was attach my modem to my printer directly (daisy wheel 130 column 
25cps), and lo-and-behold, I managed to get a printed copy of it!  300 
baud is +/- 25cps, so a little flow control, and I was home free. 
Ingenious for not being yet in my teenage years! :)

Anyways, I ended up not understanding how the 8-bit checksum worked (I 
think it was just check=check+newbyte mod 256.), and so I picked up the 
phone and called the phone number at the top of the page.(of course!) 
Turned out to be either Ward Christensen or Chuck Forsberg at some 
university.  I remember him telling me, "it's all in the spec" but I 
didn't know enough to understand most of what was in there.  He provided 
a couple quick pointers and shoo'd me away back to my paper route.

Ahh well.

Keith

Keith M wrote:
> CBFalconer wrote:
> 
>> If you are going to consider X-modem, try Z-modem.  Much better
>> error control, speed, etc.  Uses the same transmission paths.
>>
> 
> Sorry to pick on your idea CBF.
> 
> Xmodem is considerably easier to implement than Zmodem.  I implemented 
> Xmodem when I was about 10 or 11 years old, first in Basic, and then in 
> C.  

That's the sort of thing I can deal with!

>I remember Zmodem when it was first released, and it was great.  Big 
> improvement over Xmodem and Ymodem, lots of extra features and 
> functionality.  But it was also a lot more complex.  Sliding windows, 
> automatic recovery, big checksums, transfer of filenames, etc etc.
> 
> I'm not necessarily advocating anything for your particular application, 
> just wanted to point out that using Zmodem might not be a slam dunk.

I wouldn't have considered Zmodem for my app.

> Oh, and regarding FTDI chips.  Their chips, drivers, and support are all 
> top notch.  I'm using their FT232BM chip at 2mbps, and it works 
> reliably.  I started using their VCP drivers, which work very well.  I 
> eventually switched to using their D2XX .dll drivers, because it offers 
> more fine-grain control.
> 
> Be sure to download the datasheets, app notes, and tips on their 
> website, especially when they talk about latency, baud rates, etc.

Thanks for the input to the thread!


-- 
_____________________
Christopher R. Carlen
crobc@bogus-remove-me.sbcglobal.net
SuSE 9.1 Linux 2.6.5

Keith M wrote:

Snip...

> Xmodem is considerably easier to implement than Zmodem.  I implemented 
> Xmodem when I was about 10 or 11 years old, first in Basic, and then in 
> C.  

Brings back old memories.  My first product had X-Modem
download capability and I wrote and debugged it in assembly
language on a Saturday afternoon.  It was exquisitely
ugly with software timing loops and no crc, but it
worked for years.  I finally got sick of it and completely
rewrote it with crc.

CBFalconer wrote:

> If you are going to consider X-modem, try Z-modem.  Much better
> error control, speed, etc.  Uses the same transmission paths.
> 

Sorry to pick on your idea CBF.

Xmodem is considerably easier to implement than Zmodem.  I implemented 
Xmodem when I was about 10 or 11 years old, first in Basic, and then in 
C.  I remember Zmodem when it was first released, and it was great.  Big 
improvement over Xmodem and Ymodem, lots of extra features and 
functionality.  But it was also a lot more complex.  Sliding windows, 
automatic recovery, big checksums, transfer of filenames, etc etc.

I'm not necessarily advocating anything for your particular application, 
just wanted to point out that using Zmodem might not be a slam dunk.

Oh, and regarding FTDI chips.  Their chips, drivers, and support are all 
top notch.  I'm using their FT232BM chip at 2mbps, and it works 
reliably.  I started using their VCP drivers, which work very well.  I 
eventually switched to using their D2XX .dll drivers, because it offers 
more fine-grain control.

Be sure to download the datasheets, app notes, and tips on their 
website, especially when they talk about latency, baud rates, etc.

Hope this helps

Keith

Chris Carlen wrote:
> The Real Andy wrote:
>
>> For a first time protocol all i can say is dont use straight
>> binary, use ascii (start sentinals and end sentials etc) that
>> way you dont have to worry about escape sequences etc.
> 
> Since I have total control over the receiving end driver code and
> can design it to provide a getc() that doesn't process any escape
> sequences, then as long at the outgoing bytes on from the PC are
> also not processed by the PC, there is no problem with binary.
> 
> As far as I have seen so far, it is the case that outgoing bytes
> on the PC are emitted directly.
> 
> The problem with ASCII is that it will at least double the
> physical layer throughput needed to acheive a certain high-level
> data throughput.  Ie, if I took each binary byte and sent it as
> two ASCII text chars, one for each nibble, which is a common way
> of transmitting binary data in ASCII form, while allowing
> control chars to be treated as control chars.

Zmodem (and Xmodem, or Ymodem) are protocols that transmit binary. 
They require that the full 8 bits of a byte are usable for
transmission.  Zmodem provides the best results of the three.

-- 
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: <http://cbfalconer.home.att.net>
            Try the download section.



-- 
Posted via a free Usenet account from http://www.teranews.com

Chris Carlen wrote:
> Jim Stewart wrote:
>
>> X-modem CRC.  Then you only have to write it for the target.
> 
> Yeah, I will spend some time looking at Xmodem to see if I
> should do it that way.
> 
> I wonder if there is anything in Python for that?  Might have
> to use some C bindings for Python to use an existing codebase.

If you are going to consider X-modem, try Z-modem.  Much better
error control, speed, etc.  Uses the same transmission paths.

-- 
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: <http://cbfalconer.home.att.net>
            Try the download section.



-- 
Posted via a free Usenet account from http://www.teranews.com

cs_posting@hotmail.com wrote:
> On Mar 3, 3:23 pm, cs_post...@hotmail.com wrote:
> 
>>Your ack scheme will need to be pipelineable, as while USB has fairly
>>high data throughput the latency, so waiting for an ack for the data
>>you've sent will quickly kill you.  You need to be able to keep
>>sending, and handle errors after the fact.
> 
> Oh, another thing - USB is packetized.  And the virtual serial drivers
> are not necessarily real smart.  If you put bytes into the serial port
> driver, you may get only one byte of user data per USB packet.  So try
> to pass larger chunks of data to the serial driver (ideally, figure
> out how much payload it sends at a time and give it that)

I get the picture.

Thanks for the input!



-- 
Good day!

____________________________________
CRC
crobcREMOVETHIS@BOGUSsbcglobal.net
NOTE, delete texts: "REMOVETHIS" and
"BOGUS" from email address to reply.

On Mar 3, 3:23 pm, cs_post...@hotmail.com wrote:

> Your ack scheme will need to be pipelineable, as while USB has fairly
> high data throughput the latency, so waiting for an ack for the data
> you've sent will quickly kill you.  You need to be able to keep
> sending, and handle errors after the fact.

Oh, another thing - USB is packetized.  And the virtual serial drivers
are not necessarily real smart.  If you put bytes into the serial port
driver, you may get only one byte of user data per USB packet.  So try
to pass larger chunks of data to the serial driver (ideally, figure
out how much payload it sends at a time and give it that)

On Mar 2, 10:36 pm, CC <cr...@BOGUS.sbcglobal.net> wrote:

> send data out through the virtual COMM port produced by using a FTDI
> FT245BM USB-to-FIFO parallel interface chip on the target.

snip

> 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:

Your ack scheme will need to be pipelineable, as while USB has fairly
high data throughput the latency, so waiting for an ack for the data
you've sent will quickly kill you.  You need to be able to keep
sending, and handle errors after the fact.

You might look at network protocols for an example, and then cut one
down to the simplest case.

Arlet Ottens wrote:
> Chris Carlen wrote:
>> Arlet wrote:
>>> On Mar 3, 4:36 am, CC <cr...@BOGUS.sbcglobal.net> wrote:
>>>
>>>> I wish to transfer binary data in the simplest way possible from a 
>>>> PC to
>>>> either an AVR or TMS320F2812 embedded target via USB.
>>>
>>> You may be interested in RFC 1549 "PPP in HDLC framing", see
>>> http://www.ietf.org/rfc/rfc1549.txt
>>>
>>> The frame format is simple and robust, and has fairly low overhead.
>>
>>
>> :-D
> 
> I don't know what the big grin means, but I wasn't talking about PPP, 
> but rather about the encapsulation method of PPP over serial lines, 
> which is quite simple.
> 
> In fact, it's only slightly more complicated than XMODEM, but more robust.

I wasn't laughing at your suggestion.  Only that it would take me more 
time to understand RFC1549 than to implement my simple protocol.

It's just a question of what's minimally necessary.



-- 
Good day!

____________________________________
CRC
crobcREMOVETHIS@BOGUSsbcglobal.net
NOTE, delete texts: "REMOVETHIS" and
"BOGUS" from email address to reply.