Thoughts on USB and Flash,PD,Processing,vvvv,etc.

I've been experimenting with native USB ports on Arduinos. That is, I do not use an ftdi serial-usb chip, but implement the USB directly using three digital pins. The Arduino appears as a device on the host's USB and can be accessed directly.

I have been using libusb from C on a linux box for testing because it is the simplest environment that still gives me 100% control over the bus transactions. I suspect most Arduino users would like a higher level interface.

Since I have no experience with Flash, PD, processing, vvvv, or any of the other fancy tools, I will ask here...

What sort of a USB interface is reachable from these tools? Can they easily use an external library, like libusb? Can they easily use a USB device that conforms to the HID class, if so can they set data as well as read it? Would they be able to access it easily with a little helper program?

I would like to avoid the CDC serial interface. It is possible to make a virtual serial port and I presume all of the tools could access it, but it is not possible by the specification to implement CDC on a low speed device, though it appears that many OSes will actually work with a bit of a hack. In any event, that loses much of the protocol gains that are made by going to a structured, message based protocol like USB in the first place.

(For those interested: The code still has to run with a 12MHz crystal. I believe I can make it work at 16MHz but haven't run that experiment yet. I also believe I can make it not have the pins hard coded in the library, certainly at 16MHz it will have enough extra cycles. I use three pins in order to have a software disconnect function. You could get by with two, but it is much nicer during development to have the device disconnect and reconnect as part of booting. A USB bootloader will not fit, but I might be able to work something out by making the USB code live in a fixed area of non-boot memory and be shared by the bootloader and the sketch.)

Hello

The 12MHz is needed... the timings are so strict that you cant do anything about it...

about PD and friends... you can implement the HID interface and PD can connect to that... Hans developed a great object for it.

VVVV could be adapted by writing a specific object for it, same goes for other systems..

it is possible to have a USB low level bootloader fit in 2k

this is exactly what we are doing here:

http://www.tinker.it/en/Products/Tastiera

goes on sale at the end of the month

massimo

Well that is a tempting looking device, and such a clean board. And here I was going to give up on getting a bootloader into 2k, now I'll have to rewrite the usbtiny bit handler code to shave space.

About 16MHz, it will require using a pattern of 11-10-11 clock cycles for each group of 3 bits, but that results in a jitter of +21ns,-40ns,+21ns which is nearly within the low-speed upstream function driver jitter budget, if we start with an accurate crystal instead of a resonator. The 45ns jitter allocated to low speed hubs is far much larger than the out of spec component of the function source jitter. I have hopes that modern hubs aren't nearly that bad and the end result will be within spec.

Still, 12MHz, 15MHz and 18MHz make a lot more sense for new gear.

did you write the whole protocol yourself? or are u using the obdev drivers?

massimo

I started with usbtiny and have been extending and reworking it. It looked a bit smaller than obdev, but they are close.

MaxMSP has a really nice HID object too.

Paul Badger