This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CCS/TM4C129ENCPDT: Does the TM4C129 support 9-bit serial protocol? Specifically for the MDB (Multi-drop Bus) using for communications in Vending Machines

Part Number: TM4C129ENCPDT

Tool/software: Code Composer Studio

Hello,

     We are in need to add MDB support to our TM4C129ENCPDT based controller board.  For this we need to use the 9-bit serial protocol where the ninth bit is used to identify a slave device.  So  I want to know if the hardware/libraries support the 9-bit serial protocol.

Thanks,

Bill

  • It is (well) known that the lesser, yet more popular (TM4C123) MCU supports "9-bit" - thus it is reasonable to believe that the more advanced MCU (yours) does as well.

    I've been at this (and predecessor MCU forum) longer than most - have no recollection of viewing "library support" for "9-Bit" operation.     (in fairness - that is a relatively minor usage - for most here)    Personally - I'm "on your side" - believe that 9th Bit brings (much) to the table.

    I've no knowledge of any specific "MDB" support - yours is the first mention of MDB which I recall...

  • For those interested in, "UART, 9-Bit operation, here is a "true copy" from the TM4C123 MCU Manual - covering this.     Level of detail is "surprising" - and appreciated.

    14.3.7 9-Bit UART Mode
    The UART provides a 9-bit mode that is enabled with the 9BITEN bit in the UART9BITADDR register. This feature is useful in a multi-drop configuration of the UART where a single master connected to multiple slaves can communicate with a particular slave through its address or set of addresses along with a qualifier for an address byte. 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. The address can be predefined to match with the received byte and it can be configured with the UART9BITADDR register. The matching can be extended to a set of addresses using the address mask in the UART9BITAMASK register. By default, the UART9BITAMASK is 0xFF, meaning that only the specified address is matched.

    When not finding a match, the rest of the data bytes with the 9th bit cleared are dropped. If a match is found, then an interrupt is generated to the NVIC for further action. The subsequent data bytes with the cleared 9th bit are stored in the FIFO. Software can mask this interrupt in case μDMA and/or FIFO operations are enabled for this instance and processor intervention is not required. All the send transactions with 9-bit mode are data bytes and the 9th bit is cleared. Software can override the 9th bit to be set (to indicate address) by overriding the parity settings to sticky parity with odd parity enabled for a particular byte. To match the transmission time with correct parity settings, the address byte can be transmitted as a single then a burst transfer. The Transmit FIFO does not hold the address/data bit, hence software should take care of enabling the address bit appropriately.

  • cb1_mobile said:
     Personally - I'm "on your side" - believe that 9th Bit brings (much) to the table.

    For existing protocols, yes I'd agree. It looks like the original request fits that case.

    For new protocols/bespoke applications CAN is superior (As fast or faster. Easy to use, especially if you dispense with Higher Level Protocols (HLP) ) in many applications and I would think a vending machine would fall into that category. I suspect, however, that there is existing 9 bit serial infrastructure they are working to stay compatible with.

    Robert

  • Indeed friend Robert - indeed.

    Note that poster received response w/in 11 minutes of request - response has grown (now) to 3 - and (only) our poster knows the "fine/full" detail...