Firmware cmd block length

Archives GrovePi
1

Hi,

I am looking to add features to the firmware and noticed that you are receiving 5 bytes before processing a command.

0 = dummy
1 = command
2 = pin
3 = other data
4 = other data

More details here:

The current firmware:
https://github.com/DexterInd/GrovePi/blob/master/Firmware/Source/v1.1/grove_pi_v1_1/grove_pi_v1_1.ino

I am looking at adding support for the Chainable RGB Led.
I found an Arduino library that works, however, I need more than 2 bytes to issue a command.

I had to change the constructor, to use a begin() method, like Karan did here:

0 = dummy
1 = command
2 = pin (dio, clock will always be dio + 1)
3 = number of leds in the chain
4 = which led do you want to light up
5 = red
6 = green
7 = blue

I was looking into ways I could squish the values into only two bytes, but it would mean drastically limiting the number of available colours. There has to be a better way…

Looking at your firmware, was there a reason you chose 5 bytes in your .receiveData() method? Is there a limit to how many bytes can be sent in a block?

In .receiveData() it looks like every 5 bytes you reset the index and start adding to the next command, and once it reaches 5 bytes, the main loop() runs the command.

Would it be possible to instead of counting n bytes before executing a command, provide a block length byte, for sensors such as this with a larger than normal number of bytes?

eg. the block would look something like this
0 = dummy
1 = block length
2 = command
3 = pin
4 = other data
5 = other data
…
13 = other data
14 = other data etc

Another possibility could be a end of block command, which keeps adding to the cmd[] array until the end is detected.
0 = dummy
1 = command
2 = pin
3 = other data
…
14 = other data
15 = end

Does anyone have any feedback / suggestions?
I am going to start experimenting.

2

There was not a specific reason why we choose 5 bytes, but it looked more than enough for most of the applications and we wanted to keep the overhead at the minimum.
If you have too much code which goes into the ISR that handles the I2C read and writes on the Atmega328, then that could start causing problems. Keeping the messages short helped us a lot when we started with the GoPiGo. In the GoPiGo the firmware is pretty big and takes some time to execute. We were had complete the I2C transactions in less than a fixed time otherwise the firmware crashes. We haven’t seen the firmware crash on the GrovePi, but it can cause instability.

Now coming to increasing the message length, right now we don’t have any big reasons to increase the command length. You have 3 bytes at your disposal, so that’s 24 bits. It’ll be great if you could do some bit level operations to send the commands. It should be pretty simple to do that in C and Python both. Just try to avoid that if possible and we’ll also be very cautious to merge that to the current repository or completely avoid it as it can break a lot of things.

If you are really going down this path then having a logic analyzer at had would be very useful. It’s very hard to figure out what’s going on in the I2C bus without it.

Keep us posted on how things go.

-Karan