gnupic: Thread: PIC16C765 [was Re: Should JAL be added to the gputils?]

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 ####@####.####
http://www.ghz.cc/charles/

On Wednesday 07 May 2003 05:29, Charles Lepple wrote:
> 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.


Wow!  thanks for the info!  You may have saved me a lot of wasted time.  
Thanks!  

BTW what I'm thinking of trying is to re-design the Mark-III 
http://www.junun.org/MiniSumoMarkIII/ controler card to use USB over rs-232.

--mgross

Mark Gross wrote:
>>
>>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.

Is that true even if you have a USB bus with only low speed devices on it? It is frequently possible to arrange that. PCs typically have multiple USB ports, and in at least some of them, each port is on a separate bus. And if you're designing some sort of dedicated thing, you can just keep other USB devices out of the picture.

Still, your point is valid: the usefulness of the 16C765 is rather limited by the fact that it only does low speed; that pretty much restricts it to low data rate devices like keyboards and mice. The USB-enabled members of the 18F family seem to have disappeared from the Microchip web site (they're not listed either in the web pages summarizing the 18F series, or in the PDF file of future products), so it's not clear whether they will ever see the light of day - perhaps there just wasn't enough demand from Microchip's customers for them.

Mark J. Dulcey said:
> Is that true even if you have a USB bus with only low speed devices on
> it?

I think so. There may be an additional restriction in the host-controller
software, but I think it has to do with the low-speed signalling protocol,
and how often low-speed frames are permitted on the bus. Remember that
low-speed frames are only allowed a maximum of 8 data bytes, and you can
only do Control and Interrupt transfers.

With a simple data generator app, I was able to get ~2.5 Kbytes/sec
sustained from PIC to PC. I don't have the calculations handy, but I think
that's the same order of magnitude as the theoretical maximum rate.

> It is frequently possible to arrange that. PCs typically have
> multiple USB ports, and in at least some of them, each port is on a
> separate bus. And if you're designing some sort of dedicated thing, you
> can just keep other USB devices out of the picture.

I did all of my testing on a completely empty bus (except for the
device-under-test).

> Still, your point is valid: the usefulness of the 16C765 is rather
> limited by the fact that it only does low speed; that pretty much
> restricts it to low data rate devices like keyboards and mice.

Right. It is fairly low-latency, though (~2 ms if your OS has a decent
scheduler), so if that's a design requirement, you might be in luck.

> The
> USB-enabled members of the 18F family seem to have disappeared from the
> Microchip web site (they're not listed either in the web pages
> summarizing the 18F series, or in the PDF file of future products), so
> it's not clear whether they will ever see the light of day - perhaps
> there just wasn't enough demand from Microchip's customers for them.

Bummer. From the look of the prelim data sheet, those parts also had some
nice support for external endpoints (i.e. reading from an ADC or some
other parallel device).

FWIW, the EZ-USB chips have "fast read/write" strobe pins for this
purpose, and the EZ-USB FX chips build on that concept.

Or, if you want to leverage existing PIC code, you could use any number of
USB device controller chips that have a "register file" or FIFO interface.
This won't give you blazing speed, but it's better than starting from
scratch (since most PIC projects seem to be written in assembly, not C).

-- 
Charles Lepple ####@####.####
http://www.ghz.cc/charles/