NINE data bits on the serial port

[lpcware]

Content originally posted in LPCWare by mawg on Wed Dec 14 19:20:46 MST 2011
This really is a clueless n00b question, sorry.

I need to communicate with a serial bus (ModBus) which has *nine* data bits.

Is it just a metter of tweaking this line

    LPC_UART0->LCR = 0x03;        // 8 bits, no Parity, 1 Stop bit DLAB = 0

which I found in

void UART0_Init(int baudrate)

in the demo code?

If so, what do I tweak it to? If not, do I have to write my own driver, or at least modify this one?

Aargh! I just noticed that UART0_Sendchar() and UART0_Getchar() operate on `char`.  Can I just copy this code and change it to uint16_t, to accomodate that 9th bit?

Sorry to sound so dumb, but this is very new territory for me.  Thanks in advance for any help.

[lpcware]

Content originally posted in LPCWare by js-nxp on Wed Jan 04 00:17:02 MST 2012
It almost sounds like my protocol. ;)

---

Quote:

The protocol for the Ampertronics' RS485 buss is as follows:
It is a 9 bit comms protocol with bit 8 used for address or data marker. 1=Address, 0=Data
PKD_ADR 1 ;Destination address (0x01-0xff, 0 not used) bit 8=1
PKO_ADR 1 ;Origin address (0x01-0xff, 0 not used) bit 8=0 from now on
PK_N_BYT 1 ;Number of bytes in packet (0x00-0xff, 0 is used for data request)
PKIO_DATA PKIO_DATA_SIZE ;Space for data
PK_CRC 2 ;16 Bit CRC MSB,lsb
CRC must be initialized to $FFFF, polynomial 0xA001

---

[lpcware]

Content originally posted in LPCWare by Rob65 on Tue Jan 03 23:50:25 MST 2012
Mawg,

yes, I am sure. The user manual of the lpc1xxx states that the parity can be: even, odd, none (i.e. no parity bit), stuck at 0 or stuck at 1.
Just read the user manual and check out the different ways of programming the parity bit.

So you can just send your data and only set the parity when you are going to send the mode byte.

John, mawg's project is using Multi Drop Bus, a standard developed for vending machines. This protocol sends packets over a serial line to which multiple devices van listen. The first byte of a packet is the address byte, addressing the slave. To distinguish between address and data bytes in a packet the ninth bit is set only on address bytes.

Regards,
[INDENT]Rob
[/INDENT]

[lpcware]

Content originally posted in LPCWare by js-nxp on Tue Jan 03 23:27:45 MST 2012
The 9 bit Multi Processor Protol has been around for maybe 30 years.

The Motorola HC11 1990 data book shows it as RWU (reader wake up mode). I have used it with the HC11, HC05, PICs, AVRs and the PC in transmit mode only, receive is a pain and I have never managed to implement it on the PC.

As serial communications became more reliable the use of the parity bit became somewhat unecessary and some clever person thought a a very usefull way of using it, mainly as an address (bit set) or data (bit clear) indicator for, mainly, RS485 communications. The NXP data sheet are wrong when they refer to this function as RS-485/EIA-485 because that's an electrical specifcation which the chip doesn't have AFAIK.

The same thing can be realised using 8 bits and using bit 7 as an address marker but then the data needs to be sent out in 2 nybbles which is wasteful, 9 bit mode is very nice as one can send 8 data bits.

Modbus uses 8 bit mode mainly, at least the version I have used. The start of packet byte is indicated by a timed break in the communication rather than a 9th bit.

...now I have no idea of what we are trying to achieve or what we are taking about....:o

[lpcware]

Content originally posted in LPCWare by mawg on Tue Jan 03 22:10:11 MST 2012

---

Quote: Rob65
So many protocols to choose from ...
I just browsed to find this doc: http://www.vending.org/technical/MDB_3.0.pdf if that's the protocol: start bit, 8 data bits, 1 mode bit, 1 stop bit then it's easy.

You can program the UART to use 8 data bits plus parity. The parity then acts as the mode bit. The good thing is that next to programming the parity as odd or even you can also set it to stick 1 or stick 0.

---

Rob, are you sure? You sound so knowledgable, but when I interpret this from Wikipedia

---

Quote:
The D/P/S (Data/Parity/Stop) conventional notation specifies the framing  of a serial connection. The most common usage on microcomputers is  8/N/1 (8N1). This specifies 8 data bits, no parity, 1 stop bit. In this  notation, the parity bit is not included in the data bits. 7/E/1 (7E1)  means that an even parity bit is added to the seven data bits for a  total of eight bits between the start and stop bits.

---

It seems to me that I can't have eight data bits *and* a parity bit (which could be used as the Mode bit).

Or did I misunderstand it?

[lpcware]

Content originally posted in LPCWare by Rob65 on Tue Dec 20 02:05:41 MST 2011

---

Quote: mawg
Watch out for my upcoming "how do I code a driver?" question :D

---

Thanks, I needed this :D

The answer will depend of your experience.
If you are an experienced C programmer with a bit of knowledge in  the embedded world and if you know what an interrupt is, then my answer  might just direct you towards the uart example that is in one of the  examples....zip file that was installed as part of LPCXpresso.
You will then understand that [I]example[/I] is different from [I]driver[/I] in that it is not complete, nor proven work.
Not all the examples contain error handling, so even if it works you should check if it behaves the way you want.

I decided to make my own code available to the world (the part that has internet) hg.bikealive.nl/Platform1754. That code is based on FreeRTOS and it will include device drivers that use OS functions like queues mutexes and such.
Please note [B][I]will[/I][/B] include. At the moment of writing there are only two drivers, one to program the PLLs and one to control an LCD with ST7565 controller.
There is another archive with two more drivers (i2c and uart) that I currently use for a project available here. They "work for me" (tm) ;)
The new platform project will contain tested drivers, and include the testprograms so you can reproduce the results.

Rob

[lpcware]

Content originally posted in LPCWare by mawg on Mon Dec 19 19:19:27 MST 2011
I am informed by someone who has done it before that I will need to code a driver.

Watch out for my upcoming "how do I code a driver?" question :D

[lpcware]

Content originally posted in LPCWare by kalpak on Sat Dec 17 19:58:20 MST 2011
Without waiting for the HW, you can check this out on the free version of Keil.
It has excellent simulation of the UART.

[lpcware]

Content originally posted in LPCWare by mawg on Sat Dec 17 19:33:34 MST 2011
Rob, I thank you *very much* for such a comprehansive answer.

I am waiting to get my hands on the hardware, so can't check it yet, but it certainly looks good.

Thanks!

[lpcware]

Content originally posted in LPCWare by Rob65 on Thu Dec 15 23:55:07 MST 2011
So many protocols to choose from ...

---

Quote: mawg
Aaargh!!  I just realized that I made a stupid mistake when posting.

I _am_ working on a Modbus project  - but it's not this one.

---

Good, I had my doubts about your knowledge about the protocol :eek:
I'm very happy to see this is not the case :D

I just browsed to find this doc: http://www.vending.org/technical/MDB_3.0.pdf if that's the protocol: start bit, 8 data bits, 1 mode bit, 1 stop bit then it's easy.

You can program the UART to use 8 data bits plus parity. The parity then acts as the mode bit. The good thing is that next to programming the parity as odd or even you can also set it to stick 1 or stick 0.

One warning though: the parity setting is in LCR (line control register) and I don't think this is synchronized with the FIFO. So before changing the parity (mode bit) you might want to wait until the UART is idle, I think you need to wait for the TEMT bit (bit 6 in the Line Status Register) to become 1 to be sure the bit does not change when there is still data being processed.

You should test this.
If I had to do this I would do this as following:

1) initialize the UART
2) set parity to stick to 1
3) send a byte
4) wait some time (long enough to be sure the data has been transmitted)
5) write a byte into the THR
6) immediately set the parity to 0

Log the UART data with a logic analyzer and check the data.

Regards,[INDENT]Rob
[/INDENT]

[lpcware]

Content originally posted in LPCWare by mawg on Thu Dec 15 20:22:18 MST 2011
Aaargh!!  I just realized that I made a stupid maistake when posting.

I _am_ working on a Modbus project  - but it's not this one.

This one is Multi Drop Bus, which is a standard for vending machines. For some reason they add a ninth databit which is only ever used to indicate the last byte of a message.

Existing perhiperals will be using this mechaism, so I need to adhere to it. Which means reading 9 databits.

Any suggestions? Please accept my apologies for the typo earlier.

[lpcware]

Content originally posted in LPCWare by Rob65 on Thu Dec 15 04:55:06 MST 2011
Sure,

you can always play with the parity.
But the thing is that modbus is an 8 bit protocol.
The RTU physical interface uses 8 bits + parity and I was wondering if mawg misunderstood this concept.

Rob

[lpcware]

Content originally posted in LPCWare by Polux rsv on Thu Dec 15 02:29:18 MST 2011
If 9 bits is needed, you could probably play with even/odd parity setup. It is just an idea, but it should work. For each "9bit" to send, you split it in 8+1, the 9th bit beeing fit in the parity bit. Before sending every byte, you set the parity mode depending on the byte parity itself, and 9th bit you should transmit.

Angelo

[lpcware]

Content originally posted in LPCWare by Rob65 on Thu Dec 15 00:49:17 MST 2011
9 bits ???

You are referring to ModBus RTU ?
If I read the Modbus Protocol guide, I see at page 7 (page 16 of the PDF):

---

Quote:

Bits per Byte: 1 start bit
8 data bits, least significant bit sent first
1 bit for even/odd parity; no bit for no parity
1 stop bit if parity is used; 2 bits if no parity

---

To me that seems like modbus is just 8 bits + parity.

Regards,
[INDENT]Rob
[/INDENT]