Power LEDs are more efficient at lower currents but you have to do what's compatible with your driver. Some power LED buck drivers support linear regulation and a bypass capacitor in addition to PWM. You'll have to read the spec sheet, though. It will go "pop" if you make it resonate.
Linear regulation and PWM alone doesn't get you much of a perceived brightness range without hitting problems near 0% and 100%. Some buck drivers support PWM on top of the linear intensity control so you can do
10% duty cycle on 5% current to get 0.5% intensity.
LED forward voltages are (from the physics) in the range of one to four volts; 12V would burn any simple LED diode to a crisp. So, either you are using a string of LEDs and not a single one, or your LED includes a current-limit resistor. Commercial LED lamps use several to hundreds of LEDs, arranged in series groups, with a resistor (to get the operation voltage to about 12V), and with multiple group + resistor (to get to a target brightness, or to string the light source out in a long linear array).
PWM without filtering will cause flicker; this will make (for instance) rotating machinery sometimes seem to be moving slowly. It isn't necessarily safe to do that. And, at 20 Hz or so, such illumination flicker can trigger epileptic episodes. So, all PWM schemes include some low-pass filtering
Forward-biased ideal diodes have a very low impedance (at 100 mA, at room temperature, about 0.004 ohms), so a capacitor would have to be huge to make much difference; an inductor is more practical. It also limits high frequency currents and associated RF emission.
You need to find out more about your LED (the load), and its heatsinking, before running ten watts into it.
PWM doesn't require a computer, of course; you could just build/use an oscillator with a variable duty cycle.
The ti.com site shows in one set of circuits, a large electrolytic cap in parallel with the led. What happened to traditional DC supply of inductor + cap?
To the Pic has a crap free sort-of C compiler. You can also buy less crap sort-of C compilers for it. But because the cpu architecture is so bad, and so limited, there is no way to make an efficient standard C compiler for the processor.
There is only one reason I would pick a PIC over an AVR - that is if I wanted to use them for caltrops, as the DIP packages are good for hurting bare feet.
These days I would be unlikely to pick an AVR for a new project either, without some very good reasons. They are not bad devices, and the compiler is good (being gcc), but for most purposes you simply get much better value for money, and a much better processor, with ARM Cortex devices. My usual choice is Freescale Kinetis, but there can be good reasons for picking different Cortex vendors.
(I am talking about the PIC12 through PIC18 families here. The PIC24 is completely different weird architecture, and the PIC32 is a reasonable MIPS CPU smothered by bad marketing and management.)
It may help to recall that the retina is a pixelated array of photochemical integrators, that then feed nerve cells.
The photochemical response is essentially instantaneous. The nerves' output is a faithful function of the number of photons received within the integration interval, over an amazing range.
That process responses to average, not peak intensity.
IME, variation in actual LED output is responsible for all the apparent brightness differences.
I measured under photopic (light-adapted) conditions. The generations of white LEDs I tested were 30% more efficient at d.c. than pulsed.
Efficiency falls off drastically at high currents due to i^2*r losses, and the added insult that that makes them hotter, which they also don't like.
R_E = 25 ohms/I(mA), so an ideal diode at 100 mA is more like 0.25 ohms.
Cheers
Phil Hobbs
--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC
Optics, Electro-optics, Photonics, Analog Electronics
160 North State Road #203
Briarcliff Manor NY 10510
hobbs at electrooptical dot net
http://electrooptical.net
This issue of which mcu (i named a picaxe) recalls (for me) the history of the automatic transmission. The first automatics, I'm told, were called "slush boxes" or worse. And yet they caught on.
The picaxe is indeed a joke, performance-wise, but from a standing start to running code is often 30 minutes or less.
There is a saying among SW developers that many chips require the programmer to be the pre-processor. IOW, the more you have to know, the more it sucks you into its complexity.
I gotta tell you a universal truth: People are stupid. George Miller, a cognitive psychologist, wrote a paper, "Seven plus or minus two: the limit of human attention." And in polls, 90% of people say they as intelligent or more so, then the other 90%.
As Dirty Harry said, "A man's gotta know his limits." (woman, her).
In relation to an mcu, the interface should take a few things into account: Use cases mainly. IOW, 90% of the mcu usage is for 10% of it's capabilities.
That's probably the strength of interpreted languages like Python or Basic.
As R Crumb said, "It's a Ho Hum World."
I personally like C. It's the hammer I am used to. But I think the picaxe dumbed-down philosophy has some merits.
(This should not be interpreted as a covert endorsement for instant TV dinners, instant coffee, or deodorant soap.) ymmv. jb
You asked me which /I/ would prefer. I don't want a dumbed down picaxe
- /you/ may be one of the "universal stupid people" but I am not. As a professional developer, I will use appropriate tools for the job in hand. This might be an easy-to-use tool (such as Python), but it is because it is the most efficient choice at the time.
Sometimes ready-made easy-to-use development boards are the right choice, of course - in which case I would point you towards the Arduino project.
I have several Raspberry Pi boards - I have looked at BBB as well. What I am looking for is a DMA/ADC portion. I see a lot of output terminals o each sides of the Cypress boards.
That wasn't me, it was John S. I am sure the PSoC4 devices are nice, however. I haven't used them myself (the older PSoC's used hideous cpus, and had so few programmable digital and analogue blocks that dedicated hardware in "conventional" microcontrollers were always cheaper and better). But with the PSoC4 you've got a nice core, and perhaps enough flexibility to make it worth the effort compared to a normal microcontroller.
I don't see why you think DMA is needed here - it is not exactly a demanding problem. Nor do you need an ADC that could be classified as "good" - pretty much any ADC is enough here.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.