Since my post last December, I've scouted around for other ways to electrically isolate my laptop from the Due board. I've finally settled on using Beaglebone Black as a command-line development environment: The BBB is connected via Ethernet, and I connect to it from my laptop via SSH over wireless. The key piece of technology I used was Yann E. Morin's crosstool-NG (http://crosstool-ng.org/
) which allowed me to build an arm-none-eabi toolchain. I then copied over most of the stock Arduino hardware/ and libraries/ directories (except for binaries) into the Beaglebone Black, and am now in business writing Makefiles for the Due. The verbose compile output option is turning out to be very useful, for reverse-engineering what should go into a general-purpose Makefile.
Anyway, back to your problem. Since it's been a while since I've experimented with the code, the hints I can share will be a bit sketchy.
0) After a few weekends of experimenting, I downloaded a nightly release of Arduino IDE, and the Atmel CMSIS release 3.12, from http://asf.atmel.com/docs/latest/download.html
. I then basically unpacked the CMSIS over /Applications/Arduino.app/Contents/Resources/Java/hardware/arduino/sam/system/CMSIS, and moved "certain" files (I can't recall which ones) from there into /Applications/Arduino.app/Contents/Resources/Java/hardware/arduino/sam/system/libsam. The only relevant ones for me were CMSIS source and example files that had to do with USB On-The-Go functionality, and which already
exist in the Arduino Nightly release directory. My idea was simply to upgrade the parts of the Arduino CMSIS files that affected my project.
1) The files we're interested in, for the Arduino Due, are located in
2) I found individual source files for each SAM3X subsystem in the ./source subdirectory. For example, USB on the Go support, it was informative to read
3) I ended up annotating a lot of these files, and enabling debugging statements (which get printed to the Arduino console) to understand what happens during initialization. Then I wrote additional code to initialize the Bluetooth dongle, starting with low-level HCI commands (that really gave me headaches, trying to find things out from the USB Developer's Forum http://www.usb.org/developers/usb20/
, but well worth the trouble.). The three important insights I got from this are:
- First, the USBHost methods in Arduino use only a fraction
of the Atmel CMSIS framework API. There are other subsystems in the SAM3X8E chip (true random number generator, real time clock, for example) that can be accessed directly using the CMSIS API, but which are not exposed by the Arduino IDE and libraries. This means that it's still worth the trouble to write your own C/C++ code, which we will likely have to do to max out our use of these wonderful little Due boards.
- Secondly, the CMSIS framework is able to call user-defined callback functions. This is key. You can write functions that will be invoked, for example, when there is a USB error condition, or when RFCOMM messages are completed. In fact, you most likely will have to - remember, the Arduino is a learning environment, and what you're facing is that you've outgrown the limitations of that environment.
These functions of yours should be declared in with extern "C" linkage, and should match the CMSIS callback method signatures exactly. I suspect you'll also need to hack at the uotghs_host.c file, and extend it with your own functions, to do what you need to do with the MIDI device.
- Finally, for my purposes it was definitely not
necessary to use a dedicated Bluetooth USART board to communicate with the Due. You can use a Bluetooth dongle, as I [partially] document here: http://avahilario.net/2013/12/arduino-bluetooth-blues/
. However, it's a time-and-dollars tradeoff: Either I spend money to buy the Bluetooth USART board, or spend time to make the board do what I want with a dongle. I suspect your tradeoff calculation will come out the same way mine did: Write the code myself, and have fun.
I hope you'll find the hints useful!