Hello,
I am attempting to use UART in 9-bit mode for our RS485 network. The following text is written in the chip's (LM4F232H5QC) datasheet:
■ EIA-485 9-bit support
All the slaves check for the address qualifier in the place of the parity bit and, if set, then compare the byte received with the preprogrammed address. If the address matches, then it receives or sends further data. If the address does not match, it drops the address byte and any subsequent data bytes. If the UART is in 9-bit mode, then the receiver operates with no parity mode.
So I enable the hardware feature and test the function with the following code (master and slave):
// ... ROM_UARTConfigSetExpClk(RS485_UART_BASE, ROM_SysCtlClockGet(), RS485_BAUD, UART_CONFIG_WLEN_8 | UART_CONFIG_STOP_ONE | UART_CONFIG_PAR_ONE); UARTFIFOLevelSet(RS485_UART_BASE, UART_FIFO_TX4_8, UART_FIFO_RX4_8); UARTIntEnable(RS485_UART_BASE, UART_INT_TX | UART_INT_RX | UART_INT_RT | UART_INT_9BIT); // Master address is 0x01,slave is 0x02 UART9BitAddrSet(RS485_UART_BASE, 0x01, 0xFF); UART9BitEnable(RS485_UART_BASE); // ... // Send the address byte to start a transmit UART9BitAddrSend(RS485_UART_BASE, 0x02); // Send packets in the interrupt function UARTCharPutNonBlocking(RS485_UART_BASE, data[i]);
I run the code, and block in the function UART9BitAddrSend():
void UART9BitAddrSend(unsigned long ulBase, unsigned char ucAddr) { unsigned long ulLCRH; // // Check the arguments. // ASSERT(UARTBaseValid(ulBase)); // // Wait until the FIFO is empty and the UART is not busy. // while(HWREG(ulBase + UART_O_FR) & (UART_FR_TXFE | UART_FR_BUSY)) {//#################### Block here, the logic seems to be error ######################## }//#################### UART_FR_TXFE bit set when FIFO is empty ######################## // // Force the address/data bit to 1 to indicate this is an address byte. // ulLCRH = HWREG(ulBase + UART_O_LCRH); HWREG(ulBase + UART_O_LCRH) = ((ulLCRH & ~UART_LCRH_EPS) | UART_LCRH_SPS | UART_LCRH_PEN); // // Send the address. // HWREG(ulBase + UART_O_DR) = ucAddr; // // Wait until the address has been sent. // while(HWREG(ulBase + UART_O_FR) & (UART_FR_TXFE | UART_FR_BUSY)) { } // // Restore the address/data setting. // HWREG(ulBase + UART_O_LCRH) = ulLCRH; }
I try to correct the mistake and send out the address byte. But the slave receive all bytes sent by master, includding the address byte, even if the address is NOT match!
My question is:
Thanks,
Kimec Shieh
Hi,
I have successfully used 9-bit UART in one of my projects, but with Cortex-M3 and I got many useful information from the application note AN01280.pdf. There is also a software package for that.
Now some comments about your code: it seems OK, although it needs some more insight using the debugger. I suppose you have initialized the slave to be ready to receive an address first, and then it will receive the data. But you must realize that there is no possible synchronization between master and slave at start-up, so you can get some junk bytes first, so this can explain your received bytes, but you must confirm/infirm the presence of a complete in-order frame, use a debugger and look also to the other bits received in each word - these will tell you if the respective word was junk or not.
Petrei.
PetreiI have successfully used 9-bit UART in one of my projects, but with Cortex-M3
I didn't think any Stellaris Cortex-M3s supported 9-bit mode?
Petreiapplication note AN01280.pdf
That is a purely-software, "bit-banged" UART - because none of the Stellaris Cortex-M3s has hardware for 9-bit mode
http://www.ti.com/tool/spma032
Stick parity bit detection/generation was an indication that 9-bit UART is possible, even this is not so much automatized as it is in LM4F or other (microcontroller) brands.
Hi Petrei,
Thanks for your advice and suggestions, these experience will be useful for my project.
Petrei But you must realize that there is no possible synchronization between master and slave at start-up, so you can get some junk bytes first, so this can explain your received bytes, but you must confirm/infirm the presence of a complete in-order frame, use a debugger and look also to the other bits received in each word - these will tell you if the respective word was junk or not.
But you must realize that there is no possible synchronization between master and slave at start-up, so you can get some junk bytes first, so this can explain your received bytes, but you must confirm/infirm the presence of a complete in-order frame, use a debugger and look also to the other bits received in each word - these will tell you if the respective word was junk or not.
As Andy Neil said, application note AN01280 is a purely-software implementation, and I have used it in project. TI LM4F is support hardware 9-bit mode. Using hardware means high efficiency and low power.
We have contact with the local technical support, but they did not have a solution.
What means for you "purely-software implementation"? if you mean by toggling GPIO pins to realize the function then this is not, since you use UARTDTR register to send/receive data and EPS bit is the 9-th bit extension which is added/used when transmitting/receiving and this is hardware. Looking to the UART registers inside both LM3S and LM4F they appear to be the same, except LM4F can offer you a nineth-bit interrupt when the sent address is the same as the slave's. After that anyway you must modify the settings to further accept data (9th bit=0). I also wish to have it set automatically by hardware, but I haven't seen that even on other micro controllers (I do not mention here their names).
Petrei
Petrei,
Thans for your reply.
I read the LM4F datasheet again and I imagine that, once the address byte is set in UART9BITADDR register and 9BIT-mode is enabled in slave, the hardware module should recognize the address. If the address matches, it receives the following data; if NOT, it should drop the address byte and any subsequent data bytes, without notifying the caller. These work should be done by hardware, not by upper software.
We use UART6 for RS485 transmission(SN74LV123ADR, SN65HVD3088ED) in the beginning, but it works unexpectedly.
We try to test the function with UART0 (without 485 driver chip), and something changed. Master sends an address byte and some subsequent data bytes. Slave receive the address byte, and UART_INT_9BIT interrupt is triggered indeed, but slave cann't receive any data.
OK, you are at half way to succeed - what I would do is the following (from the slave point of view):
When you received the whole frame and need to transmit, then enable only transmit interrupts and send first an address then data (this means to play with EPS bit). After transmission enable again the UART_INT_9BIT.
Thank you for your reply. We now use it like that way you suggest, it seems working properly at present. But I think it's just a temporary solution, because the logic is complex and error-prone.
Kim Shieh // // Wait until the FIFO is empty and the UART is not busy. // while(HWREG(ulBase + UART_O_FR) & (UART_FR_TXFE | UART_FR_BUSY)) { //#################### Block here, the logic seems to be error ######################## } //#################### UART_FR_TXFE bit set when FIFO is empty ######################## //
while(HWREG(ulBase + UART_O_FR) & (UART_FR_TXFE | UART_FR_BUSY)) {
//#################### Block here, the logic seems to be error ######################## }
//#################### UART_FR_TXFE bit set when FIFO is empty ######################## //
Of course, one can use 9-bit UART by forcing the parity bits to one and zero manually, but I still think these functions should work as they are the first thing to try when implementing 9-bit UART and they create some confusion.
If it's something I've missed, I'm sorry I spammed my "help requests" through two channels.