• State Resolved
  • Locked Locked
  • Replies 33 replies
  • Subscribers 33 subscribers
  • Views 6248 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

EK-TM4C1294XL: Question about UART 9 bit APIs

Priya Nadathur70
Expert 2795 points
Part Number: EK-TM4C1294XL

UART 9 bit mode, used for MDB.

EK1 uart transmits periodically (master) every few seconds in 9 bit mode, LED is seen blinking,

byte is visible on the scope.

EK2 uart receives (peripheral) in 9 bit mode, LED is blinking.

 

Currently in the transmitter EK1 project, both these APIs contain address x43 which is the

assigned address for peripheral EK2. I want more clarity on the addresses in these two APIs.

UART9BitAddrSend

UART9BitAddrSet

 

 

If EK2 uart needs to send back a different byte to the master (EK1), how does this work in

9 bit mode, specifically with the UART9BitAddrSend and UART9BitAddrSet APIs?

 

Thanks,

Priya

 

  • 0
    Guru 27665 points

    Priya Nadathur70 said:

     If EK2 uart needs to send back a different byte to the master (EK1),

    Does it need to be an 'address'? If so then you use UART9BitAddrSend which will set the flag bit, otherwise you use the normal UARTCharSend which will leave the flag bit clear.

    Priya Nadathur70 said:

    how does this work in

    9 bit mode, specifically with the UART9BitAddrSend and UART9BitAddrSet APIs?


    UART9BitAddrSet is only of concern to the receiving device. It determines after what 9 bit address you will start receiving (and that you will interrupt on).

     

    Robert

    I take it from this you've figured out the interrupt response to the 9 bit interrupt?

  • 0 in reply to Robert Adsett
    Expert 2795 points
    I take it from this you've figured out the interrupt response to the 9 bit interrupt?

    Using this in the UART receive interrupt handler got the EK2 LED blinking:
    if( ( (UART_INT_RX & ui32Status) == UART_INT_RX ) || ((UART_INT_9BIT & ui32Status) == UART_INT_9BIT ) || ( (UART_INT_RT & ui32Status) == UART_INT_RT) ){

    In the EK2 project (peripheral), I have the following APIs:
    ROM_UART9BitAddrSet(UART5_BASE, 0x43, 0xFF);
    ROM_UART9BitEnable(UART5_BASE);

    ROM_UARTFIFODisable(UART5_BASE);

    //
    // Enable the UART interrupt.
    //
    ROM_IntEnable(INT_UART5);

    ROM_UARTIntEnable(UART5_BASE, UART_INT_RX | UART_INT_RT | UART_INT_9BIT);


    I am using ROM_UARTCharPutNonBlocking to send back a different byte from EK2 to EK1 inside the uart receive interrupt handler. But I am unable to see the EK2 transmit uart byte on the scope. I'm not clear where the set up is missing something.

    Thanks,
    Priya
  • 0 in reply to Priya Nadathur70
    Guru 27665 points

    You still need to figure out </>

    It would help to see the contents of this loop

    if( ( (UART_INT_RX & ui32Status) == UART_INT_RX ) || ((UART_INT_9BIT & ui32Status) == UART_INT_9BIT ) || ( (UART_INT_RT & ui32Status) == UART_INT_RT) ){

    I suspect you are treating all three interrupt sources identically. You cannot do that.

    Robert

  • 0 in reply to Robert Adsett
    Expert 2795 points
    I can add a dummy loop like this:
    if ((UART_INT_RT & ui32Status) == UART_INT_RT){
    while(ROM_UARTBusy(UART5_BASE))
    {
    // Do nothng
    }
    }

    I still don't have clarity on how the peripheral to master transmission works in 9 bit mode.
    MDB requires the peripheral to set the mode bit on the last byte to signal end of transmission
    and not otherwise. How to do this?

    Currently, there is no difference in the processing when the peripheral (EK2) gets either the
    UART_INT_RX or UART_INT_9BIT. It transmits a different byte back and blinks the LED in both
    cases.

    I need a separate power supply for one of the EKs to be able to run the debugger on the other EK.
    I currently don't have this set up.

    Thanks,
    Priya
  • 0 in reply to Priya Nadathur70
    Guru 27665 points

    Priya Nadathur70 said:
    I can add a dummy loop like this:
    if ((UART_INT_RT & ui32Status) == UART_INT_RT){
    while(ROM_UARTBusy(UART5_BASE))
    {
    // Do nothng
    }
    }

    You probably want to flag your application that you've received your address byte. Otherwise that's a good start.

    Priya Nadathur70 said:
    I still don't have clarity on how the peripheral to master transmission works in 9 bit mode.
    MDB requires the peripheral to set the mode bit on the last byte to signal end of transmission
    and not otherwise. How to do this?

    UART9BitAddrSend

    Priya Nadathur70 said:
    Currently, there is no difference in the processing when the peripheral (EK2) gets either the
    UART_INT_RX or UART_INT_9BIT. It transmits a different byte back and blinks the LED in both
    cases.

    As mentioned, you will need to change this.

    Robert

  • 0 in reply to Robert Adsett
    Genius 4355 points

    About using UART9BitAddrSend:

    Say,

    EK2 peripheral address 43.

    EK1 peripheral address 21.

    Inside EK1 code, UART9BitAddrSend should have 43, UART9BitAddrSet 21?

    Same way in EK2 code, UART9BitAddrSend should have 21, UART9BitAddrSet 43?

    I think I already tried this combination. 

    I did get to the point where one byte sent from EK2 was visible on the scope, but 

    it would not repeatedly trigger. For this, I used only address 43 in EK1 code and also in EK2 code, 

    I did not have  UART9BitAddrSend in EK2.

    Thanks,

    Priya

  • 0 in reply to Priya Nadathur
    Genius 4355 points
    I wanted to add, in the MDB document there is no address for the master, only the peripheral.
    The peripheral uses a mode bit in addition to the 8 data bits. This bit will be set under certain
    communications between peripheral to master. I'm not clear how to set this bit and how this
    makes the 9 bit uart transmission different from 8 bit mode with parity.
  • 0 in reply to Priya Nadathur
    Guru 117855 points

    Priya Nadathur said:
    in the MDB document there is no address for the master, only the peripheral.

    Might you provide a link to that (MDB document) so that we may read/review?      

    Should the "mode bit" differ from the "address bit" - we must know which bit serves as, "mode bit."    (it is assumed it is one of the 8 "normal" data bits - which (likely) prevents the transfer of binary data - or (even) data ≥ 128 (decimal).)

    It is suspected that you could learn much by "spying" upon (successful) communications upon this MDB bus...     In the absence of such (successful) communication - there (must) be "transaction examples" which well illustrate the protocol - and provide various data exchanges which you may (then) model...

  • 0 in reply to Priya Nadathur
    Guru 10570 points
    The ninth bit, the parity bit and the address bit are different names for the same bit.

    you can emulate 9 bit mode with parity modulation, substituting mark and space parity as required.

    The nine bit mode in the TM4C appears to offer two things. Automatic recognition of the defined address, ignoring all received values until after (note after) the address is received. Second it offers an easy way of setting the address bit when sending, the SW takes care of making sure the FIFO is empty before sending a byte with the ninth bit set.

    Robert
  • 0 in reply to Robert Adsett72
    Guru 10570 points
    And mode bit is another name for the address bit.

    Robert
  • 0 in reply to Priya Nadathur
    Guru 10570 points
    I did tell you how to set the ninth bit earlier, you are already using that method.

    Robert
  • 0 in reply to Robert Adsett72
    Guru 117855 points
    Thank you for that - multiple names for the (same) bit (somehow) seem to invite confusion.
    Following this poster's struggle - RS485 rises sharply in value/ease of use...
  • 0 in reply to cb1_mobile
    Guru 27665 points

    cb1_mobile said:
    Thank you for that - multiple names for the (same) bit (somehow) seem to invite confusion.

    They do at that.

    This standard appears to date from quite early in the history of micros and developed its terminology in isolation.

    Robert

    BTW, if you are using a 9-bit protocol that requires you to both recognise 9-bit values and distinguish between them (i.e. a protocol with a broadcast address, or that uses different 9-bit codes to distinguish packet types rather than address etc...) then it appears the 9-bit support on this processor is useless.

  • 0 in reply to Robert Adsett
    Expert 2795 points
    Thank you for all your replies. The processor has to do MDB and it is possible the 9 bit mode is used in a limited way, regular UART mode is needed at other times. It will also have to do ccTalk, and RS485 was mentioned with it. Maybe this will make implementing MDB easier as well, at this time I don't understand all there is.

    I do have the UART address send working the way it should for both Tx and Rx. However, transmitting the ACK byte in response to a Rx byte doesn't seem to work. I set the Tx interrupt as well, however I want this only conditionally triggering (after a receive). I can't seem to get a conditional tx interrupt to trigger by enabling and disabling the tx interrupt.

    Thanks,
    Priya
  • 0 in reply to Priya Nadathur70
    Guru 27665 points

    Priya Nadathur70 said:
    It will also have to do ccTalk, and RS485 was mentioned with it

    RS-485 and 9-bit serial are orthogonal techniques. You can use 9-bit with or without RS-485 and you can use RS-485 with or without 9-bit.

    Priya Nadathur70 said:
    I can't seem to get a conditional tx interrupt to trigger by enabling and disabling the tx interrupt.

    The transmit interrupts don't work that way. They only trigger when the FIFO passes the trigger threshold. They do not continuously trigger once below. It is necessary to fill the FIFO above the threshold before the transmit interrupt will trigger.

    Robert

  • 0 in reply to Robert Adsett
    Expert 2795 points
    What is the best way to setup a UART transmit only following a uart receive?

    Thanks,
    Priya
  • 0 in reply to Priya Nadathur70
    Guru 27665 points

    Priya Nadathur70 said:
    What is the best way to setup a UART transmit only following a uart receive?

    I'm pretty sure that's not what you want. 

    You want to send a reply packet after receiving a packet. That's simpler problem. You know when you've received a packet, you can then send the reply.

    Robert

  • 0 in reply to Robert Adsett
    Expert 2795 points
    OK, I can fit in the uart receive and transmit packets as separate parts of the main loop.

    Master to peripheral MDB communication will always involve an address byte. However, peripheral to master the mode bit may or may not always be set. How to account for this in 9 bit mode? Even in 8 bit mode this will mean opposite parity in transmitting and receiving.

    I'm not sure I have the UART_9BitAddrSet and UART_9BitAddrSend set up correctly in the transmitter and receiver code. I will revisit what the LED is doing.

    Thanks,
    Priya
  • 0 in reply to Priya Nadathur70
    Guru 27665 points

    Priya Nadathur70 said:
    However, peripheral to master the mode bit may or may not always be set. How to account for this in 9 bit mode?

    I don't think you can on this processor. Which means you have to emulate 9 bit mode with parity modulation for the master.

    Robert

  • 0 in reply to Robert Adsett
    Expert 2795 points
    Is this where the app note comes in? AN01280–August 2010 Usinga9-bitSoftwareUARTwithStellaris®Microcontrollers.
    Are there code snippets on how to access the UART Line Control register you can provide here?

    Thank you,
    Priya
  • 0 in reply to Robert Adsett
    Guru 117855 points

    Robert Adsett said:
    RS-485 and 9-bit serial are orthogonal techniques.

    So powerful & explaining/bounding is that sentence!     (brings to mind the "joy" of a performance sports car - and (brutal & enforced) local speed laws - also orthogonal.)

    So steep a learning curve casts doubt on, "This & only this" (MDB) solution.

  • 0 in reply to cb1_mobile
    Guru 117855 points

    Another idea dawns - as you've identified the "limitations"of MCU's here (in this limited role) - might poster's "discovery of those MCUs which are (already) successfully "in play" w/MDB" - provide needed insights?

    First recognition - then study of the features & special capabilities which "enhance" MDB's "ease of operation" (there must be some) would serve to highlight the requirements which MDB forces upon (hapless) MCUs...

    Minus this "inside knowledge" (achieved via focused, comparative, data collection) - poster (appears) to be shooting (very much) "in the dark."

  • 0 in reply to Priya Nadathur70
    Guru 27665 points

    Priya Nadathur70 said:
    Is this where the app note comes in? AN01280–August 2010 Usinga9-bitSoftwareUARTwithStellaris®Microcontrollers.
     

    Damdifino. I haven't read the app note.

    Priya Nadathur70 said:
    Are there code snippets on how to access the UART Line Control register you can provide here?

    Nope, I don't do much with the UART currently.

    Robert

  • 0 in reply to cb1_mobile
    Guru 27665 points

    cb1_mobile said:
    Another idea dawns - as you've identified the "limitations"of MCU's here (in this limited role) - might poster's "discovery of those MCUs which are (already) successfully "in play" w/MDB" - provide needed insights?

    It might, I've seen other micros whose 9-bit modes might better suit.

    Parity modulation at 9600bd shouldn't be beyond this processors capabilities I would think, but it may be more than the OP wants to tackle.

    cb1_mobile said:
    First recognition - then study of the features & special capabilities which "enhance" MDB's "ease of operation" (there must be some) would serve to highlight the requirements which MDB forces upon (hapless) MCUs...

    Minus this "inside knowledge" (achieved via focused, comparative, data collection) - poster (appears) to be shooting (very much) "in the dark."

    I think it will, in either case, have to be a slow stepwise build-up of capabilities.

    Robert

  • 0 in reply to Robert Adsett
    Expert 2795 points
    It might, I've seen other micros whose 9-bit modes might better suit.

    Can you name some of these micros?

    Parity modulation at 9600bd shouldn't be beyond this processors capabilities I would think, but it may be more than the OP wants to tackle.
    I will keep working on this, appreciate the help.



    Priya
  • 0 in reply to Priya Nadathur70
    Guru 27665 points

    Priya Nadathur70 said:
    It might, I've seen other micros whose 9-bit modes might better suit.

    Can you name some of these micros?

    No. Sorry, I cannot. I only noted the features in passing.

    Robert

  • 0 in reply to Robert Adsett
    Guru 117855 points

    (this directed to poster Priya!)    (even though I clicked upon a past Priya post - hallowed/(claimed) forum (upgrade?) responded to Robert...)

    Hey! Wait one (bloody) second - twas cb1 who, "Suggested the identification of (other, successful MCUs) able to exploit "MDB."
    Surely poster Robert DESERVES his "Verify" - yet that verified post includes (substantial) cb1 quotes - where is the justice?   (such attention to detail IS required - to succeed w/MDB...) 

  • 0 in reply to cb1_mobile
    Expert 2795 points
    cb1-- I don't think they will change the MCU in the application for the sake of MDB. Since other MCUs were
    mentioned I asked. I believe Robert has been answering many of my questions and I clicked verified on one of them. I don't
    click verify on every response. I'm happy to click verified on your response too, thank you!
  • 0 in reply to Priya Nadathur70
    Guru 117855 points

    That's most fair - thank you - appreciated.       Robert is clearly best based re: MDB.    

    That said - I would suggest you employ the following to better enhance your investigation:

    • search for and discover (then log) the MCUs (already) employed by the "MDB leaders."
    • study the "Accommodations those MCUs make in favor of MDB."
    • carefully compare/contrast (those MDB succeeding MCUs) against those here - focused (of course) upon MDB "accommodations."
    • should the MDB accommodations of (already MDB succeeding) MCUs far outnumber/outweigh those of MCUs here - you must then "weigh" the time/effort/expense of "massaging the reluctant MCUs into service."
    • while "counter intuitive" - your review of (other) ARM MCUs (again wrt to MDB focus) is almost certain to reveal, "productive techniques employed - to gain (some) MDB accommodation."    Reliance upon ONE source only is unlikely to "fully reveal" the "inventive efforts of the MCU field in general" - which deprives you of (very) needed ideas, methods & work-arounds...

    it should be noted that you've (not yet) revealed why "MDB" is such a requirement - AND if a similar device (which escapes MDB) may (better) serve your needs!    There is "no guarantee" that your investment of further time/effort in the pursuit of "MDB" will "pay off."    (I am not attempting to discourage - am trying to present superior (more expansive) methods - which firm/I "know to prove effective...")

  • 0 in reply to cb1_mobile
    Expert 2795 points
    MDB is used to control the coin unit in the application. ccTalk for the coin hoppers.
    Thanks,
    Priya
  • 0 in reply to Priya Nadathur70
    Guru 117855 points

    While that (MDB) is surely "true" - have you (fully/properly) investigated to see if that (MDB) is (and remains) the ONLY means to control the "coin unit?"
    I'd ask - why was MDB chosen - how firm is that commitment?      Surely (other) faster/easier methods can succeed as well - is that not true?

    You are "silent" wrt (with regard to) the multiple, "investigative suggestions just offered" - do you believe those (added insights) to be w/out value?

  • 0 in reply to cb1_mobile
    Guru 27665 points

    cb1_mobile said:
    it should be noted that you've (not yet) revealed why "MDB" is such a requirement - AND if a similar device (which escapes MDB) may (better) serve your needs!  

    From what I've seen, an I've only done a quick scan, it appears that MDB and cctalk dominate vending machine networks.

    I suspect something CAN based might be better suited to this use, but those have the history and MDB at least has an open standards document.

    Robert

    I've only done a surface scan of MDB as well but no real expert has shown up.

  • 0 in reply to Robert Adsett
    Guru 117855 points

    R.A. " But I play one on TV."

    And - we are told - rather well...
    Yet my "high rise, Chicago (lake view) office" - only on occasion - can receive station "CHU" (dominion observatory) or your Canadian broadcast... Ratz!

    (note that "you" have provided the "missing" operative info detailing the "why MDB!") Armed w/this new info - and simple investigation of (methods/capabilities of (already) succeeding MCUs) our poster is bound to glean MORE required info - despite your best (broadcast) & other efforts...