Post by thread:[PIC] USB HID peripheral?

Hi all. I'm considering making a small USB peripheral similar to the Griffin Powermate (http://www.griffintechnology.com/products/powermate/) in function, but in a different form. Now that there are USB flash PICs available, it seems like something I could do. However, I'm a little unsure about the coding portion. The Microchip demo seems to be in C, as is Jan Axelson's USB framework (or, at least the one I found on a website attributed to her is in C). I don't know C, nor do I know how hard it would be to code up an HID class device. Any thoughts or pointers on the matter? Essentially all my unit will do is enumerate as an HID mouse, then send scroll wheel signals to the PC. I don't have USB Complete, though I might be able to borrow a copy somewhere. I guess the real question is: how hard is it to develop for USB in assembly? And, is there any sample code for that? Thanks, Josh -- A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. -Douglas Adams

> Hi all. I'm considering making a small USB peripheral similar to the > Griffin Powermate > (http://www.griffintechnology.com/products/powermate/) in function, > but in a different form. Now that there are USB flash PICs available, > it seems like something I could do. However, I'm a little unsure about > the coding portion. The Microchip demo seems to be in C, as is Jan > Axelson's USB framework (or, at least the one I found on a website > attributed to her is in C). In the second edition of the *printed* book, all examples are in both C and Visual Basic (the Windows side of it). > I don't know C, nor do I know how hard it > would be to code up an HID class device. Are you talking about a device *driver* ? If so, you probably don't have to. Just use some of the builtin classes in Windows. > Any thoughts or pointers on > the matter? Essentially all my unit will do is enumerate as an HID > mouse, then send scroll wheel signals to the PC. And you application will use your device just as if it was a mouse out there ? For generic input, either a HID device or a serial-emulation might be easier. A serial emulation is available from the Microchip site. All drivers for Windows are built-in in Windows by default. > I guess the real question is: how hard is it to develop for > USB in assembly? And, is there any sample code for that? Exactly my question here about a month ago. No reply yet... :-) But, of course, if a C compiler can make out the needed assembly, *anyone* could, right ? :-) :-) Jan-Erik.

Well, my thought was that if I make my device enumerate as a mouse, then I don't have to mess with the PC side. So, I'm trying to figure out how to get the USB PIC to tell the PC that it's a mouse, then how I am supposed to format those "I'm scrolling up now" type messages. I don't think I need to do serial emulation...unless that's how all the mice work. Low down, do they just emulate PS/2 or serial over USB? Seems kind of a backwards way to do it. You are right, my application would just use the data as if it were coming from a mouse. Yes, I know I could probably just hack up a cheap mouse, but this seems more configurable (I could add extra buttons in the future), plus I will have more freedom with what I use to actually trigger the "I'm scrolling" messages. Josh -- A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. -Douglas Adams On 4/13/05, Jan-Erik Soderholm <spam_OUTjan-erik.soderholmTakeThisOuTtelia.com> wrote: {Quote hidden}> > Hi all. I'm considering making a small USB peripheral similar to the > > Griffin Powermate > > (http://www.griffintechnology.com/products/powermate/) in function, > > but in a different form. Now that there are USB flash PICs available, > > it seems like something I could do. However, I'm a little unsure about > > the coding portion. The Microchip demo seems to be in C, as is Jan > > Axelson's USB framework (or, at least the one I found on a website > > attributed to her is in C). > > In the second edition of the *printed* book, all examples are > in both C and Visual Basic (the Windows side of it). > > > I don't know C, nor do I know how hard it > > would be to code up an HID class device. > > Are you talking about a device *driver* ? > If so, you probably don't have to. Just use some of the > builtin classes in Windows. > > > Any thoughts or pointers on > > the matter? Essentially all my unit will do is enumerate as an HID > > mouse, then send scroll wheel signals to the PC. > > And you application will use your device just as if it was a mouse > out there ? For generic input, either a HID device or a serial-emulation > might be easier. A serial emulation is available from the Microchip site. > All drivers for Windows are built-in in Windows by default. > > > I guess the real question is: how hard is it to develop for > > USB in assembly? And, is there any sample code for that? > > Exactly my question here about a month ago. No reply yet... :-) > > But, of course, if a C compiler can make out the needed assembly, > *anyone* could, right ? :-) :-)

Josh Koffman wrote : > You are right, my application would just use the data as if it were > coming from a mouse. I don't think that your application will ever see the data coming from the mouse. Windows will catch all mouse data and act on it as needed. The application currently in "focus" will then get some Windows message from the kernel to "do" something just as if you had done something with a real mouse. Is that what you want ? It's not clear if your application expects to get the "raw" mouse data and act on it as it likes, or if this new device will replace the standard mouse ? Jan-Erik.

Josh writes: > The Microchip demo seems to be in C, as is Jan > Axelson's USB framework (or, at least the one I found on a website > attributed to her is in C). I don't know C, nor do I know how hard it > would be to code up an HID class device. Hi Josh, C is actually really easy, and since the syntax has bled into so many other languages, it makes sense to add C to your repertoire at some point. If you can tolerate the idea, "C for Dummies" is pretty good although it just goes over a few of the basics, enough to get you started. "C++ for Dummies", on the other hand, is terrible. Then of course you'll need a real reference book. Cheerful regards, Bob

Hm...how to better explain. There are a number of applications that use the scroll wheel on a mouse for various things. For instance, in Eagle, the scroll wheel adjusts the zoom level of the current view. What I want to build is a device that lets me adjust that using a knob for instance. The application and computer will think it's just another mouse sending the data. I guess what I'm making is a mouse that has no position sensors, just a scroll. The computer end is handled by Windows and the application. I don't have to change a thing there. I just need to make the device that looks like a mouse to the computer. It won't replace the mouse, just act in concert with it. Is that a bit clearer? Josh -- A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. -Douglas Adams On 4/13/05, Jan-Erik Soderholm <.....jan-erik.soderholmKILLspam@spam@telia.com> wrote: {Quote hidden}> I don't think that your application will ever see the data coming > from the mouse. Windows will catch all mouse data and > act on it as needed. The application currently in "focus" will > then get some Windows message from the kernel to "do" > something just as if you had done something with a real mouse. > > Is that what you want ? > It's not clear if your application expects to get the "raw" > mouse data and act on it as it likes, or if this new device > will replace the standard mouse ?

The original PICDemUSB boards, the ones for the 16C74X series, come completely setup to emulate mouse and keyboard HID's with all the firmware written in MPASM. Microchip also provided a good set of application notes with firmware for many HID applications including PS/2 mouse and keyboard to USB translators. It has been over a year since I played around with it but I believe the Microchip code was fairly easy to understand and modify. I would hope Microchip updated the app notes and code for the new USB Pics. You should be able to get all the app notes and assembly source code on their web site. Paul >{Original Message removed}

Interesting. I wonder how I find out what commands to issue so the computer knows I want to scroll. Josh -- A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. -Douglas Adams On 4/13/05, Padu <padupicKILLspammerlotti.com> wrote: > I don't know if that will help, but my Microsoft Office Keyboard has a wheel > on the left side that can be used in lieu of the mouse wheel. In eagle, I > can use either the mouse wheel of the keyboard wheel to zoom in and out.

Josh Koffman <.....piclistKILLspam.....mit.edu> wrote: > > I don't know if that will help, but my Microsoft Office Keyboard > > has a wheel on the left side that can be used in lieu of the mouse > > wheel. In eagle, I can use either the mouse wheel of the keyboard > > wheel to zoom in and out. > > Interesting. I wonder how I find out what commands to issue so the > computer knows I want to scroll. Josh: The keyboard probably enumerates as a "composite device", which presents to the host PC two interfaces that share a single USB address. That is, it enumerates as both a mouse and a keyboard; the two share a control endpoint and each has its own interrupt endpoint. The "commands to issue" are exactly the ones that a mouse would send. -Andrew === Andrew Warren - EraseMEfastfwdspam_OUTTakeThisOuTix.netcom.com

And are the commands that are sent spelled out in a document somewhere? I guess I'm pretty lost here...I should probably just find a copy of Jan's book to peruse for a bit. I may not be able to use code, but it should give me a better overview on how things work, right? Josh -- A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. -Douglas Adams On 4/13/05, Andrew Warren <fastfwdspam_OUTix.netcom.com> wrote: > The keyboard probably enumerates as a "composite device", which > presents to the host PC two interfaces that share a single USB > address. That is, it enumerates as both a mouse and a keyboard; the > two share a control endpoint and each has its own interrupt endpoint. > The "commands to issue" are exactly the ones that a mouse would send.

Josh Koffman <@spam@piclistKILLspammit.edu> wrote: > > The "commands to issue" are exactly the ones that a mouse > > would send. > > And are the commands that are sent spelled out in a document > somewhere? Well, yes... Of course. You could work your way through the USB spec and the HID spec (available from usb.org), then maybe read the USB documentation available from Microsoft... Or you could just cut to the chase and look at sample code available from Microchip or Cypress; they both have reference-design code and appnotes for USB mice and keyboards. Google might be helpful, too, although it may be difficult to construct a search that ignores reviews of and advertisements for USB mice. > I guess I'm pretty lost here...I should probably just find a copy of > Jan's book to peruse for a bit. I may not be able to use code, but it > should give me a better overview on how things work, right? Right. Her website (http://www.lvr.com) has plenty of information, too. -Andy === Andrew Warren - KILLspamfastfwdKILLspamix.netcom.com

On 4/14/05, Andrew Warren <RemoveMEfastfwdTakeThisOuTix.netcom.com> wrote: > Josh Koffman <spamBeGonepiclistspamBeGonemit.edu> wrote: > > I guess I'm pretty lost here...I should probably just find a copy of > > Jan's book to peruse for a bit. I may not be able to use code, but it > > should give me a better overview on how things work, right? > > Right. Her website (http://www.lvr.com) has plenty of information, > too. Anyone have any comments about first vs second edition of USB complete? I have found the first edition at my former school's library. Luckily I am still friends with many of the professors, so they would likely be able to check it out for me (I paid tens of thousands of dollars in tuition, now they want to charge me to let me take books out). Josh -- A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. -Douglas Adams

Josh Koffman wrote : > Anyone have any comments about first vs second edition of USB > complete? I have found the first edition at my former school's > library. Luckily I am still friends with many of the professors, so > they would likely be able to check it out for me (I paid tens of > thousands of dollars in tuition, now they want to charge me to let me > take books out). Some highlights from the chapter "What's new in the Second Edition" : - USB 2.0. - VC++ and VB code, 1'st edition had only VB code. - Windows 2000 added. - New USB chips and dev tools. I'd recomend the 2'nd edition. Remember that even the 2'nd edition was released in 2001. Jan-Erik.

Point taken. I will try to find a copy of the second edition for less than USD$50. Actually, I think what I'll do is check out the 1st edition to see if I'm even capable of doing this. USB1.1 is all I need for my current idea, and the book should give me some insight into how this all works. _Then_ I'll buy the second book. By then I'll have made millions in the stock market, so I'll hire Olin to design it for me. Should take him roughly 10 minutes. :) Josh -- A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. -Douglas Adams On 4/14/05, Jan-Erik Soderholm <TakeThisOuTjan-erik.soderholmEraseMEspam_OUTtelia.com> wrote: > Some highlights from the chapter "What's new in the Second Edition" : > > - USB 2.0. > - VC++ and VB code, 1'st edition had only VB code. > - Windows 2000 added. > - New USB chips and dev tools. > > I'd recomend the 2'nd edition. Remember that even the 2'nd > edition was released in 2001.

Josh Koffman wrote: >Point taken. I will try to find a copy of the second edition for less >than USD$50. Actually, I think what I'll do is check out the 1st >edition to see if I'm even capable of doing this. USB1.1 is all I need >for my current idea, and the book should give me some insight into how >this all works. _Then_ I'll buy the second book. By then I'll have >made millions in the stock market, so I'll hire Olin to design it for >me. Should take him roughly 10 minutes. > >:) > >Josh > > $33 on Amazon.com Super Saver shipping is even free! Aaron www.amazon.com/exec/obidos/tg/detail/-/0965081958/qid=1113529169/sr=8-1/ref=pd_csp_1/103-5002496-4979853?v=glance&s=books&n=507846

Heh, the discounts are starting to hit...because...there's a third edition coming out in August! Josh -- A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. -Douglas Adams On 4/14/05, Aaron <RemoveMEaaron.piclistTakeThisOuTgmail.com> wrote: > $33 on Amazon.com > Super Saver shipping is even free! > > Aaron > > http://www.amazon.com/exec/obidos/tg/detail/-/0965081958/qid=1113529169/sr=8-1/ref=pd_csp_1/103-5002496-4979853?v=glance&s=books&n=507846