Hi,
I'm completely new to XMOS devices, but they look interesting!
I have a design requirement for a multi-channel LED controller for a large chandelier.
The LEDs are RGBW running at 350mA each, so I have designed a lamp unit with a series switching circuit that simply needs individual logic level PWM drive signals.
I want 14bit PWM resolution to achieve smoothness of low level fading. The PWM frequency does not need to be more than ~1kHz to avoid movement strobing. I plan to control each chandelier using an ethernet port. So far so good, but as I have 120 lamps, that totals 480 PWM signals!
I've concluded that I have three options for my control board:
1. 120 x PIC controllers each with 4 PWM outputs, controlled over SPI / I2C bus from a master uP
2. One or more FPGAs generating 480 PWM signals
3. XCORE devices generating 480 PWM signals
So, can this be done with XCORE devices, and would this be the best option :)
Multi-channel PWM for LED controller
-
- Junior Member
- Posts: 6
- Joined: Thu Mar 31, 2011 4:44 pm
-
- XCore Expert
- Posts: 844
- Joined: Sun Jul 11, 2010 1:31 am
Since the output only has to be 1kHz, I'd use some shift registers (which you can
then also put closer to the leds, less wiring that way). For example, 30 16-bit
shift registers.
then also put closer to the leds, less wiring that way). For example, 30 16-bit
shift registers.
-
- XCore Addict
- Posts: 216
- Joined: Wed Feb 10, 2010 10:26 am
I second the idea of shift registers.
I personally like using MCP23S08 or MCP23S16 for shift registers, since they are real SPI output extenders (if you need an input too). But 74*595 can be sufficient. And there are a lot of options esp for LEDs.
For my HL1606 project I have written som pulse density encoder to get a very smooth high frequency grayscale generation - the advantage against PWM is that the switching frequency is higher (for the same number of gray scale levels and output frequency).
If you need the code, before I am able to upload everything to githhub just drop me a not and I will give you the code (most probably by speeding up my github upload ;) )
I personally like using MCP23S08 or MCP23S16 for shift registers, since they are real SPI output extenders (if you need an input too). But 74*595 can be sufficient. And there are a lot of options esp for LEDs.
For my HL1606 project I have written som pulse density encoder to get a very smooth high frequency grayscale generation - the advantage against PWM is that the switching frequency is higher (for the same number of gray scale levels and output frequency).
If you need the code, before I am able to upload everything to githhub just drop me a not and I will give you the code (most probably by speeding up my github upload ;) )
-
- Junior Member
- Posts: 6
- Joined: Thu Mar 31, 2011 4:44 pm
Thanks. I'd love to put the shift registers nearer to the leds - if only I had room, but the chandelier design requires a very compact lamp unit.segher wrote:Since the output only has to be 1kHz, I'd use some shift registers (which you can
then also put closer to the leds, less wiring that way). For example, 30 16-bit
shift registers.
With shift registers, configured as 30 x 16bits, won't these require a very high update rate?
For 1kHz pwm that requires 30 pulse streams each 65.536MHz does it not?
Is it definitely possible to generate 30 pulse streams at that speed with the Xcore devices?
Correction, 1kHz pwm at 14bits resolution, 16Mhz ?
Last edited by JohnL on Fri Apr 01, 2011 10:06 am, edited 1 time in total.
-
- Junior Member
- Posts: 6
- Joined: Thu Mar 31, 2011 4:44 pm
Thanks for your suggestions.Interactive_Matter wrote:I second the idea of shift registers.
I personally like using MCP23S08 or MCP23S16 for shift registers, since they are real SPI output extenders (if you need an input too). But 74*595 can be sufficient. And there are a lot of options esp for LEDs.
For my HL1606 project I have written som pulse density encoder to get a very smooth high frequency grayscale generation - the advantage against PWM is that the switching frequency is higher (for the same number of gray scale levels and output frequency).
If you need the code, before I am able to upload everything to githhub just drop me a not and I will give you the code (most probably by speeding up my github upload ;) )
I am concerned about the high pulse rate required for 1kHz pwm using shift registers, so your alternative modulation system sounds good. Is it like the scheme here: http://www.batsocks.co.uk/readme/art_bcm_1.htm
Thanks for your kind offer of code, at this stage I need to decide to go with Xcore device + shift registers, or a fpga based scheme, so I just need to know whether the Xcore scheme is definitely feasible. I'll then take it from there.
-
- XCore Addict
- Posts: 216
- Joined: Wed Feb 10, 2010 10:26 am
Thanks for the hint about the BCM code - that is exactly what I was looking for. I will play around this in the next weeks (currently just too busy).JohnL wrote: ...
I am concerned about the high pulse rate required for 1kHz pwm using shift registers, so your alternative modulation system sounds good. Is it like the scheme here: http://www.batsocks.co.uk/readme/art_bcm_1.htm
For my HL1606 driver I had also timing problems, but an intrinsincly parallelism (a led string is a led string is a led string). So I paralleled 8 strings on one 8bi port - this can reduce the time you need to update the shift registers.JohnL wrote: Thanks for your kind offer of code, at this stage I need to decide to go with Xcore device + shift registers, or a fpga based scheme, so I just need to know whether the Xcore scheme is definitely feasible. I'll then take it from there.
The more I talk the more I am willing to try to extract & publish my code as soon as possible ;)
Marcus
-
- XCore Expert
- Posts: 844
- Joined: Sun Jul 11, 2010 1:31 am
Then you'll have to route many wires there instead, which takes way more space if you ask me.JohnL wrote:I'd love to put the shift registers nearer to the leds - if only I had room, but the chandelier design requires a very compact lamp unit.
But you should know best :-)
16 x 1kHz is 16kHz. Say 20kHz or so, you probably want to do a separate latch signal.With shift registers, configured as 30 x 16bits, won't these require a very high update rate?
For 1kHz pwm that requires 30 pulse streams each 65.536MHz does it not?
You can do all 30 in parallel, but even if you would do all on separate I/O ports (you don't
have that many, but for the sake of argument), that would make only ~600kHz.
-
- Junior Member
- Posts: 6
- Joined: Thu Mar 31, 2011 4:44 pm
I know, but I'm not designing the metalwork! I am intending to run 6wires to each lamp unit, through narrow tubes, each wire is 30awg so pretty small overall. When the wires arrive at the control board it will get interesting... I am envisaging a mother and multiple daughter board setup with the daughter boards each having one or more 6 way lamp connectors on. The motherboard will have power and control stuff.segher wrote:Then you'll have to route many wires there instead, which takes way more space if you ask me.JohnL wrote:I'd love to put the shift registers nearer to the leds - if only I had room, but the chandelier design requires a very compact lamp unit.
But you should know best :-)
16 x 1kHz is 16kHz. Say 20kHz or so, you probably want to do a separate latch signal.With shift registers, configured as 30 x 16bits, won't these require a very high update rate?
For 1kHz pwm that requires 30 pulse streams each 65.536MHz does it not?
You can do all 30 in parallel, but even if you would do all on separate I/O ports (you don't
have that many, but for the sake of argument), that would make only ~600kHz.[/quote]
Err, thanks, that sounds better!
-
- XCore Addict
- Posts: 216
- Joined: Wed Feb 10, 2010 10:26 am
I have just had a look at my HL1606 code, which slowy and unoptmized encodes the data with a real bit density modulation (so lot of stuff to improve)
From the wave form analyzis of the simulator I can see that my code (i don't know if it was debug or release - let's assume release to be more conservative) has a pixel frequency of 38kHz (one bit) - so updating the 66 leds in the string takes about 1.5kHz
I hope this is in the ballpark you want to play ;)
From the wave form analyzis of the simulator I can see that my code (i don't know if it was debug or release - let's assume release to be more conservative) has a pixel frequency of 38kHz (one bit) - so updating the 66 leds in the string takes about 1.5kHz
I hope this is in the ballpark you want to play ;)
-
- Junior Member
- Posts: 6
- Joined: Thu Mar 31, 2011 4:44 pm
Well I hope so!Interactive_Matter wrote:I have just had a look at my HL1606 code, which slowy and unoptmized encodes the data with a real bit density modulation (so lot of stuff to improve)
From the wave form analyzis of the simulator I can see that my code (i don't know if it was debug or release - let's assume release to be more conservative) has a pixel frequency of 38kHz (one bit) - so updating the 66 leds in the string takes about 1.5kHz
I hope this is in the ballpark you want to play ;)
Sorry if I'm being dense, and I realise you are working with BDM, but I'm still trying to get my head around 14bit resolution pwm generation, and the use of shift registers. This is troubling me.
To make it clear, every led needs it's own individually settable variable drive = 480 individual drives. Please bear with me while I look below at pwm generation.
Assuming I need 14bit resolution pwm, and a prf of 1kHz, for the minimum ON pulse width I would need to generate 1/16384 th of maximum ON width. I could do that by taking a 16.384MHz oscillator and taking one pulse every 1000us. For wider output pulses, I join more oscillator pulses together, up to 16384 pulses which the oscillator produces 1000times/sec as intended. So far so good.
I then need to generate 16 of these PWM signals, one for each led connected to my 16bit shift register.
I assume that there isn't anything clever that I've missed about the use of shift registers, they are only a means of serial to parallel conversion. That means that to load them, they have to be clocked much faster than each channel of data, i.e. 16 x 16.384MHz = 262.144MHz to preserve my pulse widths.
That seems rather fast to me. Is there a flaw in my argument?