Hi, maybe, but fix the obvious bugs first, and see what happens. Trev On Tue, Aug 31, 2010 at 08:38:50PM -0500, Martin McCormick wrote: > Christopher Brannon writes: > > Yep, this is a buffer overrun. Additionally, the OP isn't > > checking the return value of read(). It returns -1 on failure, in which > > case, it should not be used as an index into the buffer. > > Even though I am not supposed to be receiving anywhere > near a full buffer's worth of data, it has got to be a reference > pointer problem of some kind. I did experiment with a smaller > buffer but nothing changed. One would have expected the garbage > data to be different but it was always the same string > fragment. > > When I figure it out, I will tell you what I found. I > know that the serial routines under Linux are supurb so I am > sure I just have something configured wrong. > > I spent the first day perplexed because I wasn't even > sure whether I needed a null modem or not. I couldn't get > anything to come back. It turns out that the hardware flow > control needs to be absolutely shut off as the radio doesn't > even fake it by leaving the correct lines on all the time. If > your communicator program is looking to use CTS or RTS, you will be > waiting forever. As soon as I took that out, it started talking > big time. I was never so glad to see an error message in all my > life. If you send anything other than a valid command, even an > empty carriage return, the radio responds with "ERR" I almost > think I hear it laughing at me. > > Thanks for all of your suggestions. > > Martin > > _______________________________________________ > Blinux-list mailing list > Blinux-list@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/blinux-list
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ Blinux-list mailing list Blinux-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/blinux-list