Simple 4-color multichannel garland based on the ATTINY13A microcontroller
As they say - prepare a sleigh in the summer ...
Surely for the new year you decorate the Christmas tree with all sorts of garlands, and most likely they have long since become boring with the monotony of their blinking. I would like to do something so that the ear, just like on the capital Christmas trees blinked, only on a smaller scale. Or in extreme cases - hang on the window, so that this direct beauty illuminates the city from the 5th floor.
But alas, there are no such garlands on sale.
Actually, it was precisely this problem that had to be solved two years ago. Moreover, because of laziness, from idea to implementation, 2 years passed as usual, and everything was done in the last month. Actually, you will have more time (or I don’t understand anything in human psychology, and everything will be done the same way in the last 2 weeks before the new year?).
It turned out quite simple construction of individual modules with LEDs, and one common that transmits commands from the computer to the network of these modules.
')
The first version of the module was conceived so as to connect them to the network via two wires, so that there is less confusion and all that - but didn’t grow together; The third wire is not so convenient, but it is much easier to organize a data transmission channel.
How it all works.
The developed network is capable of addressing up to 254 subordinate modules, which will be called SLAVE hereafter - they are connected with just 3 wires, as you already guessed - the two wires are + 12V power, the common and the third ones are signal.
they have a simple scheme:
As you can see, it supports 4 channels - Red, Green, Blue and Purple.
True, according to the results of practical testing, purple is clearly visible only near but how! Also, due to the fact that the colors are too far from each other, mixing colors can only be seen from 10 meters away, if you use RGB LEDs, the situation will be somewhat better.
In order to simplify the design, the quartz stabilization also had to be abandoned - firstly, the extra output takes away and secondly the cost of the quartz resonator is quite noticeable and thirdly - there is no urgent need for it.
A protective cascade is assembled on the transistor to prevent the controller port from being knocked out of static - the line is still quite long, in the extreme case only the transistor will suffer. The cascade is calculated in MicroCap and has an approximate response threshold of about 7 volts and a weak dependence of the threshold on temperature.
Naturally, in the best traditions, all modules react to the address at number 255 - so you can turn them all off at once with one command.
A module called MASTER is also connected to the network - it is an intermediary between a PC and a network of slave SLAVE modules. Among other things, it is a source of model time, for synchronization of slave modules in the absence of quartz stabilization in them.
Scheme:
There are optional potentiometers in the scheme - they can be used in the program on a PC for convenient and quick setting of the desired parameters, at the moment it is implemented only in the test program as an opportunity to assign any of the potentiometers to any of the 4 channels. The circuit is connected to the PC via a USB-UART interface converter on the FT232 chip.
An example of a packet issued to the network:
Its beginning:
Electrical characteristics of the signal: log.0 corresponds to +9 ... 12V, and log.1 corresponds to 0 ... 5V.
As you can see, data is transmitted sequentially, at a fixed rate of 4 bits. This is due to the necessary margin for error in data reception speed - SLAVE-modules do not have quartz stabilization, and this approach ensures data reception when transmission speed deviation is up to + -5% over those that are compensated programmatically based on measuring the calibrated interval at the beginning of data transfer, which gives resistance to the care of the reference frequency by + -10%.
Actually, the algorithm of the MASTER-module is not so interesting (it is quite simple - we receive data on the UART and forward them to the network of slave devices), all the most interesting solutions are implemented in SLAVE-modules, which actually allow you to adjust to the transmission speed.
The main and most important algorithm is the implementation of 4-channel 8-bit software PWM that allows you to control 4 LEDs with 256 brightness gradations of each of them. The implementation of this algorithm in hardware also determines the speed of data transmission in the network - for software convenience, one bit is transmitted for each PWM operation step. The preliminary implementation of the algorithm showed that it runs in 44 clocks, so it was decided to use a timer configured to interrupt every 100 clocks - so the interrupt is guaranteed to run before the next one and execute part of the main program code.
At the selected clock frequency of the 4.8 MHz internal generator, interruptions occur at 48 kHz - this is the bit rate of the slave network and PWM is filled with the same speed - as a result, the frequency of the PWM signal is 187.5 Hz, which is enough to ignore the blinking of the LEDs. Also, in the interrupt handler after the execution of the algorithm responsible for the formation of PWM, the data bus state is fixed - it turns out approximately in the middle of the timer overflow interval, this simplifies data reception. At the beginning of the reception of the next packet of 4 bits, the timer is reset, this is necessary for more accurate synchronization of reception and resistance to deviation of the reception speed.
The result is the following picture:
The implementation of the rate adjustment algorithm is interesting. At the beginning of the transmission, MASTER gives a pulse with a duration of 4 bits of log.0, according to which all the subordinate modules determine the required reception rate using a simple algorithm:
st_syn_delay = 60 - a constant that determines the maximum duration of the starting pulse, which is approximately 2 times longer than the nominal (for reliability)
Experimental method was established such a dependence of the resulting number in tmp2 when the clock frequency deviates from the nominal:
4.3Mhz (-10%) 51 units (0x33) corresponds to 90 timer ticks for returning the reception speed to the nominal
4.8Mhz (+ 00%) 43 units (0x2B) - corresponds to 100 timer ticks (nominal)
5.3Mhz (+ 10%) 35 units (0x23) - corresponds to 110 timer ticks to return the reception speed to the nominal
These data were used to calculate the correction coefficients for the timer interrupt period (this is how the reception rate is adjusted to the available clock frequency of the controller):
Y (x) = 110-x * 20/16
x = tmp2 - 35 = (0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16)
Y (x) = (110, 108.75, 107.5, 106.25, 105, 103.75, 102.5, 101.25, 100, 98.75, 97.5, 96.25, 95, 93.75, 92.5, 91.25, 90)
Numbers are rounded to whole numbers and entered in the EEPROM.
If, when the voltage is applied to the module, to keep the line in a logical state "1", a calibration subroutine will turn on, which will allow you to measure the period of the PWM signal without correction with a frequency meter or oscilloscope and, based on the measurements, judge the deviation of the clock frequency of the module controller from the nominal, with a strong deviation greater than 15% Correction of the calibration constant of the built-in RC generator may be required. Although the manufacturer promises calibration at the factory and the deviation from the nominal value of not more than 10%.
At the moment, a Delphi program has been developed that allows reproducing a previously created pattern for 8 modules with a given speed. As well as a utility for working with a separate module (including reassigning the address of the module).
Firmware.
for a SLAVE module, only fushes CKSEL1 = 0, and SUT0 = 0 need to be flashed. The rest should be left unstitched. The contents of the EEPROM can be flashed from the RGBU-slave.eep file, if necessary, you can immediately specify the desired module address in the network - 0th byte of the EEPROM, default flashed as $ FE = 254, at the address 0x13 contains the calibration constant of the built-in RC generator of the controller, at 4.8 MHz frequency, it is not loaded automatically therefore it is necessary to read the factory calibration value by the programmer and write to this cell - this value is individual for each controller; for large frequency deviations from the nominal, you can change the calibration through this cell exactly agivaya factory values.
for a MASTER module, only futures SUT0 = 0, BOOTSZ0 = 0, BOOTSZ1 = 0, CKOPT = 0 need to be flashed. Leave the rest unstitch.
Finally, a small demonstration of the garland located on the balcony:
In fact, the functionality of the garland is determined by the program on the PC - you can make color music, stylish iridescent room lighting (if you add LED drivers and use powerful LEDs) - etc. What I plan to do in the future. There are plans for a grid of 12 modules with 3-watt RGB LEDs, and room lighting based on pieces of 12-volt RGB tape (only field-effect transistors are needed to switch the tape on each module by 3 pieces or 4 if you add a piece of violet tape of other differences from the original will not be).
To manage the network, you can write your own program, even in BASIC - the main thing that the selected programming language should do is to be able to connect to the immortal COM ports and configure their parameters. Instead of the USB interface, you can use an adapter with RS232 - this gives you the potential to control the lighting effects from a wide range of devices that you can program.
The protocol of exchange with the MASTER device is quite simple - we send a command and expect a response about its success or failure, if there is no answer for more than a few milliseconds - there are problems with the connection or operation of the MASTER device, in this case it is necessary to carry out the reconnection procedure.
Currently the following commands are available:
0x54; “T” symbol - “test” command - connection test, the answer should be 0x2B.
0x40; The "@" symbol is the "download and transfer" command. After giving the command you need to wait for the answer "?" followed by 6 bytes of data:
+0: ​​Slave Address 0..255
+1: command device
0x21 - bytes 2 ... 5 contain the brightness of the channels that you want to apply immediately.
0x14 - set a timeout after which the brightness on all channels will be
reset to 0 if no command is received during this time. The timeout value is in the red channel cell, i.e. in byte offset +2. a value of 0-255 corresponds to a timeout of 0-25.5 seconds by default, a timeout = 5 seconds (recorded in the EEPROM with firmware, it can also be changed there in a byte with an offset of +1).
0x5A - change device address.
The procedure for changing the address for reliability must be performed three times - only then the new address will be applied and registered in the EEPROM. At the same time, you need to be careful - if you register two devices with one address, they will react synchronously and “share” them only by physically disconnecting unnecessary modules from the network and changing the address of the rest, or the programmer. The value of the new address is transmitted in the cell of the red channel - i.e. in byte offset +2.
2: Brightness red 0 ... 255
+3: Green brightness 0 ... 255
+4: Blue brightness 0 ... 255
+5: Brightness violet 0 ... 255
0x3D; symbol "=" - the command "ADC". After giving the command you need to wait for the answer "?" then you should send 1 byte - the channel number of the ADC 0..7 in binary form (ASCII digits 0..9 are also suitable in this capacity, since the upper 4 bits are ignored).
In response, the command returns 2 bytes of the measurement result in the range 0 ... 1023
Possible responses to commands:
0x3F; character "?" - readiness for data entry, means that the device is ready to accept command arguments
0x2B; "+" symbol Answer - command executed
0x2D; symbol "-" Answer - the command is not defined or wrong
More details can be extracted from the sources located on the githaba, the latest versions of ready-made firmware are also located there: github.com/Alexeyslav/RGBU_light
Surely for the new year you decorate the Christmas tree with all sorts of garlands, and most likely they have long since become boring with the monotony of their blinking. I would like to do something so that the ear, just like on the capital Christmas trees blinked, only on a smaller scale. Or in extreme cases - hang on the window, so that this direct beauty illuminates the city from the 5th floor.
But alas, there are no such garlands on sale.
Actually, it was precisely this problem that had to be solved two years ago. Moreover, because of laziness, from idea to implementation, 2 years passed as usual, and everything was done in the last month. Actually, you will have more time (or I don’t understand anything in human psychology, and everything will be done the same way in the last 2 weeks before the new year?).
It turned out quite simple construction of individual modules with LEDs, and one common that transmits commands from the computer to the network of these modules.
')
The first version of the module was conceived so as to connect them to the network via two wires, so that there is less confusion and all that - but didn’t grow together; The third wire is not so convenient, but it is much easier to organize a data transmission channel.
How it all works.
The developed network is capable of addressing up to 254 subordinate modules, which will be called SLAVE hereafter - they are connected with just 3 wires, as you already guessed - the two wires are + 12V power, the common and the third ones are signal.
they have a simple scheme:
As you can see, it supports 4 channels - Red, Green, Blue and Purple.
True, according to the results of practical testing, purple is clearly visible only near but how! Also, due to the fact that the colors are too far from each other, mixing colors can only be seen from 10 meters away, if you use RGB LEDs, the situation will be somewhat better.
In order to simplify the design, the quartz stabilization also had to be abandoned - firstly, the extra output takes away and secondly the cost of the quartz resonator is quite noticeable and thirdly - there is no urgent need for it.
A protective cascade is assembled on the transistor to prevent the controller port from being knocked out of static - the line is still quite long, in the extreme case only the transistor will suffer. The cascade is calculated in MicroCap and has an approximate response threshold of about 7 volts and a weak dependence of the threshold on temperature.
Naturally, in the best traditions, all modules react to the address at number 255 - so you can turn them all off at once with one command.
A module called MASTER is also connected to the network - it is an intermediary between a PC and a network of slave SLAVE modules. Among other things, it is a source of model time, for synchronization of slave modules in the absence of quartz stabilization in them.
Scheme:
There are optional potentiometers in the scheme - they can be used in the program on a PC for convenient and quick setting of the desired parameters, at the moment it is implemented only in the test program as an opportunity to assign any of the potentiometers to any of the 4 channels. The circuit is connected to the PC via a USB-UART interface converter on the FT232 chip.
An example of a packet issued to the network:
Its beginning:
Electrical characteristics of the signal: log.0 corresponds to +9 ... 12V, and log.1 corresponds to 0 ... 5V.
As you can see, data is transmitted sequentially, at a fixed rate of 4 bits. This is due to the necessary margin for error in data reception speed - SLAVE-modules do not have quartz stabilization, and this approach ensures data reception when transmission speed deviation is up to + -5% over those that are compensated programmatically based on measuring the calibrated interval at the beginning of data transfer, which gives resistance to the care of the reference frequency by + -10%.
Actually, the algorithm of the MASTER-module is not so interesting (it is quite simple - we receive data on the UART and forward them to the network of slave devices), all the most interesting solutions are implemented in SLAVE-modules, which actually allow you to adjust to the transmission speed.
The main and most important algorithm is the implementation of 4-channel 8-bit software PWM that allows you to control 4 LEDs with 256 brightness gradations of each of them. The implementation of this algorithm in hardware also determines the speed of data transmission in the network - for software convenience, one bit is transmitted for each PWM operation step. The preliminary implementation of the algorithm showed that it runs in 44 clocks, so it was decided to use a timer configured to interrupt every 100 clocks - so the interrupt is guaranteed to run before the next one and execute part of the main program code.
At the selected clock frequency of the 4.8 MHz internal generator, interruptions occur at 48 kHz - this is the bit rate of the slave network and PWM is filled with the same speed - as a result, the frequency of the PWM signal is 187.5 Hz, which is enough to ignore the blinking of the LEDs. Also, in the interrupt handler after the execution of the algorithm responsible for the formation of PWM, the data bus state is fixed - it turns out approximately in the middle of the timer overflow interval, this simplifies data reception. At the beginning of the reception of the next packet of 4 bits, the timer is reset, this is necessary for more accurate synchronization of reception and resistance to deviation of the reception speed.
The result is the following picture:
The implementation of the rate adjustment algorithm is interesting. At the beginning of the transmission, MASTER gives a pulse with a duration of 4 bits of log.0, according to which all the subordinate modules determine the required reception rate using a simple algorithm:
LDI tmp2, st_syn_delay DEC tmp2 ;<+ BREQ bad_sync ; | SBIC PINB, cmd_port; | RJMP PC-0x0003 ;-+ st_syn_delay = 60 - a constant that determines the maximum duration of the starting pulse, which is approximately 2 times longer than the nominal (for reliability)
Experimental method was established such a dependence of the resulting number in tmp2 when the clock frequency deviates from the nominal:
4.3Mhz (-10%) 51 units (0x33) corresponds to 90 timer ticks for returning the reception speed to the nominal
4.8Mhz (+ 00%) 43 units (0x2B) - corresponds to 100 timer ticks (nominal)
5.3Mhz (+ 10%) 35 units (0x23) - corresponds to 110 timer ticks to return the reception speed to the nominal
These data were used to calculate the correction coefficients for the timer interrupt period (this is how the reception rate is adjusted to the available clock frequency of the controller):
Y (x) = 110-x * 20/16
x = tmp2 - 35 = (0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16)
Y (x) = (110, 108.75, 107.5, 106.25, 105, 103.75, 102.5, 101.25, 100, 98.75, 97.5, 96.25, 95, 93.75, 92.5, 91.25, 90)
Numbers are rounded to whole numbers and entered in the EEPROM.
If, when the voltage is applied to the module, to keep the line in a logical state "1", a calibration subroutine will turn on, which will allow you to measure the period of the PWM signal without correction with a frequency meter or oscilloscope and, based on the measurements, judge the deviation of the clock frequency of the module controller from the nominal, with a strong deviation greater than 15% Correction of the calibration constant of the built-in RC generator may be required. Although the manufacturer promises calibration at the factory and the deviation from the nominal value of not more than 10%.
At the moment, a Delphi program has been developed that allows reproducing a previously created pattern for 8 modules with a given speed. As well as a utility for working with a separate module (including reassigning the address of the module).
Firmware.
for a SLAVE module, only fushes CKSEL1 = 0, and SUT0 = 0 need to be flashed. The rest should be left unstitched. The contents of the EEPROM can be flashed from the RGBU-slave.eep file, if necessary, you can immediately specify the desired module address in the network - 0th byte of the EEPROM, default flashed as $ FE = 254, at the address 0x13 contains the calibration constant of the built-in RC generator of the controller, at 4.8 MHz frequency, it is not loaded automatically therefore it is necessary to read the factory calibration value by the programmer and write to this cell - this value is individual for each controller; for large frequency deviations from the nominal, you can change the calibration through this cell exactly agivaya factory values.
for a MASTER module, only futures SUT0 = 0, BOOTSZ0 = 0, BOOTSZ1 = 0, CKOPT = 0 need to be flashed. Leave the rest unstitch.
Finally, a small demonstration of the garland located on the balcony:
In fact, the functionality of the garland is determined by the program on the PC - you can make color music, stylish iridescent room lighting (if you add LED drivers and use powerful LEDs) - etc. What I plan to do in the future. There are plans for a grid of 12 modules with 3-watt RGB LEDs, and room lighting based on pieces of 12-volt RGB tape (only field-effect transistors are needed to switch the tape on each module by 3 pieces or 4 if you add a piece of violet tape of other differences from the original will not be).
To manage the network, you can write your own program, even in BASIC - the main thing that the selected programming language should do is to be able to connect to the immortal COM ports and configure their parameters. Instead of the USB interface, you can use an adapter with RS232 - this gives you the potential to control the lighting effects from a wide range of devices that you can program.
The protocol of exchange with the MASTER device is quite simple - we send a command and expect a response about its success or failure, if there is no answer for more than a few milliseconds - there are problems with the connection or operation of the MASTER device, in this case it is necessary to carry out the reconnection procedure.
Currently the following commands are available:
0x54; “T” symbol - “test” command - connection test, the answer should be 0x2B.
0x40; The "@" symbol is the "download and transfer" command. After giving the command you need to wait for the answer "?" followed by 6 bytes of data:
+0: ​​Slave Address 0..255
+1: command device
0x21 - bytes 2 ... 5 contain the brightness of the channels that you want to apply immediately.
0x14 - set a timeout after which the brightness on all channels will be
reset to 0 if no command is received during this time. The timeout value is in the red channel cell, i.e. in byte offset +2. a value of 0-255 corresponds to a timeout of 0-25.5 seconds by default, a timeout = 5 seconds (recorded in the EEPROM with firmware, it can also be changed there in a byte with an offset of +1).
0x5A - change device address.
The procedure for changing the address for reliability must be performed three times - only then the new address will be applied and registered in the EEPROM. At the same time, you need to be careful - if you register two devices with one address, they will react synchronously and “share” them only by physically disconnecting unnecessary modules from the network and changing the address of the rest, or the programmer. The value of the new address is transmitted in the cell of the red channel - i.e. in byte offset +2.
2: Brightness red 0 ... 255
+3: Green brightness 0 ... 255
+4: Blue brightness 0 ... 255
+5: Brightness violet 0 ... 255
0x3D; symbol "=" - the command "ADC". After giving the command you need to wait for the answer "?" then you should send 1 byte - the channel number of the ADC 0..7 in binary form (ASCII digits 0..9 are also suitable in this capacity, since the upper 4 bits are ignored).
In response, the command returns 2 bytes of the measurement result in the range 0 ... 1023
Possible responses to commands:
0x3F; character "?" - readiness for data entry, means that the device is ready to accept command arguments
0x2B; "+" symbol Answer - command executed
0x2D; symbol "-" Answer - the command is not defined or wrong
More details can be extracted from the sources located on the githaba, the latest versions of ready-made firmware are also located there: github.com/Alexeyslav/RGBU_light
Source: https://habr.com/ru/post/191424/
All Articles