It blocks until 64 bytes are copied into the buffer. If the requested amount is already present in the queue then it exits immediately.
You may change the behavior using the Timeout variant, as example by specifying TIME_IMMEDIATE as timeout the read function only reads data already present into the queue without blocking, this is preferred mode when using events, in this case you just want to empty the queue in the event handler.
Oh, I may be misusing the OS. I set up a thread to block on reading from a GPS I have connected. It takes whatever bytes it gets and then parses them, and loops.
Should I be using events instead? Can I get an event for when bytes are available on the port? I don't necessarily want to execute code on every single byte, unless the system is otherwise idle.
How big is the internal buffer for the serial port?
I'll read up on the events docs in the meantime. Thanks!
The buffer size is configurable in halconf.h, it is 16 bytes deep by default but is should not affect operations unless you omit to read data fast enough.
The correct way of reading data depends on how your data are organized. If you receive text lines then the best approach would be to read one byte at time (sdGet()) until you read the delimiter, this way you would be able to process one line at time.
About events, you don't have to use them, those are mainly useful when you have a single thread serving multiple event sources.
Do you have a how-to on events? I finally found this: http://www.chibios.org/dokuwiki/doku.php?id=chibios:kb:events, but it's still not clear to me how I can get an event sent when serial data is available, and how I would respond to that event (like, what are the actual calls).
The serial driver implicitly broadcasts event when it has something to report, for example: - Data in the receive queue. - Transmit queue empty. - Receive errors.
In order to receive events a thread must "register" on the driver "event source" using chIOGetEventSource() and chEvtRegister() then it can wait for events using one of the chEvtWaitxxx() functions and optionally use chEvtDispatch() to jump directly to an handler function, note that a single thread can be waiting on multiple events at the same time. After receiving a driver event the function chIOGetAndClearFlags() returns a mask of the pending conditions on the driver, the thread can then decide what to do in response.
I don't have a specific example of events with serial drivers but if you look into the various FatFs demos you can find examples of all the above functions. I think this is a good idea for a new guide, serial drivers are appearing often as topic in the forum.
A serial driver article might be nice, but I think a general events article would be quite helpful as well. Something in the form of http://www.chibios.org/dokuwiki/doku.ph ... eatethread but for events would do the trick, I think.
If these were hosted in a wiki, it might be easier to collaboratively edit them instead of just lodging requests
liamstask wrote:If these were hosted in a wiki, it might be easier to collaboratively edit them instead of just lodging requests
Hi Liam,
I finally fixed the problem with registrations on the Wiki, now it seems to work. Note that registered users are not able to edit by default, I have to move each user in an "editors" group manually in order to stop spammers.
Those wanting to fix existing articles or wanting to write new ones may contact me via PM, I am thinking to add a section for contributed material (that would retain the signature of the author of course).