Quantcast

[PIC] USB Resources.

classic Classic list List threaded Threaded
31 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[PIC] USB Resources.

Todd Bailey

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


--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PIC] USB Resources.

Richard Prosser
On 15/12/05, Todd Bailey <[hidden email]> wrote:

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

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: [PIC] USB Resources.

Chen Xiao Fan
In reply to this post by Todd Bailey

> -----Original Message-----
> From: Todd
> Sent: Thursday, December 15, 2005 10:31 AM
> To: [hidden email]
> 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
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PIC] USB Resources.

Harold Hallikainen
In reply to this post by Todd Bailey
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
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PIC] USB Resources.

Bob Axtell
In reply to this post by Todd Bailey
Todd Bailey wrote:

> 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
[hidden email] .
1-520-777-7606 USA/Canada
http://beam.to/azengineer

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: [PIC] USB Resources.

dal-2
In reply to this post by Todd Bailey
 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.  

http://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-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of
Todd Bailey
Sent: Wednesday, December 14, 2005 7:31 PM
To: [hidden email]
Subject: [PIC] USB Resources.


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?





--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.371 / Virus Database: 267.13.13/199 - Release Date: 12/13/2005

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PIC] USB Resources.

Todd Bailey
In reply to this post by Bob Axtell

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

Todd Bailey wrote:

>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
[hidden email] .
1-520-777-7606 USA/Canada
http://beam.to/azengineer

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist


--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: [PIC] USB Resources.

Todd Bailey
In reply to this post by dal-2

  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" <[hidden email]>
Reply-To: "Microcontroller discussion list - Public." <[hidden email]>
To: "'Microcontroller discussion list - Public.'" <[hidden email]>
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.

http://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-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of
Todd Bailey
Sent: Wednesday, December 14, 2005 7:31 PM
To: [hidden email]
Subject: [PIC] USB Resources.


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?





--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.371 / Virus Database: 267.13.13/199 - Release Date: 12/13/2005

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist


--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PIC] USB Resources.

Alan B. Pearce
In reply to this post by Todd Bailey
>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.

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PIC] USB Resources.

Olin Lathrop
In reply to this post by Todd Bailey
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
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PIC] USB Resources.

Olin Lathrop
In reply to this post by Bob Axtell
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
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: [PIC] USB Resources.

Wouter van Ooijen
> 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: www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: www.voti.nl/hvu
 

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PIC] USB Resources.

Harold Hallikainen
In reply to this post by Todd Bailey
On Wed, 2005-12-14 at 23:38 -0500, Todd Bailey wrote:

>   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

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PIC] USB Resources.

Dave Lag
In reply to this post by Olin Lathrop
Olin Lathrop wrote:
> Bob Axtell wrote:
>
>> You will get bogged down quickly trying  to do this by the specs.
.....

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

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PIC] USB Resources.

M Graff
In reply to this post by Wouter van Ooijen
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
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PIC] USB Resources.

William Couture
On 12/15/05, M Graff <[hidden email]> 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

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: [PIC] USB Resources.

Wouter van Ooijen
In reply to this post by M Graff
> 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: www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: www.voti.nl/hvu
 

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PIC] USB Resources.(/PICkit2)

Timothy Gale
In reply to this post by Olin Lathrop
Olin Lathrop wrote:

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

Hi Olin,

I'm not sure whether this will be exactly what you want, but over the
past little while I've been playing with the 2550 and written a C
library for SDCC.  It's available for download here:
http://www.geocities.com/tegale2001/downloads/pickit2.tar.gz

usb.c and comms.c are the places where the main USB work is done.
Unfortunately, no support for interrupt pipes as yet, but bulk ones
appear to go pretty well (using linux here for the client).  As
suggested by the filename, it's intended for the PICkit 2 - the goal is
to get STDP for dspics working, but unfortunately at the moment it
doesn't seem to be working, whether due to not entering the mode or not
recognising commands I'm not sure.  If anyone figures out what's wrong,
I'd be very grateful!

Hope this is of some use
Tim

PS SDCC version used was from about June - not sure whether the current
one will still work

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PIC] USB Resources.

Mario Mendes Jr.
In reply to this post by Harold Hallikainen
Now if they would only come up with a uC with built-in FireWire
hardware....  =)

-Mario
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PIC] USB Resources.

William "Chops" Westfield
In reply to this post by Olin Lathrop
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

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
12
Loading...