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

Exact match. Not showing close matches.
PICList Thread
'[PIC] Microchip USB library'
2012\01\18@144503 by David

flavicon
face
A quick survey for anybody who has used USB on 18F parts.  Is the Microchip USB library the only real solution?

From previous experience with Microchip libraries I prefer to simply start from scratch.  However I assume that the USB module is more complex than the MSSP, ADC and the other 'basic' peripherals.

I'm off to read the datasheets & other documents now, but would appreciate a steer on the libraries.

Davi

2012\01\18@145827 by Wouter van Ooijen

face picon face
On 18/1/2012 8:45 PM, David wrote:
> A quick survey for anybody who has used USB on 18F parts.  Is the
> Microchip USB library the only real solution?

If you allow a+bi solutions: Olin has an USB lib in - of course - assembler, the Jallib has an USB part in - of course - Jal.

--
Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu
C++ on uC blog: http://www.voti.nl/erblog

2012\01\18@165128 by Christopher Head

picon face
I did USB from scratch on the 18F4550 and later ported to 18F67J50. I
have nothing worth sharing, but like anything else: read the specs for
the peripheral and the USB specifications (available for free from
usb.org) and you can do it.

A hardware USB protocol analyzer may be useful here. A protocol analyzer
is more useful for USB than other protocols since (1) USB is fairly
complex, (2) unlike something like asynchronous serial you can't just
use a normal transceiver to hack up a sniffer, and (3) sniffing in the
host computer is less useful because a lot of the low-level details you
need to worry about (like data PIDs and handshake packets) are taken
care of by the host controller and thus not visible in e.g. Wireshark.

I got the Beagle 12 from TotalPhase because it wasn't too expensive,
and I'm happy with it (particularly the official software being
available for Linux), though others are probably good too. I definitely
wish I'd bought it earlier than I did!

Chris

On Wed, 18 Jan 2012 19:45:00 +0000
David <spam_OUTlistsTakeThisOuTspamedeca.net> wrote:

> A quick survey for anybody who has used USB on 18F parts.  Is the
> Microchip USB library the only real solution?
>
>  From previous experience with Microchip libraries I prefer to simply
> start from scratch.  However I assume that the USB module is more
> complex than the MSSP, ADC and the other 'basic' peripherals.
>
> I'm off to read the datasheets & other documents now, but would
> appreciate a steer on the libraries.
>
> David

2012\01\18@192639 by Oli Glaser

flavicon
face
On 18/01/2012 19:45, David wrote:
> A quick survey for anybody who has used USB on 18F parts.  Is the
> Microchip USB library the only real solution?
>
>   From previous experience with Microchip libraries I prefer to simply
> start from scratch.  However I assume that the USB module is more
> complex than the MSSP, ADC and the other 'basic' peripherals.
>
> I'm off to read the datasheets&  other documents now, but would
> appreciate a steer on the libraries.
>
> David

The MCHP USB library is not too bad as their libraries go, but given it's size it does take some time to get up to speed with.
I initially used the MCHPUSB driver, but then switched to the generic LibUSB example (with LibUsbDotNet) as an initial template. After that you can tweak things as necessary.
Compared to e.g. the STF4 ARM USB stack, I found it much easier to find my way around (ST's stack is far too abstracted IMHO, and the documentation is produced from the code comments with doxygen so it's almost useless)
At least the Microchip library is pretty lean and has good documentation and examples - I would at least give it the once over before you decide to try something else.

2012\01\18@193517 by Oli Glaser

flavicon
face
On 18/01/2012 21:51, Christopher Head wrote:
> A hardware USB protocol analyzer may be useful here. A protocol analyzer
> is more useful for USB than other protocols since (1) USB is fairly
> complex, (2) unlike something like asynchronous serial you can't just
> use a normal transceiver to hack up a sniffer, and (3) sniffing in the
> host computer is less useful because a lot of the low-level details you
> need to worry about (like data PIDs and handshake packets) are taken
> care of by the host controller and thus not visible in e.g. Wireshark.

Agreed on the hardware analyser front.
Just thought it worth mentioning that there are a couple of reasonably useful software tools available. I found USBlyzer to be quite good, here is a run down of features:

Completely customizable interface with docked windows and user-defined screen sets.
Display all plugged USB devices in a hierarchical auto-refreshed tree-view.
View and explore the USB Devices and their components.
View detailed USB-related information about each USB device: Device Descriptor, Configuration, Interfaces, Endpoints, etc.
View detailed PnP-related information about each USB device: Hardware IDs, Instance ID, Software Key, PDO Name, etc.
Real-Time monitoring at any level in the USB driver stack from USB Host Controller to target USB Device.
Display detailed information about IRP, IO_STACK_LOCATION and URB structures associated with each captured request.
Display the buffer contents, if any, associated with the request in hex format.
Capture several USB devices simultaneously.
Separate log records for request issue and completion.
Capture almost all types of USB Request Block (URB).
Capture all USB-related kernel-mode device I/O control requests.
Capture all user-mode device I/O control requests to USB Host Controller and USB Hub.
Capture state transition PnP IRPs.
Automatically capture hot plugged devices. Can be used to monitor device enumeration process.
Saving captured data in binary file for later analysis.
Configurable filtering to exclude non-essential information from the view.
Search feature to search the capture file for the particular request types.
Export all captured data or any part of it to plain text, CSV or HTML formats.

2012\01\19@003157 by Xiaofan Chen

face picon face
On Thu, Jan 19, 2012 at 3:45 AM, David <.....listsKILLspamspam@spam@edeca.net> wrote:
> A quick survey for anybody who has used USB on 18F parts.  Is the
> Microchip USB library the only real solution?

It is not the only solution. But depending on your goal, it might
be the best bet.

As mentioned by Wouter, there are alternative USB Stack
written in Assembly or JAL. But Microchip's USB Stack
is probably the most complete and with more detailed
documentation than the others.

And Microchip's USB forum is very active and there are
experts (eg: Tsuneo Chinzei who is active in many USB
related forums) who are willing to help you, again, the help
will be mainly on Microchip's USB Stack.
http://www.microchip.com/forums/f102.aspx

Occasionally there will be discussions about Brad Minch's
simplified stack as well.

Some links I and other Microchip forum members collected
are probably useful as well.
http://www.microchip.com/forums/m123533.aspx

>  From previous experience with Microchip libraries I prefer to simply
> start from scratch.  However I assume that the USB module is more
> complex than the MSSP, ADC and the other 'basic' peripherals.

I will say it is much much more complicated than the basic
peripherals, say >>100 times more complicated than the
MSSP/ADC stuff.

> I'm off to read the datasheets & other documents now, but would
> appreciate a steer on the libraries.

It is good to read some ABCs of USB before start as well. Then the
USB 2.0 spec is also good but may be too much if you just want
to start.

Eg: http://www.usbmadesimple.co.uk/ (the author is also an
active Microchip USB forum member).


-- Xiaofan

2012\01\19@031942 by Christopher Head

picon face
-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

On Thu, 19 Jan 2012 00:33:30 +0000
Oli Glaser <oli.glaserspamKILLspamtalktalk.net> wrote:

{Quote hidden}

A lot of this is the same kind of information you could get on a Linux
system using lsusb in its most verbose mode and Wireshark/usbmon. The
parts that are notably missing are things like data PIDs and handshake
packets. Wireshark/usbmon, for instance, can't tell you if you got a
data PID wrong because PID toggle is handled by the host controller
hardware; the OS won't see the discarded packet at all, whereas a
proper sniffer will show you the transaction and also which PID it
used. Similarly a decent sniffer will show you what sequence of NAKs,
no-handshakes, ACKs, or STALLs are flying around, whereas Wireshark will
basically only tell you whether the transfer timed out (too many NAKs),
failed with I/O error (which one assumes means too many no-handshakes,
but you can't see the individual attempts), stalled (which typically
would mean a single STALL handshake), or completed (which would mean an
ACK, but with an unknown number of NAKs before it, plus maybe a few
no-handshakes as well). And in my case these tended to be the issues
that sucked up quite a bit of time before I bought the analyzer.

A software sniffer is certainly MUCH better than nothing, and if you're
working on a kernel driver it's probably very helpful as it can show
you more details about how I/O requests travel through the kernel
layers, but IMO the hardware sniffer has a lot of advantages when
working in firmware. The Beagle USB12, by the way, can also capture
from multiple devices simultaneously; you would just put a hub
downstream of it with the devices plugged into the hub (the analyzer
acts like a tapped transparent USB cable).

Chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)

iEYEAREDAAYFAk8X0hoACgkQXUF6hOTGP7cSPgCgm8amATqIpceCXMH6LiHo/l16
3lcAoIF3i1b/9+b2HmAQB9ixy9oflVpm
=Y1Jl
-----END PGP SIGNATURE-----

2012\01\19@061119 by David

flavicon
face
Quoting Xiaofan Chen <.....xiaofancKILLspamspam.....gmail.com>:
> Some links I and other Microchip forum members collected
> are probably useful as well.
> http://www.microchip.com/forums/m123533.aspx

Thanks to all, these links & suggestions are useful.  My aim is not to  quickly develop a product, this is a hobby so understanding how things  work is more important.  The FT232RL has served me well for a long  time, but it is time to step up a gear!

I will check the official stack and the few that have been referenced  in this thread.  I'll also get a copy of Jan Axelson's USB complete,  that seems like the best book available on the subject.

One last question: does the USB peripheral vary greatly between  devices?  If it's a fairly standard set of registers and buffers then  it will be a much easier task.

Davi

2012\01\19@153724 by Matt Bennett

flavicon
face
On Thu, January 19, 2012 5:11 am, David wrote:

> One last question: does the USB peripheral vary greatly between
> devices?  If it's a fairly standard set of registers and buffers then
> it will be a much easier task.

There is just one current ("official" Microchip) USB stack across all the
architectures that have USB. Do all your interaction with USB via the
software stack, and you don't have to worry about differences between
parts.  Some of the lower level files may change, but the stack is there
to make it lots easier.


Matt Bennett
Just outside of Austin, TX
30.51,-97.91

The views I express are my own, not that of my employer, a large
multinational corporation that you are familiar with

2012\01\19@162454 by Mike Harrison

flavicon
face

This might be of interest

http://dangerousprototypes.com/2011/08/29/honken-jtr-usb-stack-echo-demo-for-pic-18f-and-24f/

2012\01\21@105012 by Josh Koffman

face picon face
On Thu, Jan 19, 2012 at 6:11 AM, David <EraseMElistsspam_OUTspamTakeThisOuTedeca.net> wrote:
> One last question: does the USB peripheral vary greatly between
> devices?  If it's a fairly standard set of registers and buffers then
> it will be a much easier task.

I've only used a handful of 18F parts, but they seem to be pretty
similar. I did get bit when porting to an 18F65J50 (from memory, might
be wrong) when I didn't do my homework, and some registers that used
to be in the Access bank suddenly weren't. That was embarrassing.

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 2012 , 2013 only
- Today
- New search...