Could an ousb be programmed the same as Arduino?

Hi all,
Last year I did basic C++ at Uni and we had to buy an 'ousb'. Apart from turning LEDs on and off via a char value sent through a pipe we didn't use it very much. (Links about it at the end)
Its powered by an ATMEGA32 an I was wondering if it could be made to work like an Arduino, while I wait for my Arduino Mega 2560 to be sent?

I can program it (a little) at the moment but I'd rather be learning/programming it so I can be ready when my board arrives.
The reference PDF is: http://pjradcliffe.files.wordpress.com/2009/04/open-usb-io_reference_1v083.pdf
Schematic is: http://pjradcliffe.files.wordpress.com/2009/04/ousb_schematics.pdf

It all seems so awesome (as in awe-some as well as 'cool') and mind-boggling.

Thanks Byro

These just give more info:

www.pjradcliffe.wordpress.com

Well, there is a company in Thailand the produces an ATmega32 Arduino clone so it's not a huge stretch. A first step would be to download "Software Support" from their page:

The 12MHz clock rate will be a problem. Anything that relies on 'delayMicroseconds()' only works properly at 8 or 16 MHz. Also any value of MHz that doesn't divide into 64 evenly will get incorrect values for delay(). You should change the crystal to 8 MHz.

Then you have to burn an Arduino bootloader onto the chip. Since it comes with a 10-pin ICSP port and not a 6-pin ICSP port you will probably need an ICSP programmer that supports both, like the USBtinyISP from adafruit: USBtinyISP AVR Programmer Kit (USB SpokePOV Dongle) [v2.0] : ID 46 : $22.00 : Adafruit Industries, Unique & fun DIY electronics and kits

The "Software Support" from Thailand doesn't include a bootloader. Maybe the ATmegaBOOT.hex bootloader will work. Maybe it won't. I suspect they just didn't think users would need the ability to burn a fresh ATmega32 bootloader so I suspect the bootloader and fuse settings they provide are just left over from whatever boards.txt entry they cloned:

atmega32.name=ArduinoMega32
atmega32.upload.protocol=stk500
atmega32.upload.maximum_size=28336
atmega32.upload.speed=19200
atmega32.bootloader.low_fuses=0xff
atmega32.bootloader.high_fuses=0xdd
atmega32.bootloader.extended_fuses=0x00
atmega32.bootloader.path=atmega
atmega32.bootloader.file=ATmegaBOOT.hex
atmega32.bootloader.unlock_bits=0x3F
atmega32.bootloader.lock_bits=0x0F
atmega32.build.mcu=atmega32
atmega32.build.f_cpu=16000000L
atmega32.build.core=arduino

Other entries in there may be bogus as well. I'd suspect the maximum sketch size value. Also, the f_cpu will need to match your new 8 MHz crystal.

The Software Support provides a new ATmega32 compatible arduino core. Looks like they may have intended you to OVERWRITE the existing core. Probably better to save the new core as 'arduino32' under /hardware/arduino32/cores/arduino32

So the short version of that is not very easily and not without new parts. :slight_smile:

I'll leave it as is and save the money for parts for the Arduino. I'll use it for just playing around with while I wait, the main concepts will transfer across to the Arduino so I wont be wasting my time.

Thanks johnwasser that was very insightful and in depth.

That Thai company no longer sells the ATmega32 Arduino clone. Looks like this project might help:

https://github.com/eaconner/ATmega32-Arduino

If you want to still use the USB port you couldn't change the crystal to 8MHz, it needs to either remain at 12MHz, or you could the 16MHz version of V-USB.

It looks like OUSB used the software-driven (VUSB) code to connectivity, making it somewhat similar to the recent tiny85 systems that have been shipped (digiSpark, Gemma, Trinket.) That probably means that it COULD be used under Arduino, given some "Small amount of programming" (and perhaps that 16MHz crystal upgrade.)

Or it might be easier to run existing non-USB arduino cores (mega32 has been mentioned before), with the addition of an external USB/Serial cable.

Byro:
So the short version of that is not very easily and not without new parts. :slight_smile:

Actually, you may not have to change anything if you are willing to reinterpret the semantics of the delay() etc. functions.

So, delay(1000) now gives you a delay of ~1.33 seconds. delay(750) gives you a delay of ~1 sec. In many (if not most) situations, no big deal.

If you want your own version that automatically adjusts back to "real" milliseconds, write some wrapper functions. e.g.

void ousb_delay(unsigned long t)
{
 // multiply t by 3/4 to compensate for 12MHz clock when expecting 16MHz
 t *= 3;
 t /= 4;
 delay(t);
}

Just program it as if it was an Arduino 16MHz device, and see how you go. Worth a try... better than junking it.

I'd write that another way, just for the same of optimisation:

void ousb_delay(unsigned long t)
{
 // multiply t by 3/4 to compensate for 12MHz clock when expecting 16MHz
 t += (t<<1); //gets rid of slow multiplication - t*3 = t + (2*t) = t + (t << 1)
 t >>= 2; //this would have been optimised in anyway.
 delay(t);
}