"tiny" single i2C or serial RGB led controller

[TucoRamirez]

hello,

i'm working on a RGB led controller to be put in a kinda 200 x 200 led pannel to perform some funny things ...

In this first phase i'm working with xc8 and a pic12f675,

this  is a bulky code (i havent added the serial communication capabilities )


i have still bugs to overcome...

in my output i have the 3 pwm outputs but their behave in a "strange way" ,  i mean they dont hold the '1' state all the time, they do a 10 1010101  but covering the duty cycle space ( to be fixed)

do you have any good suggestion about the way to implement the databus?   i mean a rs232 on digital  or a i2c?  which one would be the most efficient ? (i'm planning to use a  pc or another mcu to admin the bus then control the lights coulour and brightness ...

thanks in advance

Posted on: November 26, 2012, 05:42:37 17:42 - Automerged
fix: 

delete the GPIO=0 line and add an else condition to each if statusbits.carry=1 ...  to put each led in '0' mode ...

then you will have a 10KHz (approx) pwm signal 


Cheers ...


TuCo

[sarah90]

do you have any good suggestion about the way to implement the databus?   i mean a rs232 on digital  or a i2c?  which one would be the most efficient ? (i'm planning to use a  pc or another mcu to admin the bus then control the lights coulour and brightness ...

* rs232 requires precise timing between host and device, so you will need a crystal oscillator as the rc oscillators are not precise enough.
* i2c is a complex protocol that enables multiple device to be connected to the same bus consisting of just 2 wires. It really helps when the mcu has hw support for i2c (especially for the device part)
* spi is simpler, can achieve high speeds and multiple devices can be addressed using chip select lines. but you need one cs line per device.

[TucoRamirez]

if you checked my code, i have 2 free pins, so i can add a crystall ( as long as i will not need an additional white led entry ^^ ) 

btw i'll send data to one device each time, as long as the led pannel activation will activate sequentially led by led ...   maybe a broadcast mode will be useful ...

anyway, if i share the 232 bus, must i use a driver ?   i mean the fanout becomes important when i add multiple ics ...  i was thinking about a max2x2 driver andin the esclave side (F675)  a simple npn receiver state ....
what do u think?

[Gallymimu]

You can get away without a crystal on RS232 as long as the error isn't too bad.  I think the spec is +/- 2% and some of the RC oscillators in the newer pics are near or better than that.  You'd better check to be sure.  Also if you implement autobaud this can easily compensate for drift between device oscillators.  It should be pretty good as long as the temp doesn't drift markedly.  though I don't know off hand how much temp drift there is in those oscillators.

If you are going to use a UART I'd consider using RS485 2 wire half duplex.  It is intended for this type of application (in terms of having one master multiple slaves).  Otherwise I'd go I2C or microwire or something similar as they are also designed well for arbitration on a single master multiple slave setup.  Otherwise you are going to have a mess with bus arbitration and dealing with the need for a high impedance state capability on all of your TX lines to make it work.

I typically wouldn't use SPI for more than just a few devices.  It's higher speed but using an extra line for each chip select is a bummer.

There are also lots of cool tricks for communicating over your dc power bus that I don't know well off hand but you could look into.

I2C is great honestly.  Be careful as the XC8 implementation of I2C sucks really badly.  I recently rewrote a bunch of their built in functions for I2C since none of them were fault tolerant.  All of the microchip functions have while loops that hang if the bus isn't working correctly.  It is easily fixed by adding a soft timer check in those while loops (at the cost of a little processor power).

Posted on: November 26, 2012, 06:34:46 18:34 - Automerged
if you don't need bidirectional comm, then broadcast is definitely the way to go.  You can be single wire RS232 transmit or SPI transmit with no need for chip select lines (so only data out and clock would be needed).  that would probably be easiest and cheapest to implement.

[sarah90]

If you only send data to the devices, I would go for spi with two lines: clock and data to the device (MOSI). All devices can listen to the same bus and you can add an extra byte to your messages to address a single device.

You'll need an extra device to drive the spi. Not sure whether it will drive 200 devices directly.

You may look at the mcp2210: http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en556614

[Gallymimu]

If you only send data to the devices, I would go for spi with two lines: clock and data to the device (MOSI). All devices can listen to the same bus and you can add an extra byte to your messages to address a single device.

You'll need an extra device to drive the spi. Not sure whether it will drive 200 devices directly.

You may look at the mcp2210: http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en556614

If he uses a chip with an SPI port it might be able to drive 200 devices especially if he keeps the speed low (few hundred kbits or so).  A check of the input/output impedance and perhaps the input capacitance.  Also you could break it up with 10 TTL buffers if it was an issue.  That MCP2210 is a sure fire solution if he want's to control from the PC. 

Make sure that the distance you are transmitting isn't very far.  SPI/TTL isn't designed to go more than a few feet at full speed.  Again, lower speeds will get you more distance.

[sarah90]

Coming back on the design. 200xpic12f675 is not cheap. Why not combine several leds and use larger pin count devices?

[TucoRamirez]

no matter about pin number, but i wanted to do each led independnt in order to give easy maintenance ...   otherwise i would opt for another more epic device ^^ ...  ( by now i will use this cuz i can debug simulate it on isis and then after the final codesize i ll migrate maybe to another one ) (and as you can see as long as my routine can work versus the bitrate of the bus , i can extend the pwm out number of pins ^^ )

[Ichan]

With no intention to break your development spirit, i am suggesting you to look into a ready made solution. They have all the things required, pwm brightness, constant current driver, spi like daisy chained serial, communication line (cable) driver, dot correction, high speed clock, etc - all in single chip which is i think won't go higher than 12f675 price. One of them is allegro A6281, many other which is much cheaper can be sourced from taiwan/china.

-ichan

[TucoRamirez]

you broke my spirit ^^  thanks ichan (but if i can fit my  final code into a small code i"ll use a pic10 and i"ll have something interesting ...

[flo0319]

200x200 RGB leds with one pic for each one

   OK. 1 LED need 20ms ON and 980ms OFF in 1 Second. in this case you can control 50 leds with the same PWM channel (serial commands) and a multiplexed logic selection( to control Vcc or GND for common Anode or Cathode). For each RGB you need also 3 PWM channel (simultaneously). You can find MCU with a big numbers of PWM channels or you can use a software PWM ( but you need time for communication also).

  For communication can be use 1 MCU ( Master ) with RS232, USB, Parallel buses  for PC, and SPI or other UART just in TX mode to transmit LEDs map.

  If you want to build a TV panel, I think you need a high speed processor architecture or FPGA platform.

 

[Ichan]

you broke my spirit ^^

Haha, my apology then  .

I will follow this closely if you decide to continue, just quick read your code - how about using timer interrupt as the pwm timebase?

The bad thing about pic10 is they have no interrupt.

-ichan

[TucoRamirez]

flo0139  : sorry, is not 200 x 200 ^^  maybe 8 x 8 or 10 x 10  ^^  ,

Ichan:  in fact i dont care too much about the frequency as long as it will be higher than 100hz ^^
          yes, the pic10 has no interrupt but i'll try to avoid use that as possible... but i'll use surely a pin interrupt to shoot the bus response...

anyway is just to control a square and control the colour/brightness to test another more complicated vision circuit ....

[flo0319]

Tuco, in 12F683 you have 3 Timers, 1 Timer can be configured for PWMs timing, and other timer can be configured for 1 wire serial RX, or 2 pins for SPI software. But, I think is easy and cheap if you use a pic with SPI or UART modul integrated ( also with PWM, or just 3 Timers)

[Faros]

The following is an old but still valid post "PICBASIC PIC16F767 RGB Led Controller", if you can translate the PICBASIC code, the example is showing the use of 3 PWM hardware channels, this way you can avoid using a very short interrupt timer setting, short timer setting is needed to correctly time the PIC ports in order to get the PWM to function properly. also short timer settings will make your communication task very hard if not buffered.

http://www.sonsivri.to/forum/index.php?topic=24131.msg82289#msg82289

[TucoRamirez]

ok, i decided to use a 12f1840 ( nice price for all the extra capabilities vs a 12f675 ... eusart, internal 32M oscillator and more space for code i.e. ) so i'll do some tweaks to fit into the correc registers... btw, i don't know if the usart.h from plib on xc8 is compatible with ( that means that i haven't tested yet ^^ )  ...  so the tactic i'll use is to receive serial data by the rx interrupt , load the status of the pwm and the propagate it via a serial shift register (latched) to mantain lots of pwm outs ... now i'll study the time frame to ensure the correct baudrate to not perturb the normal operation of the led array when data is read ...

[Ichan]

Interesting use of status register on your C code:

Code:

PwmRamp++;
if (STATUSbits.ZERO == 0)

Wonder how the generated assy compared to this:

Code:

if(!++PwmRamp)

Both will make a headache when someday the var PwmRamp changed to other than char.

-ichan

[TucoRamirez]

yes you're right but i will migrate my crapy code to a interrupt based one to conserv that size and using tmr to extent the ++ interval  ... gimme this weekend to prepare something more interesting (even if you killed my spirit ^^ )

btw i m not an C expert yet :p

[sarah90]

Both will make a headache when someday the var PwmRamp changed to other than char.

I don't think it is bad practice to make use of the size of a variable in embedded code as long as you use typedefs like uint8.

[Ichan]

?

On this case, if the PwmRamp variable changed let say from char to int (whatever it use typedef or not) then the pwm resolution will be automatically changed from 255 to 65535 - will took 256 times longer to do one pwm period, the led will be flicker.

I guess OP knows Assembly better than C and/or porting assy code to C.

-ichan

[sarah90]

On this case, if the PwmRamp variable changed let say from char to int (whatever it use typedef or not) then the pwm resolution will be automatically changed from 255 to 65535 - will took 256 times longer to do one pwm period, the led will be flicker.

When you use typedefs like uint8 it will always have the resolution of 8 bits (256 ) even when you move the code to another platform or architecture. It may be mapped to another integer base type, but it will have the 8 bit resolution. Unless of course an 8 bit integer type is not supported on that platform.

[ZASto]

On the LED side you can use WS2801 chip. It is an RGB led controller. You can not beat it's price with any uC.

[Faros]

you can beat the price with the PIC10LF322 from Microchip , it targets LED drivers apps. the price tag is as low as the WS2801, provided that you can put your code in 896 Byte !! ... and you will still be one PWM short after all.

[ZASto]

Welllll for WS2801 you do not need to code anything. You just feed the string of WS with data.

[TucoRamirez]

ok i found a solution ...  200 hz output and > 64 PWM outputs with shift registers and the pic12f1840   controlled by RS232  ...  i tested on simulator now i'll buy the ci to real test

[TucoRamirez]

btw, i have an offline question ...

it's concerning the following...

if i made a led pannel (10x10 , RGB)  , and i have to do some tests with a camera to check patterns and detect colours (on a translucid surface)  what will be the most efficient way to not perturb on any way the sensors :   simultaneous pwm signal on each led  or  multiplexed like zuisti's MMD  ?   

its my one penny question as long as i have not received the components yet ^^

[ehnonymouse]

  what will be the most efficient way to not perturb on any way the sensors

I'd like to help you with this, but I'm afraid I don't understand what you mean here. Is there any chance you could explain?

[Gallymimu]

I can only guess he is talking about flicker due to the frame rate of the camera?  Is that what you are asking?

[TucoRamirez]

yes off course, i mean, a cmos image sensor ( in a first state a webcam )  will watch to the led panne ( i'll put a translucid screen)   to test some colour , brightness and pattern profile detection algorithms...   but i'm affraid if i use a multiplexed matrix technique the sensor will have troubles identifying the whole pattern at a specific analyse instant  (or instant picture of the pannel)

thanks for your interest, 

[SpaleKG]

If you use camera (ie. slowest web camera with 10fps) then you need to have vertical scan at least 50-100Hz in your muxed matrix. For better cameras like 20-25fps that should be x10 about vertical scan (200-250Hz) of your LED panel.

[TucoRamirez]

and in the case of a picture taken of it???   (i'll confirm the strategie of the 'robotic eye' testing the pannel in 2 weeks when the chief of the project will be back from hole-in-days )

thanks again, at least i'll do a parallel pwm with a tiny pic just for initial test then i'll switch to a usb F2550 maybe to use its more ports and pins ... still in paper and pen mode until final response about the flicker stuff

[Gallymimu]

If your LED power is low enough you could put some capacitors on them to stabilize the output and reduce flicker.

[SpaleKG]

and in the case of a picture taken of it???   (i'll confirm the strategie of the 'robotic eye' testing the pannel in 2 weeks when the chief of the project will be back from hole-in-days )

thanks again, at least i'll do a parallel pwm with a tiny pic just for initial test then i'll switch to a usb F2550 maybe to use its more ports and pins ... still in paper and pen mode until final response about the flicker stuff

The single shot picture is one frame. Speed of that frame (how long camera will store all pixels) is as long as one frame in 25fps. So if your camera does 25fps then your single shot will be 1/25 of second. So it is same as for moving pictures and do the math. Also some cameras (like camera in iPhone) have delaying until picture is stable (no movement). Those type of cameras avoiding flickering.

[Ichan]

ok i found a solution ...  200 hz output and > 64 PWM outputs with shift registers and the pic12f1840   controlled by RS232  ...  i tested on simulator now i'll buy the ci to real test

I would like to see the schematic and code, it must be interesting - so you will generate 64 channel pwm using serial in parallel out shift register, it must be a tricky one.

-ichan