Is there a option to "STICK UART PARITY" to 1 and 0 using the CMSIS Drivers...
This is all that is defined in the HEADER file;
/*----- USART Control Codes: Mode Parameters: Parity -----*/ #define ARM_USART_PARITY_Pos 12 #define ARM_USART_PARITY_Msk (3UL << ARM_USART_PARITY_Pos) #define ARM_USART_PARITY_NONE (0UL << ARM_USART_PARITY_Pos) ///< No Parity (default) #define ARM_USART_PARITY_EVEN (1UL << ARM_USART_PARITY_Pos) ///< Even Parity #define ARM_USART_PARITY_ODD (2UL << ARM_USART_PARITY_Pos) ///< Odd Parity
The hardware does support it. The controller is the NXP LPC18xx series.
USART Line Control Register (LCR - addresses 0x4008 100C (USART0)
Bit 3 is Parity Enable. 0 Disable parity generation and checking. 1 Enable parity generation and checking.
Bits 5:4 are Parity Select. 0x0 Odd parity 0x1 Even Parity. 0x2 Forced "1" stick parity. 0x3 Forced "0" stick parity.
The "Stick Parity" feature is only available in some devices. Actually the NXP document does not explain it very well.
You can find better documentation here: infocenter.arm.com/.../index.jsp
As you have correctly indicated, it is currently not supported (also because we have no seen the value of it yet).
It seems to be used to transmit a 9-bit value. This could be implemented in the CMSIS-Driver (but is currently not available for the NXP devices).
Is this the use case that you are looking for?
Doesn't look like it:
www.keil.com/.../group__usart__parity__bit.html
:-(
Yes, using sticky parity is very valuable when needing to send 9-bit data to control device adressing.
I need the "stick parity" to transmit a 9-bit value in the protocol to indicate it is an address BYTE. 0 = DATA
The transmit functions actually support 9-bit transmissions.
www.keil.com/.../group__usart__interface__gr.html
However it is currently not implemented for the NXP devices.
Would this solve your problem?
I would prefer the "STICK UART PARITY" feature, NXP on the LPC18xx does not do 9-bit transmissions properly.
So doesn't CMSIS have a formal method for adding "extended" features to the standard API?
This would seem pretty fundamental, as it's really only the peripherals that distinguish the different manufacturer's offerings - if CMSIS is just going to reduce everything to the lowest common denominator, that would seem to defeat the object ... ?!
Could you not, instead, choose a device with 9-bit support?
Still doesn't help that CMSIS won't support it, though.
Of course I would love to choose a device with good 9-bit support but I am way into the development cycle and a change at this point would set me back months! The LPC18xx does have 9-bit support but it is very poorly documented and anyway what good is it if CMSIS won't support it.
Is my best bet to modify the driver? (USART_LPC18xx.c and associated include files)
Scott,
Yes, of course you can add the functionality (9-bit mode) to the USART driver yourself.
In which time frame would you need a solution? I can ask the team if we have already a good starting point (from other devices) for that.
Reinhard
I prefer the STICKY BIT method and not 9-bit. Thanks for the help. I am attempting to add the STICKY BIT support to the driver.
Do you have to go through CMSIS?
Could you not just use your own code for this?
Don't NXP have a "driver" ?