Linux Programming Discussions

[Trevor Saunders]

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 at redhat.com
> https://www.redhat.com/mailman/listinfo/blinux-list
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/blinux-list/attachments/20100831/0756be20/attachment.sig>