I have a 32u4 Robot Controller LV. I mounted it on a Raspberry Pi 3. I successfully loaded the AStar32U4 and PololuRPiSlave libraries in my Arduino dev environment and loaded the AStarRPiSlaveDemo onto the Controller. I also pulled the Python3 AStar class and the blink, beep, and benchmark examples onto the Pi. The blink and benchmark examples work just fine. The beep may or may not; it makes noise, but I am not sure what it is supposed to sound like (I should probably note that when testing the Controller independent of the Pi BuzzerBasics example ran just fine).
So far, so good.
I looked at the code because I will need to add (and probably subtract) some functions; for example, I’ll want to drive a pair of servos. I started examining the Data structure in AStarRPiSlaveDemo and the implementation of the AStar class in a_star.py. It became obvious that the “address” parameter in read_unpack and write_pack methods refers to the byte address in the buffer created from the Data structure. Trying to do the formatting and math, etc. I get the following addresses:
0 = the 3 LEDs (each 1 byte) – used by the leds method
3 = the 3 buttons (each 1 byte) – used by the read_buttons method
6 = the 2 motors (each 2 bytes) – used by the motors method
10 = the battery voltage (2 bytes) – used by the read_battery_millivolts method
12 = the 6 analog inputs (each 2 bytes) – used by the read_analog method
24 = the playNotes indicator (1 byte) – used by the play_notes method
25 = the 14 notes (each 1 byte) – used by the play_notes method
39 = the 2 encoder values (each 2 bytes) – used by the read_encoders method
So from what I can see, all the addresses line up nicely with the byte structure created using the struct.pack method.
However, I cannot understand the implementation of the play_notes method, which I copy here for discussion:
def play_notes(self, notes):
self.write_pack(24, ‘B15s’, 1, notes.encode(“ascii”))
If I understand it, the format ‘B15s’ should map the 1 as an unsigned char (a byte) and place it in address 24. Then format should map the next 15 “things” as char (a byte array) starting at 25. Since the Data structure has notes, I would have expected the format to be ‘B14s’. At least in theory, the 15 could cause an overwrite into the encoder values. What am I missing?