Are there plans to update the Arduino IDE so that it uses a newer version of the Atmel Software Framework (ASF)?
This question arose for me while I was looking for a way to use the Arduino Due native USB port in OTG mode. This seemed interesting to try, as it would allow me to attach a Bluetooth dongle to my Due and use it as an SPP "server", presenting three virtual COM ports to a paired computer. This would allow me to electrically isolate my laptop from the Arduino, while allowing me to monitor text being sent by another Arduino to a text terminal.
The bottom line here is that I'll eventually be able to
use the Due as a Bluetooth device host (thanks to USBOTG on the SAM3X8E), without having to use an external shield - so lowering the cost of experimentation - as well as
avoid the timing issues of handling USB communication from within the main Arduino work loop.
After a couple of weeks or so of research on USB, SAM3X8E capabilities, and Bluetooth specs, I started work to merge headers and source files from ASF version 3.12 into my Arduino IDE USBHost library. My thought was that this would allow me to issue non-blocking USB pipe reads and writes, by using the interrupt-driven USB host device methods (uhd_setup_request(), uhd_ep_run()) in my code. The attempt succeeded: I'm now able to issue HCI commands from my Arduino Due to a Bluetooth dongle, without the hiccups (stalls, hangs) I encountered with blocking pipe reads and writes.
I do suspect, however, that I might be duplicating work already underway at Arduino LLC, and would like to find out whether release 1.5.5 will contain ASF 3.12.
Hi!
I am researching the SAM chip on the Due as well, and fiddeled around with the USBHost lib to read the messages of an Midi Keyboard.
Unfortunately i got stuck when connecting my device to the Arduino. I could read the device properties like manufacturer, interfaces and endpoints, but i couldn't address the device properly and establish a bulk connection.
I digged through most of the files of the USBHost lib, and the inline doc gave me some hints, but i didn't get the missing link.
So i kept reading and researching, and now i stumbled upon your thread.
Did you use the USBHost lib? How did you manage to address your bluetooth dongle? Which functions did you call?
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.
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.
The files we're interested in, for the Arduino Due, are located in
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.