Difference between revisions of "TipsForDealingWithSerial"
m (Get the category name right this time...) |
m (→General: the protocol uses LFs, not CRs.) |
||
| (2 intermediate revisions by the same user not shown) | |||
| Line 3: | Line 3: | ||
== General == | == General == | ||
| − | * Bear in mind the size of your buffers - if your transmit buffer is small, during the "Synchronisation" phase, make sure your tx buffer is empty/has enough space (or your serial library will block until transmission is complete) before sending the next configuration item as most microcontrollers easily run fast enough to outpace 9600bps serial. | + | * Bear in mind the size of your buffers - if your transmit buffer is small, during the "Synchronisation" phase, make sure your tx buffer is empty/has enough space (or that your serial library will block until transmission is complete) before sending the next configuration item as most microcontrollers easily run fast enough to outpace 9600bps serial. |
| − | * If you get a RX Overrun, your best option with the OIS protocol right now is to discard bytes up until the next | + | * Because almost all microcontrollers can outpace serial transmissions, there can be a significant time delay between characters. Be prepared to use a blocking read that will wait until a end of line occurs, or to reconstruct the string yourself. |
| + | |||
| + | * If you get a RX Overrun, your best option with the OIS protocol right now is to discard bytes up until the next LF. | ||
* Because of the format of the messages, you really should check for RX overruns as you read the messages sent by the host - an overrun can very easily change the intent of a message and cause unexpected behaviour, particularly if your channel numbers are similar. (a channel 20 message could be misinterpreted as being channel 2 for example). | * Because of the format of the messages, you really should check for RX overruns as you read the messages sent by the host - an overrun can very easily change the intent of a message and cause unexpected behaviour, particularly if your channel numbers are similar. (a channel 20 message could be misinterpreted as being channel 2 for example). | ||
Latest revision as of 04:23, 4 June 2018
Some generic tips for dealing with Serial Protocols
General
- Bear in mind the size of your buffers - if your transmit buffer is small, during the "Synchronisation" phase, make sure your tx buffer is empty/has enough space (or that your serial library will block until transmission is complete) before sending the next configuration item as most microcontrollers easily run fast enough to outpace 9600bps serial.
- Because almost all microcontrollers can outpace serial transmissions, there can be a significant time delay between characters. Be prepared to use a blocking read that will wait until a end of line occurs, or to reconstruct the string yourself.
- If you get a RX Overrun, your best option with the OIS protocol right now is to discard bytes up until the next LF.
- Because of the format of the messages, you really should check for RX overruns as you read the messages sent by the host - an overrun can very easily change the intent of a message and cause unexpected behaviour, particularly if your channel numbers are similar. (a channel 20 message could be misinterpreted as being channel 2 for example).
Arduino Specific
- Arduino's USB Serial port is implemented in one of two ways depending upon the specific model: Either USB-Serial adapter IC directly connected to USART 0 (most models); or Direct ACM CDC implemented on the AVR itself (Leonardo, some others). With CDC, bit rate commands are a technicality to maintain compatibility with real serial - it has no meaning however (data flows at USB speeds, packet by packet), and with the serial converters, because the converter is wired back to back with the microcontroller, you can safely push the bitrate up. Speeds of 19200-57600 bps should be safely usable as long as you can get the host to agree.
- Don't try to be too generic in your Arduino code - the Arduino library itself is quite inefficient, and you will save a lot of cycles by just doing what you specifically need to do directly, rather than trying to have a degree of runtime configurable behaviour.
- Use pin change interrupts rather than polling the pins for input.
