• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 31 subscribers
  • Views 863 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.

CCS/TM4C123GH6PM: UART : How to read next char from FIFO without removing it ?

Nathalie Guillemain
Prodigy 30 points
Part Number: TM4C123GH6PM
Other Parts Discussed in Thread: ENERGIA

Tool/software: Code Composer Studio

Hi,

Is there an equivalent of Serial.peek() energy function in the TivaDriverLib ?

UARTCharGetNonBlocking get the next char from FIFO but removes it. I need to be able to read it but leave it in the FIFO. How can this be done ?

Thanks

  • 0
    Guru 117855 points

    Hi back,

    May it be noted - WHAT a terrific, thoughtful question!     Very well done!

    Now you don't reveal, 'Why you seek this capability' - yet if 'your need' proves of  'general benefit' - does not that insure WIDER INTEREST?      And the investment of (even greater) time/effort - in your behalf?

    My small group has been tasked w/examining the 'different FIFO schemes' - employed by (multiple) ARM MCU vendors.    

    Thus - should it not be possible - to 'seed' the FIFO w/ 'Highly Recognizable - yet KNOWN  'Patterns and/or Values'  - and then ... attempt to discover, 'How & Where' - such FIFO data  is stored?

    It must be 'hoped' - that should this method uncover the storage (even transient storage) mechanism of the MCU's FIFO - that such 'read and/or copy' of FIFO content (to a "more convenient" user location) - does not - in itself - unload/unpack the FIFO...

    Dawns that a 'simple-minded' method (term used 'loosely') would have you employ that API function ... yet (only) to 'Read & Store' FIFO content -  and to immediately 'follow that' w/a complete RELOAD of the FIFO...    (Credit me - should this work ... I will (otherwise) deny authorship.)

  • 0 in reply to cb1_mobile
    Prodigy 30 points
    Hi,

    Why am I seeking this capabity ?
    I'm trying to port a project that I made on arduino to TM4C123.

    Amongs things, this project interacts with a RS485 bus.

    I've had problems with this bus as the slaves respond very quickly so that arduino was not not able to distinguish between messages from the master and messages from the slave (no pause between messages). The only way I found was each time I meet a '4' (EOT), check whether next char is a '1' (SOH) or a '6' (ACK) meaning end of message has been reached ('4' sometimes appears in the middle a the message).

    On arduino I used peek() function which does this. energia.nu/Serial_Peek.html

    That's why I'm trying a way to do the same.

    I've had a look at the energia peek implentation but it seems that they have rebuilt their own fifo (circular buffer)

    I am very very new to TM4C123.

    Thanks
  • 0 in reply to Nathalie Guillemain
    Guru 117855 points

    Thank you - it proves rare that an 'Arduino' can (possibly) 'out-perform' an ARM device.

    In the broader sense - now that you've identified 'RS485 as being 'in-play' - is not this (exact) challenge one (normally) encountered w/in such RS485 bus transactions?    I can (only) recall the (known) desire to 'Quickly switch the RS485 differential line driver' from transmit - back to receive.    (to avoid - bus outputs' contention!)

    That said - I cannot recall 'multiple messages - arriving without pause - in the 'cascade' - as you describe.     It must be asked - is that 'without pause' message arrival, a 'recognized and/or normal/customary'  RS485,  standard operating procedure?

    That creation of a separate buffer (implemented by another) - either to replace or to augment this MCU's FIFO - does appear a valid approach.

    You've made no mention of (either) of the 2 suggestions - earlier presented.    Have you (already) come to a conclusion - and if so - might you describe your 'reasoning?'

  • 0
    TI__Guru*** 135355 points
    Hello Nathalie,

    I reviewed the device datasheet for how UART FIFO operation is handled for our MCU and cannot find any feature that would allow you to do what you have indicated. The only way to access the data is to read it out from what I can see.

    I like cb1's idea of using a separate buffer to make this possible, where that buffer is filled with UART data and then you are free to 'peek' at it at will to make the determinations you need.
  • 0 in reply to Ralph Jacobi
    Guru 117855 points

    Thank you, Ralph.

    May we ask - have you (any) idea of just where - such 'FIFO' data is stored?    (Staff has seriously 'combed' thru several MCU manuals - not even the 'slightest' of hints - revealed.)

    Your guidance - would be most gratefully accepted - while (springboarding) insight into the FIFO!

    Our idea is to 'Seed the FIFO' with an 'easily recognized' (properly sized) data pattern - and then (simply) search.    (among RAM & MCU Registers)    Such may - or may not - prove (another) means to, 'Expand the Use & Understanding' of the FIFO mechanism - which is almost certain to, 'Raise User Competence & Achievement!'

  • 0 in reply to cb1_mobile
    Prodigy 30 points

    Hi Raph,

    You write : "I cannot recall 'multiple messages - arriving without pause - in the 'cascade' - as you describe.  "

    I am studying communication with several hardwares and I've met many that respond immediately to an incomming message.
    I've met this in RS232, but this is not a problem as answer in not on the same channel.
    On RS485, master and slave data are received on the same channel. I have confirmed on oscilloscope that answer is coming with minimal delay. So that  the while(UARTCharsAvail(UART0_BASE))  doesn't pause at the right place to be able to distinguish between master and slave.

    Anyway I'll investigate other solutions such as having my own fifo.

    Thank for your explanations. I didn't imagine the FIFO was so well hidden !

  • 0 in reply to Nathalie Guillemain
    Guru 117855 points

    It is hoped that your 'studies' and investigations prove 'more precise'  than your, 'recognition of authorship' - noted above...

    The major 'explanations' you note - sprang (not) from Ralph.   (Ralph most properly noted that he 'Could NOT find any feature to meet your objective'  - which while appreciated - was NOT 'Resolving.')

    How you determined - that posting - to have 'Resolved your issue' - proves suspect  - does it not?      And still - the first TWO suggestions (w/in the first responding post here) remain w/out your comment...