Serial comunication

[Misterbenn]

i'm making a mood light project, the basic idea is that i have 5 units, each unit controls 4 LEDs (red green blue and white). this gives me a total of 20 elements to control. these will all be controled by a main unit.
i want each LED to have variable brightness.
it will operate in three modes, 1) where all the units are given the same instruction, all produce the same light levels
2) where the units are out of phase so while one is red teh other is green the other is blue so on
3) manualy set levels, set by a pot, but all units have the same light levels.

size is a very important issue here, i want the minimum amount of wires posible so i've chosen serial comunication with each unit.

now i have very limited experiance with PICs, i only have the PIC kit1 starter kit, limiting the pics i can use, also i only know assembeler, (would it be worth learning i diferent programing language, such as C)

i've done a basic basic block diagram of my system.

i would really love any help / advice you could give me, would you sugest a diferent method?

 

[eblc1388]

..i have 5 units, each unit controls 4 LEDs (red green blue and white).

OK.

2) where the units are out of phase so while one is red teh other is green the other is blue so on

What should the color for the fifth unit be? You said you only have 4 LEDs of different colors. Maybe you would add yellow or amber to your mood LED collection.

 

[Misterbenn]

What should the color for the fifth unit be? You said you only have 4 LEDs of different colors. Maybe you would add yellow or amber to your mood LED collection.

they were just examples, the acctual colours would be a mixture of the 4 diferent colours the sub-units control eg red and green = purpple.

i'm going to use 4 bits to define the light level of each LED giving me 16 brightnss levels for each LED, and the LEDs will be flashed at a rate proportional to the 4 bit binary value to give the impresion of brightlness (havent thought of the code for this yet)

because i have 5 units i will need 3 adress bits, these will be followed by the 4 4 bit instructions for the brightness of the 4 LEDS of each unit. giving my a total of a 21 bit serial transmition. i will need a start and stop bit as well as a parity bit so the units can reject the data if it isnt valid giving me a total of 24 bits. again havent thought of the code for this.

its all just an idea atm

 

[Jay.slovak]

because i have 5 units i will need 3 adress bits, these will be followed by the 4 4 bit instructions for the brightness of the 4 LEDS of each unit. giving my a total of a 21 bit serial transmition. i will need a start and stop bit as well as a parity bit so the units can reject the data if it isnt valid giving me a total of 24 bits. again havent thought of the code for this.

So basicaly you are using your own serial protocol? I suggest you should use I2C instead, that would be much better.

now i have very limited experiance with PICs, i only have the PIC kit1 starter kit, limiting the pics i can use, also i only know assembeler, (would it be worth learning i diferent programing language, such as C)

Assembly will be ok with this project. There is no need to switch to different language.

Also, read this: https://www.electro-tech-online.com/threads/circuit-impedance-loading.15292/

 

[mechie]

Serial comms to multiple units

If you are only controlling a few (20) LEDs split across a few locations...

Why not stick to bog-standard RS232 format and send an instruction string of 20 bytes, the first card reads the first four bytes, removes them from the string and passes the rest (16 bytes) on along the chain. The next card reads four bytes, deletes them and passes the remainder on.
The last card in the chain reads the last 4 bytes, deletes them and sends nothing on (there is nothing else to recieve anyway).
This would allow the cards to use a full 8 bits for each LED, even if you don't use all 256 brightnesses.

I reckon this could be done fairly easily, and if the controllers aren't too far apart you might even use 5v logic levels instead of full RS232 spec.
The code could be easier to write as all the controllers are identical and could be extended by simply adding more to the chain and sending more bytes from the 'master'.

Or ... (a bit harder, I think) send an address byte followed by a brightness byte. Each controller will need to know its base address and will accept this address or the next three, each refrerring to one of its LEDs.
Again, you would have a full 8 bits for each LED. This would require each controller to be programmed with an address or read an address from a swith bank to know its position in the chain.

RS232 could easily cope with this and you would be lucky to see any effects of one controller being addressed before the others.

Ignoring power for the controllers and LEDs, only two wires would be required, ground and 'transmit data'

If you learn assembler programming you will never need another language, if C++ can do a job then so can assembly language :wink:

 

[audioguru]

Why use an almost white LED?
If the RGB colours are correct, pure white is made by having their currents in the correct ratios.

I made some colour LED analog mood lights that slowly brighten and dim. The ramps are logarithmic and have slightly different frequencies so all colours and brightness levels are produced smoothly.

A few years later I found a similar light at Wal-Mart, except its brightness levels were about 32 obvious jerky digital steps. It also makes many neat patterns and sequences them, and tinny-sounding bird and surf sounds. :lol:

 

[Misterbenn]

audioguru:
, i would of also of used analog but size of the sub-units is key here and ramp generators, or DAC would of been to bulky so i'm having to use the pic method.
also i've done projects like this b4 and never seem to be able to get a nice white with RGB although yes in theory it is posible. i think it must be because my LEDs are pure red/ green / blue but i may try this project out with out the white leds at first as they cost a fair bit more.

Jay.slovak:
this sounds good, though i need to keep the sub-unit size down, could this system interface directly with say 12F675? i'd prefer to keep it down to just one wire if pos

mechie:
RS232 sounds perfect, however i dont know much about it, and affter googling it, it seems to just be a computer port right? ideally i want an indevidual unit, not one conected to the PC, but this kind of chain system sounds perfect, and elimintaes the need for addresses , so i'll prob try and recreate this type of serial comunication using a pic, i assume this would be synchronous?

 

[Jay.slovak]

Jay.slovak:
this sounds good, though i need to keep the sub-unit size down, could this system interface directly with say 12F675? i'd prefer to keep it down to just one wire if pos

mechie:
RS232 sounds perfect, however i dont know much about it, and affter googling it, it seems to just be a computer port right? ideally i want an indevidual unit, not one conected to the PC, but this kind of chain system sounds perfect, and elimintaes the need for addresses , so i'll prob try and recreate this type of serial comunication using a pic, i assume this would be synchronous?

I2C is multidevice synchronus two wire half-duplex serial BUS, designed for communication between many devices (each one having it's own unique address).
As for RS-232... is generally refered to PCs, but if you ignore voltage levels and use standart TTL (0-5V) it will appear as a standart asynchronus full-duplex two wire (one wire for each direction) BUS. it was NOT designed for multiple IC communication, but you can connect many IC's on the same wire to listen for commands (sending commands back will require more things to take into acount).

Or there is 1Wire BUS (Dallas), which is pretty usefull to. It's half-duplex asynchronus serial BUS designed for multidevice operation with relativelly slow speed (14Kbit). Take a look at it at www.maxim.com

 

[mechie]

Comms

mechie:
RS232 sounds perfect, however i dont know much about it, and affter googling it, it seems to just be a computer port right? ideally i want an indevidual unit, not one conected to the PC, but this kind of chain system sounds perfect, and elimintaes the need for addresses , so i'll prob try and recreate this type of serial comunication using a pic, i assume this would be synchronous?

RS232 is a communication 'protocol', it seems far more daunting than it needs to be.
It could be used as a 'sort-of synchronous'(after a fashion) comms link but never is, there is no clock signal for the bits of data- RTS could be seen as a 'byte ckock' but this is me just jibbering - back to the idea ...

If you are using PICs then they may contain hardware UARTs (to do the comms fancy stuff for you) or you can do it in software quite easily, it isn't that big a job!
I can't see anything in your spec for what distances are involved between units - a few metres of wire should be no problem but 50m could be problematic. To minimise component count 5v logic levels seems the sensible choice as the PIC needs no support devices (MAX232 to give true RS232 voltages).
Another missing info point is "what is the controller going to be ?" - I assume ther will be a 'control pad' somewhere - will it be a seperate unit or one of the LED control units?
My idea is that the 'master' unit will send out a full command string of 20 bytes to the first PIC-based LED controller, this looks at the full string, reading the lot into its memory, it uses the first four bytes for its LEDs, deletes them from the string and then transmits the remainder (in this case, 16 bytes) on along the chain. The next controller does exactly the same, now passing 12 bytes on.
This sytem NEEDS a common wire and a data wire to work - 2 conductors, and power to each unit.

If you fancy trying this I could offer to help with the code :?:

As for RS-232... ...it will appear as a standard asynchronus full-duplex two wire (one wire for each direction) BUS. it was NOT designed for multiple IC communication

Full-duplex is one of the options of RS232, but here I am suggesting a 'simplex' (comms only in one direction) system - there should be no need to ever read back from one of these devices.

... it was NOT designed for multiple IC communication

No two controllers have their recieve lines are connected to any one transmit line - I am suggesting a daisy-chain arrangement, one-to-one, anyway, I connect THREE computers together with RS232 (single port on each computer) - I just 'bend the rules' a bit !

 

[Misterbenn]

distances will be a meter max, and the control unit is a seperate unit and isnt a LED control unit, its only function is to tell the other units what do do.

My idea is that the 'master' unit will send out a full command string of 20 bytes to the first PIC-based LED controller, this looks at the full string, reading the lot into its memory, it uses the first four bytes for its LEDs, deletes them from the string and then transmits the remainder (in this case, 16 bytes) on along the chain. The next controller does exactly the same, now passing 12 bytes on.

this idea seems perfect, one thing why would it need two wires? for handshaking? couldnt this be avoided by using synchronous transmition?

i'll prob be using 16F684 for the main controler and 12F675 for the sub-units, or similar.

thanq for the offer of help with the code, i may very well take you up on that

and as for bending the rules, thats how new systems are discoverd!

 

[Jay.slovak]

this idea seems perfect, one thing why would it need two wires? for handshaking? couldnt this be avoided by using synchronous transmition?

I think you misunderstod synchronus and asynchronus transmissions. Synchronus requires 2 wires (one for clock, second for data). Asynchronus will be fine with one (Start and Stop bits will take care of syncronisation). So if you want to save wires, look for asynchronus (it's slower then synchronus).

 

[mechie]

Daisy-chained Mood lights

one thing why would it need two wires? for handshaking? couldnt this be avoided by using synchronous transmition?

There seems to be some confusion about how I counted two wires for data. I am referring to a 'data' line and a 'common' or 0v line, the return path for the current.
A three-core cable (or a bit of 4 core alarm system cable?) could carry 0v, a positive power supply and a data line, the 0v is then negative supply and data return.
No handshaking would be required as each controller would listen for new commands and would be plenty fast enough to capture data at 9600 baud (I think this would be faster than required for the data anyway), I have programmed a PIC to recieve serial data at 19200 baud without problem (4MHz clock).

thanq for the offer of help with the code, i may very well take you up on that

No problem - an interesting project and a chance for me to learn :!:

and as for bending the rules, thats how new systems are discoverd!

True, but read below :? :wink:

 

[Misterbenn]

ah right got ya
so i know how i'm going to tell the units what to do now.

i still have one problem, how can i get the units to then use this binary signal to vary the brightness of the LEDs, clearly flashing them would work. i could use the binary value to tell the units how long to turn each LED on i guess that would work....

i'll start building the units soon then i can start to have a lil play

 

[mechie]

LED brightness

To control the LED brightness I would suggest some form of pulse-width modulation, I guess that is what you are thinking of ?
Maybe to simultaneously control 4 LEDs you could create a single program loop which decrements a counter, when the counter matches the 'control value' sent over the comms link the appropriate LED is turned ON, staying on until the counter reaches zero, at which point all LEDs are turned off. The higher the 'control value', the longer the LED is on.
This would allow all four (or more!) LEDs to be modulated independently. If a value of 255 is sent then the LED is permanently on, if 0 is sent then the LED is permanently off.

Each loop of the program would need to ...
. . . check the comms port, if required, jump to comms routine, else
. . . decrement the counter,
. . . compare counter with LED1 'control value', energise LED1 if 'less than'
. . . compare counter with LED2 'control value', energise LED2 if 'less than'
. . . etc for each LED in turn
. . . compare with zero, kill all LEDs if true, (ignore zero value as next decrement will reset it to 255)
. . . repeat loop
. . .
. . . COMMS routine :-
. . . recieve data, keep recieving until silence signals end of string (keep a count of how many bytes are recieved)
. . . copy first four bytes into 'control value' buffers
. . . send remaining bytes on to next controller in chain
. . . go back to main loop

The program loop needs to run fast enough to make any flashing invisible (>20 Hz) - that should be dead easy on the slowest of controllers :!:

This can't be the only way of achieving your desired result but it seems reasonably simple, compact and flexible. The only 'fly in the ointment' would be some visible flicker during data transmissions as the LEDs would not be getting updated, but this should only last for about a twentieth of a second for 9600 baud ? (worst case is first controller which has to read 20 bytes and send 16).

 

[Misterbenn]

I was going to move the time data for LED X into the timer register, then turn LED X on until the timer had overflowed. then dont the same for the next LED.
similar to your idea, but yours is more advanced

right i think i have a clear picture in my head now, fingers crossed i'll find the time to start my circuits by the end of the week with the software following soon after

thanks for all your help

 

[Misterbenn]

ok i've finaly got around to starting this project.
i'm only using 3 LEDs per unit now, i found this nice little RGB unit. so i'm only sending 15 bites now. though i think i'll need a transducer driver or somthing like that. any one got any idears about a small transducer driver i could use? i thought of a darlington driver but they only come in 8/chip, i need a smaller 3/chip version.

i think the code is going ok, although i'll need some / lots of help with the transmition, and reception bit of the code. i'm planning to run this at about 20MHz, and transmit the LED light level data 50 times a second.

i'll post the code later so people can look through it, any and all help with it will be welcomed with wide open arms! i'm sure there must be a way to make it look a little less complex.

i've decided i'm going for a light pattern of

R G B
3/3 2/3 1/3
2/3 1/3 0/3
1/3 0/3 1/3
0/3 1/3 2/3
1/3 2/3 3/3
2/3 3/3 2/3
then back to the top.

 

[Optikon]

ok i've finaly got around to starting this project.
i'm only using 3 LEDs per unit now, i found this nice little RGB unit. so i'm only sending 15 bites now. though i think i'll need a transducer driver or somthing like that. any one got any idears about a small transducer driver i could use? i thought of a darlington driver but they only come in 8/chip, i need a smaller 3/chip version.

i think the code is going ok, although i'll need some / lots of help with the transmition, and reception bit of the code. i'm planning to run this at about 20MHz, and transmit the LED light level data 50 times a second.

i'll post the code later so people can look through it, any and all help with it will be welcomed with wide open arms! i'm sure there must be a way to make it look a little less complex.

i've decided i'm going for a light pattern of

R G B
3/3 2/3 1/3
2/3 1/3 0/3
1/3 0/3 1/3
0/3 1/3 2/3
1/3 2/3 3/3
2/3 3/3 2/3
then back to the top.

You mean "transistor" driver? Right? Darlington is ok. 3 per pkg is NOT necessary. Can't you use the 8 per pkg and fit two groups of three in there? or gang them all up? If not, why not use 3 single packages instead? You can buy them or make them easily. They can be as small as your power levels will allow.

 

[Misterbenn]

the single versions will add to the size of my units. i need to keep this as small as possible. i could just use surface mount fransistors and resistors, but they cost more and i'd need to by the solder for them. so i need a cheap small soulution.
all i need is 3 drivers packaged in a single chip or something similar, so a small darlinglton aray would be perfect

 

[Optikon]

the single versions will add to the size of my units. i need to keep this as small as possible. i could just use surface mount fransistors and resistors, but they cost more and i'd need to by the solder for them. so i need a cheap small soulution.
all i need is 3 drivers packaged in a single chip or something similar, so a small darlinglton aray would be perfect

Your final size will be determined by the power dissipation you need to provide anyhow. You had better make use of the common arrays. Also, eliminating the use of surface mount severly ties your hands in terms of size. You will have one of the physically largest designs possible. Also, whatever you use, be sure you can dissipate the heat in the package or you'll be making doomed boards.

 

[Misterbenn]

ok i'll come back to the hardware in a bit, i'll just make a prototype atm so dont need to worry about size.

i've attached a copy of my program, not totaly finiahed yet, the main bit that i need help on is the transmition part.