FullDuplexSerial with 7/8 bits n/o/e-parity?

Nick Mueller · 2009-07-13 08:02

Hi!

Before I do that by myself, is there a variant of the FullDuplexSerial that can be configured to do
* 7 or 8 Bits?
* Odd, even or no parity?
* as an extra bonus selectable number of stop-bits?

Thanks,
Nick

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!

The DIY Digital-Readout for mills, lathes etc.:
YADRO

Kye · 2009-07-13 13:57

Mine will do that fo you.

It works for only 8 bits. But of course you can always make the last bit high as to make it only 7 bits that are transfered.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,

Post Edited (Kye) : 7/13/2009 4:35:18 PM GMT

Mike Green · 2009-07-13 14:32

It's very rare to find true 7 bit serial. Most of the time it's really 8 bits of data where the 8th bit is the parity bit (even / odd / always zero / always one).

There's no need to configure the number of stop bits for receiving, only for transmitting when it's required. If you're using Simple_Serial which is not buffered, you can just add some delay between transmitted characters (one bit-time for each extra stop bit).

Nick Mueller · 2009-07-13 14:43

> But of course you can always make the last bit high as to make it only 7 bits that are transfered.

That's almost perfect!

Am I right (had just a short look at it), that it supports parity just in 7 bit mode?

Thanks,
Nick

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!

The DIY Digital-Readout for mills, lathes etc.:
YADRO

Kye · 2009-07-13 16:31

Yup.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,

Nick Mueller · 2009-07-13 17:04

> It's very rare to find true 7 bit serial. Most of the time it's really 8 bits of data where the 8th bit is the parity bit
> (even / odd / always zero / always one).

That's right.
But my requirement for sending data (to fullfill the standard) is 7 and 8 bits, with any parity and one stop bit.
OK, I'll dive into the original assembler, should not be too complicated.
"TEST wc" is a great help here.

Nick

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!

The DIY Digital-Readout for mills, lathes etc.:
YADRO

Mike Green · 2009-07-13 17:46

Nick,
There is no "standard" for this. True 7-bit serial is historical only. You will not find modern equipment capable of sending or receiving it. Modern equipment is all 8-bit data as I mentioned, with the 8th bit configurable to always hold a zero bit, a one bit, the even parity of the other 7 bits, or the odd parity of the other 7 bits. You can use FullDuplexSerial for this, unchanged, with all of the work on the 8th bit done by the caller. If you're doing it in Spin, you'd just have:

case mode
   always_one:
      data |= $80
   always_zero:
      data &= $7F
   even_parity:
      data := (data & $7F) | (((data << 1) ^ (data << 2) ^ (data << 3) ^ (data << 4) ^ (data << 5) ^ (data << 6) ^ (data << 7)) & $80) ^ $80
   odd_parity:
      data := (data & $7F) | ((data << 1) ^ (data << 2) ^ (data << 3) ^ (data << 4) ^ (data << 5) ^ (data << 6) ^ (data << 7)) & $80
ser.tx(data)

Nick Mueller · 2009-07-13 21:32

> There is no "standard" for this. True 7-bit serial is historical only.

The standard is the standard of the protocol (ModBus) that requires these settings.
7 bits for ASCII-transmission (Hex, two chars / byte), 8 bits for binary (called RTU) transmission.

All that is no problem with 7 bits (o/e/n), but with 8 bits, I'll have to modify the ASM-code. The standard *requires* even parity for 8 bits.
And when I'm doing that, it is more efficient to implement all requirements (7/8 o/e/n) at the ASM-level. Much faster (compared to counting/shifting/masking bits in a high-level language) and more size-efficient.

I'm currently developing with the ASCII-transmission, because it is easier to read for me while debugging and testing, but I want to switch over to binary (keeping the ASCII-part) to speed things up. More than 50% (don't know the exact number right now) of the time (receiving a command, decoding and executing it and then sending a response) is spend with communication.

Nick

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!

The DIY Digital-Readout for mills, lathes etc.:
YADRO

Kye · 2009-07-13 23:19

I hope my code helped.

Also you could be lazy and do it the higher level way. if speeds not a problem.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,

Peter Jakacki · 2009-07-13 23:35

Nick, I have written MODBUS drivers for the Prop but to tell the truth I didn't bother with 7-bit ASCII as although it may be a option for MODBUS I haven't come across it's actual use. I think I did do a serial coms driver with 7-bit and parity once but I will have to dig through my "junk box" and dress it up if you really do need it. Using 8-bit mode for receiving 7-bit data is fine as long as 2 stop bits are used because otherwise you may receive two 7-bit characters with only one stop bit between. What the Prop will see is a framing error as the start bit of the next character makes it look like that there is no stop bit for the last character.

*Peter*

Nick Mueller · 2009-07-13 23:38

> Also you could be lazy and do it the higher level way. if speeds not a problem.

I don't see how I could set the 9th bit (the parity bit of a 8 bit transmission) outside of PASM. But I might be missing something.

Nick

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!

The DIY Digital-Readout for mills, lathes etc.:
YADRO

Kye · 2009-07-14 02:31

9 Bits?

... Yeah, guess you have to.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,

caskaz · 2009-07-15 15:35

Hi.
I also have trouble about FullDuplexSerial.Plus
I put sinple-test-program on Propeller-Demo-Board.
(sending "0", LED-P16 is ON)
I connect Linux and Propeller-Demo-Board. But cannot communicate.
I set 7bit no Parity 1-Stopbit to /dev/ttyUSB0 on Linux.
Linux recognize device(Serial-To USB).
Command from Linux
#echo -n 0 > /dev/ttyUSB0

What wrong?
Please.

Mike Green · 2009-07-15 15:49

caskaz,
It is impolite to "hijack" another thread. Unless your question is directly related to the subject, please start your own thread.

Linux probably supports actual 7-bit no-parity serial (with a start bit, 7 data bits, and a stop bit) which FullDuplexSerial doesn't support.
Try 8-bit no-parity on Linux.

You may have an error in your program so you must include that (as an attachment to a message, use the Post Reply button).

FullDuplexSerial with 7/8 bits n/o/e-parity?

Comments