gnupic@linuxhacker.org

On Tuesday, May 6, 2003, at 11:20  PM, Mark Gross wrote:
> Look at what it would take to add support for other processors (AVR, 
> 8051, the
> USB enabled PIC16C765/JW - 2 PIC I'm getting samples for ;)

I'm not sure if Microchip has an ICE for this processor, but if not, I 
can tell you from experience that you will want to put a ZIF socket on 
your board, and have about 5 or 6 of the windowed chips handy when 
debugging.

While I'm not saying that you couldn't write a decent USB app with this 
chip given enough time, it's a real pain. I suppose a HLL could help, 
but once you've used a chip with a "real" USB SIE (such as the EZ-USB 
series, which handles a lot of layers of the USB protocol in hardware) 
you may never go back. The PIC SIE makes you do everything by hand, and 
the sample code relies heavily on banking and paging (which I find 
difficult to debug without a simulator). Plus, several months ago when 
I started working on my code, gpasm didn't support relocatable objects, 
and therefore wouldn't assemble Microchip's sample code without a lot 
of help (read: hand editing). I trust the situation is better now, but 
haven't verified it.

Also, these chips are low-speed, which makes them even slower than 
serial once you subtract out the protocol overhead. Granted, you do get 
some nice error detection and insertion/removal events from the  USB 
stack, but what's hidden in the fine print is that low-speed HID 
devices (the easiest to interface to under Windows) get only 800 
bytes/sec per HID report ID. I say "low-speed" and not "1.5 Mbps" 
because 1.5 Mbps is only the signaling rate, and only a small portion 
of the available bandwidth is allocated to low-speed devices.

I don't want to intentionally rain on your parade, honest-- I just feel 
that I got bitten by brand loyalty when I started down the path with 
USB-enabled PICs. Although the EZ-USB chips aren't as free-standing as 
a PIC (needing at least an LDO regulator and possibly some power-on 
reset circuitry), they are definitely a strong contender if you just 
want to get a USB design off the ground with minimal hassle. Oh, and 
SDCC works great with the EZ-USB chips.

I will probably give the upcoming USB-enabled 18F series chips a 
chance, but the 16C765 disappointed me.

-- 
Charles Lepple <clepple@ghz.cc>
http://www.ghz.cc/charles/