Quote:
Originally Posted by ffonseca
Thank you for your answer yes when I send data this is hex.
Now for the language if this C is best no problem I learn if this necessary.
Thank you
|
I would write a C program versus use a script to communicate over a serial port. Ultimately you may eventually wish to do other processing besides receive and transmit. You may also need to decode, parse fragmented data, or conduct other processing. As a result you'll need to either use threads or write efficient code which will service the serial port rapidly enough to not have data be lost while you are performing other processing. In my signature there should be a hyperlink number under "Blog Entries:" click there and within the list of entries is an example of a USB serial port receiver talking to a GPS device. It shows you how I configure and open a USB serial port for communications and also how I transmit/receive with the same. In general there are other Linux serial port examples out there if you web search.
The big part for me is when I mention fragmented data. I do a lot of things like serial interface to GPS or other sensors where the data is continually streaming. Say most messages are 75 characters, I may receive 22 chars with one receive call, then 10 with the next one, and then 112 with a next call. Therefore I end up needing to have a parser which keeps track of where I last was in a message so when I exit and re-enter my receive loop, I can continue parsing new data without having lost where I was last at. Even though what you're showing appears to be small amounts of data, it is only going at 9600 and I'd recommend that you never assume that you're always going to get an entire data frame each time you perform a receive, nor that you'll only ever receive just one single data frame each time you perform a receive.