| Author |
Message |
mikep
Joined: 24 Sep 2005
Location: Austin, TX
|
|
Posted: 23 December 2006, 17:25 PM Post subject: 11-bit Serial Communications |
|
|
Currently ZBasic only supports 10 bit serial communications. The ten bits include one start bit and one stop bit. The remaining 8 bits are either 8 data and no parity or 7 data and 1 bit for parity.
The default transmission mode for the Modbus protocol (and some other serial devices) is 11 bits. This means there are 8 bits for data and 1 for parity or 8 bits for data and 1 additional stop bit.
It would be good to add this function to both COM1 and logical com ports. |
|
| Back to top |
|
 |
dkinzer
Site Admin
Joined: 03 Sep 2005
Location: Portland, OR
|
|
Posted: 23 December 2006, 19:27 PM Post subject: Re: 11-bit Serial Communications |
|
|
| mikep wrote: | | [...] 8 bits for data and 1 for parity or 8 bits for data and 1 additional stop bit. |
The latter mode can be realized now on Com3-6. The DefineCom() call allows an optional fifth parameter to specify the number of stop bits to transmit. Adding more stop bits can be helpful when transmitting to a slower device that needs extra time between characters sent.
The additional stop bit can be added for Com1 using the following code.
| Code: | ' for the mega644-based devices
Register.UCSR0C = &H08
' for the mega32-based devices
Register.UCSRC = &H88 |
The "8-bits plus parity" mode probably could be implemented fairly easily by computing the parity bit at the time the data byte is taken from the queue for transmission. The more difficult issue is what to do with the parity bit for received characters. |
|
| Back to top |
|
|
mikep
Joined: 24 Sep 2005
Location: Austin, TX
|
|
Posted: 23 December 2006, 20:09 PM Post subject: Re: 11-bit Serial Communications |
|
|
| dkinzer wrote: | | mikep wrote: | | [...] 8 bits for data and 1 for parity or 8 bits for data and 1 additional stop bit. |
The latter mode can be realized now on Com3-6. |
I was looking at hardcopy of an older version of the system library reference.
| dkinzer wrote: |
The additional stop bit can be added for Com1 using the following code.
| Code: | ' for the mega644-based devices
Register.UCSR0C = &H08
' for the mega32-based devices
Register.UCSRC = &H88 |
The "8-bits plus parity" mode probably could be implemented fairly easily by computing the parity bit at the time the data byte is taken from the queue for transmission. The more difficult issue is what to do with the parity bit for received characters. |
The Atmel code example doesn't look too hard. The most work is probably to the DefineCom API and serial data structures in the VM. |
|
| Back to top |
|
|
dkinzer
Site Admin
Joined: 03 Sep 2005
Location: Portland, OR
|
|
Posted: 23 December 2006, 23:48 PM Post subject: Re: 11-bit Serial Communications |
|
|
| mikep wrote: | | The Atmel code example [for 9 bits] doesn't look too hard. The most work is probably to the DefineCom API and serial data structures in the VM. |
The UART can handle 8 bits + parity with very little work. Doing so in the software UART would not be complicate, either.
The question is, would you want each received byte to be placed in the reception queue as two bytes (with the parity bit as the LSB of the high byte) or as one? If the latter, what should be done when a parity error is detected? The simplest thing to do is to just drop the received byte or ignore the parity error (the latter is the currently implemented strategy). An alternate strategy is to implement some way to provide notification that an error occurred. A caller-specified byte value would work but may not be suitable for all applications. |
|
| Back to top |
|
|
mikep
Joined: 24 Sep 2005
Location: Austin, TX
|
|
Posted: 24 December 2006, 18:19 PM Post subject: Re: 11-bit Serial Communications |
|
|
| dkinzer wrote: | | The question is, would you want each received byte to be placed in the reception queue as two bytes (with the parity bit as the LSB of the high byte) or as one? If the latter, what should be done when a parity error is detected? The simplest thing to do is to just drop the received byte or ignore the parity error (the latter is the currently implemented strategy). An alternate strategy is to implement some way to provide notification that an error occurred. A caller-specified byte value would work but may not be suitable for all applications. |
The problem is determining the true application needs.
Parity only provides single-bit error detection but not correction i.e. it doesn't tell you which bit is wrong and if two bits are wrong it can look correct. I believe that many serial communication prototcols use some kind of CRC or LRC which can tell you if the whole message (packet) is correct or not. So there seems to be three choices:- Ignore parity altogether and don't even return it in the data. This requires a change to the existing 7-bit data to be consistent.
- Check for parity and keep a flag bit that a parity error occurred since the last GetQueue() call to retrieve data. The problem is matching up the byte or bytes that had parity errors with the data returned in GetQueue. As in option 1 the data itself does not contain any parity data.
- Return the parity bit and let the application check it and decide what to do. This requires two data bytes to include all 9 bits.
The best approach in my opinion is to have a flag (&H10) on DefineCom that determines whether to ignore or keep parity bits. If the flag is off then 7+1 or 8+1 bit data is placed on the queue. If the "ignore parity" flag is set then 7 or 8 bit data is placed on the queue. |
|
| Back to top |
|
|
dkinzer
Site Admin
Joined: 03 Sep 2005
Location: Portland, OR
|
|
Posted: 25 December 2006, 21:03 PM Post subject: Re: 11-bit Serial Communications |
|
|
| mikep wrote: | | Return the parity bit and let the application check it and decide what to do. |
It might be more useful to return a "parity error" bit instead of the actual parity bit. If a parity error is detected, the parity bit would be one, otherwise zero. |
|
| Back to top |
|
|
mikep
Joined: 24 Sep 2005
Location: Austin, TX
|
|
Posted: 26 December 2006, 4:29 AM Post subject: Re: 11-bit Serial Communications |
|
|
| dkinzer wrote: | | mikep wrote: | | Return the parity bit and let the application check it and decide what to do. |
It might be more useful to return a "parity error" bit instead of the actual parity bit. If a parity error is detected, the parity bit would be one, otherwise zero. |
Yes it might but I was trying to maintain backwards compatibility and consistency with the existing implementation for 7 bit data plus 1 parity bit.
This is also why I called the new flag "Ignore Parity" rather than "Check Parity" |
|
| Back to top |
|
|
|
