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.

LM3S5791: Is it possible to use uDMA with I2C on this processor?

Part Number: LM3S5791

I am using I2C to interface to a UART and would like to offload the CPU to the DMA to perform the transfer on completion. The initial kickoff request is a series of command bytes to the UART which communicates to a remote device, and on completion would be to simply read the data from the I2C UART's FIFO into system memory.

Is there a application note describing this, if it is doable?

Thanks,

Bart

  • Hello Bart,
    I have moved your post to the correct forum for better service.
    -Francis Houde
  • Bart Bartel said:
    I am using I2C to interface to a UART

    Unstated is/are the device(s) containing "I2C" and "UART."      Such proves helpful - does it not?

    Bart Bartel said:
    simply read the data from the I2C UART's FIFO into system memory.

    This writing suggests that your target is a device which "implements I2C to control/access a UART."    (I2C UART's FIFO)    Even "long in the biz" I can't quickly/easily recall an I2C-based IC which (also) controls/accesses a UART.      (and it is doubted that this is, "just me.")       Some clarity IS required - don't you agree?

    Note that the part number listed has long been "retired" - unless you have stock - yours is a "one-board - one-time" project.      Is the "special learning" required justified under such limitation?

  • Yes, more info, I am connecting to an SC16IS750 which then talks over the UART to a remote SC18IM700 and on the other side of that are I2C devices. I would like to know if I can use DMA to manage these transaction. The SC750 to SC700 UART requires an ASCII command set to communicate with the I2C devices hanging of the SC700, but once the request is made, the I2C devices response gets transmitted back to the SC750's FIFO.

    I'm not sure this is a good model for DMA since sending and receiving are both fairly complex, especially the request.

    I hope this helps clarify my issue.

    Thank you,
    Bart
  • Thank you - such input was (much) needed.

    Must note your "silence" as regards the, "End of the Line" for your MCU.     Unless you have sufficient number to "complete your job" - and to "cover safety/repair stock" - your movement to a newer (and improved) version of this vendor's offerings appears a, "Better Path" - don't you agree?      

    Some/many/most  "tech specifics" -tied to your past device -  are likely to become, "Lost or garbled in translation" (tech translation) - should you have to switch (later) to the newer MCU...leading to dreaded, "double effort!"       Our firm still has many LM3S (and LX4F) devices (yet not yours, unfortunately) - and face this "calculus" (both for ourselves & clients) upon a reasonably regular basis...

  • We are locked into this MCU, we have the quantities we need to ship and support. I don't think switching MCU's is an option at this point in our FAA certification efforts.
  • Our firm is among the few which still offers design support (paid support) for the LM3S series.      And we too have produced product and/or components (always prefer components) which are subject to Regulatory Agency directives/approvals.         IIRC - for parts such as yours - a "history/chain of custody" documentation (may) be required.       (intends to insure that the devices were - at all times - properly handled/safe-guarded.)

    If it were me - I'd "Switch to this vendor's "best match" MCU - purchase five or so (ideally Eval Kits) and "Prove the feasibility of your design" in this manner.       Your past MCU is no longer supported (or is nominally so) - newer devices - in stark contrast - are highly & efficiently supported by skilled/trained vendor staff.       (who have access to "insider info.")

    Once your "mission's accomplished" w/the new device - you may consider, "Depleting your inventory of the older parts - via "copy/paste and (likely) modification of "new code" to accommodate "old device."

    Silent is "why you believe" you are "locked in" to such an old device - w/limited support - and (likely) lesser performance...      "Adder costs" (design & other) are likely to be incurred w/either (old or new) devices - thus "sticking w/an expired/aging device" may produce, "Just the illusion" of cost-saving!