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

SCI communication (with DMA?) and varying message lengths

David Sabol
Genius 4850 points
Other Parts Discussed in Thread: HALCOGEN

Hi,

I'm using SCI communication between a TMS570 and an external module.  I'd like to use it in interrupt mode, and potentially incorporate DMA, but I am unsure how to do this properly.

I generated an SCI driver with halcogen, but I am not sure how to incorporate reading messages with varying bit lengths.  The generated receive function has an input parameter for the size to receive.  Do I need to add the size to the beginning of the message, read that in, and then read the number of bytes that it specifies?  Is this possible to do with DMA if I am receiving messages of different lengths?

Thanks,

Dave

  • 0
    TI__Guru 68920 points
    David,

    You mean # of bytes per message correct? Not a varying bit length per word...
  • 0 in reply to Anthony F. Seely
    Genius 4850 points
    Correct. The messages will always be increments of 8 bits, but the number of bytes will vary.
  • 0
    TI__Guru 68920 points

    David,

    Ok then:

    David Sabol said:
    Do I need to add the size to the beginning of the message, read that in, and then read the number of bytes that it specifies?  I

    I think you are asking what sort of protocol or packet you should define on your UART to carry messages with variable length payloads.

    If so yes you do need to come up with something like you suggest but it's well above the level of HalCoGen and the MCU.   You really have to decide this yourself. 

    David Sabol said:
    Is this possible to do with DMA if I am receiving messages of different lengths?

    Not really,  because there is no way to count how many bytes have been received.  You can get 1/2 block interrupts out of the DMA but you can't find out if you are 3/4 of  the way through a block..   So you'd wind up possibly waiting indefinitely for an interrupt if no additional messages come in to push you over the 1/2 block boundary.    This is a known weakness in the SCI / DMA.

    For this reason you might consider going with a fixed length packet if you can.   Although again there's some weakness there if the packet were ever to get interrupted. 

    Best to not use DMA w. SCI IMO.

  • 0 in reply to Anthony F. Seely
    Genius 4850 points
    Great, thanks for your help and clarifications.
  • 0 in reply to David Sabol
    Expert 1395 points
    You can 'easily' use DMA for that purpose, requires "a bit" coding and dodging one pit fall. I have it running.
    - practically HALCoGen does not offer any support for this method (well, it offers sciinit() and dmainit() :))

    Make RX side continuous ring-buffer and read the progress of the DMA RX (CTCOUNT-register) either periodically and/or route SCI RX-line also to N2HET module pin and monitor line there and generate IRQ from N2HET if line is idle long enough.
    - make long enough ring buffer so that it can't even theoretically fill between pollings
    - suitable method depends on your protocol/timing requirements and how you are transferring data over UART (requiring at least certain idle period between messages (like 3 chars) is very simple and effective way recognize packets without knowing anything about the content).

    Another down side is that from N2HET module you cannot flag or read the current DMA progress, so when you are processing the IRQ in the Hercules side, you cannot know what was the DMA count at that time when IRQ was generated. If your UART is fast and IRQ service latency long the other party may have sent more data and it will be tricky trying to separate new message from old message (especially if there will be bit-errors in the UART bus, so won't get valid messages to determine which byte belongs to which message).
    - it may/should be possible to count chars in the line with N2HET and then read that information when handling the N2HET IRQ to get only bytes belonging to one message, if this is possible it would require even more N2HET coding... That way you would have very robust non-CPU intervention requiring low level driver. I haven't done this even we are running with 2M speed because we have half-duplex bus so another party can't send more data immediately after a message. And I'll guess that if counting bytes is possible with N2HET, it can't keep up if running fast enough or does not have anymore enough instructions to do what would need to be done.

    NOTICE (pit fall): you need to have "dummy" DMA channel to do something stupid (like copying value from one address to another) just to get your primary RX channel out of the execution in order to updates its progress counter(s) (CTCOUNT register for example).
    - see TRM desctiption for CTCOUNT register (effects whole register even though restriction mentioned weirdly only in CETCOUNT field) and my post in this forum...