v-usb and CodeVision

[mantares]

I am new to v-usb and, after reading the posts, am curious as to what the current status (August 27, 2009) is working with v-usb in a CodeVision environment?

[NeVaDa]

hi
no , at this point its not working with cvavr but
i'm interested if this project can compile with cvavr.
of course i try to compile it with cvavr but there are some problems.
we have to compatible it with avr assembler 2 [ inline asm file ].
who can help me to compile it???

[Grendel]

Why ? WinAVR and AVR Studio are free, professional high performance tools.

[mantares]

I've used AVR Studio with the GCC plugins and it's not too bad for the price . I just like CV better and it's the programming environment we use in our company so, just to keep things consistent, we would like to be able to compile v-usb using it. If no one has already succeeded, I'll try my hand at it...I'm already familiar with many of the general porting issues involved in getting GCC code to compile with CV. I just don't want to reinvent the wheel if someone has already gone through the effort!

Michael Antares
Senior Systems Engineer
New Water Technologies

[Grendel]

For pro-development I'd suggest to check out the Atmel chips that come w/ a USB module like the Atmega16U4.

[mantares]

Grendel, I'd love to use the chip rather than v-usb but for a high-volume product the price difference is significant between a device having usb capability and one that doesn't. If v-usb can do the job the savings are very significant. For our product speed is not an issue so a low-speed implementation is OK. What I would be concerned about is if using the firmware method creates issues for the end-user that a hardware method doesn't.

[Grendel]

Well, w/o knowing the details of what you need I really don't know (you may get away w/ a AT90USB82, as low as $1.80 @ 100 quantity). Just making sure you're aware of native USB AVRs The main problems w/ V-USB are 1. USB 1.1 (slow) and 2. it needs a guaranteed low ISR latency. Depending on your device class that may also come w/ high CPU bandwidth usage, you have to be very carefull how you utilise the remaining CPU time. The USB driver overhead w/ the native USB modules is a lot lower and more forgiving latency wise. Plus the modules support USB 2.0 full speed and have a build-in voltage regulator for 3.3V, makes the interface real simple.

[mantares]

Grendel, you've convinced me! I also found that the chip price is not that high. I think using V_USB could box us into a development corner where we spend a lot of time fighting timing issues--been there, done that and don't need to do it again . The processor does have other tasks to do that may be time critical to some extent so goodbye to V_USB, at least for this time.

Again, thanks for your inputs...

Michael

[Grendel]

You are welcome For development check out the Teensy boards. Be aware that his code examples don't implement a full USB state machine in the interrupt, they are good for learning tho. As an alternative take a look at the Atmel USBkey board. Atmel has example source code for the USB chips online, you have to digg for it on the Atmel site tho (eg. here and here).

[christian]

For large scale professional products, I'd really recommend chips with built-in hardware USB. You can NEVER become USB compliant with V-USB because the AVR does not meet the electrical specifications.

Regarding CodeVision: I tried to port V-USB to this development environment, but there are some fundamental problems. Maybe we can port to a forthcoming release of CodeVision AVR.