EEVblog Electronics Community Forum
Electronics => Beginners => Topic started by: .o:0|O|0:o. on October 27, 2010, 02:10:22 am
-
I am at the beginning of a design, which I hope to have ready for Christmas. In principle it is simple, in practice it is a bit of a headache already.
I need to program a microcontroller, a PIC in this case, to flash >5000 bright LEDs in sequence of predetermined combinations.
The number of predetermined combinations is large (>1000) so unless there is a particularly efficient way of using the memory of a PIC, I will probably need to include some form of external memory so that I can transfer the data from a PC to the device in its entirety.
My first thought is to use a PIC to supply data to some yet unknown arrangement of multiplexers, which will then flash the LEDS, via transistors once in each predetermined manner.
The design should be able to flash any number of LEDs at once, or in tight succession if this helps make more efficent use of the batteries and hardware. Batteries might be any number of AAs.
The LEDs might be pulsed with current above their specification, for extra lumens, briefly and infrequently considering that each combination will be different from the last.
One possible way I was thinking about would be to have multiple levels of multiplexers to account for the many independent outputs, but when you consider the software complexity of controlling LEDs through a number of layered multiplexers it might be more convenient to design the software to replace a layer or two, especially since the LEDs of each combination may be flashed in rapid succession.
Ideally I want each update to be as quick as possible. I was thinking that the problem might be in some ways similar to addressing pixels on a TFT screen. Does anyone know if there is a really good way of accomplishing this sort of task?
Thanks in advance!
.o:0|O|0:o.
-
By the way I had also thought of having a master-slave setup with multiple MCUs, but for that number I would need many MCUs. The number of LEDs is so large that I would still need some other method realistically....
-
maxim has a nice application note on large led displays. (see .pdf attached)
i believe mikeselectricstuff on the forum here is an authority on the matter.
-
Okay, I don't want to be a wet blanket but back up a second ...
">5000" ... "any number of AA batteries"
Say that worst case only 10% of the LEDs can be on at the same time. That's 500 LEDs.
Presuming an average of 20mA per LED, that adds up to 10 AMPS.
You need to be considering a car battery, not AA cells.
Suppose, God forbid, you want all 5,000 on at the same time ... that's 100 amps.
Now we're talking a couple of golf cart batteries to get any run time out of the thing.
Sure you could mux them, but you'll take a big hit in brightness.
What's more, you said bright LEDs which could easily draw much more than 20Ma depending on the device.
I think you need to do a little power budgeting (http://chrisgammell.com/2010/10/25/what-is-a-power-budget/) before diving into what are going to be some serious computer horsepower issues.
-
maxim has a nice application note on large led displays. (see .pdf attached)
i believe mikeselectricstuff on the forum here is an authority on the matter.
Thanks for that. Any help is great. Going through it now!
-
Okay, I don't want to be a wet blanket but back up a second ...
">5000" ... "any number of AA batteries"
The batteries are not a strict requirement. Power adapters could be used in the limit if I couldn't devise a suitable parallel/ serial configuration. I should have specified this, but I didn't want to get side tracked......
Since the device will only update (probably 33% to 50% of the LEDs) once every few minutes, I was also considering charging and discharging caps....
The forward current of the LEDs would be about 50mA each. Essentially, they should be ON and OFF as quickly as visibly possible.
Your point is taken, but I am hoping to find a creative way around these issues.
Note that activating all LEDs simultaneously is not a requirement, smaller clusters could be updated in succession as long as the overall update didn't take too long. You can find AAs apparently rated at 2500mAh Nickel Metal Hydride. Even if these ratings are overstated, 15 AA's is not an inconsiderable amount to play about with.
If I can't find a way of delivering the current I need in the short time required, I will be forced to reduce the number of LEDs, but consider this, if I flashed clusters of 50 x 50mA at a time, on paper that is 2.5A
Thanks for the link...
.o:0|O|0:o.
-
I just had a look at that Maxim datasheet and I think there is a good chance I will be using their devices. :)
I may be able to drastically reduce the number of LEDs to 8x8 x 8 = 512. However, I would still be seeking to flash, though very briefly, as many LEDs at once as I could (or in clusters or sequentially, in as brief a time as possible).
Thanks again.
.o:0|O|0:o.
-
1) your rambling and probably trying to do something beyond your abilities
2) your still not understanding just the amount of power you are asking for, you have a big power management project before you even start on the control system.
3) in view of 2&3 why not give us full details of the desired result as you seem to have a goal in mind but not quite know how to deal with the scale on which you are trying to do it.
-
search for charlieplexing
-
I just had a look at that Maxim datasheet and I think there is a good chance I will be using their devices. :)
I may be able to drastically reduce the number of LEDs to 8x8 x 8 = 512. However, I would still be seeking to flash, though very briefly, as many LEDs at once as I could (or in clusters or sequentially, in as brief a time as possible).
Thanks again.
.o:0|O|0:o.
Be careful, Maxim IC's are insanely expensive.
Look into the XMOS microcontrollers. Their parallel execution is perfect for something like LED matrix driving. They even have a bunch of calculations done already for how many XMOS's are needed for a given amount of LED's.
Maybe look into the TLC5947 (if you want fading), or the TLC5951? I did a project with them. It should be pretty straightforward to expand it by using a lot more drivers and multiple microcontrollers. https://www.eevblog.com/forum/index.php?topic=1487.0 (https://www.eevblog.com/forum/index.php?topic=1487.0)
It's going to get pretty expensive though.
Another idea is to use an FPGA, which is perfect for this sort of task... massively parallel I/O.
-
maxim also have a tendency to not have parts available, I once bought out farnell of chips with just 12 parts although suspect that they were going to ditch the line in favor of a newer product of which they still only carried 50 odd when I last ordered
-
Thanks for all the advice. I wanted to avoid FPGAs, but I will now have reconsider all my options. It is interesting how the simple task of flashing a LED becomes many times more complicated with increased numbers...
Nice circuit by the way!
Fortunately I don't have the added requirement of variable brightness and the LEDs themselves are unlikely to warm up significantly because of their brief ON times. I will probably need to cool my chips if I find a particularly efficient method. The TLC5951 appears to provide 40 mA per channel, I might look into it. Farnell don't have it at this time though.
Interesting reading about the charlieplexing... I think I will continue to browse the IC section for ideas.
.o:0|O|0:o.
-
Your point is taken, but I am hoping to find a creative way around these issues.
.o:0|O|0:o.
Finding a creative way around the laws of physics is difficult at best! :)
-
Your point is taken, but I am hoping to find a creative way around these issues.
.o:0|O|0:o.
Finding a creative way around the laws of physics is difficult at best! :)
sure is, physics is the bottom line in any science and technology. there are many things about electronics, many quirks that are simply down to the way materials we make parts with work on a physical level.
-
This is more of a systems engineering problem than overcoming device physics though...
-
yes it is. really it's down to maths and the amount of combination you can implement with as little address lines as possible
-
It is interesting how the simple task of flashing a LED becomes many times more complicated with increased numbers...
its not that complicated, as long as you have enough fund for it.
i agree with allanw, this is engineering, not science. science is to find the truth, and engineer is to get around it :P or in more precise word... manipulating it ;D
-
Finding a creative way around the laws of physics is difficult at best! :)
...So you believe that flashing a large number of LEDs within a finite period is impossible ~against the laws of physics~, even if modest numbers are flashed at a time to circumvent the lack of an ideal power supply (calculated based on the charge available at any given time - which might be stored and discharged by an array or capacitors)?
Above I suggested a number of clusters of fifty 50 mA LEDs flashing briefly one cluster after the other (2.5 A per cluster). You reckon that this is ~against the laws of physics~?
I don't believe it is impossible. I believe that a level of complexity exists in addressing such a large number of LEDs (which I have brought down to a more manageable 512), that there are trade-offs to be made in several areas (including power), that the cost could be high or even prohibitive ....hence the "Most cost-effective" in the title.
.o:0|O|0:o.
-
yes it is. really it's down to maths and the amount of combination you can implement with as little address lines as possible
........Well, its a start! (rolls eyes)
-
The laws of physics have to do with the amount of energy in a few AA batteries. There's only so much energy there no matter how you slice it. A short burst of high current, a longer period of moderate current - the amount of energy available doesn't change (much).
The mA-hr rating of a battery doesn't say how much current a battery can supply. It's a measure of the energy in the battery. At high current draws, the rating goes down.
As was stated earlier, you should start with some calculations on current draw.
-
Putting a capacitor across the battery terminals is enough to supply those short spikes of current. It will be too hard to notice anyway.
-
The laws of physics have to do with the amount of energy in a few AA batteries. There's only so much energy there no matter how you slice it. A short burst of high current, a longer period of moderate current - the amount of energy available doesn't change (much).
The mA-hr rating of a battery doesn't say how much current a battery can supply. It's a measure of the energy in the battery. At high current draws, the rating goes down.
As was stated earlier, you should start with some calculations on current draw.
You have transformed my hypothetical 15 AA batteries into "a few AA batteries". 2400 mAh per AA is an indication of the capacity and longevity of a battery. Batteries have an output resistance which means they cannot safely supply more than a certain amount of current at a time, each. However, arranged in series and parallel, the drain on each battery is divided.
e.g.
2.5 A / 7 = 334 mA per battery pair (2 x 1.5V) per cluster flash.
Apparently, AAs are more than capable of sustaining this sort of drain: http://www.candlepowerforums.com/vb/showthread.php?t=79302 (http://www.candlepowerforums.com/vb/showthread.php?t=79302)
And I haven't even touched on the ancillary use of capacitors yet.
Peace! :)
.o:0|O|0:o.
-
Well, according to the graphs, not quite 1.5V at those currents, but that is why I doubled up...
-
Might also want to check out 3D LED cubes. Another application involving thousands of LED's. Some are three color tripling the number to be driven.
-
Might also want to check out 3D LED cubes. Another application involving thousands of LED's. Some are three color tripling the number to be driven.
Thanks for that! I came across LED cubes a while back and had totally forgotten about them. Like this:
http://technabob.com/blog/2008/04/06/led-3d-cube-color-display/ (http://technabob.com/blog/2008/04/06/led-3d-cube-color-display/) :)
In all probability they used the Maxim chips suggested above, but maybe not.
(Phew, at least some people have a clue!)
.o:0|O|0:o.
PS.
This one exceeds anything I want to achieve. And yet................
http://www.seekway.com.cn/e/3d/a08/detail.htm (http://www.seekway.com.cn/e/3d/a08/detail.htm)
-
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 (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 (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 (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 (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)
Ps. Hero999, how are you deriving that pin count? I haven't worked it out for myself yet...
LEDs = n2-n
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 (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/ (http://www.i2c-bus.org/common-problems/)
I2C in software (Master):
http://ww1.microchip.com/downloads/en/AppNotes/00554c.pdf (http://ww1.microchip.com/downloads/en/AppNotes/00554c.pdf)
http://www.microchipc.com/sourcecode/#i2c (http://www.microchipc.com/sourcecode/#i2c)
1-wire:
http://ww1.microchip.com/downloads/en/AppNotes/01199a.pdf (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 (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 (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 (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 (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 (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 (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 (http://forum.sparkfun.com/viewtopic.php?t=10960)
-
Since you only need one direction communication, couldn't you use a daisy-chained SPI-like link?
-
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.
I really like the idea of experimenting with FPGAs at some point, but a suitable programmer and a couple of devices seems to become really expensive... In fact if it were not for the disproportionate costs for the hardware and also the software licenses then I would chosen this route very early on. FPGAs would also make the system more compact which is always desireable.
Also, see this: doesn't seem too bad to drive a 64x64 display
http://forum.sparkfun.com/viewtopic.php?t=10960 (http://forum.sparkfun.com/viewtopic.php?t=10960)
Thanks for that link I am going through it now.
.o:0|O|0:o.
-
Since you only need one direction communication, couldn't you use a daisy-chained SPI-like link?
If I am to base the design around multiple PICs then I would want a two way system to allow for the possibility of making full use of the parallel processing potential. It would be a secondary use of the circuit, but one I wouldn't be willing to let slip away...
.o:0|O|0:o.
-
I really like the idea of experimenting with FPGAs at some point, but a suitable programmer and a couple of devices seems to become really expensive... In fact if it were not for the disproportionate costs for the hardware and also the software licenses then I would chosen this route very early on. FPGAs would also make the system more compact which is always desireable.
What have you been looking at? Unless you're using a high-end FPGA, the tools are free. The cheapest development boards I'm aware about are the LatticeXP2 Brevia (http://www.latticesemi.com/products/developmenthardware/developmentkits/xp2breviadevelopmentkit.cfm) (was on sale for $29 and may still be for a few more hours) and the Butterfly One (http://www.gadgetfactory.net/index.php?main_page=product_info&cPath=1&products_id=18) ($49). These both come with programming cables/interfaces.
-
Thanks for those links. I wonder if I can convert that to USB without there being problems...
What have you been looking at? Unless you're using a high-end FPGA, the tools are free.
Well, I have been taking another look and just stumbled on this post concerning someone with a similar issue, but I need to learn more so I am not sure how relevant it is: http://forum.allaboutcircuits.com/showthread.php?t=13719 (http://forum.allaboutcircuits.com/showthread.php?t=13719) (post #8) Also, from what I have read it seems that FPGAs are more versatile than CPLDs, so maybe it is worth embarking on the right learning curve.
(With previous projects there was never a real need for FPGAs or other complex logic devices so I hadn't looked into them seriously; I was going by what you find listed in places like RS and Altera/ Xillinx products pages.
.o:0|O|0:o.
-
Thanks for those links. I wonder if I can convert that to USB without there being problems...
Sorry, convert what? The Butterfly One has a USB-serial chip, and is programmed over USB. However if you do need a hundred-odd I/Os, there are better boards that expose all of the pins (though nothing as cheap as these). Some sort of serial protocol is probably going to be better than connecting a hundred LEDs to one FPGA, though.
-
Thanks for those links. I wonder if I can convert that to USB without there being problems...
Sorry, convert what?
This is what I was referring to...
Please note that Lattice programming software does not operate with a 3rd party USB to parallel port adapter. Instead the USB ispDOWNLOAD Cable,HW-USBN-2A, should be used.
Some sort of serial protocol is probably going to be better than connecting a hundred LEDs to one FPGA, though.
You'd be surprised at the differences in opinion so far. Note that I wouldn't be connected the LEDs all at once and there would be some form of current amplification, based on transistors, perhaps Darlingtons or Sziklai pairs. I tend to agree with a previous poster that FPGAs would offer the best solution, especially if I wanted the produce in quantity in a commercial sense.
After reading that post#8 I posted above, I am interested in how FPGAs are actually programmed in-circuit. Maybe that would save me a bundle.
Off to consult a device datasheet for the time being.
.o:0|O|0:o.
PS. (I wonder how Dave is implementing his recently mentioned RGB LED design. It doesn't look like he is using FPGAs...)
-
Thanks for those links. I wonder if I can convert that to USB without there being problems...
Ah, it's pretty much guaranteed not to work with a cheap USB-parallel adaptor. You'd need to get the official USB cable, which costs $149 (!). If you're just experimenting, you probably want to investigate cheaper options. The official Xilinx USB cable is also expensive (~$90?) but the board I linked to before has an on-board USB interface.
After reading that post#8 I posted above, I am interested in how FPGAs are actually programmed in-circuit. Maybe that would save me a bundle.
Generally it's done through a JTAG interface. While JTAG is a standard, what happens at the PC end of a JTAG cable is not. Many development boards cut costs by implementing a proprietary USB protocol with a custom (typically) Windows application that uploads bitstreams to the FPGA or flash.
-
An intro to FPGAs and CPLDs:
http://www.instructables.com/id/A-Beginners-Guide-to-Programmable-Logic-Devices/ (http://www.instructables.com/id/A-Beginners-Guide-to-Programmable-Logic-Devices/)
According to http://www.mouldy.org/using-cplds-and-fpgas-in-hobby-electronics (http://www.mouldy.org/using-cplds-and-fpgas-in-hobby-electronics)
JTAG is the usual interface used to program a PLD (although many other options exist). You need a JTAG cable to link the FPGA and your computer. Usually, these would come as part of a development kit, with the associated 'development kit tax' which made it infeasibly expensive for hobbyists.
Now, more options are available; many devices can use SPI or I2C for programming, and free interfaces are available for that. If you want to stick with JTAG, you can build an 'official' Xilinx design, or a cheap and nasty cable. You use your free design software to program the devices over JTAG.
http://www.xilinx.com/itp/3_1i/data/common/jtg/dppb/appb.htm (http://www.xilinx.com/itp/3_1i/data/common/jtg/dppb/appb.htm)
Another circuit I found:
http://www.fpga-faq.com/FAQ_Pages/0036_Config_FPGA_with_PIC_and_Cheap_SEPROM.htm (http://www.fpga-faq.com/FAQ_Pages/0036_Config_FPGA_with_PIC_and_Cheap_SEPROM.htm)
http://www.fpga-faq.com/Images/piccfg.pdf (http://www.fpga-faq.com/Images/piccfg.pdf)
Hmm:
http://www.instructables.com/id/Ghetto-Programmable-Logic-CPLD-Development-Syste/ (http://www.instructables.com/id/Ghetto-Programmable-Logic-CPLD-Development-Syste/)
This looks cheap if it can be adapted for my purposes:
http://uk.farnell.com/jsp/search/results.jsp?N=0
Ns=PRICE_PLS_006_PRICE1|0&Ntk=gensearch_001&Ntt=Xilinx+Coolrunner&Ntx=mode+matchallpartial (http://uk.farnell.com/jsp/search/results.jsp?N=0&Ns=PRICE_PLS_006_PRICE1)
http://www.farnell.com/datasheets/84321.pdf (http://www.farnell.com/datasheets/84321.pdf)
http://www.xilinx.com/support/documentation/data_sheets/ds094.pdf (http://www.xilinx.com/support/documentation/data_sheets/ds094.pdf)
.o:0|O|0:o.
-
Have a look at the ht1632 (google it), it can drive 256 leds with one chip
-
Another way to go with this is to use CAT4016 chips, basically a shift register
with constant current outputs, 16 outputs per chip:
http://www.onsemi.com/PowerSolutions/product.do?id=CAT4016W-T1 (http://www.onsemi.com/PowerSolutions/product.do?id=CAT4016W-T1)
Form one or more serial chains building modules with these chips and drive
them up to 25 Mhz. With a large enough micro, you could drive, say, 16
serial chains at a time, by outputting bytes to two ports and toggling a
clock line.
Or for I2C fans, there's the SAA1064 which can do some light multiplexing:
http://www.nxp.com/#/pip/pip= (http://www.nxp.com/#/pip/pip=)[pip=SAA1064_CNV]|pp=[t=pip,i=SAA1064_CNV]
But really I'd do this with an FPGA and memory driving the serial chains
and have the micro just update the memory. You could easily do flashing and
fading effects as well with this.
Personally, I've moved away from multiplexing entirely. Too many issues
of insuring your micro doesn't stop and then burn out the LEDs and you
have nasty current spikes and associated noise to deal with. I just drop a
constant current driver near each display (or group of LEDs) and address
them serially and be done with it. Quite failsafe and program bugs just give
you incorrect displays. And you don't have to start switching with MOSFETs
or other such things. Plus the current drivers really help with brightness
matching (more important for 7 segment displays).
My 2 cents.
Scott
-
Thanks for those links. I will likely compare several of the LED driving solutions offered so far, once I get the control/logic side off the ground. Then hopefully I will be able to post some feedback on the results and any other useful information I might come across.........
But really I'd do this with an FPGA and memory driving the serial chains
and have the micro just update the memory. You could easily do flashing and
fading effects as well with this.
I think that as far as the control/logic side is concerned, for a design of this type with the constraints mentioned, there are only two good (reliable and financially sound) ways of moving forward:
1) Using multiple pics communicating in a master-slaves arrangement with I2C (which seems made for this). This approach makes the design modular and scalable and there are other perks like being able to experiment with parallel processing.
2) Then there is the proper way, using CPLDs or FPGAs, which is how you would go if you wanted to mass produce and market the design (though I have no such plans for that). Considering the cost of the equipment and the costly devices, in my case this is probably not much cheaper than solution (1); however, it drammatically reduces the area of PCB required and probably saves on the power consumption before the drive/LED stage.
So I have two possible ways to proceed (all the other methods being less than satisfactory for this particular design)...
I will attempt the design around the FPGA or CPLD and if the technology proves to be inaccessible in terms of cost of equipment or the associated learning curve, then I will be able to fall back on the other solution which is comparably straightforward.
Many thanks to anyone who has helped on this thread. I will share any successes and if anyone has any good FPGA/CPLD advice it would be really welcome.
Regards,
.o:0|O|0:o.