BrickPi Programming in C++11

BrickPi
#1

I have been experimenting with the BrickPi tank robot. I want to use C++11 for my project, so I have spent some time trying to get BrickPi.h to work in g++. I am able to run the “LEGO Motor - Test.c” when I compile it in C, but when I run that test program C++'ified with C++ BrickPi version there are multiple read retry failures. In order to understand why C++ was not working as expected, I started investigating the C version, and ran into a strange bug, which I suspect is timing related:

If I modify this code https://github.com/DexterInd/BrickPi_C/blob/master/Sensor_Examples/BrickPi.h#L753 to the following:

  while(i < (ByteCount + 3)){
	write(uart0_filestream, &tx_buffer[i], 1);
        printf("Tx buffer %u: %u\n", i, tx_buffer[i]);
    i++;
   }

Then the BrickPiSetupSensors() times out on reading the output in BrickPiRx. I would appreciate any help with this. Does this have anything to do with I2C settings? You can find my code at the following github project: https://github.com/ayeganov/tank_roboto/tree/motor

#2

Hey nindza,

One thing to note about the BrickPi is that it uses serial, not I2C. Without diving too deep on this snippet of code, if you do change it, you will see problems with timeout, as you might not catch serial messages.

Best, John

#3

Hi John,

Thank you for your reply. I am a little new to embedded, so still getting acquainted. I am actually very interested to know why adding a print statement breaks the serial communications and causes a timeout. I am concerned, because at this point I don’t know what else might affect the stability of the serial. If, however, as long as I don’t touch the BrickPiTx and BrickPiRx the serial remains stable I may leave it that.

Thank you

#4

Nindza,
The serial communications are working on strict timings. Both devices are timing out when there’s a problem; they will essentially give up if they don’t hear everything they’re looking for, and an appropriate response. The communications between the two are precise, and if anything is off (a checksum, a missing bit, etc), the reeiving device assumes a corrupted message and gives up.

I wouldn’t be “concerned” about this; this is a necessary and proper way for devices to talk to each other. This filters out junk messages, and filters out errors caused by external factors and interrupts.