Tiva Parallel I/O

One reporter's opinion - Robert was considering a synthesized, common output - created from multiple ports.  Some ARM MCUs (not confined to external bus devices) may accommodate up to 16 port pins w/single read/write...

Shashank Kulkarni said:

Fundamentally impossible? Why do you say so? Please see the GPIO section of the datasheet.

Do you wish an explanation at the PCB, IC or quantum level?  There are limits, either practical or fundamental, at all three.  The only question is one of scale.

Most simply at the MOSFET gate outputs, the transition timing will depend on the individual gate capacitances and the current drive feeding the gates.  These will be subject to variation as so the timing from pin-pin even on the same port will be different.

Now, in a lot of cases this will not matter but in some cases it might and the original request was for change at the exact same time. Thus my plea for more timing information.

Shashank Kulkarni said:

Highly unusual? Why do you say so?

I have never seen any IC that would guarantee outputs at the exact same time.  Many times it is ignored simply because the difference is too small for the problem domain considered.  Where it is considered there are phase measurements and specifications.

What does happen is a lot of trouble spent to re-sync and guarantee phasing.

This question of simultaneous signals is a big reason clocked circuits became used to begin with and why there is a limit (other than heat dissipation) to a digital ICs speed of operation.  By clocking at a fixed speed the signal speed variation can be masked by only requiring the signals to change before the clock transition rather than requiring them to change at the same time.

Robert

R2R DAC,

OK that gives restrictions and goals.

First is there a reason not to use PWM?  It is likely to be easier. Also R2R beyond a few bits is going to show accuracy and probably linearity problems.  How fast do you need your output sine way to change?

However, assuming you want to continue with an R2R setup, I suspect your biggest problem is not non-simultaneous switching but rather the normal glitching you would expect to see on transitions as a result of the output capacitance of the drivers.  This has to filtered out but it can be minimized by careful design.

Assuming you already have your outputs on a single port or have taken cb's suggestion of an external latch to synchronize the outputs your biggest noise is going to come from switching multiple lines at once.  So design you output code to minimize that switching.  Take a look at the gray code, it is designed to only switch a single bit as you count up or down.  For a sine wave gray coding should make a big difference.  You will end up switching only a few bits worst case near the 50% point.

If you are outputing essentially random values then you are going to have to filter the output (You probably want a post resistor driver anyway).  The good news is that this should all be high frequency noise and relatively easy to filter out.  Truthfully you probably want to filter the output in any case but covering the all on/all off transition is harder than a few bits.

You will note that commercial high frequency DACs have a maximum glitch specification.  Now you know one of the sources of the glitches.

Robert

@ Robert,

May I ++ your report.  Well argued/presented.

May I further suggest that the listed requirement, "set multiple pins - either high or low, at the exact same time" begs further (i.e. "some") definition of "exact."  Believe his "exact" differs far from the precision you've provided.

Suspect instead that the DAC's parallel inputs should be driven from a single port - and that clocking (data sync) - should emanate (spring)  via gpio resident upon some other port.  (which insures adequate, set-up/hold etc. and assumes DAC is clocked)

Normal Stellaris/rebrand gpio output function should prove adequate for such, "Gov't Work" - and likely meet the imprecision of poster's "exact."

cb1, thanks.

Agreed that timing on any single output port is probably good enough that it would be a secondary issue.  In any case there is little that can be done about it if the phase difference between port pins are an issue.

It would be interesting to know what the timing requirements on the D2A were.  PWMs  and inexpensive serial D2As are likely to be better alternatives in many cases.  Hand built R2R convertors use a lot of pins and are really not any simpler.  If I needed a fast converter I think I'd still look at fast parallel interface D2As.

On the other hand it's a good learning experience.  So if that's the goal it's good to fight through it.

Robert

@ Robert/interested others,

So appears "exact" here follows in the long, distinguished footsteps of, "MCU Does not work."  (never is it user's mis-understanding or mis-application)

Robert earlier identified PWM output - followed by some filter - as perhaps a superior alternative.  (devil in the detail - and we have no performance {accuracy, settling time etc.} targets in this case...)

Original post did not hint at application and I suspected some chance of "multi-port" combination - thus my proposal of an external latch(s) which could accommodate multiple ports - and exceed 8 "sync'ed" bits...  (sync'ed w/in "reason")

*** Best speeches on the, "ride home dept."   Dawns - just now (of course) perhaps poster's plight - or others not using R2R implemented DAC - stems from his/their parallel input DAC exceeding MCU's 8 bit port output capability!  (i.e. a 10, 12 bit or beyond DAC!)   Now we have subjected the DAC to 2 gpio transfers - and output glitch - unless heavily filtered - very likely to appear! 

Suspect this "beyond 8 bit, sync'ed (reasonably) parallel transfer," requirement may equal or exceed the value/application of original post.  And again - Robert's PWM suggestion (w/its 16 bit counter) looks better & better when/where DAC operation desired...  Should the need be digital outputs - then this reporter's latch(s) fed by multiple ports and clocked uniquely wins out...

*** Best speeches - "now even further along on ride home."   From Carlos, "In order for my code to work, I have to reset all of the pins to low."  Appears that statement sits unchallenged.  Carlos - why is that?  If it's an 8 bit parallel DAC does not the input of 0xFF yield full scale DAC output.  And as we pass thru that max - would not 0xFC as the very next byte passed to the DAC - cause the DAC output to reduce by 4 bits?  And - there has been no "drive" to DAC zero! 

Unstated is "Why all pins must be reset low?"  (haven't built/used R2R style DAC in decade(s)) - but should not that R2R respond to inputs in any sequence - w/out being forced to zero?  Quite often the problem is not w/in the MCU - but w/in the problem description & presentation - seems quite possible, here...

I'd missed that "must reset all outputs to zero".  That makes me think the outputs are spread over multiple ports (the 'scope trace also suggests this) but that doesn't fully explain things without a better description.

Carlos, please describe the symptoms of what you are seeing and fully describe your electrical setup as well as how you are driving the port pins in software.

Certainly if you are spread over multiple ports you will have an even larger problem and cb1's suggestion of a latch is the first thing to do.

Robert

I'd submit that even if outputs are spread over multiple ports - there is little (no) benefit of clearing these bits.  (and - this is especially true of bits which are to remain set - as these now "needlessly" transition from H to L back to H - makes no sense!

Believe you/I/others missed this - struggling instead w/the limitations caused by imprecise description.

There is one small advantage I can see to zeroing.  The signal looks cleaner on an oscilloscope capture.

It's a worse match to the wanted output but it is visually easier to interpret. 

That's really only useful if the goal is to produce an oscilloscope output though.

Robert