Poor man's PWM

Am 29.01.2020 um 04:54 schrieb Don Y:
> Hi Hans-Bernhard,
> 
> On 1/28/2020 6:43 AM, Hans-Bernhard Bröker wrote:
>> Am 28.01.2020 um 01:53 schrieb Don Y:
>>> But, instead of having N different times at which the IRQ
>>> might be signalled (for the N+1 different duty cycles) in
>>> each refresh interval, I plan on having log2(N) times, each
>>> delimiting an period "twice" as long as the previous.  This
>>> keeps the hardware cheaper than dirt 
>>
>> I rather much doubt that.  If there are indeed "few" intensity levels, 
>> i.e. 16 rather than 1024, this approch will at most reduce the overall 
>> software-PWM interrupt rate by a factor of 4;
> 
> Which means the timer can be four times FASTER!

No, it really doesn't.  Reducing the overall interrupt rate is, at most, 
the top of this iceberg.  The aspect that invariably drives CPU speed 
requirements, and thus cost, here is the peak interrupt rate, and your 
proposal doesn't affect that at all: you still have two interrupts to 
serve at 1/(16 * f) for PWM output frequency of f Hertz.

Also, your proposal will actually _increase_ the overall number of 
interrupts* for cases where you have to turn on one LED twice in the cycle.

> Obviously you're not a hardware person.  

Enjoying yourself throwing ad-hominems around, much?

> E.g., with a 10KHz *peak* IRQ rate, you'd have 100us to respond to THAT
> IRQ and get the next data ready -- simply COPYING it from a FIXED
> LOCATION to another FIXED I/O LOCATION -- for the timer to transfer
> to the LED "(hammer) drivers" coincident with the *next* IRQ.

Those 100 us are not the problem.  It's the latency of the interrupt 
routine, and its raw processing time.  The actual time between turning 
on and off that output has to be the same every time round, to within a 
few percents, or the thing will flicker abominablly, particularly at 
duty cycle '1'.  That means interrupt timing (including run-time of the 
handler itself) has to be stable down to a few us.

>> Overall, hardware that can implement this scheme will thus hardly be 
>> any cheaper than hardware that can implement the usual one.

> Really?  How much for 20 PWM channels?  200?  2000?  (I have a 2000 LED
> "moving message" sign at my feet, here -- wanna bet it DOESN'T have
> 2000 PWM channels?  Or, 2000 programmable current sources?)

That puts just as much burden on your scheme as it would on a 
straight-forward one.  Those 100us will appear mighty short if you were 
to do any work involving 2000 independent inputs on a cheap-ish micro.

PWM generation is rightfully delegated to dedicated hardware units, 
whether inside the CPU or outside.  SW is, ultimately, the wrong tool 
for this job.

>> Your plan also destroys any possibilities to distribute those EM 
>> emissions (and power supply loads) more evenly by staggering the PWM 
>> cycles of several LEDs. That aspect becomes more important as the 
>> loads get heavier, of course: 20 mA LEDs are a piece of cake, 20 
>> Ampere heaters not so much.
> 
> They are *indicators*, not *illuminators*.
> 
> I'm going to give you 20 (or 200 or 2000) DEDICATED PWM channels.  How 
> are YOU
> going to stagger theur cycles?  

By distributing their starting points evenly across the base cycle. 
Possibly, in a higher-level routine, keep a watch out for any time slot 
that has higher workload than others, and shift that around.

And at 2000 LEDs, your _are_ talking about quite an illuminator if you 
turn them all on. Avoiding wildly fluctuating loads to the power supply 
does become a factor to consider in that case, particularly if you want 
that supply to stay cheap.

Ultimately one might not need ISRs at all, if just about all that chip 
is going to do is turn on and off LEDs.  It could busy-loop on a 
time-sorted priority queue of switching events instead.

On 1/29/2020 4:58, Don Y wrote:
> Hi Dimiter,
> 
> On 1/28/2020 8:39 AM, Dimiter_Popoff wrote:
>> whatever PW you do beware the randomness, even small,
>> from period to period. I did something like that once many years ago
>> (just wanted to have 3 colours out of a 2 colour LED) and the mixed
>> colour was quite visibly flickering. I don't remember how much
>> randomness there was and how it might compare to yours but using
>> IRQ and bit banging it does invite some, I'd test that before
>> rolling it out. I think mine used IRQ just to switch tasks and
>> measure time on a HC11 back then (some 20 years ago) but I don't
>> think I pushed much to get rid of the flicker, it was not a problem.
> 
> How were you driving it?  I.e., was it a two-lead (bi-color)
> device?  Or, THREE?  In the former case, I could see how
> the duty cycle in one direction (terminal 1 to terminal 2)
> differing from that of the other direction (terminal 2 to
> terminal 1) would alter the relative mix of the two colors
> and, thus, the resulting color.  In the latter case,
> perhaps driving one (or both) anodes/cathodes with a
> particular duty cycle to "tune" the color?
> 
> The obvious fix is to double-buffer the drive to the device so
> that the same signal that prompts the ISR to change the drive
> *also* locks in the previous decision to the actual indicator.
> This makes the entire IRQ period available for servicing the
> ISR without having visual consequences -- for the cost of (an)
> external latch(es).  Latency issues go away (largely).
> 
> [But, this either requires a "terminal count output" from an
> internal timer/counter -or- an external counter/timer driving
> an IRQ input (that can also trigger the latches).]
> 
> A related problem is how "nearby" indicators are perceived.
> E.g., will two different indicators be seen as having differing
> intensities even though *intended* to have the same intensity?
> I.e., is the visual output of a device "matched" to others
> ACROSS THE FULL RANGE OF DRIVE CONDITIONS?  Or, just at
> a particular test criteria?
> 
> And, how far apart do such devices need to be in order for the user
> NOT to be able to perceive (minor) differences?  Two die in the same
> package (your case!) is obviously one extreme!
> 
> I'm not keen on having to purchase "matched" devices or any
> "select at test".  So, would rather just AVOID issues that
> could lead to visual aberrations, etc.

Hi Don,
this was the LED indicator of a HV unit, I wanted it green while
operating normally, red if some protection did kick in and yellow
while the voltage was being driven up (at say 100V/s for 4-5 kV).
So the fact it was flickering was no issue at all, it even gave the
impression of an ongoing change.
I probably did not use double-buffering for that indicator on the HC11
that controlled it which did double-buffering for the PWM driving the
HV convertor though (using output compare with double buffering is
the standard way to do PWM on a HC11).

The LED had 2 leads (never had one with 3 so I know that) and the
uncertainty because of latency must have been within microseconds,
may be tens of microseconds (I just do not remember how I did it,
I remember I did not care a lot, saw it flicker but deemed it
good enough and moved on).

Dimiter

======================================================
Dimiter Popoff, TGI             http://www.tgi-sci.com
======================================================
http://www.flickr.com/photos/didi_tgi/

On Wednesday, January 29, 2020 at 7:21:41 AM UTC-5, David Brown wrote:
> 
> FPGAs are great for making lots of PWM channels, but it would not be so
> easy to route those signals to the LEDs.  So you'd want multiple
> distributed FPGAs with serial links between them.  It could be done, but
> I'd expect it to be more development effort.

Yes, but every time we discuss FPGAs I believe you show how little you know about them.  This is very much a perfect application for small, low cost FPGAs.  There is enough logic in each one to drive as many LEDs as is convenient.  The development time is likely less than using MCUs since you can just develop your code without any worries of using interrupts to fake a sequential processor into appearing to provide parallel processing.  

Design the circuit needed to drive an LED and duplicate it for N outputs without worry.  Simulate it in all it's gory detail and then run the final result with a high probability of success the first time. 

-- 

  Rick C.

  --- Get 1,000 miles of free Supercharging
  --- Tesla referral code - https://ts.la/richard11209

David Brown <david.brown@hesbynett.no> writes:
> The way I have seen big LED signs done is with chains of LED driver
> chips.  Each chip supports 8 to 24 chains of LEDs...

Another idea might be use Neopixel strips or whatever those things are
officially called.  Each LED has its own chip inside so you send it an
RGB value and it lights up at the color and brightness you tell it.
They are addressible, there's an older style with a timing based
interface, and a newer style that uses SPI directly:

https://www.adafruit.com/product/3919  etc.
https://www.adafruit.com/product/2240  These are the SPI ones

Rick C <gnuarm.deletethisbit@gmail.com> writes:
> Design the circuit needed to drive an LED and duplicate it for N
> outputs without worry.

But then there is the matter of getting the signals out to the LEDs.  Do
you want to use 1000s of wires, or have some kind of fanout protocol?
Either way is a pain.

Of course the whole problem is fictional, but if they are really
indicators, addressible LED's and some CAN bus stuff seems like the way
to go.

David Brown <david.brown@hesbynett.no> writes:
> And if you don't want people to concentrate on trying to move you away
> from a seriously daft control software idea, then don't make it the
> centre of your post.

This is the guy who went on for weeks about a realtime control system
that turned out to be lawn sprinklers, so I wouldn't worry.  I plonked
him years ago.

On Wednesday, January 29, 2020 at 1:07:40 PM UTC-5, Paul Rubin wrote:
> Rick C <gnuarm.deletethisbit@gmail.com> writes:
> > Design the circuit needed to drive an LED and duplicate it for N
> > outputs without worry.
> 
> But then there is the matter of getting the signals out to the LEDs.  Do
> you want to use 1000s of wires, or have some kind of fanout protocol?
> Either way is a pain.

How would you be driving 1000s of LEDs from one chip?  That seems like a disaster. 


> Of course the whole problem is fictional, but if they are really
> indicators, addressible LED's and some CAN bus stuff seems like the way
> to go.

Yes, 1000s of LEDs is a rare application indeed.  

On a project like this the devil is in the details.  But I will say using FPGAs as a solution is often overlooked because of the lack of familiarity with them and the imaginary difficulties in working with them.  

People don't use them much, so they reach for the hammer.  Some problems are actually screws, but if you want to use it, a hammer still works.  

-- 

  Rick C.

  --+ Get 1,000 miles of free Supercharging
  --+ Tesla referral code - https://ts.la/richard11209

Rick C <gnuarm.deletethisbit@gmail.com> writes:
> How would you be driving 1000s of LEDs from one chip?  That seems like
> a disaster.

Right, so now the multiple chips have to communicate somehow.

> Yes, 1000s of LEDs is a rare application indeed.  

It happens with large display signs, but indicators?  Most anyone would
use LCD screens these days.  Didn't your car replace the whole dashboard
with an LCD screen?

On Wednesday, January 29, 2020 at 1:28:44 PM UTC-5, Paul Rubin wrote:
> Rick C <gnuarm.deletethisbit@gmail.com> writes:
> > How would you be driving 1000s of LEDs from one chip?  That seems like
> > a disaster.
> 
> Right, so now the multiple chips have to communicate somehow.

Yes, "somehow".  Perhaps we can use magic??!!!


> > Yes, 1000s of LEDs is a rare application indeed.  
> 
> It happens with large display signs, but indicators?  Most anyone would
> use LCD screens these days.  Didn't your car replace the whole dashboard
> with an LCD screen?

Not the whole dashboard, there are two displays in my car and a bunch of controls around the steering column. 

But there are still many, many LEDs blinking, nodding and winking all around us every day even though most of them are at best ignored and at worst tolerated... very few ever looked at. 

However, the multiplexing of controls and inputs is a very valid concept.  Speaking of my car, it has a central processor in the dash and many, many things are connected to it.  This creates a LOT of wiring.  Tesla has a patent on using a chip to multiplex controls over a bus (I can't believe no one is doing that), greatly reducing the wiring in a car.  It seems that while buses are very commonly used in cars, it didn't occur to anyone to put an MCU in each door, one or two in the back of the car, one in the steering column, etc., to allow a single four wire run to each of these devices to control all the indicators, actuators, speakers, illuminators and sensors in each area.  

It sure seems obvious to me.  I guess the auto industry really is a bit technology adverse. 

-- 

  Rick C.

  -+- Get 1,000 miles of free Supercharging
  -+- Tesla referral code - https://ts.la/richard11209

On 29/01/2020 18:51, Rick C wrote:
> On Wednesday, January 29, 2020 at 7:21:41 AM UTC-5, David Brown
> wrote:
>> 
>> FPGAs are great for making lots of PWM channels, but it would not
>> be so easy to route those signals to the LEDs.  So you'd want
>> multiple distributed FPGAs with serial links between them.  It
>> could be done, but I'd expect it to be more development effort.
> 
> Yes, but every time we discuss FPGAs I believe you show how little
> you know about them.  This is very much a perfect application for
> small, low cost FPGAs.  There is enough logic in each one to drive as
> many LEDs as is convenient.  The development time is likely less than
> using MCUs since you can just develop your code without any worries
> of using interrupts to fake a sequential processor into appearing to
> provide parallel processing.

Of course FPGA's /could/ be used.  And small, cheap FPGA's are small and
cheap.

This system would need software to generate or otherwise control the
values to be used on all the PWM channels.  That would be /software/.

My suggestion involves developing hardware :

1. A board with a microcontroller that has a fast SPI peripheral, DMA,
enough memory, and whatever is needed for receiving or generating the
picture data.

2. Dumb boards with LED controller chips, with SPI in on one side and
out on the other side.  You use as many of these as needed for scaling.

On the software side, you have:

1. Software on the microcontroller for receiving or generating the
picture data.

2. Software for generating the PWM values for the picture.

3. Software to set up SPI, DMA and a timer.


Your solution would need hardware :

1. A board with a microcontroller (or FPGA with a processor) with some
fast bus (SPI, or something else) to the slave boards, and whatever is
needed for receiving or generating the picture data.

2. Slave boards with small, cheap FPGA's, with bus in and out of the
card, and lots of PWM signals.  You need LED driver hardware to power
the LEDs, and perhaps monitoring for currents (depending on the quality
of the display you are targeting).  You need a system for programming or
configuring the FPGAs, preferably in the bus (for simpler production and
updates).

It needs FPGA firmware:

1. If the main board uses an FPGA rather than a plain microcontroller,
that needs to be designed.

2. The small FPGA's need multiple PWM's, a daisy-chain bus (such as
SPI), and coordination of data between these.  It's not magic and would
be a straightforward task for an experienced FPGA designer, but it is
not insignificant either.  If you want current feedback and regulation,
that would be a good deal more work.

It needs software:

1. Software on the microcontroller for receiving or generating the
picture data.

2. Software for generating the PWM values for the picture.

3. Software to set up SPI, DMA and a timer (or whatever other bus is used).



I can't imagine how you think an FPGA solution is less development work
- it requires FPGA design in addition to everything else, not as an
alternative.  Note also that it requires three experts (or an expert in
three fields), rather than just two.

> 
> Design the circuit needed to drive an LED and duplicate it for N
> outputs without worry.  Simulate it in all it's gory detail and then
> run the final result with a high probability of success the first
> time.
> 

Or simply /don't/ design the circuit needed to drive an LED, because it
is in the driver chip.  That is obviously simpler.

And what is this about "using interrupts to fake a sequential processor
into appearing to provide parallel processing" ?  You are /way/ out to
sea on this one - utter nonsense.

You regularly accuse me of not knowing much about FPGAs.  I think you
know little about software development (your fondness for Forth suggests
your experience is limited to extremely simple programs on extremely
limited devices - it is a fine language for tiny stack-based processors,
but not for anything else).  You are so solidly FPGA-focused that you
see FPGA's everywhere, and are unable to imagine solutions that don't
involve them, or why there might be better solutions.  In particular,
you simply don't understand how software works - because you are
thinking in terms of FPGA design, and assume that sequential processor
software has to simulate parallel logic.