Post by thread:[PIC] USB Resources.

Hi there. I know the USB dragon keeps getting slayed over and over again on this mailing list, but I finally got contracted to make a device which interprets some simple user data (switch closures, mostly) and sends them to a PC at a really slow (8kbits per second would be more than sufficient) data rate. The client wants the project done with USB, and honestly, I've been remiss in not taking it upon myself to figure out that particular protocol before now. I guess the questions I have for you wizards are: 1.) I'm inclined to use one of the PIC18F parts with a hardware usb transciever, although I've seen it done in examples with software and an external transciever IC. Any reason I would want to use the two chip solution? 2.) I'm getting it together, slowly, from datasheets and the Microchip docs. Can any of you recommend a good (better) resource (web page, book, source code, etc) for a simple USB project AND/OR usb theory of operation? Seems like there's a lot of arbitrary handshaking and protocols that go on in USB communication. Any pointers you guys had would be great. You've always steered me right before -- I hope these questions aren't too remedial or understudied. Thanks in advance, Yours, Todd

On 15/12/05, Todd Bailey <spam_OUTtm_baileyTakeThisOuThotmail.com> wrote: {Quote hidden}> > Hi there. > > I know the USB dragon keeps getting slayed over and over again on this > mailing list, but I finally got contracted to make a device which interprets > some simple user data (switch closures, mostly) and sends them to a PC at a > really slow (8kbits per second would be more than sufficient) data rate. > The client wants the project done with USB, and honestly, I've been remiss > in not taking it upon myself to figure out that particular protocol before > now. > > I guess the questions I have for you wizards are: > > 1.) I'm inclined to use one of the PIC18F parts with a hardware usb > transciever, although I've seen it done in examples with software and an > external transciever IC. Any reason I would want to use the two chip > solution? > > 2.) I'm getting it together, slowly, from datasheets and the Microchip docs. > Can any of you recommend a good (better) resource (web page, book, source > code, etc) for a simple USB project AND/OR usb theory of operation? Seems > like there's a lot of arbitrary handshaking and protocols that go on in USB > communication. > > Any pointers you guys had would be great. You've always steered me right > before -- I hope these questions aren't too remedial or understudied. > > Thanks in advance, > > Yours, > > Todd > Todd, There's a few web pages around with examples of AVRs being used as USB slaves directly. Low speed mode - 1.5Mb/sec only. May be enough for you anyway. But the pages do give a certain amount of background info for this sort of implementation. The examples are mostly HID type devices such as joysticks etc. but it seems a good place to start. RP

> -----Original Message----- > From: Todd > Sent: Thursday, December 15, 2005 10:31 AM > To: .....piclistKILLspam@spam@mit.edu > Subject: [PIC] USB Resources. > > Any pointers you guys had would be great. You've always > steered me right before -- I hope these questions aren't > too remedial or understudied. > The Microchip Forum USB section is one of the best place to discuss PIC USB chips. http://forum.microchip.com/ I've collected some PIC USB related websites here. http://forum.microchip.com/tm.asp?m=123533 I am still a beginner of USB and I feel it is not a easy topic in general. Regards, Xiaofan

Todd Bailey wrote: {Quote hidden}> Hi there. > > I know the USB dragon keeps getting slayed over and over again on > this mailing list, but I finally got contracted to make a device which > interprets some simple user data (switch closures, mostly) and sends > them to a PC at a really slow (8kbits per second would be more than > sufficient) data rate. > The client wants the project done with USB, and honestly, I've been > remiss in not taking it upon myself to figure out that particular > protocol before now. > > I guess the questions I have for you wizards are: > > 1.) I'm inclined to use one of the PIC18F parts with a hardware usb > transciever, although I've seen it done in examples with software and > an external transciever IC. Any reason I would want to use the two > chip solution? > > 2.) I'm getting it together, slowly, from datasheets and the Microchip > docs. Can any of you recommend a good (better) resource (web page, > book, source code, etc) for a simple USB project AND/OR usb theory of > operation? Seems like there's a lot of arbitrary handshaking and > protocols that go on in USB communication. > > Any pointers you guys had would be great. You've always steered me > right before -- I hope these questions aren't too remedial or > understudied. > > Thanks in advance, > > Yours, > > Todd > > While using a USB PIC seems like best solution, the easiest solution is to use the FT232B AND a simple serial PIC, such as an F88. That way, you can use their free USB Windows driver that works perfectly. You will get bogged down quickly trying to do this by the specs. My printed copy of the USB 2.0specs is 2 2" notebooks thick. Microchip makes fooling with the USB PICs a tough job. I'm not saying you can't do it, but its a lot like teaching yourself brain surgery and practicing on the closest available brain (yours). --Bob -- Note: To protect our network, attachments must be sent to attachKILLspamengineer.cotse.net . 1-520-777-7606 USA/Canada http://beam.to/azengineer

You can get a 18f4550 usb demo board fairly cheap, and play with the example CDC serial code (AN956). That'd get you going pretty fast. Microchip has a couple of less expensive USB offerings for production --18F2550 and the soon upcoming 18f2450, depending on what other hardware you'll be needing. Anyway, the serial example will get you moving with a minimum of fuss. www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1824& appnote=en021631 If you've got time critical services (other than USB) the two part solutions give you more cpu power dedicated to your task --the 18F is fairly busy while servicing the USB. I think the 18F is a more flexible solution even in 2 device solutions --you have an extra processor to do things with if you aren't using it for USB at the time --for basically the same price as a dedicated USB to serial converter. I've also got designs out with the FTDI chip --which works pretty well. They've just released a new one that is pretty similar to the cygnal offering --oscillator and other support "jellybeans" are on chip. -Dal {Original Message removed}

Whoa -- I checked out those datasheets for USB to serial and they seem immesurably easier. So with the FT232 or the CP2102 (and the driver on the PC end) it's just a matter of sending, say, a serial byte from the PIC to the interface chip, and then, voila -- it shows up in Hyperterminal or whatever? Meaning that if I send the ascii code for 'Hello World /n' it'll just magically appear? Is it just that easy? If this is the case, wow indeed. If not, I expect I'll find out soon enough. Either way (and as usual) I suspect this list has saved me a lot of toothgrinding. Thanks again, guys. Yours, Todd Bailey From: Bob Axtell <.....engineerKILLspam.....cotse.net> Reply-To: "Microcontroller discussion list - Public." <EraseMEpiclistspam_OUTTakeThisOuTmit.edu> To: "Microcontroller discussion list - Public." <piclistspam_OUTmit.edu> Subject: Re: [PIC] USB Resources. Date: Wed, 14 Dec 2005 20:00:21 -0700 Todd Bailey wrote: {Quote hidden}>Hi there. > > I know the USB dragon keeps getting slayed over and over again on this >mailing list, but I finally got contracted to make a device which >interprets some simple user data (switch closures, mostly) and sends them >to a PC at a really slow (8kbits per second would be more than sufficient) >data rate. > The client wants the project done with USB, and honestly, I've been >remiss in not taking it upon myself to figure out that particular protocol >before now. > >I guess the questions I have for you wizards are: > >1.) I'm inclined to use one of the PIC18F parts with a hardware usb >transciever, although I've seen it done in examples with software and an >external transciever IC. Any reason I would want to use the two chip >solution? > >2.) I'm getting it together, slowly, from datasheets and the Microchip >docs. Can any of you recommend a good (better) resource (web page, book, >source code, etc) for a simple USB project AND/OR usb theory of operation? >Seems like there's a lot of arbitrary handshaking and protocols that go on >in USB communication. > > Any pointers you guys had would be great. You've always steered me right >before -- I hope these questions aren't too remedial or understudied. > >Thanks in advance, > >Yours, > >Todd > > While using a USB PIC seems like best solution, the easiest solution is to use the FT232B AND a simple serial PIC, such as an F88. That way, you can use their free USB Windows driver that works perfectly. You will get bogged down quickly trying to do this by the specs. My printed copy of the USB 2.0specs is 2 2" notebooks thick. Microchip makes fooling with the USB PICs a tough job. I'm not saying you can't do it, but its a lot like teaching yourself brain surgery and practicing on the closest available brain (yours). --Bob -- Note: To protect our network, attachments must be sent to @spam@attachKILLspamengineer.cotse.net . 1-520-777-7606 USA/Canada http://beam.to/azengineer

Yeah, cost and processing power were the two big reasons I thought it would be a good idea to use the PIC in the first place -- for any run of more than a dozen it seems like it'd be hard to justify the cost of the extra IC. I'll look into that demo board. It seems like it'd be useful to learn, even if it is a little hairier than using one of the interface ICs. Thanks for the tip, TB From: "dal" <KILLspampiclistsrvKILLspamcableone.net> Reply-To: "Microcontroller discussion list - Public." <RemoveMEpiclistTakeThisOuTmit.edu> To: "'Microcontroller discussion list - Public.'" <spamBeGonepiclistspamBeGonemit.edu> Subject: RE: [PIC] USB Resources. Date: Wed, 14 Dec 2005 21:32:02 -0700 You can get a 18f4550 usb demo board fairly cheap, and play with the example CDC serial code (AN956). That'd get you going pretty fast. Microchip has a couple of less expensive USB offerings for production --18F2550 and the soon upcoming 18f2450, depending on what other hardware you'll be needing. Anyway, the serial example will get you moving with a minimum of fuss. www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1824& appnote=en021631 If you've got time critical services (other than USB) the two part solutions give you more cpu power dedicated to your task --the 18F is fairly busy while servicing the USB. I think the 18F is a more flexible solution even in 2 device solutions --you have an extra processor to do things with if you aren't using it for USB at the time --for basically the same price as a dedicated USB to serial converter. I've also got designs out with the FTDI chip --which works pretty well. They've just released a new one that is pretty similar to the cygnal offering --oscillator and other support "jellybeans" are on chip. -Dal {Original Message removed}

Todd Bailey wrote: > 2.) I'm getting it together, slowly, from datasheets and the Microchip > docs. Can any of you recommend a good (better) resource (web page, > book, source code, etc) for a simple USB project AND/OR usb theory of > operation? Seems like there's a lot of arbitrary handshaking and > protocols that go on in USB communication. I'm just starting on my first real native USB project now too. I think I'll be sending the boards out this afternoon. The new 18F USB PICs look great on paper. I'm using the 18F2550. I've read thru the docs and things seem clear enough at this point. I'm sure there'll be various hickups along the way, but I won't know what those are until getting knee deep into the software and firmware. I don't see any substitute for reading the real documentation, which in this case is the USB spec and the PIC data sheet on the device side. I'm sure there'll be questions once I start writing the code, but at this point it all seems to be there. I haven't looked into the host side at all yet, but Microsoft usually does a good job of documenting their stuff. I'm assuming they will have a mini-port driver architecture for individual vendor and device IDs, but I don't know yet. I'll be real surprised if the necessary information isn't in the MSDN Library and the DDK. For this project I could probably make due with the device acting like a HID, but part of my motivation for doing this project is to have a full native USB implementation from host library to PIC pins that I can easily re-use for other projects. I'm planning on making the application interface to the USB device look like a bi-directional stream of bytes. This will make it possible to use other low level connection schemes to a device without the higher layers of the software needing to know the difference. A bi-directional stream of bytes makes the most sense as you can get pretty much anything with that with the right high level protocol. And, other low level interfaces provide this too, like RS-232 and TCP. Anyway, I'm looking forward to getting into the firmware/software and getting this capability set up. So many idea, so little time.... ****************************************************************** Embed Inc, Littleton Massachusetts, (978) 742-9014. #1 PIC consultant in 2004 program year. http://www.embedinc.com/products

Bob Axtell wrote: > You will get bogged down quickly trying to do this by the specs. Why do you say that? This is exactly what I'll be trying to do. I have read the standard and the 18F2550 data sheet and it all seems clear enough at this point. It sounds like you know something more here. What have you found? > My printed copy of the USB 2.0specs is 2 2" notebooks thick. Mines not so bad as I used a single 4" notebook ;-). Really though, while the spec is certainly dry it does appear to be complete and clear. All in all I thought it was well written for what it is. I've certainly seen worse. > Microchip makes fooling with the USB PICs a tough job. Please elaborate as I'm about to start doing this. On a bigger point, why does everyone have the attitude that this must be done by someone else. Clearly *someone* has to understand and implement this stuff. To me this prevailing attitude is even more motivation to do it myself because I'll end up with something more rare and therefore valuable in the end. What am I missing? ****************************************************************** Embed Inc, Littleton Massachusetts, (978) 742-9014. #1 PIC consultant in 2004 program year. http://www.embedinc.com/products

> On a bigger point, why does everyone have the attitude that > this must be done by someone else. Someone must eradicate this attitude! Seriously, this is something that realy annoys me too. Why isn't there a free GCC compiler for 12 and 14 bit PICs? Why are there no cheap, easy-to-read, complete, and of course error-free PIC books targeted specifically at me? Why can't Microchip make a list of all as-yet unidentified problems in PICs? Why are the Microchip datasheets so thick and difficlut to read? Why arn't there any good starter-level introduction sites for 18F's, 30F's, etc. Why has no-one made the ideal PIC prototyping PCB and made it available for $10 or less? Why? Why didn't you do it, dude! Everyone else has as good a reason not to do it as you have! Wouter van Ooijen -- ------------------------------------------- Van Ooijen Technische Informatica: http://www.voti.nl consultancy, development, PICmicro products docent Hogeschool van Utrecht: http://www.voti.nl/hvu

Olin Lathrop wrote: > Bob Axtell wrote: > >> You will get bogged down quickly trying to do this by the specs. ..... {Quote hidden}>> Microchip makes fooling with the USB PICs a tough job. > > Please elaborate as I'm about to start doing this. > > On a bigger point, why does everyone have the attitude that this must be > done by someone else. Clearly *someone* has to understand and implement > this stuff. To me this prevailing attitude is even more motivation to > do it > myself because I'll end up with something more rare and therefore valuable > in the end. What am I missing? > I don't have the experience you guys do to separate the wheat from the chaff but while looking at USB I ran across this FWIW. http://forum.microchip.com/tm.asp?m=85120&mpage=1&key= Seems to imply an unacknowledged bug in the eusart on some USB PICs? Is it something to worry about? D

On 12/15/05, M Graff <TakeThisOuTexplorer-piclistEraseMEspam_OUTflame.org> wrote: > Wouter van Ooijen wrote: > > Seriously, this is something that realy annoys me too. Why isn't there a > > free GCC compiler for 12 and 14 bit PICs? > > Why can I not find if there is an 18F back-end for gcc? > > Seriously, this is actually a question, not a whine. I'm currently > looking at the source for gcc to see if someone got to it already. :) Because GCC, like C in general, expects a stack-based computer. But since the 18F processor has such a small stack, and addressing values on the stack is so cumbersome, most compilers use a "compiled stack" (i.e. use and re-use memory based on what parameters are currently in use, based on which functions call which functions (a "call tree")). Since GCC does not know how to deal with a "compiled stack", GCC does not make a good 18F C compiler. Bill -- Psst... Hey, you... Buddy... Want a kitten? straycatblues.petfinder.org

> Why can I not find if there is an 18F back-end for gcc? I don't understand the question. How would you find that there is NO backend for a let's say a 74HCT595? You can only find what is there... But to my best knowledge there is no backend for the 18F's, and there would be a lot of demand. But I think the 18F's are nmot as C-friendly (at least not GCC-friendly) as Microchip says. For efficient code generation you would have to make the step from GCC's stack/registers oriented organistation to the one-register/direct-memory-addressing PIC architecture. Wouter van Ooijen -- ------------------------------------------- Van Ooijen Technische Informatica: http://www.voti.nl consultancy, development, PICmicro products docent Hogeschool van Utrecht: http://www.voti.nl/hvu

On Wed, 2005-12-14 at 23:38 -0500, Todd Bailey wrote: {Quote hidden}> Whoa -- I checked out those datasheets for USB to serial and they seem > immesurably easier. > So with the FT232 or the CP2102 (and the driver on the PC end) it's just a > matter of sending, say, a serial byte from the PIC to the interface chip, > and then, voila -- it shows up in Hyperterminal or whatever? > Meaning that if I send the ascii code for 'Hello World /n' it'll just > magically appear? > Is it just that easy? > > If this is the case, wow indeed. If not, I expect I'll find out soon > enough. > > Either way (and as usual) I suspect this list has saved me a lot of > toothgrinding. > > Thanks again, guys. > > Yours, > > Todd Bailey > Yes, it's that easy! Both the CP2102 and the FT232 come with "virtual comm port" drivers for various operating systems. They also come with directly callable drivers if you don't want the device to look like a serial port. My experience is with the CP2102. It has worked quite well. In one application, I'm running it at 500kbps and driving the internal UART on a PIC. Harold

On Dec 15, 2005, at 5:10 AM, Olin Lathrop wrote: > why does everyone have the attitude that this must be done by someone > else. Clearly *someone* has to understand and implement this stuff. Well, at some point you have to decide whether you want to be an OS and protocol stack developer, or an "application" developer. For large companies, it certainly seems to be easier to buy a USB stack than to spend a couple man years (at $100k+ each) writing one that then isn't compatible with anything else (at the internal API layer) and requires each new employee actually LEARN about its idiosyncracies before they can start using it... Much easier to advertise "should be familiar with berkeley tcp using sockets" than "needs to learn cisco IOS TCP API..." :-( Then there's the whole testing and compatability problem; You develop your USB device stack and it works fine on every OS and machine you have available to try it on, but somehow doesn't work on the customer's newer model laptop. grr. On the one hand, it's nice to understand the code well enough to be able to attack the problem yourself; on the other hand it sure would have been nice if the stack had been written by someone with more testing resources in the first place. (There's a related "open source" dilemma. Sure, you can find and fix bugs yourself. Theoretically. But the number of people actually capable of doing that is much smaller than the number of people likely to be affected by that bug...) BillW

> Well, at some point you have to decide whether you want to be an > OS and protocol stack developer, or an "application" developer. For > large companies, it certainly seems to be easier to buy a USB stack > than to spend a couple man years (at $100k+ each) writing one that > then isn't compatible with anything else (at the internal API layer) and > requires each new employee actually LEARN about its idiosyncracies > before they can start using it... I agree that the USB "stack" is something the operating system should take care of for you, but I wasn't talking about that. I was only reacting to people saying that one should not attempt to create a new USB device because it's too complicated and to use an FTDI chip or HID class even if your device has nothing to do with HID. I'm sure there are gotchas, but at least there are interfaces that are supposedly intended for creating your own USB device. If you do everything according to the interface spec, it should be the OS vendor's task to make it run on any hardware supported by that OS. > (There's a related "open source" > dilemma. Sure, you can find and fix bugs yourself. Theoretically. But > the number of people actually capable of doing that is much smaller > than the number of people likely to be affected by that bug...) Yeah, I agree that open source is way overrated. In some ways it's bad because it lets someone writing software be lazy and rely on others fixing bugs for them. For stuff I use to get my job done, I'd rather pay for working software. And no, I don't want to see the code because I've got better things to get on with. I don't care what's inside, I just want it to work and am willing to pay for the software to get that. Open source software is the most expensive kind. ****************************************************************** Embed Inc, Littleton Massachusetts, (978) 742-9014. #1 PIC consultant in 2004 program year. http://www.embedinc.com/products

> Yeah, I agree that open source is way overrated. [...] > Open source software is the most expensive kind. Come on Olin, you should know that blanket statements are seldom true (like Xiaofan had to admit). Most of the www we use to communicate runs on OSS. I won't deny there is crap that's published as open source, but there is closed source crap too, and pearls among both categories. And of course everything inbetween. But if you find an OSS pearl you know you can get the source and in most cases use it freely. Wouter van Ooijen -- ------------------------------------------- Van Ooijen Technische Informatica: http://www.voti.nl consultancy, development, PICmicro products docent Hogeschool van Utrecht: http://www.voti.nl/hvu

Wouter van Ooijen wrote: >> Yeah, I agree that open source is way overrated. [...] >> Open source software is the most expensive kind. > > Come on Olin, you should know that blanket statements are seldom true I didn't mean to imply that open software is always a bad thing, not that the quality is worse or better than closed software. It's just that I hear a lot of knee jerk "it's closed software therefore I don't like it" attitudes, apparently without any consideration of all the trouble it would take to actually do something with the source code. While I'm probably capable of getting into most software and spending effort on adding some feature or fixing some bug, the point is I don't want to. I also think a large majority of people who are always on about open software don't actually ever touch the code. There is also the effect that openess gives the authors an exuse for not implementing something. A somewhat relevant example is when I started using Eagle. A few times I called Cadsoft tech support on how to do something specific, and sometimes was told "Eagle doesn't do that, but you could write a ULP to do that". Yes I probably could, but the point is I didn't want to. I wanted to get my project done without being a CAD system programmer. I was also new to Eagle, and figuring out how ULPs work, finding all the documentation, figuring out the development environment, etc, sounded like a lot of hassle. I have meanwhile dug into that, and like most things it's not so bad once you get into it and set up, and I've written a few (pretty cool, I think) ULPs since then. I like that Eagle has the ULP capability, but it pisses me off how Cadsoft allows that to be an excuse for not implementing some generally useful things themselves. I think most people underestimate the work in setting up a development environment, getting all the files in the right place, the right tools, and getting that first build to work just to get what there is now. Then you still have to dig thru the source code and hope it's documented better than 99% of all the source code out there so that you can figure out how it works. I'm not against open source, I'd just like to see the costs included whenever its benefits are touted. ****************************************************************** Embed Inc, Littleton Massachusetts, (978) 742-9014. #1 PIC consultant in 2004 program year. http://www.embedinc.com/products

I've been following this thread with lots of interest. I just had a look at the datasheets for the 2 chips and it looks like the only way to get the drivers for the CP2102 is to buy the $50 evaluation kit while for the FT232 you can go download them right now from their website. I think that will be enough to give the FT232 a look first. FJ ============================================== Yes, it's that easy! Both the CP2102 and the FT232 come with "virtual comm port" drivers for various operating systems. They also come with directly callable drivers if you don't want the device to look like a serial port. My experience is with the CP2102. It has worked quite well. In one application, I'm running it at 500kbps and driving the internal UART on a PIC. Harold --

however....talking to the mchip FAE he showed me the USB demo board, no worries about drivers and such because the USB port (host side) acts like a serial port, and the chip/demo board is able to swap between USART and USB, both independent. Seems like its a better way to go...might check into that more, or have your local FAE come out and demo the board to you. Bob Axtell <engineerEraseME.....cotse.net> wrote: While using a USB PIC seems like best solution, the easiest solution is to use the FT232B AND a simple serial PIC, such as an F88. That way, you can use their free USB Windows driver that works perfectly. You will get bogged down quickly trying to do this by the specs. My printed copy of the USB 2.0specs is 2 2" notebooks thick. Microchip makes fooling with the USB PICs a tough job. I'm not saying you can't do it, but its a lot like teaching yourself brain surgery and practicing on the closest available brain (yours). --Bob -- Note: To protect our network, attachments must be sent to EraseMEattachengineer.cotse.net . 1-520-777-7606 USA/Canada http://beam.to/azengineer