Searching \ for '[PIC] USB Resources.' 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 Resources.'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] USB Resources.'
2005\12\14@213101 by Todd Bailey

picon face

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


2005\12\14@214725 by Richard Prosser

picon face
On 15/12/05, Todd Bailey <spam_OUTtm_baileyTakeThisOuTspamhotmail.com> wrote:
{Quote hidden}

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

2005\12\14@215112 by Chen Xiao Fan

face
flavicon
face

> -----Original Message-----
> From: Todd
> Sent: Thursday, December 15, 2005 10:31 AM
> To: .....piclistKILLspamspam@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

2005\12\14@215317 by Harold Hallikainen

face picon face
I've done my USB projects with the Silicon Labs CP2102. Future Technology
Devices has similar chips. These are USB to async (like EIA232) that you
can simply drive a PIC USART with. You don't have to mess with USB
protocols at all.

Harold


--
FCC Rules Updated Daily at http://www.hallikainen.com

2005\12\14@220028 by Bob Axtell
face picon face
Todd Bailey wrote:

{Quote hidden}

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
attachspamKILLspamengineer.cotse.net .
1-520-777-7606 USA/Canada
http://beam.to/azengineer

2005\12\14@233104 by dal

flavicon
face
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}

2005\12\14@233829 by Todd Bailey

picon face

 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 <.....engineerKILLspamspam.....cotse.net>
Reply-To: "Microcontroller discussion list - Public." <EraseMEpiclistspam_OUTspamTakeThisOuTmit.edu>
To: "Microcontroller discussion list - Public." <piclistspamspam_OUTmit.edu>
Subject: Re: [PIC] USB Resources.
Date: Wed, 14 Dec 2005 20:00:21 -0700

Todd Bailey wrote:

{Quote hidden}

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@attachKILLspamspamengineer.cotse.net .
1-520-777-7606 USA/Canada
http://beam.to/azengineer

2005\12\14@234840 by Todd Bailey

picon face

 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" <KILLspampiclistsrvKILLspamspamcableone.net>
Reply-To: "Microcontroller discussion list - Public." <RemoveMEpiclistTakeThisOuTspammit.edu>
To: "'Microcontroller discussion list - Public.'" <spamBeGonepiclistspamBeGonespammit.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}

2005\12\15@044141 by Alan B. Pearce

face picon face
>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?

That may be a bit much. I would go for a one chip solution, using an FTDI
FT245 or their slightly bigger chip which can do multiple protocols - FT2245
IIRC.

See http://www.ftdichip.com/ for info on the chips.

2005\12\15@075836 by olin piclist

face picon face
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

2005\12\15@080929 by olin piclist

face picon face
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

2005\12\15@085831 by Wouter van Ooijen

face picon face
> 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


2005\12\15@095533 by Dave Lag

picon face
Olin Lathrop wrote:
> Bob Axtell wrote:
>
>> You will get bogged down quickly trying  to do this by the specs.
.....
{Quote hidden}

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

2005\12\15@100210 by M Graff

flavicon
face
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.  :)

--Michael

2005\12\15@102305 by William Couture

face picon face
On 12/15/05, M Graff <TakeThisOuTexplorer-piclistEraseMEspamspam_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

2005\12\15@103239 by Wouter van Ooijen

face picon face
> 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


2005\12\15@103602 by Harold Hallikainen

face picon face
On Wed, 2005-12-14 at 23:38 -0500, Todd Bailey wrote:
{Quote hidden}

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

2005\12\15@105409 by Mario Mendes Jr.

flavicon
face
Now if they would only come up with a uC with built-in FireWire
hardware....  =)

-Mario

2005\12\15@114802 by William Chops Westfield

face picon face
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

2005\12\15@121225 by olin piclist

face picon face
> 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

2005\12\15@133211 by Wouter van Ooijen

face picon face
> 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


2005\12\15@151133 by olin piclist

face picon face
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

2005\12\15@175746 by Jan Wagemakers

flavicon
face
Olin Lathrop <RemoveMEolin_piclistspamTakeThisOuTembedinc.com> schreef:

> 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.

I think this discussion is little-bit OT ;-)


--
Met vriendelijke groetjes         - Jan Wagemakers -

... When we speak of free software, we are referring to freedom, not price.
         -- GNU GENERAL PUBLIC LICENSE Version 2, June 1991

2005\12\15@180824 by fred jones

picon face
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

--


2005\12\16@000331 by William Chops Westfield

face picon face

On Dec 15, 2005, at 9:13 AM, Olin Lathrop wrote:

> 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.

Alas, all too often closed source software has as many bugs and
as poor support as open source software, even though you're supposedly
paying for better.  An if that's so; you're at the end of your options.
At least with open source software, the possibility of fixing it
yourself
always exists, even if it will be "expensive"...

BillW

2005\12\19@121036 by alan smith

picon face
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 <engineerEraseMEspam.....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
EraseMEattachspamengineer.cotse.net .
1-520-777-7606 USA/Canada
http://beam.to/azengineer

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