Rainbowduino Serial

End-Of-Life Products & Services Tech support before 2012
#1

Hi,
I was wondering if there is a full official release of Rainbowduino for serial communication instead of I2c,

I only found a non-official buggy one: milesburton.com/wiki/index.php?t … Via_Serial

is Seedstudio working on this?
is there any better/deeper documentation than the one posted in here: “http://www.seeedstudio.com/depot/rainbowduino-led-driver-platform-plug-and-shine-p-371.html”? (which is v1.1)

Thanks

#2

we don’t have a serial version because the Uart serial is not so suitable for many Slaves connect in series , so the IIC is the better solution.

#3

What happens then if I want to control just one rainbowduino but high speed (115200Kbps)?
The datasheet says that it is possible but then there is no sample code available on that?

In addition, I think it would be possible to have several slaves in series, each of them with an identifier ID and using flooding to send the commands to all of them, then only the boards with the specific ID would react to those messages, maybe it would require some buffering, …

#4

Yeah I’d agree. Serial is a nice method of communication with the Rainbow.

There’s a few serial examples around here was are far superior to my version. I’ve been trying to get a new version working.

#5

For what it’s worth the MeggyJr port I did for the Rainbowduino works with the MeggyJr SerialCommunication examples: code.google.com/p/meggy-jr-rgb/

#6

We have I2C version by default, the hardware supports serial.

You might need to use community API or make your own to suit the specific need. Thanks for the suggestion!

#7

So …
why dont you guys change the specifications then?
since seeedstudio only supports I2C on software, on the specifications it shouldn’t say:
“communications protocols: I2C, Uart”,
it should say I2C, possible Uart (ONLY hardware supported)
So It wont be so confusing …

I mean if you put Uart communication protocol, I woud expect that it would be a simple example on how to handle serial communication (by SeeedSatudio (full supported communication sample)), and with every process in the code commented. So if someone wants to change something quicly doesnt have to go through all the code to understand whats happening …

I am kind of frustating with this product because the official documentation v1.1 is not very clear and the code comments (besides it has quite of typos) is not very helpful,

thanks for the responses in the forum tho

#8

Then rainbowduino supported IIC or Uart communication , but you need to write the code yourself .
we supply the Sample sketch to show you how to use the rainbowduino hardware , it’s not a firmware … it just a demo code show you that you can do it like this.

we show your that you can use the command form to control the rainbowduino with a host , and just give out some simple command for example , specific function command like draw a line or draw a dot , even turn the angle , that you need to write yourself.

we supply the hardware can to this , and the demo code just show you how to do this, the specific application you should use the specific code writen by yourslef.

#9

Is there a way that you guys can post an detailed explanation of the sketch (not firmware ) that is supported by seeedstudio, instead of us performing reverse enginnering?

I’ve been looking at the sketch and at the hardware and several questions pop up:

  • why the color level is restricted to just 15 levels?
  • when the array is 4x8 while one byte represents two adjacing dots (are they adjacing horizontally or vertically)?
  • what the purpose of having 2 adjacing dots , just compressing the matrix? or the hardware cannot distinguish so many levels in color? well, … the methods accepts unsigned chars as level of colors but then only the 4 less significant bit are taken ? cna the hardware represent 255 level of color?
  • the unsigned char dots_color[2][3][8][4], what is 8 columns? or rows? and 4 ?( i am asking this because in the code sometimes there is a reference to:
    1. dots_color[Buffprt][line][row]
      and other times:
    2. dots_color[(Buffprt+1)&1][row][dots]
      where “row” is in different index
  • what are lines, are lines supposed to be columns?
  • who worte the sketch? would it be possible to create a new Manual/Documentation with detailed information about how the inside of the hardware coordinated with software works? diagrams of how to pass the info of color to the different LED drivers? etc etc,

thanks

#10
  1. each colour have 16 level brightness (0 to 15 is 16 level), and then 3 colour that you can make up a 16^3=4096 colour .
  2. the array just store the colour data not to to drive the LDE , for to maximum ues the flash , we use 4 bit to express one colour brigtness for one dot , so one byte store the two dot colour brightness information . of cause you can modify the array to 88 to store the colour brightness data , then the drive code is more easier then ues 48 's, but you waste the room.
  3. each dot is separate , not adjacing dots , what you saw just the data be compress to one byte . and in the code when to drive one dot , read the dot brightness infromation from the array , analyze in the code and to drive the dot .
  4. dots_color[2][3][8][4] is the two buff for display , the [3] is for each colour , and the is [8]for each line or row , the [4] is all dot data of the line or row(8X4bit , each 4 bit for a dot).
#11

thanks,
could you explain a little bit deeper the use of the variable “level”
why does it have to scan the LED matrix level by level on the interruptions?
increasing the number of levels to 255 (8bits) would decrease the speed of refresh?
are the 16 levels directly related to 16 level of PWM?

#12

yes , just as PWM, 16times a cycle , every times add a level . also you can 256 level ,that you can show out 256^3=16777216 colour . but the problem is that , as a cycly is 10 ms , that for 16level the interruptions just 625 us, but use 256level that you neeed every 39us a interruption, is not enough time for you to analyze and drive the LDE , even not enough to do the communications.

#13

thanks,
Ive another question about the software fro rainbowduino,
so there are 5 images predefined right?
What would be the maximum (approx) number of predefined images that the rainbowduino chip can allocate?
thanks

#14

the image is store in the FLASH , so how may image can be stored be decide by your code size. the maximum (approx) number of predefined images is (16K FLASH- your code size)/(size of every image(now is 384=96byte)) , just modify the array that your can change the number of the images.

#15

thanks,
I saw the flash memory predeifned images, Ive already finished an serial version pretty fast with external eeprom to save more predefined images, also i included some commands to change those images and the inclusion of a board ID in order to have different rainbowduinos chained,
now Ive a nother question about the board …

so ADC6, ADC7 and PD2 are being reserved and we can use them as we want, right?
Is there any way to make ADC6 and ADC7 digital outputs?
is there other pins free/available in the atmega128 in the rainbowduino? even if I have to solder an extra wire to the board?
Thanks

#16

the ADC6, ADC7 just can be used as a AD input , can not be a output pin.

#17

so PD2 is the only pin that can be used as an difital output?
i mean is there any other pin in the atmega128 contained in the rainbowduino that is not being used?
thanks

#18

It has other 3 pins are not used, on ISP header.
The Digital pin 10,11,12(PB3,PB4,PB5).
It is easy to use and align in 100mil than driver pins.

Thanks
Albert

#19

10 , 11, and 12, should correspond to PB2, PB3, PB4 instead of PB3, PB4, PB5 right?

#20

Besides there is also a problem when the lines are addressed:

in the code, every interrupt we have:

PORTB=0x04;

this clears the portB completely but PB2 (digital pin 10), then the rest of the pin in B are cleared to zero and its impossible to control it externally,
however if we substitute every line for something like this:

PORTB=(~0x07 & PORTB | 0x04);

now the state of the rest of B pins (that do not take part in the line enabling) are saved