-
In theory this can be done with 33 output pins using Charlieplexing but it's not practical as the maximum current from an IO pin is 25mA. I don't know maybe you could add a push pull emitter follower to boost the current but it's not really practical.
-
What is a reliable way of measuring instantaneous forward current, current impulses or spikes through a device, other than estimation from component values? My measurements seem to be all over the place. I am comparing a generic LED's behaviour controlled directly by an MCU (via a resistor) and then by the same MCU via a transistor (and the same current limiting resistor). I have been thinking that if I pulse the LED fast enough (not much longer than the response time), then the limiting resistor might not be necessary. The steap IV characteristics might not allow this to be done reliably though.
http://www.stockeryale.com/i/leds/lit/app001.htm
The thing is that measuring current spikes between 10 and 100 ns does not seem to be straightforward. I was reading this but it isn't exactly what I was after:
http://www.edaboard.com/thread41181.html
Any suggestions?
.o:0|O|0:o.
-
The easiest way is to use a current sense resistor in series with the LED and then view the voltage across it. A 1 ohm resistor will only drop 100mV for 100mA which affects the measurement a little bit but it'll still be in the right ballpark. Smaller resistor affects the measurements less but then you have to probe lower voltage levels. One of my recent posts in the project forums was about measuring current spikes through an LED actually...
Otherwise pay out big bucks for a Hall effect current sense probe.
Obviously you'll also need a high bandwidth scope. At really short impulses it'll be hard to distinguish between effects of the measurement itself and what's really happening.
An AVR that is only specced to put out 20mA per I/O can probably be connected directly. -
search for charlieplexing
That saves I/O lines, but makes the programming harder for such a large system, I'd avoid such complicated schemes unless necessary.
Dave. -
This is more of a systems engineering problem than overcoming device physics though...
I agree, it's a systems engineering issue.
Your actual electronics implementation will likely be dictated by your physical requirements.
i.e.
how are you mounting and wiring all these LED's?
over what physical area are they spread? (e.g. all over your house for xmas lights, or just something the size of a table?
I haven't done any calcs but I'd start out with a basic configuration of X number of large PIC chips driving X number of LED's with a simple driving scheme (i.e 1 LED per pin), one board per bank of LED's.
Make each board identical, and possibly separately battery powered?
A large pin count PIC might drive say 50 LED's. That's only 100 PIC's and 100 boards for a system of 5000. Not much cost there, a few hundred bucks.
Each board has a DIP switch with an individual address.
Have one master controller board talk to all board on multi-drop bus system (i.e. I2C)
You could choose to have an individually addressed LED system, i.e. each PIC listens on the bus for a LED within it's range and latches that LED on.
Or you could offload more smarts to the remote driver PIC's.
In any case there are plenty of options depending upon how you want to program the system.
Do the costing for a simple system like that first and see were you stand and what limitations there are or areas for improvement in terms of system functionality or cost.
You might find you spend more money on wiring, connectors, mounting etc than trying complex schemes like charlieplexing to maximise the number of LED's per pin.
Beware the law of diminishing returns! (both in terms of cost and design time)
Sometimes the best complex systems take the dumb-arse brute force approach.
Dave. -
search for charlieplexing
That saves I/O lines, but makes the programmer very hard for such a large system, I'd avoid such complicated schemes at all costs.
Yes, the high peak current requirement also rules it out. If you aim for an average of 10mA per LED, you'll need 10A but an MCU pin can only provide 25mA. You could theoretically buffer each pin with a four transistors connected as Szikla pairs but the LEDs won't be able to handle that peak current and if the MCU crashes, the LED connected to that pin will be toast. -
If you aim for an average of 10mA per LED, you'll need 10A but an MCU pin can only provide 25mA
use relays? or those big big transistor/mosfet?
-
Relays won't work because they can't switch fast enough.
Using MOSFETs would be a pain because Charlieplexing needs tristate outputs so a circuit needs to be designed to measure the output impedance of the MCU and switch the appropriate MOSFET on or off which would be complicated as you need 33 of them.
-
I had thought of a multiple PICs solution as well, but I didn't want to do the crazy thing of ordering thousands of LEDs, resistors and many PICs without making damn sure I wasn't overlooking a more sensible solution.
I really like the idea of using many PICs (instead of many MUXs) because there is the added benefit of being able to implement programs to make use of all that parallel processing potential...
Anyway, the immediate goal of the project is to have some fancy Christmas lights: I am thinking of covering a ceiling with LEDs and having the constellations gradually move across it; amongst other things, ceiling Tetris and chess if enough data can be represented.
In the case of the constellations, any LED flickering would be appropriate and a Tetris block would not be fully lit, but would be a moving sparkling shape.
I would also like the option of communicating with the system wirelessly from a computer, to transfer data and to reprogram all chips.
If it all goes well, I plan on using it for more serious purposes. I would also like to adapt it to control miniature actuators; a more long term thing I have been working on for a possible novel idea. This secondary goal will require that I supply more than the MCU's 20 mA to 25 mA. It is likely that I will construct some sort of MOSFET bank for this.
Thanks once again for all your suggestions.
.o:0|O|0:o.
PS.
Fantastic video blogs Dave, very inspirational stuff, glad you didn't abandon the idea early on!
PPS.
Regarding the Charlieplexing, I thought it was a clever idea, but not for so many LEDs. The probability of a LED failure is vastly increased in my case because of the way I want to operate the LEDs (rapid brief pulses) and because of the sheer numbers involved. -
Just to check, you're arranging these LED's like LED matrices are connected right?
http://tinkerlog.com/wordpress/wp-content/uploads/2008/08/l_matrix_schematic.png
You can arrange them in 8x8 grids, and chain them together to make something with 64 x 8 connections. A chain of shift registers drive the 64 connections, while your MCU directly controls the 8 common connections through a transistor. I believe that's the typical thing people do.
Use MCU's in parallel by letting them control each group of 8 commons separately. For instance, if you calculate that you get your desired brightness controlling 256x8 on one MCU, then use one MCU per 256x8 group. -
Use low cost microcontrollers to control small blocks of the array, then use a larger microcontroller to control them all.
-
Use low cost microcontrollers to control small blocks of the array, then use a larger microcontroller to control them all.
Sounds like a good idea.
You could then use Charlieplexing on each MCU so you need less pins.
The PIC16F57 which has 20 I/O pins and is dirt cheap.
If you use 19 pins do Charlieplexing you'll be able to control 380 LEDs but you'll need pair of booster transistors on each pin and something to make sure that the MCU doesn't lock up leaving an LED on continuously.
No Charlieplexing that many is still impractical. You're better off Charlieplexing two groups of LEDs with 9 pins each giving a total of 144 LEDs per MCU. One pin of the MCU could be used for data, the other as a watchdog which is cycled on and off continuously so you can tell the MCU is still functional. -
The I2C protocol seems spot on for this application, allowing me to address a minimum of 128 MCUs or other devices using the 7-bit addressing mode, so I am quite set on using that. (I also like the potential of using the slave MCUs to process data and report back to the master/s for a potential secondary non LED use - it seems like a waste not to).
However, I would have to select a PIC (or a selection of models) that would allow me to implement the I2C without too much hassle. Furthermore, they would have to have a decent I/O pin count, perhaps handle a decent amount of current per pin depending on how I am connecting the LEDs (some of the 50+ pin devices will only allow 4 mA per pin, which would make sense).
As I am using PICs I have decided that I would prefer using in-circuit reprogrammable devices as opposed to OTPs, not only because of the flexibility this offers, but also because the idea of irreversibly programming a bug into a hundred PICs is not an option.
It is going to take me a little while to figure out the best PIC/s to use and where to source them from due to my relative lack of experience with anything on this scale.http://tinkerlog.com/wordpress/wp-content/uploads/2008/08/l_matrix_schematic.png
In principle, I *think* I see what you are doing with the regsiter. Are you implementing a serial/parallel converter, allowing the data to "settle" over a n cycles (according to the matrix size), before activating the LEDs? Having looked at the high pin count chips I am not sure how large I am going to be able to make these matrices. Also, is the arrangement you are referring to the same as the Charlieplexing that has been suggested or another method?The PIC16F57 which has 20 I/O pins and is dirt cheap.
If you use 19 pins do Charlieplexing you'll be able to control 380 LEDs but you'll need pair of booster transistors on each pin and something to make sure that the MCU doesn't lock up leaving an LED on continuously.
No Charlieplexing that many is still impractical. You're better off Charlieplexing two groups of LEDs with 9 pins each giving a total of 144 LEDs per MCU. One pin of the MCU could be used for data, the other as a watchdog which is cycled on and off continuously so you can tell the MCU is still functional.
I am a bit concerned about the potential for catastrophic failure if the Charlieplexing goes wrong. However, done correctly it would serve the purpose and reduce the cost drammatically. Frankly, I can't see how else it would be achieved.
I think the next step is to figure out which PIC to use. I will look into the 16F57. How do Farnell measure up to other suppliers in terms of prices? (Their servers seem to be down at the moment).
According to RS
74hc595n: ~£30 (100 chips)
16F57: ~£50 (100 chips) -- Not bad.
.o:0|O|0:o.
Ps. Hero999, how are you deriving that pin count? I haven't worked it out for myself yet... -
74hc595n: ~£30 (100 chips)
LEDs = n2-n
Ps. Hero999, how are you deriving that pin count? I haven't worked it out for myself yet...
Where n = the number of pins so using 9 pins gives to 81-9 = 72 LEDs, two banks of 9 pins would give 144 LEDs or you could have 306 LEDs but it's not practical due to the peek current requirement, so it's best to keep the number of pins under 10.
Here's the output current booster circuit I was talking about. It should be able to boost the output capability of the PIC by a factor of at least 10 but you can loose up to a volt which won't do for driving blue/white LEDs.
I didn't completely read the datasheet for the 74HC595 but it has tri-state outputs which could allow a type of Charlieplexing, even if it isn't as good efficient as with a PIC.
The PIC16F57 doesn't natively support I2C but it shouldn't be hard to come up with a simple kind of serial communication, even if it means using one line for each PIC.
-
I was reading about the 16F57. Microchip have a solution for programming this chip with a PicStart Plus:
http://ww1.microchip.com/downloads/en/DeviceDoc/etn22.pdf
...I could start adapting the PicStart Plus or I could get a Pickit 2. In fact, another issue will be programming all these PICs. I think some form of mass in-circuit programming will be the way to go and I doubt I will be using through hole components anyway.
(Incidentally, I wonder if there have been any improvements to the Pickit 3 or useful 3rd party s/w. As far as I can tell from searching, people have really been left uninspired by Pickit 3 and are unlikely to contribute towards it....).
.o:0|O|0:o. -
Would that be a total of 18 transistors for each slave PIC?
The PIC18F57 doesn't natively support I2C but it shouldn't be hard to come up with a simple kind of serial communication, even if it means using one line for each PIC.
I thought you were being really optimistic for a second (as in a single line of code)... The thing with 1 data/clk line per MCU is that somehow a master has to manage them and they start to amount to a big number. I2C is really well suited to this task.
There do seem to be s/w alternatives to the h/w implementation, but that is potentially more time spent on debugging and who knows what other problems. An alternative might be SPI or 1-wire, which I have never come across before.
Software I2C requires a fast XTAL and that makes sense because the program is quite long.
http://www.i2c-bus.org/common-problems/
I2C in software (Master):
http://ww1.microchip.com/downloads/en/AppNotes/00554c.pdf
http://www.microchipc.com/sourcecode/#i2c
1-wire:
http://ww1.microchip.com/downloads/en/AppNotes/01199a.pdf
.o:0|O|0:o. -
if your programming in some higher level language than assembly then you can easily use library's provided by the compiler to implement serial and IC2 in software.
-
No, charlieplexing is completely different.
If you look at how people usually drive large LED displays, they do not use charlieplexing. It's all driving LED's in this configuration. Look into this:
http://www.xmos.com/products/development-kits/xc-3-led-tile-kit
Internally, the matrices look like this:
http://www.nuxie1.com/images/stories/gallery/albums/LED_Matrix/LEDM88G_Circuit.GIF -
if your programming in some higher level language than assembly then you can easily use library's provided by the compiler to implement serial and IC2 in software.
I may well have to do that, but a hardware I2C is faster and and more reliable, while a software implementation might reveal bugs very late on. That there are libraries is clear enough, but my point is that if I am going to implement a software protocol, I might be able to find something simpler, leaner and faster for my application which needs greater emphasis on addressing than it does on data.
.o:0|O|0:o. -
well yes it's up to you to decide between hardware and software based on your requirements and the available processing power
-
Internally, the matrices look like this:
http://www.nuxie1.com/images/stories/gallery/albums/LED_Matrix/LEDM88G_Circuit.GIF
I am familiar with control principle in the GIF. For some reason I imagined you were describing something more complicated in your other post and from what I have gathered so far, there are a few ways people implement LED arrays, so I wasn't sure what you meant was typical. Thanks for explaining.
I have quite a few ideas at this point and I think the way I proceed with connecting the LEDs will depend fundamentally on the choice of MCU: no. pins vs current source/sink vs cost vs I2C protocol availability.
In the case of the LED array that you proposed I was thinking that I could use interlacing together with the transistors in order to keep the LEDs on (should I require).
Charlieplexing makes interlacing more complex.
.o:0|O|0:o.
-
charlieplexing seems to be usable only for very ad hoc situations and probably only gets mentions so as to show up front one way that you really should only use as a last resort
-
well yes it's up to you to decide between hardware and software based on your requirements and the available processing power
Since the design will effectively be composed of many identical modules, perhaps differing only in terms of the MCU addresses, implementing a software comms would be preferrable *if it reduced the cost considerably when compared to the cost of a hardware I2C*, especially since it would be a matter of adapting already existent code to the MCU of choice. A while back I designed a two way full handshake based protocol in ASM out of sheer laziness because I didn't want to learn C for PICs and because it just seemed easier than going through someone else's program and familiarizing myself with their coding style in order to work out what they were doing... anyway, it worked out well for the simple application at the time, but this time it is a little more involved because of all the device addressing and possibly the need or desire to also address registers within the devices. Besides I am doing this for the learning experience which is why I am placing so much emphasis on applying/adapting typical solutions rather than re-inventing the wheel or inventing my own solution and perhaps failing in the process or spending more than necessary....
.o:0|O|0:o.
-
In terms of circuit board technologies I am thinking of using surface mount on double sided PCBs. Even though a single side might be sufficient, it might reduce the cost by allowing the use of through hole parts which might cost less (I am thinking along the lines of connectors). In reading about I2C I came across a limitation of 400 pF on the bus. Would this exclude the use of something like this:
http://uk.farnell.com/jsp/search/browse.jsp;jsessionid=2KJKGLA5IIE5UCQLCIPZMMQ?N=0&Ntk=gensearch_001&Ntt=pcb+presensitised+2+sides&Ntx=mode+matchallpartial&suggestions=false&ref=globalsearch&_requestid=8362
I can't find more technical information from the manufacturer than this so far:
http://www.farnell.com/datasheets/514374.pdf
Or for the number of boards required would it be better to just have them produced professionally?
Also, since I intend to use in-circuit serial programming of the devices, I was wondering if it would be possible to update all the devices at the same time. The MCUs would all be stepping to the same master CLK. Is the in-circuit programming efficient enough to allow this. I am also thinking that the internal frequency dividers of the individual chips might not be close enough to allow this. Does anyone know of this being attempted before?
The other option - probably the best one - would be to ICSP the chips sequentially taking advantage of the I2C. From memory, my Picstart Plus was able to program in under 10 s. For a hundred MCUs or so, that might amount to a wait time of perhaps two minutes, or say something under 5 minutes. Would it be practical to adapt my Picstart Plus to achieve this (it seems just about possible to program the 16F57 with it - not that I have selected that chip so far), or a Pickit, albeit with a circuit to help with the signal level?
.o:0|O|0:o.
PS.
http://ww1.microchip.com/downloads/en/devicedoc/30277d.pdf -
You should probably just go with professional PCB manufacturing. BatchPCB is cheap for small orders. DorkbotPDX has a PCB order that is also pretty cheap. You'll probably be waiting around 3 weeks for your boards though.
I2C does have a wiring distance limit. 400pF isn't a lot if you have discrete cables connecting your devices together. I forgot what the figure was for pF/trace length though. If you use a slower clock you'll be able to get away with larger capacitances. But then your refresh rate will be slower. You can also use I2C buffer IC's but they're expensive since you have to put one in front of every device.
Maybe try having I2C regions to separate the bus capacitances. Inter-device communication is a difficult part of this too... which is why an FPGA or massively parallel MCU like the XMOS is the way to go for something like this.
Also, see this: doesn't seem too bad to drive a 64x64 display
http://forum.sparkfun.com/viewtopic.php?t=10960