Balboa and SPI Really slow balance update

Support Robots
1

Hello,
I’ve been trying to use a bluetooth device (Adafruit BLE SPI Friend) with the Balboa 32u4 with no success. To begin, I loaded the Balancer demo program to get an idea of how quickly the yellow and green lights track the tipping motion. They’re pretty responsive! Only a few milliseconds response time, I’d guess.

Next I loaded the Controller demo program from Adafruit’s library to test the SPI communication with the board. Both of these gave me favorable results with my iPhone and the bluefruit app:

/* ...hardware SPI, using SCK/MOSI/MISO hardware SPI pins and then user selected CS/IRQ/RST */
Adafruit_BluefruitLE_SPI ble(BLUEFRUIT_SPI_CS, BLUEFRUIT_SPI_IRQ, BLUEFRUIT_SPI_RST);

and

/* ...software SPI, using SCK/MOSI/MISO user-defined SPI pins and then user selected CS/IRQ/RST */
Adafruit_BluefruitLE_SPI ble(BLUEFRUIT_SPI_SCK, BLUEFRUIT_SPI_MISO,
                             BLUEFRUIT_SPI_MOSI, BLUEFRUIT_SPI_CS,
                             BLUEFRUIT_SPI_IRQ, BLUEFRUIT_SPI_RST);

Next, I started combining the code, recompiling along the way, until I had a working program. The issue is that when the SPI code is loaded, the yellow and green lights update every second or so. Much slower than the Balance code alone.

I noticed that the SCK and MOSI pins are also shared with the Right Motor Direction and Left Motor Direction.

I’m using the following pins for my interface:

#define BLUEFRUIT_SPI_SCK              15 
#define BLUEFRUIT_SPI_MISO             14
#define BLUEFRUIT_SPI_MOSI             16

I also use these pins:

#define BLUEFRUIT_SPI_CS               1 
#define BLUEFRUIT_SPI_IRQ              0

Can you suggest anything to help speed up the update rate while taking commands from the BLE?

2

Hello.

We don’t expect it to be practical to use the ATmega32U4’s hardware SPI interface while maintaining precise control of the Balboa’s motors (including while balancing). Can you try switching to the Bluefruit software SPI and using pins other 15 and 16? In case you have not already seen it: you can find a list of available Balboa I/O pins at the bottom of the table in the “Pin assignments” section of the Balboa’s user’s guide, which you can find under the Resources tab of its product page.

-Jon

3

Hi Jon,
And thank you for the promp reply. I’ve switched back to software SPI and am using pins 12, 18, and 20 for SCK, MISO, and MOSI. Handshaking works fine with the phone, but again the balance update is really slow.

Incidentally, it works fine using the UART version of the BLE Friend. The update rates are really fast and it balances well. (There is an interrupt conflict with one of the encoders preventing compiling unless I edit the SoftwareSerial.h)

This project was to explore the SPI flavor. Is there too much overhead making the updates slow?

4

We are not entirely sure why the balance updates would be slow then. Is there anything in the Bluefruit code that blocks for long periods of time?

You might consider adding some debugging code. For example, you could try turning one of the LEDs on and off at various points in the program to get an idea of how long it’s spending in the different parts of the code. (Note that to do this you would need to disable the example program’s normal use of the LEDs.)

-Jon

5

Hi Jon,
You, sir, are a genius! I commented out the line that reads the command from the Bluefruit and the update rate returned to normal. Looking at the code more closely, I found a variable in one of the header files controlling how long to wait for a new command. The default was 500 ms. Changing it to 2 ms cleared up the delay in the loop.

// These settings are used in both SW UART, HW UART and SPI mode
// ----------------------------------------------------------------------------------------------
#define BUFSIZE 128 // Size of the read buffer for incoming data
#define VERBOSE_MODE true // If set to ‘true’ enables debug output
#define BLE_READPACKET_TIMEOUT 2 // Timeout in ms waiting to read a response <was 500!>

Incidentally, I see now that this header file for the serial version of the BLE was also set to 2 ms. Thank you for pointing me in the right direction!

–Tim

1 Like
6

Jon,
I believe this thread shows a pinout I can use to connect the Adafruit RFM69HCW radio to my Balboa. I can put this in a separate thread if you prefer; either way I’d appreciate your comments.

This is the wiring list for connecting the RFM69 to an Arduino. I’ve added the Balboa pins that timalot and you seem to agree will work.
Connection Pin
CLK connects to SPI clock. 12
MISO connects to SPI MISO. 18
MOSI connects to SPI MOSI. 20
CS connects to our SPI Chip Select pin. 1
RST connects to (the) radio reset pin. (any of the unused digital pins)
G0 (IRQ) connects to an interrupt-capable pin. 0
Jim

7

I’ve got it up and running now and am tuning the PID parameters for better stability. You can see it in action here: https://youtu.be/d2vfSL83l_k The loop is really fast now that I’m only checking for a command every 4000 cycles (see code snip below). I also changed the BLE_READPACKET_TIMEOUT to 1 ms and its still very responsive to the commands send from the phone. I just have to make a custom wiring harness to make it look better.

void loop()
{
  balanceUpdate();
  
  if (i > 4000){
    ReadCommand();
    i = 0;
  }
  else {
    i++;
  }

–Tim

1 Like
8

Jim, it looks like the Adafruit library for their radio boards requires hardware SPI connections, and it looks like you are connecting to pins on the Balboa that are not hardware SPI pins. Are you planning on doing some kind of software SPI modification to the Adafruit library?

Tim, looks great! I am glad your Balboa is up and running; thanks for sharing the video.

-Jon

9

Jon, no, I had it fixed in my mind (from timalot’s first post and the ATmega32U4 pinout diagram) that the Balboa hardware SPI pins (14, 15, 16?) are being used (‘Left motor direction”, etc.) so I had to go to software SPI.

Can I use those pins without interfering with the Balboa operation? Is the (required) interrupt pin taking care of multiuse issues?
Jim

10

Are you asking if you can use the pins you specified in your previous post (12, 18, etc) or the hardware SPI pins? Like I mentioned earlier, we don’t expect it to be practical to use the Balboa’s hardware SPI pins while it’s balancing. It looks like using the pins you chose won’t interfere with anything in terms of hardware resources, but I wanted to check if you were prepared in terms of finding or writing the code to do software SPI communication since it looks like the Adafruit library doesn’t support that.

-Jon

11

Thanks Jon, I finally understand the SPI situation. I’d prefer not to rewrite the library (I’m using Radiohead as recommended by Adafruit) as I’m not fond of writing C. I’m thinking about going with plan B: using the Adafruit Feather platform (with built-in radio support) to ‘convert’ from SPI to serial (UART) communication.

Looks like pins 0/1 are the Balboa UART Rx/Tx pins, and the pin assignment page shows then as unused. Does this seem like a reasonable plan?

For others interested in communicating with the Balboa, I recommend the Adafruit BLE Friend like Tim is using. I tried it and the system (including the phone app) does what Adafruit says. Unfortunately, the Bluetooth ‘library’ in the programming language I use professionally (LabVIEW) does not ‘speak’ Bluetooth LE … go figure?!

12

Hi Jim,

If you do end up using serial (UART) watch out for a compiler error with the Software Serial library. I spent a week chasing it down to an interrupt conflict with the UART and one of the encoder pins. I ended up editing one line of code in the software serial library to get it to compile. Details are here: Balboa examples and on Github in the Softwareserial_TL.cpp file here: https://github.com/timalot/BLE_Pololu32U4Balboa_03 There may be other ways to do it but this was one that I used

Line 229 now reads :

#if defined(PCINT9_vect) // was ISR(PCINT0_vect) in cases below
ISR(PCINT9_vect)    
{
  SoftwareSerial::handle_interrupt();
}
#endif
13

Thanks for the feedback Tim; you bring up the chance for several ‘gotchas!’

The ATmega32U4 chip has hardware UART support, and the Balboa pinout diagram implies the board CAN make that hardware available. However, (like most modern chips) this microcontroller supplies ‘a lot’ of features through 44 pins, so they are (obviously) multiplexed.

Jon, are these pins connected to a hardware UART and can they be used with Arduino hardware UART support? The pin assignment chart shows 0 and 1 (Rx/Tx) as unused, and 11 and 30 (RTS/CTS) used only for LCD connection. If not, what pins do you recommend for softserial?

Jim

14

Jim,

Yes, pins 0 and 1 are free I/O on the Balboa. Like it is shown in our pin assignment table, those Arduino pin names correspond to the pin names PD2 and PD3 (respectively) on the ATmega32U4, which are the data input and output pins for USART1, which is the hardware serial port on that microcontroller. If you plan to use the Arduino’s Serial library with the Balboa (which uses an ATmega32U4 like the Arduino Leonardo), you should be sure to use Serial1 (instead of Serial) when communicating with pins 0 and 1. (You can read more about that on the Serial web page on Arduino’s website.)

Also, yes, if you do not use an LCD, then I do not see any obvious conflict when trying to use pins 11 and 30 (RTS/CTS).

-Jon