TipsForDealingWithSerial - Revision history

Kuroneko: /* General */ the protocol uses LFs, not CRs.

2018-06-04T04:23:41Z

‎General: the protocol uses LFs, not CRs.

Kuroneko: /* General */

2018-06-04T04:22:56Z

‎General

Kuroneko at 21:49, 3 June 2018

2018-06-03T21:49:42Z

Kuroneko: Get the category name right this time...

2018-06-03T02:34:17Z

Get the category name right this time...

Kuroneko at 02:33, 3 June 2018

2018-06-03T02:33:48Z

Kuroneko: Created page with "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" p..."

2018-06-03T02:33:23Z

Created page with "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" p..."

New page

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 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 CR.

* 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.

@@ Line 7: / Line 7: @@
 * 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 CR.
+* 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).

@@ Line 3: / Line 3: @@
 == 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.
 * 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.

← Older revision		Revision as of 21:49, 3 June 2018
Line 4:		Line 4:

	* 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 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 CR.		* If you get a RX Overrun, your best option with the OIS protocol right now is to discard bytes up until the next CR.

← Older revision		Revision as of 02:34, 3 June 2018
Line 17:		Line 17:
	* Use pin change interrupts rather than polling the pins for input.		* Use pin change interrupts rather than polling the pins for input.

−	[[Category:~~ExternalProtocol~~]]	+	[[Category:HardwareInterfacing]]

← Older revision		Revision as of 02:33, 3 June 2018
Line 16:		Line 16:

	* Use pin change interrupts rather than polling the pins for input.		* Use pin change interrupts rather than polling the pins for input.
		+
		+	[[Category:ExternalProtocol]]