Sonsivri
 
*
Welcome, Guest. Please login or register.
Did you miss your activation email?
December 09, 2016, 12:57:19 00:57


Login with username, password and session length


Pages: [1] 2  All
Print
Author Topic: "tiny" single i2C or serial RGB led controller  (Read 3779 times)
0 Members and 1 Guest are viewing this topic.
TucoRamirez
Senior Member
****
Offline Offline

Posts: 277

Thank You
-Given: 197
-Receive: 95


Tuco ... dead or Alive


« on: November 26, 2012, 06:08:04 18:08 »

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  Smiley


Cheers ...


TuCo
Logged

Whoever double crosses me and leaves me alive... he understands nothing about Tuco.
sarah90
Active Member
***
Offline Offline

Posts: 109

Thank You
-Given: 6
-Receive: 11



« Reply #1 on: November 26, 2012, 06:09:23 18:09 »

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.

Logged
TucoRamirez
Senior Member
****
Offline Offline

Posts: 277

Thank You
-Given: 197
-Receive: 95


Tuco ... dead or Alive


« Reply #2 on: November 26, 2012, 06:23:16 18:23 »

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?
Logged

Whoever double crosses me and leaves me alive... he understands nothing about Tuco.
Gallymimu
Hero Member
*****
Offline Offline

Posts: 579

Thank You
-Given: 101
-Receive: 151


« Reply #3 on: November 26, 2012, 06:36:52 18:36 »

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.
Logged
sarah90
Active Member
***
Offline Offline

Posts: 109

Thank You
-Given: 6
-Receive: 11



« Reply #4 on: November 26, 2012, 06:44:26 18:44 »

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
Logged
Gallymimu
Hero Member
*****
Offline Offline

Posts: 579

Thank You
-Given: 101
-Receive: 151


« Reply #5 on: November 26, 2012, 07:26:53 19:26 »

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.
Logged
sarah90
Active Member
***
Offline Offline

Posts: 109

Thank You
-Given: 6
-Receive: 11



« Reply #6 on: November 26, 2012, 07:54:34 19:54 »

Coming back on the design. 200xpic12f675 is not cheap. Why not combine several leds and use larger pin count devices?
Logged
TucoRamirez
Senior Member
****
Offline Offline

Posts: 277

Thank You
-Given: 197
-Receive: 95


Tuco ... dead or Alive


« Reply #7 on: November 26, 2012, 08:15:29 20:15 »

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 Smiley ^^ )
« Last Edit: November 26, 2012, 08:17:52 20:17 by TucoRamirez » Logged

Whoever double crosses me and leaves me alive... he understands nothing about Tuco.
Ichan
Hero Member
*****
Offline Offline

Posts: 840

Thank You
-Given: 312
-Receive: 387



WWW
« Reply #8 on: November 26, 2012, 09:01:12 21:01 »

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
Logged

There is Gray, not only Black or White.
TucoRamirez
Senior Member
****
Offline Offline

Posts: 277

Thank You
-Given: 197
-Receive: 95


Tuco ... dead or Alive


« Reply #9 on: November 26, 2012, 09:17:19 21:17 »

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 ...
Logged

Whoever double crosses me and leaves me alive... he understands nothing about Tuco.
flo0319
Junior Member
**
Offline Offline

Posts: 82

Thank You
-Given: 7
-Receive: 16


« Reply #10 on: November 26, 2012, 09:29:32 21:29 »

200x200 RGB leds with one pic for each one Huh

   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.

 
Logged
Ichan
Hero Member
*****
Offline Offline

Posts: 840

Thank You
-Given: 312
-Receive: 387



WWW
« Reply #11 on: November 26, 2012, 09:31:04 21:31 »

Quote
you broke my spirit ^^

Haha, my apology then  Grin.

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
Logged

There is Gray, not only Black or White.
TucoRamirez
Senior Member
****
Offline Offline

Posts: 277

Thank You
-Given: 197
-Receive: 95


Tuco ... dead or Alive


« Reply #12 on: November 26, 2012, 09:37:03 21:37 »

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 ....
Logged

Whoever double crosses me and leaves me alive... he understands nothing about Tuco.
flo0319
Junior Member
**
Offline Offline

Posts: 82

Thank You
-Given: 7
-Receive: 16


« Reply #13 on: November 26, 2012, 10:34:27 22:34 »

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)

Logged
Faros
Senior Member
****
Offline Offline

Posts: 253

Thank You
-Given: 125
-Receive: 178


« Reply #14 on: November 26, 2012, 11:47:46 23:47 »

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


Logged
TucoRamirez
Senior Member
****
Offline Offline

Posts: 277

Thank You
-Given: 197
-Receive: 95


Tuco ... dead or Alive


« Reply #15 on: November 28, 2012, 11:10:14 11:10 »

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 ...
Logged

Whoever double crosses me and leaves me alive... he understands nothing about Tuco.
Ichan
Hero Member
*****
Offline Offline

Posts: 840

Thank You
-Given: 312
-Receive: 387



WWW
« Reply #16 on: November 29, 2012, 08:39:13 20:39 »

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
Logged

There is Gray, not only Black or White.
TucoRamirez
Senior Member
****
Offline Offline

Posts: 277

Thank You
-Given: 197
-Receive: 95


Tuco ... dead or Alive


« Reply #17 on: November 30, 2012, 01:18:25 01:18 »

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
« Last Edit: November 30, 2012, 01:21:48 01:21 by TucoRamirez » Logged

Whoever double crosses me and leaves me alive... he understands nothing about Tuco.
sarah90
Active Member
***
Offline Offline

Posts: 109

Thank You
-Given: 6
-Receive: 11



« Reply #18 on: November 30, 2012, 05:00:33 17:00 »

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.
Logged
Ichan
Hero Member
*****
Offline Offline

Posts: 840

Thank You
-Given: 312
-Receive: 387



WWW
« Reply #19 on: November 30, 2012, 09:46:07 21:46 »

?

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
Logged

There is Gray, not only Black or White.
sarah90
Active Member
***
Offline Offline

Posts: 109

Thank You
-Given: 6
-Receive: 11



« Reply #20 on: November 30, 2012, 11:29:20 23:29 »

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.
Logged
ZASto
V.I.P
Newbie
*****
Offline Offline

Posts: 18

Thank You
-Given: 62
-Receive: 10



WWW
« Reply #21 on: December 05, 2012, 11:18:44 23:18 »

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.
Logged

Make no mistake between my personality and my attitude.
My personality is who I am.
My attitude depends on who you are.
Faros
Senior Member
****
Offline Offline

Posts: 253

Thank You
-Given: 125
-Receive: 178


« Reply #22 on: December 08, 2012, 12:28:49 12:28 »

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.
Logged
ZASto
V.I.P
Newbie
*****
Offline Offline

Posts: 18

Thank You
-Given: 62
-Receive: 10



WWW
« Reply #23 on: December 09, 2012, 11:40:15 23:40 »

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

Make no mistake between my personality and my attitude.
My personality is who I am.
My attitude depends on who you are.
TucoRamirez
Senior Member
****
Offline Offline

Posts: 277

Thank You
-Given: 197
-Receive: 95


Tuco ... dead or Alive


« Reply #24 on: December 10, 2012, 12:07:57 12:07 »

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

Whoever double crosses me and leaves me alive... he understands nothing about Tuco.
Pages: [1] 2  All
Print
Jump to:  


DISCLAIMER
WE DONT HOST ANY ILLEGAL FILES ON THE SERVER
USE CONTACT US TO REPORT ILLEGAL FILES
ADMINISTRATORS CANNOT BE HELD RESPONSIBLE FOR USERS POSTS AND LINKS

... Copyright 2003-2999 Sonsivri.to ...
Powered by SMF 1.1.18 | SMF © 2006-2009, Simple Machines LLC | HarzeM Dilber MC