• State Resolved
  • Locked Locked
  • Replies 21 replies
  • Subscribers 34 subscribers
  • Views 1989 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.

TM4C123GH6PM: Controlling of 12 Digital Bits at rate upto 5MHz.

Suraj Nigave
Prodigy 180 points
Part Number: TM4C123GH6PM
Other Parts Discussed in Thread: EK-TM4C1294XL

Hello all,

In my project, I want to control 12 digital bits (All 0's to all 1's) at rate upto 5Hz (It may be 1MHz, 2MHz, 3MHz, etc.)

Note :- There is no relation of Analog to Digital conversion, ADC, Sampling rate, etc.

Please suggest me which micro-controller should I use for this application?

Micro-Controller has to work on 1.8Volts or 3.3Volts DC power supply.

Just now, I have evaluation kit of TM4C123, so that I'm trying to do job done on same.

But you can also suggest me other Micro-controllers, Counters, Timers, etc.. to job done.

For reference I'm attaching the system requirement block diagram.

Thank you.

  • 0
    Genius 3850 points

    12 bits that are all 0s or all 1s? Wouldn't that be one bit fanning out to 12 inputs?

    If you want to output some 1s and 0s on a pin at upto 5Mhz, pretty much any modern mcu can do that. Your tm4c is certainly one of them.

  • 0 in reply to Danny F
    Guru 117855 points

    Danny F said:
    12 bits that are all 0s or all 1s? Wouldn't that be one bit fanning out to 12 inputs?

    Excellent!      It may prove advantageous to "buffer" prior to fanning out to that degree.     However - the "usefulness" of such "fanning" is limited - and poster did note his desire to, "Control 12 BITS!"

    Part 2 of your response - I'm not so sure.      "It is in the realm" -  although questionably stated - that poster seeks "individual control" of each of the 12 bits.       Should that prove the case - and "multiple bits" are to change in unison - the "certainly" aspect of MCU capability - may be negated...     (I would "take book" that poster seeks, "Individual bit control.")     (but only in Las Vegas - where such is legal)

  • 0
    TI__Guru 72500 points
    Hello Suraj,
    I interpreted your question differently from Danny and CB1. Please clarify for us. Are you trying to make a digital 12-bit counter that outputs 12 lines in the sequence 000000000000, 000000000001, 000000000010, 000000000011 ... 111111111111? If this is the case, it can be done with the GPIO pins, but there is a catch. The pins will not all change state at exactly the same time. The GPIO ports are 8-bits wide, and those 8-bits will change state at relatively the same time, but a pin going high to low may change state faster than a pin going low to high or the other way around. What is more serious is that to change 12 pins requires writing to two ports. The transition from 000011111111 to 000100000000 will look like 000000000000 or 000111111111 for a short time. How will your sub-system react to the pin transitions? Is there some additional signal to tell your sub-system when the 12 signals are valid?
  • 0 in reply to Bob Crosby
    Guru 117855 points

    Bob,

    Excellent addition - the difference between "pin transitions" (rise/fall) was clearly "missed" by me - possibly by Danny as well.

    The addition of a "strobe signal" - as you well noted - would allow the "2 Port MCU" outputs to present all 12 bits, "In Sync - w/the strobe."      And that - even though - especially though - the bit data arrives in a "time-staggered" (asynchronous) progression.

  • 0 in reply to cb1_mobile
    Guru 27665 points

    cb1_mobile said:
    The addition of a "strobe signal" - as you well noted - would allow the "2 Port MCU" outputs to present all 12 bits, "In Sync - w/the strobe."      And that - even though - especially though - the bit data arrives in a "time-staggered" (asynchronous) progression.

    At that point, it's pretty much looking like a standard memory bus. The simplest solution would be to use a device that supported a memory bus.

    OTOH, if it really is a counting sequence then a counter (with synchronous output) would be an easy thing to add. I suspect from the description that the bus is closer to what's required though.

    Robert

  • 0 in reply to Robert Adsett
    Guru 117855 points
    Indeed - I too suspected that an elementary counter IC (or two - operated in cascade) may "best satisfy."
    As too often arrives here - sufficient "vagueness" w/in the request - forces "everything under the sun" - onto the playing field.
    While one here stated, "certainly 5 MHz could be obtained" that proves (only) possible under the most base (and least useful) requirement...
  • 0 in reply to Bob Crosby
    Guru 55913 points
    Hi Bob,

    Could not the poster simply use the External Peripheral Interface (EPI) 8-/16-/32- bit dedicated interface for peripherals and memory?
  • 0 in reply to Genatco
    Guru 117855 points

    BP101 said:
    Could not the poster simply use the External Peripheral Interface (EPI) 8-/16-/32- bit dedicated interface for peripherals and memory?

    No need to torment vendor's Bob w/this one.      Poster identified his MCU as '123 - I opened that MCU Manual - searched for "EPI" - NO "EPI" Chapter nor Segments resulted!

    What did reveal was the following:

    Items in highlight confirm - EPI was "Not included" w/in the '123.   (it IS a simpler, lower cost device)

    This - along w/Zero "EPI" Chapter/Segments - rather strongly - suggests that the "EPI" is  "Non-Resident" w/in poster's  '123 MCU...

    Thus - "NO" ...  poster could not, "simply use" a "non-existent Peripheral.      (EPI in this case - )

  • 0 in reply to cb1_mobile
    Guru 55913 points
    And that would suggest the poster has selected the wrong MCU for the job.
  • 0 in reply to Genatco
    Guru 117855 points

    Not necessarily - much depends upon poster's application - which as presented here (per usual),  "Lacks sufficient detail."

    Further - those EPI bits you propose are NOT LATCHED - are they?       Should poster seek "latched" - another chip would be required.

    Your EPI idea DOES provide the ability to overcome this vendor's,  "8 bit per Port Limitation" - long since eclipsed by others...      (even without - especially without - "EPI-Like" implementation ... i.e. via  "wider GPIO Ports!")

  • 0
    TI__Guru 72500 points
    Hello Suraj,
    I have not heard back from you. I assume you have resolved this issue. If not, please just respond to this thread and let me know.
  • 0 in reply to Bob Crosby
    Guru 117855 points

    Or ... We "come here" - not to praise this thread - but to bury it...      (quote's inversion - deliberate)

    When posters,  "Go SO long quiet - they deserve the "extra-effort" - required to re-launch!"

  • 0 in reply to Bob Crosby
    Prodigy 180 points
    Hello Bob,
    I'm really sorry for not responding to post.
    This will not happen again from my side.
    As of now my problem is solved.

    Sorry once again.
    Regards,
    Suraj
  • 0 in reply to Suraj Nigave
    Guru 117855 points
    May the "record reveal" that, Each/Every post marked "Verified" - Did NO SUCH Thing!
    Poster's "solving" - even after MANY helper attempts to GUIDE - remains UNKNOWN! (and THAT should be Verified!)
  • 0 in reply to cb1_mobile
    Prodigy 180 points

    Hello cb1_mobile,

    I'm using this type of forums first time, I'm new to this platform, I understand so many helpers are guiding me to solve my problem and It is bad thing to not respond them.

    I commit the mistake in this post by not responding.
    Now I understood my mistake and will not commit it again.

    Please forgive me as this is the first time I'm doing so.


    Thank You,
    Regards,
    Suraj

  • 0 in reply to Suraj Nigave
    Guru 117855 points

    Thank you - it is "good" that you returned and responded.   Many "came to your aid" - silence (may) be seen as "disrespect" - you now know this.

    No "apology" is sought - however the Green Verify should be awarded ONLY to those posts - which you believe - guided you to your (hopefully) satisfied objective.    The two posts you, marked in Green  (yours & Bob's) - revealed  "Nothing CLOSE to a solution!" 

    One of Bob's earlier posts WAS "solution oriented" - as was Robert's - and perhaps one of mine.     It is (those) postings - which provided technical assistance & guidance which are "Candidates for Verification!" (and not posts which announce your success - or the closing of the thread - such makes NO SENSE!)        (as I believe - someone here noted...)

  • 0 in reply to cb1_mobile
    Prodigy 180 points

    Thank you very much for explanation...
    Now I get it, to which post I have to mark as "This resolved my issue"

    I will take care of this from next time.

  • 0 in reply to Suraj Nigave
    Guru 55913 points
    Please let us know how you make the TM4C123Gxx produce synchronous digital peripheral outputs! I sometimes forget this is a multi MCU forum since so many people post issues about EK-TM4C1294XL launch pads.

    CB1 post shows the TM4C123G MCU is not capable to make synchronous GPIO occur without adding more hardware.
  • 0 in reply to Genatco
    Guru 117855 points

    Mon ami - it is (highly) suspected that poster's (claimed) fix was more "theoretical" than real.    (i.e. like MCU "Security" - perhaps an over-promotion...)
    5MHz Sync clocked -  "Controlled, 12 bit data bus" - is FAR (very far) from achievable w/this MCU.

    You will note that "No description of "How this difficult problem" was solved - appeared.      Is it not likely that "problem is solved" by, "No longer considering this challenge,  "As a problem?"

  • 0 in reply to Genatco
    Prodigy 180 points

    I'm not using TM4C123 micro-controller.

    We decided to go with FPGA Implementation as we want to do multiple tasks (Other than just controlling the 12 Digital bits).

    We have launchpad of TM4C in our lab, so we tried to do things on this micro-controller but it seems it is not possible to do all required tasks on same micro-controller.

    Thank You

  • 0 in reply to Suraj Nigave
    Guru 117855 points

    Suraj Nigave said:

    I'm not using TM4C123 micro-controller.    We decided to go with FPGA Implementation...

    And that ... was not entirely unexpected.     (one here - if coordination was bit better - would award deserved/ceremonial, "pat on the back.")

    Do be aware that should you seek to "exchange data" between the MCU & FPGA - two separate transfers (minimum) would be required.     (I'd suggest 6-bit data transfers - w/one extra bit serving as strobe - via (each) one of two, MCU GPIO Ports.    

    Alternatively if you employed the entire 8-bits of  one GPIO Port - and 4-bits from a 2nd GPIO Port - you'd require FOUR such transfers!   

    • 8-bits presented (1st Port)
    • fire strobe 1
    • 4-bits presented (2nd Port)
    • fire strobe 2.  

    Both strobes could co-exist upon Port 2 - and would be actuated separately.    (although you may "get away" w/just a single strobe...)

    Sixteen bit GPIO Ports - fairly standard elsewhere - hopefully arrive w/"latest/greatest/newer" devices...  (enabling 14 bit + Cmd/Data + strobe - in single transfer!)