Using BBB to replace Robotis robot controllers...

Greetings all,

I’ll apologize for the big lead up, I just want everyone to know where I’m coming from. I also apologize if I posted this to the wrong place or reposted it. I’m new here and still finding my way around.

I am considering getting a BBB to use with my Robotis robot kit to replace the CM-5 and CM-530 I’ve been using, and was hoping people here could give me help/advice/guidance, or direct me to those who can, as I have a million questions. I will start to list them here. Any help greatly appreciated in advance.

I’ve already written firmware for both the CM-5 (which is Atmega128 powered) and the CM-530 (which uses an STM32F103, an ARM Cortex M3), You can see the source for these here: Obviously these are bare metal firmware given that the extremely limited platform in both cases couldn’t practically support an OS. I would like to port my code to the BBB. I want to stick with the bare metal approach, so I can go real time without having to use a patch for the OS or Xenomai, and since I won’t be interested in a good part of the functionality of the board initially (also I’m kind of a big Linux noob). I have already downloaded StarterWare and started poking around. The big draw for me to BBB is the processor clock speed (the CM-5 is just 16Mhz, the CM-530 not much better at 72), the huge memory (for the controllers I’m using now, we’re measuring in Kb), and the huge number for GPIOs (the CM-5 has none, the CM-530 only has a few). So here are some of my initial questions:

  • Is anything special required to use the full 512MB memory? In other words, can I directly address all the available memory without having to go through any special procedures? Could I theoretically declare a really big structure (iike a MB or 2) or array and be able to handle it in code like I always have?
  • With the code I’ve written thus far, the servos are updated 128 times a second. I have everything for doing that interrupt driven. I have a timer fire an interrupt every 8ms that calculates the next servo target positions and creates a packet to put in a buffer that feeds the shift register of the serial bus. The serial bus is also interrupt driven. When the buffer is loaded, an interrupt is enabled that fires whenever the shift register is empty. Every time it fires, it loads the next byte from the buffer. If the buffer is empty, it disables the interrupt. Receiving bytes is handled similarly, firing an interrupt every time a byte is received to put it in a buffer and empty the shift register. This allows the packets to be consumed as quickly as the 1Mb serial bus can consume them. Could I do something comparable on the BBB?
  • My third, and heaviest question, is one of the main motivators for considering the BBB (and moving away from the above mention controllers). I would like to get into vision processing, so I would like to hook a camera (maybe two) to the BBB. I don’t want to use the camera cape (since I want to be able to position the camera somewhere else on the robot). Could I use something like the OV7670 hooked up to some GPIO pins? I was thinking something along the lines of having one pin output a clock to the camera (along with a pin for power and ground), and then have an input pin for the HREF, VSYNC, and pixel clock, and have the pixel clock pin set to fire an interrupt that would read the input pins that D0-D7 from the OV7670 are connected to and push them into a big buffer in memory. I figure for a 640 x 480 RGB565 image at 15 FPS, it would be about 9MB a second, and even if every byte was taking 20 to 30 clock cycles to handle (I think each interrupt could be handled much more quickly than this), it would only eat up at most 200Mhz a second (I’ve seen some posts talking about using the PRU for doing this). Does this sound totally off the wall? What would I need to interface the pins from the camera to the BBB GPIO pins?

I apologize for the long windedness of this. Like I said, I’m not really sure even where to start, or how applicable what little experience with ARM I already have is to this. Again, any help appreciated!

I’m not 100% sure about the 512MB of memory, but I suspect you’d be fine after the initial setup of the memory controller… probably best to look at the memory controller section of the technical reference manual in order to figure that out. I don’t imagine you’d have to deal with any virtual addressing or anything of that sort, as long as you can simply operate without the MMU.

The interrupt driven stuff should work just as well in the same way you’ve done with your other microcontrollers, I wouldn’t be too worried about that. I think that’s pretty much how the Linux drivers work anyway, unless they are using DMA. If you really wanted to get fancy and efficient, you could also set up DMA in the bare metal to take some load off the processor.

Lastly, I would imagine that you’d need the PRU to read from the camera, though you may be able to do something clever with DMA as well. It could also be worth looking at another platform that has dedicated camera hardware.

Personally if I was going to do this, I would stick with Linux and Xenomai (look into Machinekit for a way of getting that all set up without having to compile your kernel since they are pre-packaging it for you!!).
One thing is that Xenomai doesn’t have a “real-time safe” UART driver for BBB just yet, but if you can afford some slack on the latency of UART data coming in then you could find a way to work with the regular Linux driver and there are some options on bridging the data from non-realtime domain to realtime.
My reasoning is that Linux has multitasking and a lot of devices and services out of the box that you might want to use at some point (filesystems, networking, etc) and you can optionally add in other software (ROS, OpenCV, whatever you want) as you go along, which could be a lot harder to deal with in bare metal. If you have some hard requirement that forces you into bare metal, then that’s another thing…

Hope that helps some!