Forum - MCS Electronics

 

FAQFAQ SearchSearch RegisterRegister Log inLog in

Virtual USB-port for AVR
Goto page 1, 2, 3 ... 20, 21, 22  Next
 
Post new topic   Reply to topic    www.mcselec.com Forum Index -> BASCOM-AVR
View previous topic :: View next topic  
Author Message
Mrshilov
member
member


Joined: 24 Jan 2009
Posts: 98
Location: Russia

russia.gif
PostPosted: Thu Jun 25, 2009 1:06 am    Post subject: Virtual USB-port for AVR Reply with quote

http://www.obdev.at/products/vusb/index.html

Can anyone write a library for BASCOM to use this subj? It needs for many application. Pleeeeeeeease!
Back to top
View user's profile
pedro
member
member


Joined: 24 Apr 2009
Posts: 128

portugal.gif
PostPosted: Thu Jun 25, 2009 2:05 pm    Post subject: Reply with quote

Hello

Show this. I is Usb direct to Attiny2313 in Bascom without extra chip, but compare the schematic with the Bascom code i not understand how can this work.

Regards
Sato
Back to top
View user's profile
ollopa
member
member


Joined: 03 Sep 2007
Posts: 233
Location: California

usa.gif
PostPosted: Thu Jun 25, 2009 7:21 pm    Post subject: Reply with quote

I'm in the process of writing a firmware USB library for BASCOM.

OBDEV has a nice implementation but I don't want to copy theirs because of the infectious GPL license.

My results so far are promising. I'm about 80% through. I think I will have a library available for testing in about 1 week.

I plan to release it under a licensing structure similar to ARV-DOS, including a binary-only library that is free for personal use.
Back to top
View user's profile
pedro
member
member


Joined: 24 Apr 2009
Posts: 128

portugal.gif
PostPosted: Thu Jun 25, 2009 7:55 pm    Post subject: Reply with quote

Hello ollopa

That's great, all people that programming in Bascom will gratefull

Regards
Sato
Back to top
View user's profile
glena
member
member


Joined: 25 Jul 2007
Posts: 275
Location: PA near Philly

usa.gif
PostPosted: Thu Jun 25, 2009 8:09 pm    Post subject: Reply with quote

I too would love to see someone make this work! If possible I'd like the DTR line out as I use it for the reset line when serial boot loading to other avr chips.

Thanks again!

-Glen

_________________
http://bahbots.com
Back to top
View user's profile Visit poster's website AIM Address
AdrianJ
member
member


Joined: 16 Jan 2006
Posts: 2182
Location: Queensland

australia.gif
PostPosted: Thu Jun 25, 2009 11:40 pm    Post subject: Reply with quote

I dont see that you gain much over what you can do with an AVR connected to either an FTDI FT232 or 245 device. You tie up a fair bit of the AVR resources in doing the USB, rather than pass it off to a chip already well capable of doing just that job. Extra cost is almost negligible for small qty, compared to the time writing and integrating in the USB code, so unless you have some killer app selling in thousands, I cant see much advantage.

I would like to see an app that REALLY needs this, and could not be done any other way. The only one that I see would be a bootloader, where you dont want to add an extra chip just to provide that rarely used function.

_________________
Adrian Jansen
Computer language is a framework for creativity
Back to top
View user's profile Visit poster's website
ollopa
member
member


Joined: 03 Sep 2007
Posts: 233
Location: California

usa.gif
PostPosted: Fri Jun 26, 2009 12:26 am    Post subject: Reply with quote

Damn, the forum ate my reply! I had typed up a big one too.

AdrianJ: You are right that in many cases a dedicated chip is a better solution. The FTDI chips, however, are limited to emulating RS232 and parallel endpoints as far as I know. There are times when you want to make a custom class device or a HID class joystick or keyboard and then the FTDI chips are no good.

"Can I make FTDI devices appear as a different device class?
Return to Introduction Previous page Next page
FTDI have defined our own device class, so FTDI devices return a 0 for the bDeviceClass (Vendor class).

The class cannot be configured by the designer.

Our devices do not return the correct USB device descriptors to be USB HID class or USB Mass Storage class. It may be possible to write a filter driver that will make our chip appear to be a HID or mass storage class device, but to do this would involve a lot of work."

So there ARE cases when it is better to do a firmware implementation.

For what Glen is talking about, it doesn't make sense. USB is not RS232. USB is a multi-layer packet-oriented protocol with several important limitations.


Anyway,

An app that needs this would be a HID class keyboard or joystick. Can't do it with FTDI. Nice thing about HID class is that you don't have to write any custom drivers for the PC. When I'm done with my library and my project, I will put up a site with documentation and examples.
Back to top
View user's profile
AdrianJ
member
member


Joined: 16 Jan 2006
Posts: 2182
Location: Queensland

australia.gif
PostPosted: Fri Jun 26, 2009 1:27 am    Post subject: Reply with quote

I look forward to seeing your progress. I must admit I think much more about using AVRs as stand-alone controllers and data collection devices than as PC peripherals.
_________________
Adrian Jansen
Computer language is a framework for creativity
Back to top
View user's profile Visit poster's website
ex4
member
member


Joined: 13 Jan 2006
Posts: 1064
Location: indonesia

indonesia.gif
PostPosted: Fri Jun 26, 2009 3:25 am    Post subject: Reply with quote

to ollopa : may we know in what avr type it would fit? quick preview of the technical spec maybe Very Happy
very nice research you got there
hope it will be release soon
Back to top
View user's profile Visit poster's website AIM Address Yahoo Messenger
ollopa
member
member


Joined: 03 Sep 2007
Posts: 233
Location: California

usa.gif
PostPosted: Fri Jun 26, 2009 4:29 am    Post subject: Reply with quote

You need a part with at least 2k of flash. The USB code will use about 40 bytes of SRAM for one USB endpoint (+12 bytes for each additional endpont).

Two IO pins on the same port. One must be an interrupt pin--preferably Int0 because it is the highest priority.

A 12MHz crystal must be used. Timing is very critical and it must be exactly 12.000MHz. (in the future, the code may be modified for faster crystals like 15MHz. 12MHz is very hard to do, so I did it first. After that, it is easy to extend the code)

USB voltage levels are 3.3V. You can either run your AVR at this voltage or use zener diodes to clamp the IO pins. I will show schematics later, or you can search online. The important note is that if you use zener diodes, get small ones and get 3.6V zeners. 3.3v diodes will start to break down around 2.7v, which is technically too low for the USB spec.

So it should run on all the standard-voltage MEGAs and all but the smallest TINYs. (V and L parts are too slow)
Back to top
View user's profile
AdrianJ
member
member


Joined: 16 Jan 2006
Posts: 2182
Location: Queensland

australia.gif
PostPosted: Fri Jun 26, 2009 6:26 am    Post subject: Reply with quote

One real nuisance I can see with using this firmware USB as a bootloader, is that you MUST use a 12MHz crystal. That means your app must use that frequency too, unless you want to swap crystals just for a program load.

12 MHz is hopeless for UARTs. 7% error at 115200 baud, 2% error at 38400.
I suppose if it will work at 12 MHz, it can be adapted to work at 14.74 Mhz, the next nearest useful UART frequency.

But that still means recompiling a lot of programs, and adjusting timer prescalers. Especially for many apps running at low speeds or timing long intervals, you probably run out of timer range, which can be a pain.

I think I prefer being able to select processor crystal frequency to suit the application, than to suit the USB requirements.

_________________
Adrian Jansen
Computer language is a framework for creativity
Back to top
View user's profile Visit poster's website
Evert :-)
member
member


Joined: 18 Feb 2005
Posts: 1814

netherlands.gif
PostPosted: Fri Jun 26, 2009 9:45 am    Post subject: Reply with quote

AdrianJ wrote:

12 MHz is hopeless for UARTs. 7% error at 115200 baud, 2% error at 38400.
I suppose if it will work at 12 MHz, it can be adapted to work at 14.74 Mhz, the next nearest useful UART frequency.


The same problem we have with the usb-avr's from Atmel like the usb162 and usb1287.
The usb needs a clock of 48mhz, so the crystal must be 8mhz or 12mhz. This will be intern multiplied.
The Usb1287 that i'm using a lot must run on 8mhz otherwise the usb won't work, the disadvantage is indeed that the uart is not running perfect, however it works perfect now for 1year at 38k4.

More info: http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=61267&highlight=usb+baudrate

One of the disadvantage of the FTDI is that you can not decide yourself when flushing the internal buffer. This will give unregular delay in "realtime" transmission, maybe packet burst is a better name.
With dedicated usb chips like the atmel's and Ollopa code you can do this yourself. You still have a delay, but it's now regular and that's easier to compensate in the software.

_________________
www.evertdekker.com Bascom code vault
Back to top
View user's profile
ollopa
member
member


Joined: 03 Sep 2007
Posts: 233
Location: California

usa.gif
PostPosted: Fri Jun 26, 2009 10:27 am    Post subject: Reply with quote

Well 19200, 28800, and 57600 work fine with an error 0.16%. I use 57600, myself (MEGA644). The crystal requirement is because low-speed USB works at 1.5Mbps and does not tolerate any error. 12MHz allows for 8 cycles between bits, 15MHz allows for 10, 16.5MHz gives 11. 14.74, on the other hand, would be 9.826666 cycles between bits. You can see that the error would accumulate and it would be impossible to maintain accurate USB timing at that frequency.

There are definitely trade-offs that need to be considered when bit-banging USB on an AVR. I think a lot of people have misconceptions about how USB works, too. It's not like RS232 where you just connect two devices together and start sending data back and forth. Data are sent in packets of limited size with headers and CRC footers. The host (the PC) always initiates communication. Even if the device (AVR) has a burning message to transmit, it has to wait until the host requests the data. There is a whole enumeration phase that the device must go through when it is first connected that describe in detail all its specifications and requirements to the host. The PC uses some of this information to search for drivers or to decide how much power to make available to the device. The minimum polling time is also specified and for low-speed USB devices this is no less than 10ms. That means there is at least 10ms latency in all low-speed USB communications. If you specify 10ms polling interval, then the AVR will be busy processing USB packets all the time. If you specify a less frequent polling interval, then there will be greater latency in the communications.

USB passes information in virtual "pipes" that terminate at different "endpoints" on the device. That's how some devices might have a keyboard AND a mouse, but only one plug. Or a scanner, fax, and a printer. Each virtual device likely has its own separate endpoint. Low-speed USB (which is all the AVR can do in firmware) supports only the default control endpoint (which is bidirectional) and two additional unidirectional endpoints. I know it's funky and somewhat confusing and I swear I am not making this up. I have no idea why supplemental pipes were decided to be unidirectional.

The full usb1.1 spec is available for free on usb.org for anyone who is interested. It's a long read and it doesn't even begin to cover HID class, which is something I think people will be interested in. There is a separate document that describes HID descriptors and how all that works.

Suffice it to say, rolling your own USB peripheral is not for the faint-of-heart. It still is of great interest to myself and undoubtedly others. I was planning to wait to announce my work with BASCOM in this area, but this was the second request for firmware USB that I have seen and I thought I should mention something.

A complicated subject like this will generate a lot of questions and require both a healthy set of documentation and lots of examples. USB is very open-ended. Just like programming, there are several ways to solve the same problem and I cannot say which way will be the best for anybody else's particular project. The library I am putting together is the Serial Interface Engine (SIE) part of the protocol. It gets and sends the raw USB packets with a minimum of automated processing. That leaves all the possibilities open to implement whatever kind of endpoints and communication protocols you choose. Again I plan to demonstrate how to do that through examples--I'm sure most of what I am babbling on about is confusing unless you have some prior USB experience.

For anyone who really wants to get into this, I recommend the following two condensed introductions to USB:
http://www.usbmadesimple.co.uk/
http://www.beyondlogic.org/usbnutshell/usb1.htm

They give good explanations of the data flows and basic descriptors of USB. After that, what I just said above will make more sense.

HID is a wholly separate topic and some tools and resources on it can be found here: http://www.usb.org/developers/hidpage/

I think this is the last big post I will make until I have some code to show. I have my work cut out for me if I'm going to deliver on all these promises I have made. I have basic sending and receiving working right now. ACK and NAK working fine. I'm extending the code to handle multiple endpoints and to properly track DATA0/DATA1 toggling for each endpoint (I refer you to the spec or those condensed links I posted for further explanation). I spent weeks working on the assembly ISR so that it can decode the captured serial stream in real-time. You need about 9 or 10 instructions to read and decode each bit, but at 12MHz you only have 8. There are lots of tricks required to optimize the routine and make it work and I will just leave it at that. The hard part is working and I just have to extend it for those optional endpoints and write up some examples.
Back to top
View user's profile
Luciano
member
member


Joined: 29 Nov 2004
Posts: 3149
Location: Italy

blank.gif
PostPosted: Fri Jun 26, 2009 11:04 am    Post subject: Reply with quote

Hi,

Here's some additional reading:

AVR309: Software Universal Serial Bus (USB)
www.atmel.com/dyn/resources/prod_documents/doc2556.pdf
Author: Igor Češko

Igor Češko WEB site:
>http://www.cesko.host.sk/IgorPlugUSB_RS232/IgorPlug-USB%20(AVR)%20RS232_eng.htm

* * *

Implementing USB 1.1 in Firmware by Christian Starkjohann
http://www.obdev.at/developers/articles/00003.html

Best regards,

Luciano
Back to top
View user's profile
AdrianJ
member
member


Joined: 16 Jan 2006
Posts: 2182
Location: Queensland

australia.gif
PostPosted: Sat Jun 27, 2009 8:43 am    Post subject: Reply with quote

Yah ! I too read through the USB spec, and decided it was all too hard. Great for PCs and their standard peripherals.

You have done a lot of work to get so far, congratulations. I am glad someone still does this sort of heavy ASM processing, but in this case I'm also glad its not me.

The transmission delay lags I dont see as a problem, at least for any of my apps, I dont need real time response, just a way of transmitting data to/from a PC with only a USB port. But certainly for a HID type device it could become an issue.

Have fun !

_________________
Adrian Jansen
Computer language is a framework for creativity
Back to top
View user's profile Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic    www.mcselec.com Forum Index -> BASCOM-AVR All times are GMT + 1 Hour
Goto page 1, 2, 3 ... 20, 21, 22  Next
Page 1 of 22

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum