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.

TM4C129ENCPDT: 18-bit SPI-like communication?

Part Number: TM4C129ENCPDT

I need to communicate in a manner that resembles SPI Slave with some external equipment. Based on some initial measurements, the communication appears to be in eight 18-bit words at a 10 MHz clock rate. The signals appear to be SPI-like, meaning I am receiving Clock, SS, and Data In, and I need to transmit Data Out.

The TM4C SSI peripheral does not appear to support arbitrary size words (only 8, 16, or 32 bit).

Any ideas on a strategy to deal with this? (Other than bit-banging?)

  • The SSI supports any size word from 4 to 16 bits, see page 1246 of the datasheet. Depending on how the data is stored, you may want to do 18 8-bit transfers or 16 9-bit transfers. Unfortunately, either way you need to do more transfers than will fit at one time in the 8 level FIFO.

  • Thanks. I must have been thinking of another MCU with the 8, 16, or 32-bit transfer limitation. I'll try to experiment with data size.

    Note: I am not (yet) sure if the signals are actually SPI-compliant. If not, then I may need to come back for additional ideas.

    Thanks for your input so far.

  • Greetings,

    twelve12pm said:
    communicate in a manner that resembles SPI Slave -  eight 18-bit words at a 10 MHz clock rate.

    You may consider:

    • TM4C (i.e. 'other') MCUs demand a substantially slowed clock rate when commanded into Slave Mode.    Might that render '10 MHz clock' unreachable?
    • Assuming 'that' Slave's Reduced Clock Rate can be tolerated - would not 'Back-to-Back, 9bit SPI transfers' (w/your Master holding the Slave's 'FSS' level) prove most reasonable?
    • The '8 level FIFO' presents another challenge - it must be read regularly & 'in time' - to prevent FIFO over-flow

    Such requirement (may) be better met via (other) means.     (FPGA - enabling the serial to parallel conversion - comes to mind... and (even) simple, 'cascaded SIPO ICs' - which may better meet your 10MHz data-rate specification.)      

    Somehow - the (earlier) reward of 'Resolved' - seems 'generous...'

  • Hello cb1,

    Good to see you here!

    Quoth the TM4C129ENCPDT datasheet, section 20.3.1:

    "For slave mode, SYSCLK or ALTCLK must be at least 12 times faster than the SSInClk. In slave legacy mode, the maximum frequency of SSInClk is 10 MHz."

    My SYSCLK is 120 MHz so the maximum frequency is 10 MHz. I don't like operating right at the maximum but sadly I have no control over the external equipment that I have to communicate with. Also, I'm not even sure if the communication presented by that fabulous equipment is "compliant" SPI. It may be similar but not quite fit what the SSI peripheral expects. There are various complications here.

    Since I'm being so generous with the green paint...

  • Oh, regarding that FIFO, I think I'll have to use DMA.

    That external equipment communicates with us at some not-quite-consistent intervals, with bursts of several transfers occurring at one time, followed by a lull for a few milliseconds (which seem more like seasons from a microcontroller's perspective). To make matters worse, it seems like such a lull may occur during the middle of a communication, though happily this seems to occur only between "words" (or whatever this external equipment considers to be a "word"), never in the middle of a word.

    Nevertheless this introduces what I consider to be the bane of communication with DMA: Interrupted communications lead to lack of synchronization between master and slave. So in my LIKE-less "Other MCU" slave, I'll need to come up with a way to detect interrupted communications and reset the DMA back to the beginning. If the communication intervals were always consistent, this could be accomplished with a simple timer set to trigger after a slightly longer interval. But because of the (slightly) chaotic nature of the thing, this is made slightly more complicated. It will take some data capture and study to figure out what "the longest" interval might be.

  • Let the generosity (properly) flow then.    (You didn't really expect young staff here (cb1's 'back-room') to 'read' a tattered/yellowed TM4C 'parchment'  (that's what they used back then (prior to 'Like-Less & Other') - did they not?)

    Indeed - your 'distrust' at operating '@ the Max' is well (and historically) founded.

    Would not (another) of your (famed) 'High Noon' (staff demanded that) Scope Caps - 'Free you/your group' - from the burden of 'SPI compliance Judgement?'   Off-loading such 'dirty work' to (others) proves attractive - you must (or should) agree.   (provides even 'more time' for your unique, 'Adult Beverage Creation' - or should that 'Not be mentioned?')

    Be sure to set the 'Fab Equipment's' SPI Clk & SPI MOSI to (slight) variants of your 'green inkwell.'     (Young staff awards 10/10 for such (colorful) originality - two of them are 'expected to regain sight' early 'Next Year.')     [color employed was, 'Unavailable w/in Nature... like the sun - should be 'glanced briefly/indirectly, only!']

    [edit]: this was composed prior to the arrival of your 'latest' (09:13) posting.

    Shifting to that - due to the 'stuttered signal (burped) approach' of that fabulous equipment - and your recognition of the (somewhat) demanding nature of (other MCUs i.e. Like-Less) µDMA - is it not time to adopt the guidance provided w/in the (properly) 'This Resolved' posting?    (first 'resolving?' post listed that which, 'Could not be Done - FAR from Resolving!)

    Use of an FPGA instead - or even (from memory) 'HC595 SIPO ICs' - places 'NO/ZERO Time Constraints upon the 'Arrival of Serial Clock and Serial Data!'    And is not THAT - exactly what you need?

    Much appears that a '2nd Invasion of that High-Noon Inkwell' has been (well) earned.    (We are told that Hawthorne Ave. is (again) crawling - staff did 85MPH coming to our office - (near) empty LSD (Lake Shore Drive) earlier...)   L.A.'s time has (mucho) passed...  (has it too - become 'LIKE-Less' dare we say, 'other?')

  • I am well aware of the magic of FPGAs, but alas the boards were designed and fabricated long ago, and the customer is so happy that he returns frequently to request (and pay for) additional features. So when he says JUMP, we say, "Other? Or LIKE-less?"

    This particular enhancement request was declared "an experiment" from the start. But I would like to make this experiment succeed. We shall soon find out how our Other MCU performs in this Other task...

    P.S., There is no such thing as COLOR in the natural world. It's all in staff's head. Various wavelengths of light enter the eyes, causing varying responses from three cone cell types (L, M, and S), which become encoded into two channels (R-G, B-Y) for transmission down the optic nerve to the brain's vision center, where these two channels are expanded out to four channels (Red, Green, Blue, Yellow). Using this information, the brain assigns colors to things. There's no saying whether one person's green looks like another's. With the use of special equipment, it is possible to see impossible colors: greenish red, yellowish blue, which are different than the result of mixing those colors of paints or inks. The equipment confounds the brain's edge-finding ability, causing adjacent fields of those colors to "mix."

    P.P.S., please encourage young staff to Drive More Carefully in the future! 85 MPH down the city streets of the South Bay area risks all sorts of terrible outcomes. In SPI, fast is good. In driving, you get no points for going fast, only for getting there in one piece and with no LIKE-less scratches in our lovely green paint.

  • twelve12pm said:
    ...well aware of the magic of FPGAs, but alas the boards were designed and fabricated long ago

    And:

    twelve12pm said:
    customer is so happy that he returns frequently to request (and pay for) additional features.

    That is precisely my firm's, 'Claim to Fame.'     (several clients have been w/us for > 10 years...)     Often we are asked to, 'Restore a (still) necessary system and/or key component' - which has gone, 'End of Life' thus proves 'Irreplaceable!'    AND - to add even more to the 'Skill-Level Demanded' - 'Maintain FULL Compatibility' w/the client's (long past) Software!

    That said (and 'common between us') - would not your (existing) offering be 'even stronger' - if you, 'Noted a "New & Improved Method" to more quickly & robustly deliver those 'additional features' (even) capabilities!?'    We've done just that - by developing a small 'Add-On board' - which may be 'Hacked onto client boards' or more simply, 'Dropped into an 'Awaiting Slot' of (most all) of our boards - designed w/the past 5 years!

    Now 'your Add-On board' could contain an FPGA or sufficient 'SIPO ICs' (overcoming 'staggered SPI data arrival') & possibly a small MCU (ideally low pin-count ARM Cortex M0) which serves to 'organize & order' your 'Acquired SPI Data' - prior to (now proper) presentation to your (past) board - fabricated long ago!  

    In your case - this 'Add-On board' "Frees you from the 'high-risk' of Failure" - attributed to that, 'Erratic Fab equipment's SPI' & the limitations imposed by 'other MCUs' in concert w/their demanding µDMA.'    Even better - such boards are likely to be 'Re-Usable' (repeatedly) and when 'fund injection' becomes desirable - VCs (really) appreciate such 'clever re-usability!'    (i.e. Design (nearly) Once - Sell multiple/many times ...)     'Not so much' - endless & varying, highly specific/unique/unanticipated, 'Add-On' (ONE-OFF) board hacks!

    And (Objection-Slayer) now arrives ... Nothing prevents you from, 'Implementing such an Add-On Board' ... while continuing your (hopeful yet challenging) attempt to, 'Beat/Pound/Carve' your (other) MCU into (some) form of 'additional feature accommodation!'     The Add-On board thus serves as a, 'Client Satisfaction Insurance Policy' - which adds (even further) to the 'perceived value' of your delivery!

    Is not your 'Green-tinged' inkwell in danger of over-flowing ... arrives here a (pretty solid) 'lowering justification!'    (Again - only one here has described, "How you CAN ... Not how/why you CANNOT!")

  • cb1_mobile said:

    That said (and 'common between us') - would not your (existing) offering be 'even stronger' - if you, 'Noted a "New & Improved Method" to more quickly & robustly deliver those 'additional features' (even) capabilities!?'    We've done just that - by developing a small 'Add-On board' - which may be 'Hacked onto client boards' or more simply, 'Dropped into an 'Awaiting Slot' of (most all) of our boards - designed w/the past 5 years!

    Now 'your Add-On board' could contain an FPGA or sufficient 'SIPO ICs' (overcoming 'staggered SPI data arrival') & possibly a small MCU (ideally low pin-count ARM Cortex M0) which serves to 'organize & order' your 'Acquired SPI Data' - prior to (now proper) presentation to your (past) board - fabricated long ago!  

    In your case - this 'Add-On board' "Frees you from the 'high-risk' of Failure" - attributed to that, 'Erratic Fab equipment's SPI' & the limitations imposed by 'other MCUs' in concert w/their demanding µDMA.'    Even better - such boards are likely to be 'Re-Usable' (repeatedly) and when 'fund injection' becomes desirable - VCs (really) appreciate such 'clever re-usability!'    (i.e. Design (nearly) Once - Sell multiple/many times ...)     'Not so much' - endless & varying, highly specific/unique/unanticipated, 'Add-On' (ONE-OFF) board hacks!

    And (Objection-Slayer) now arrives ... Nothing prevents you from, 'Implementing such an Add-On Board' ... while continuing your (hopeful yet challenging) attempt to, 'Beat/Pound/Carve' your (other) MCU into (some) form of 'additional feature accommodation!'     The Add-On board thus serves as a, 'Client Satisfaction Insurance Policy' - which adds (even further) to the 'perceived value' of your delivery!

    This idea is interesting for a variety of reasons. Now, we don't have any "Awaiting Slot" where an "Add-On" board should be "Dropped Into" but I think I'll try the following:

    (1) Try to make the existing Other MCU do the task with firmware only, as originally planned.

    This would be accomplished by one of:

    Using the SSI module in "Legacy Mode" to do the trick (and only in "Legacy Mode" because a review of the successful and client-satisfaction-inducing board's schematics and the Other MCU's Errata reveal that SSI1, the only one available for this task, can only be used in "Legacy Mode"), or

    Bending the SSI module to my will through the use of Top Secret Techniques (which means to try all kinds of things until something works), or

    Bit-banging it. Now, I have no idea how quickly the Other MCU can execute a software SPI (or SPI-like) protocol, but I wonder if the GPIO port pins can be read (inputs) and written (outputs) using some crafty combination of DMA and Timers.

    (2) If all else fails, persuade the customer to let us design an adapter, along the lines of your "Add-On Board" idea. One end of this adapter would plug into our successful and client-satisfaction-inducing board's communication port; the other would connect to that "Fab" external equipment.

  • Green-Infused - Day One - Brand New Decade Greetings,

    twelve12pm said:
    This idea is interesting for a variety of reasons.

    Yet if I may redirect your attention - 'beyond interesting' may reveal:

    • Young staff's suggestion is 'Not' a binary one - we often develop 'aspects' of our projects via, 'Multiple, Parallel Paths!'     Krazily efficient - as crafty/motivated staffers are beyond enthused - to prove 'their method' performs BEST!    You may attempt to 'sledge hammer' the MCU into (maybe) some form of compliance while (near) simultaneously following the (pardon) 'likely more enlightened (Add-On) path.'
    • As a manager - you should make the client 'keenly aware' that their past board may be 'Unable to accommodate' this added capability.    (Really - it was Not designed to do so!)    And great time & effort (will) be required - yet may result in unsatisfactory performance - or (worse) 'down the road' failures.    (such results from your 'over-focus' upon 'sledge-hammer tactics' - lessening the time/effort available for 'Properly Designed & Implemented Testing!')     (Even our 'giant clients' - too often - downplay the importance of 'proper & in-depth Test Design!')
    • I cannot recall (ever) - any of our clients - when presented w/this 'Add-On Board' option - being anything other than 'enthused!'    And they indeed 'see & recognize' the 'added value' produced - which (naturally) raises profit potential...
    • Will your 'Top Secret Techniques' (i.e. try everything) prove (at all) efficient - and/or (ever) be used again?     Instead you WILL BENEFIT from the  (more thoughtful) design & implementation of such an 'Add-On Board' - it will force 'strategic design choices' - yielding multiple, technical, 'clarifications & advantages' - sure to prove 'Repetitively Useful.'     And Sellable!

    We fail to see, "Why the client must be 'persuaded' to accept a properly designed Add-On Board."     Such may signal that you've (pardon again) 'under-estimated the 'extent & degree of diffficulty' such "Sledge-Hammered MCU" task demands.'    (and perhaps conveyed that (premature) 'confidence' to the client...)

    Yours appears to be a 'negotiation issue' as much as a technical challenge - again we expect that most 'reasonable' clients will welcome the 'Add-On' approach!    (especially in light of the 'case made' - right here...)

  • cb1_mobile said:

    Yours appears to be a 'negotiation issue' as much as a technical challenge - again we expect that most 'reasonable' clients will welcome the 'Add-On' approach!    (especially in light of the 'case made' - right here...)

    This is correct.
    As I think back to the beginning of this project in 2012, we recommended various things to the customer, but the customer insisted on certain sacred principles, chief among them being "ONE BOARD." I don't know why. Maybe it's concern about board-to-board connections developing reliability issues through vibrations and temperature swings, who knows. Regardless, the "ONE BOARD POLICY" was honored.
    So, the boards, equipment, and who knows what else, should all be arriving here by tomorrow or early next week. (Yes, they need to actually get the equipment to us so that we can work on it.) So, we'll find out how this plays out. I'll keep you and staff posted.
    Meanwhile, let's all enjoy a nice warm cup of GREEN-INFUSED tea. :-)
  • Greetings,

    'TEA' - isn't that (still) a major constituent of 'Boston's Harbor?'    And - when we 'ferry' our UK partners/clients on my sailboat (docked in MDR) anytime (near) summer - they 'burn like your (pardon) horribly managed woodlands.'    (Couple of Sam Adams & having them 'Man the Tiller' - shortly highlights 'Crafts Chain of Command.'    (successfully sailing on (any) of the Great Lakes is WAY HARDER (due to strong lake currents & severely shifting wind) than on your 'peaceful (Pacific)  ocean.')

    Glad that 'Nego' rather than 'Tech Issue alone' - has been agreed.   And you've presented new & useful facts ... yet your 'desired outcome' remains - and (even) your 'One & Only One' client - is likely to respond to 'sound logic.'

    Note that staff & I (have) tried to offer assistance - & my past, 'co-founding, then taking Tech Firm PUBLIC - and 'doing time' @ UCLA Law' - may arm my team w/'beyond usual' insights/experience/methods.    

    We suggest:

    • One board IS preferred - yet at this early stage - cannot be guaranteed to succeed.    You MUST convey this fact - the earlier the better!
    • Your group's time, effort & funds will be required to determine if this 'One board' may succeed.    Has client agreed to pay appropriately for such effort?    (working for 'free' - does not 'keep the lights on!')
    • Again - your proposal of 'TWO Paths' (your 'try everything/one board' ALONG With my staff's suggestion of an 'Add-On Board') should be presented.    You should note that 'both paths may be worked/attacked simultaneously' - with the 'Add-On board' approach offering:
      • Increased capability
      • Increased flexibility
      • Re-use by your firm for (likely) other/similar requests - downstream (by this client and/or others)
      • Almost a 'guaranteed solution' - in contrast to the 'high-risk,' grossly uncertain attempt - forced by the 'One Board sanction.'

    Note that cb1 staff have, 'Committed to the Inevitability of Change!'    All of our boards now include such an 'Over-Flow/Expansion/Change-Welcoming' (optional) Added/Extra-board 'Plug-In!'    As time passes - this extra board (magically) becomes 'more & more capable' - while 'repeatedly' Saving Us from the: Cost, Effort, Time & Expense of (now (almost) needless) Board Spins!

    By properly, 'Alerting your client to the 'element of risk' which their 'One Board Only' approach demands' - while presenting them w/a 'likely more workable alternative' (which may 'Run in Parallel') - most 'reasonable clients' will, 'See the Light!'    Should client 'prove blind' to your presentation of such a 'Thoughtful, Dual (even executed in Parallel) Approach' then you've (at minimum) 'Well covered your bases!'    (i.e. you've 'Lessened the Shock/Surprise' - brought about by the 'One board's (likely) failure!'     Note that clients - and especially investors - HATE (unpleasant) surprise!)

    And - once the Add-On board approach succeeds - you may (then) suggest the (near fool-proof) creation of a 'BRAND NEW SINGLE BOARD - which combines their Old Board AND the 'Add-On' into 'Just one board' - thus complying w/their 'One Board Desire!'    (i.e. you have 'incrementally steered' this (pardon) 'unrealistic client' into a 'Safe Harbor' - even though - especially though - client's eyes/ears were 'Tightly shut!')