Searching \ for '[PIC] USB Example code?' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'USB Example code?'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] USB Example code?'
2005\12\06@162149 by Josh Koffman

face picon face
Hi all. If you've been watching my other posts, you'll know that I'm
embarking on a new USB project. I've been reading a bunch of websites
about USB, and I'm working my way through USB Complete by Jan Axelson.
As I go along, I'm becoming a bit more worried about writing this all
from scratch.

I'm now looking for some example code that I can look at to help me
along as I write my own. The problem is this. I program in assembly.
There is a bunch of USB code in assembly for the 16C chips, but I'm
having trouble locating something for the 18F4550 (or it's relatives).
Ideally something implementing the HID class driver, and even more
ideally something implementing a USB keyboard.

At this point something showing how to initialize the interface and
set up descriptors would be helpful.

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

2005\12\06@162752 by Robert Rolf

picon face
For which end of the link? Host or Client? Makes a HUGE difference
on the amount of effort needed.
Robert

Josh Koffman wrote:
{Quote hidden}

2005\12\06@163934 by Josh Koffman

face picon face
On 12/6/05, Robert Rolf <spam_OUTRobert.RolfTakeThisOuTspamualberta.ca> wrote:
> For which end of the link? Host or Client? Makes a HUGE difference
> on the amount of effort needed.

I suppose that is true...while I've never coded in assembly for i86 I
imagine it's not easy.

Luckily I'm looking for just the PIC side. One of the reasons I chose
this as my first USB project is that I just want it to appear to the
computer as a normal keyboard, no special drivers required.

Josh
--
A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools.
       -Douglas Adams

2005\12\06@173127 by Jan-Erik Soderholm

face picon face
Josh Koffman wrote :

> USB Complete by Jan Axelson.

Edition 2 or 3 ?
I have edition 2, and it is great but I think ed 3
added some new "things".

> I'm now looking for some example code that I can look
> at to help me along as I write my own...

I just downloaded the HID/Mouse example from Microchip.
Written in C so had to complement with Student edition
of C18. The USB example built cleanly first round.

I havn't done anything more with it, and I can't say
that the "framework" was *that* easy to grasp... :-)

>  The problem is this. I program in assembly.

Yep, that would be nice.
*But*, the C exmaples are not that hard to port to ASM, the
C is mainly a framework to hold a lot of register handling
code. That logic should be possibly to transfer to an ASM
environment.
If one "speaks" C, the definitions of the descriptions
might also be clearer then they was for me.

> There is a bunch of USB code in assembly for the 16C chips,..

Which is probably quite different from the new 2.0 chips.

So yes, ASM examples for the "new" chips would be nice... :-)

Jan-Erik.

PS:
I was using Olins EasyProg and QuickProto01 with a 18F2550.
>



2005\12\06@175511 by Xiaofan Chen

face picon face
On 12/7/05, Jan-Erik Soderholm <.....jan-erik.soderholmKILLspamspam@spam@telia.com> wrote:
>
> So yes, ASM examples for the "new" chips would be nice... :-)
>
> Jan-Erik.

Yes there are ASM based examples for PIC USB as well as simpler
C based examples from Dr Bradley A. Minch of Olin College.

http://pe.ece.olin.edu/ece/projects.html

The following thread is one of the most popular in Microchip Forum
USB section.
http://forum.microchip.com/tm.asp?m=89669

The Microchip Forum USB section is one of the best place to
discuss PIC USB chips.

I've collected some related websites here:
http://forum.microchip.com/tm.asp?m=123533

Regards,
Xiaofan

2005\12\06@183330 by Josh Koffman

face picon face
On 12/6/05, Xiaofan Chen <xiaofancspamKILLspamgmail.com> wrote:
> Yes there are ASM based examples for PIC USB as well as simpler
> C based examples from Dr Bradley A. Minch of Olin College.
>
> http://pe.ece.olin.edu/ece/projects.html
>
> The following thread is one of the most popular in Microchip Forum
> USB section.
> http://forum.microchip.com/tm.asp?m=89669
>
> The Microchip Forum USB section is one of the best place to
> discuss PIC USB chips.
>
> I've collected some related websites here:
> http://forum.microchip.com/tm.asp?m=123533

Wow, great links Xiaofan! For others who may want to check them out,
read the second link (to the Microchip forum) first. In it Dr Minch
describes what's on his site - which is good as his site isn't that
descriptive.

Lab 2 looks to be exactly what I need.

Thanks again!

Josh
--
A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools.
       -Douglas Adams

2005\12\18@005435 by Josh Koffman

face picon face
Alright, I've been working my way through the USB example code (thanks
Xiaofan!) located here:
http://pe.ece.olin.edu/ece/projects.html specifically lab2 at
http://pe.ece.olin.edu/ece/projects/lab2_18F2455.zip

I haven't had the chance to breadboard and play with it yet, but the
more I read it, the more confused I get. Part of the problem is that
he's defined a bunch of macros that do things I don't understand at
all. Regardless, most of that happens in the USB code that I'm not
trying to decipher at the moment.

My current confusion revolves around the interrupt routine. It seems
he doesn't have any! It seems that he's setup TMR0 and is polling for
the interrupt flag, near as I can tell anyway. I think that the best
way to deal with will be with actual interrupts in my final
application.

So what I'm looking for...has anyone else been reading the code? Is my
above interpretation true? Should I decide to use interrupts to handle
the USB stuff, I'm a little unsure of the best way to handle it all.
It seems there are two parts to this, the general USB housekeeping,
and then stuffing bytes into the buffer to be sent as keystrokes. the
keystrokes I should just be able to decide on my own. If I call that
more often, I get a quicker response time on the keys. The USB
housekeeping (ServiceUSB in his code) is a bit more confusing...I have
no idea how often I need to call it to keep the host happy.

Anyone have any thoughts or comments? I'd even just love to hear if
anyone else out there is playing with this code.

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

2005\12\18@114017 by Josh Koffman

face picon face
After thinking about this all night as I tossed and turned (something
I do frequently when thinking of a problem), I think I've figured it
out. Essentially the mainline code will handle all the USB
transactions in an infinite loop. That will ensure the quickest
possible handling of host requests. In the ISR I will read my keypad,
figure out what I need to send, and stuff it in the buffer. It should
take very little time (comparatively) so I should end up ok.

I'm still confused by much of the professor's custom macros, but at
least I feel like I have more of a chance of using the code
successfully now.

Thoughts? Original post follows for reference. Yes, I top posted, but
this is really a mostly free standing post.

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 12/18/05, Josh Koffman <.....joshybearKILLspamspam.....gmail.com> wrote:
{Quote hidden}

2005\12\18@155115 by Terry Chen

picon face
Hey Josh,

  I have recently started struggling with the PIC18F USB chips also. From
what I understand of the code, I think you are correct in that he is polling
it using an infinite loop with delays in it. I think that if you want to
make it interrupt-based then maybe divide the ServiceUSB subroutine into
many smaller pieces and call it from the ISR after you poll for the
appropriate response. (Note: I am not entirely sure of this approach, but
it's an idea)
  By the way, when you said the custom macros, do you mean the
select/case/ends macros / if macros. They bugged me too, until I skimmed
over ENGR2210.inc. It is pretty well documented in it. Also, I suggest you
read the Microchip C USB firmware for the USB Starter kit, it is pretty well
documented and explains a lot detailed firmware workarounds for certain USB
issues.
  As an aside, I am thinking about working some more on this assembly PIC
usb firmware after finals. Maybe I will get back to you then once I know
more specific details...

-Terry (Seitai) Chen

2005\12\18@180357 by Josh Koffman

face picon face
On 12/18/05, Terry Chen <EraseMEseitai.chenspam_OUTspamTakeThisOuTgmail.com> wrote:
>    I have recently started struggling with the PIC18F USB chips also. From
> what I understand of the code, I think you are correct in that he is polling
> it using an infinite loop with delays in it. I think that if you want to
> make it interrupt-based then maybe divide the ServiceUSB subroutine into
> many smaller pieces and call it from the ISR after you poll for the
> appropriate response. (Note: I am not entirely sure of this approach, but
> it's an idea)

I'm thinking about leaving his ServiceUSB routine alone for now and
running it in the main loop. Rather than poll for the TMR flag, I'll
actually let it interrupt to service my keyboard routine.

>    By the way, when you said the custom macros, do you mean the
> select/case/ends macros / if macros. They bugged me too, until I skimmed
> over ENGR2210.inc. It is pretty well documented in it. Also, I suggest you
> read the Microchip C USB firmware for the USB Starter kit, it is pretty well
> documented and explains a lot detailed firmware workarounds for certain USB
> issues.

I have looked at his include file, and the descriptions are good, he's
just pulling stuff like:
                       goto                _repeat#v(_rptstack#v(_rptstackptr))
which I don't really get. Also they're annoying when debugging as
invariably the infinite loop I'm getting caught in is in one of the
macros. I haven't figured out yet what to set a watch on so I can
figure out where the macro was called from. Any tips on that would be
useful. I will try and take a look at the Microchip firmware - even if
I don't understand C, perhaps I can learn from the comments.

I'm also seriously considering expanding all of his macros in the main
code. It will make debugging easier, and having to go through the code
in that detail should force me to learn more about it.

After an afternoon of trying to figure out why the heck my
breadboarded circuit wasn't working, I discovered something about his
code. For whatever reason, it doesn't seem to work with Win2K at all.
It does work with WindowsXP though, which I found out after trying
another computer in desperation. Something to note though if you're
planning on playing with it.

Well, back to study it some more!

Josh
--
A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools.
       -Douglas Adams

2005\12\18@205336 by Terry Chen

picon face
Hey Josh,

I have looked at his include file, and the descriptions are good, he's
> just pulling stuff like:
>
>                         goto            _repeat#v(_rptstack#v(_rptstackptr))


Well I know the #v means concatenation to the MPASM preprocess (actually...
I am not so sure anymore...). So I think all that does is jump to a label
you generated before. The _rptstack and _rptstackptr  I am not so sure
about. But I can guess that one number is to differentiate it from other
loops. And the other maybe implement a sort of fake label stack (if that
makes any sense at all) so that you can nest these macro loops? This is
actually a very interesting way to implement this, however it makes
debugging very difficult indeed.


which I don't really get. Also they're annoying when debugging as
> invariably the infinite loop I'm getting caught in is in one of the
> macros. I haven't figured out yet what to set a watch on so I can
> figure out where the macro was called from.


I am not sure I understand what do you mean by where the macro is calling
from. Isn't it in the main loop the repeat-until macro. If you want, you may
want to insert a random nop into the loop and set a breakpoint on it using
ICD 2. However, this basically renders the USB connection useless b/c it
would time out.


I'm also seriously considering expanding all of his macros in the main
> code. It will make debugging easier, and having to go through the code
> in that detail should force me to learn more about it.


Why not just look at the list files? It is probably going to be the same,
and will save you a ton of work. Although doing it your way may save you a
lot of headache trying to understand all those weird labels.


After an afternoon of trying to figure out why the heck my
> breadboarded circuit wasn't working, I discovered something about his
> code. For whatever reason, it doesn't seem to work with Win2K at all.
> It does work with WindowsXP though, which I found out after trying
> another computer in desperation. Something to note though if you're
> planning on playing with it.


Really? Before I stopped playing with it, I managed to get his lab1 and lab2
working for both XP and 2000. But I am not using the same usb chip though (I
am using the 18F2550) and I did screw around with the oscillator settings
and what not.

Well, back to study it some more!


Well best of luck... hmm this is so interesting now, I probably will start
working on it after finals which would be around wednesday. Maybe someone
with more experience with the PIC USB chips will be willing to help you out.

- Terry

2005\12\19@073645 by Alan B. Pearce
face picon face
>I have looked at his include file, and the descriptions
>are good, he's just pulling stuff like:
>goto _repeat#v(_rptstack#v(_rptstackptr)) which I don't
>really get.

The #v gets replaced when the macro is expanded by the assembler, which
makes the labels unique within the module when more than one instance of the
macro occurs. Check the MASM help files and manual for more information.

>Also they're annoying when debugging as invariably the
>infinite loop I'm getting caught in is in one of the
>macros. I haven't figured out yet what to set a watch
>on so I can figure out where the macro was called from.
>Any tips on that would be useful. I will try and take a
>look at the Microchip firmware - even if I don't
>understand C, perhaps I can learn from the comments.

Setting anything inside a macro is a pain with MPLAB as the listing window
does not step the pointer through the macro code even though the opcode
window steps.

You may also like to look at the print listing output to see just what code
and labels have been generated from the macros. You will not want to do this
often, as it can be a wild ride to work your way through much verbiage from
the assembler output, but it can be instructive when you are learning just
what the assembler does with the macro.

2005\12\19@135114 by Josh Koffman

face picon face
On 12/18/05, Terry Chen <seitai.chenspamspam_OUTgmail.com> wrote:
> I am not sure I understand what do you mean by where the macro is calling
> from. Isn't it in the main loop the repeat-until macro. If you want, you may
> want to insert a random nop into the loop and set a breakpoint on it using
> ICD 2. However, this basically renders the USB connection useless b/c it
> would time out.

What I meant is that at some point the code is getting caught waiting
for something. I haven't figured out yet what that is. When I'm using
the ICD and stop execution to see where the code is stuck, MPLAB shows
me the code running is a macro in the include file. What it doesn't
tell me is what part of the main code called that macro. So, I know
I'm stuck, but I don't know how far along the USB enumeration it's
gotten.

> Why not just look at the list files? It is probably going to be the same,
> and will save you a ton of work. Although doing it your way may save you a
> lot of headache trying to understand all those weird labels.

I will take a look at the list files when I have the chance. It will
likely get me started at least. Then if I decide to manually expand
everything I'll at least have a better basis for what should be
happening.

> Really? Before I stopped playing with it, I managed to get his lab1 and lab2
> working for both XP and 2000. But I am not using the same usb chip though (I
> am using the 18F2550) and I did screw around with the oscillator settings
> and what not.

Interesting...I will have to try it on another Win2K machine. Did your
2K machine have USB2.0 or 1.1 ports? Maybe it's something in 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

More... (looser matching)
- Last day of these posts
- In 2005 , 2006 only
- Today
- New search...