Objective Development Forums

I am trying to make a board using BootloadHID. So far it works well, and I managed to compile it with the latest version of the driver. I have several questions, however.

1. What is better - to use 3.3v for ATMEGA8 and risk that it will not work or use 5v for USB and risk it will be damaged ? Currently I placed ONE diode, so there is 4.5 volts on ATMEL.

2. Is it possible to fool C runtime and use USB routines at the bootloader from the main program, thus saving 2 kb of memory ?

3. I need a sort of a terminal to communicate with the board. Did someone already try to make such a thing over HID USB connection ?

Re (1): I have seen no chip which fails at 3.3 V, although it's outside the spec. Even the 10 MHz devices work. So I assume that it's safe. USB devices and hosts can't be damaged with 5 V levels, the spec demands that. However, some hosts simply don't work with 5 V on D+ and D-.

Re (2): In principle, that would be possible. But it's not worth the effort. Since the driver has a lot of compile-time options, both, the main software and the boot loader would have to use the same options. You would only save ~ 1200 bytes. The rest is application layer code which can't be shared.

Re (3): See AVR-Doper and the avrdebug tool. Or AVR-CDC.

Hello!

This is the first time post in this forum. I like a lot v-usb and bootloadHID projects. I come from Arduino and Java worlds.

I have a project that I use ATmega8 and on in I run the bootloader. My main application code + V-USB is around 6kb and I am desperate for an extra kb!!

Is there a possibility to point us to the right direction to share the bootloader's V-USB driver with the main application??

Thanks in advance!!

er

Just upgrade your chip...

What you are asking for is probably not possible, V-USB includes and excludes code depending on each project configuration.

It is possible and I have seen code which shares the USB driver between boot loader and main code. Can't remember the reference, though.

However, in general, I'd really recommend against this solution. That's because most of V-USB's features are compile time constants. You would have to ensure that you need the same configuration in the boot loader AND in the main code. Furthermore, you are locked to a particular version of V-USB in the main code, since you can't change the boot loader via the boot loader. This is definitely not what you want.

You would save ca. 1.2 kB of code in the best case. If you move compile-time options to run-time (e.g. provide descriptors via functions), that will even be less because these functions are duplicate in the boot loader and in the main code.

In general, I'd recommend a chip with more memory. Unless this is really large scale production. And IF this is large scale production, I'd recommend against locking the code to a particular V-USB version.