Searching \ for '[PIC] MCHPFSUSB USB stack bug' 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: 'MCHPFSUSB USB stack bug'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] MCHPFSUSB USB stack bug'
2010\01\14@130637 by Philip Pemberton

face
flavicon
face
Hi guys,

A few of you might remember the thread I started in November about an
apparent bug in the ping-pong buffering feature of the Microchip USB
stack. Specifically, if you have an odd number of IN packets between a
pair of USB_SET_CONFIGURATION packets, then the IN endpoint locks up
when the second SET_CONFIGURATION packet is received.

Well, I got a lovely email the other day from Mchip Support, asking for
more info.. This was provided, and about 20 minutes ago I got a second
email: "yep, there's a problem, we know what it is, and we're working on
a fix."

So I can add "Microchip USB Stack" to my "things I broke or found bugs
in" list... Maybe I should be doing software testing instead of software
"engineering"?...

--
Phil.
spam_OUTpiclistTakeThisOuTspamphilpem.me.uk
http://www.philpem.me.uk/

2010\01\14@182508 by Xiaofan Chen

face picon face
On Fri, Jan 15, 2010 at 2:06 AM, Philip Pemberton <.....piclistKILLspamspam@spam@philpem.me.uk> wrote:
> Hi guys,
>
> A few of you might remember the thread I started in November about an
> apparent bug in the ping-pong buffering feature of the Microchip USB
> stack. Specifically, if you have an odd number of IN packets between a
> pair of USB_SET_CONFIGURATION packets, then the IN endpoint locks up
> when the second SET_CONFIGURATION packet is received.
>
> Well, I got a lovely email the other day from Mchip Support, asking for
> more info.. This was provided, and about 20 minutes ago I got a second
> email: "yep, there's a problem, we know what it is, and we're working on
> a fix."
>
> So I can add "Microchip USB Stack" to my "things I broke or found bugs
> in" list... Maybe I should be doing software testing instead of software
> "engineering"?...

This is one thread I started, you can call it an unofficial bug list
for the Microchip USB stacks. There are quite some open items.
http://www.microchip.com/forums/tm.aspx?m=275422


--
Xiaofan http://mcuee.blogspot.com

2010\01\14@192818 by Funny NYPD

picon face
Honestly I don't trust most of the Microchip software stack after take a quick look of the source codes. Also, after several years of improvement on its CAN and USB firmware, I still see users posting "bugs found" here or there.

Based on what I knew, I will also try to avoid new (<2 years) Microchip PICs on USB, Ethernet, and CAN as far as I can.

Funny N.
Au Group Electronics, http://www.AuElectronics.com
http://www.AuElectronics.com/products
http://augroups.blogspot.com/




________________________________
From: Xiaofan Chen <xiaofancspamKILLspamgmail.com>
To: Microcontroller discussion list - Public. <.....piclistKILLspamspam.....mit.edu>
Sent: Thu, January 14, 2010 6:24:31 PM
Subject: Re: [PIC] MCHPFSUSB USB stack bug

On Fri, Jan 15, 2010 at 2:06 AM, Philip Pemberton <EraseMEpiclistspam_OUTspamTakeThisOuTphilpem.me.uk> wrote:
{Quote hidden}

This is one thread I started, you can call it an unofficial bug list
for the Microchip USB stacks. There are quite some open items.
http://www.microchip.com/forums/tm.aspx?m=275422


--
Xiaofan http://mcuee.blogspot.com

2010\01\14@195158 by Philip Pemberton

face
flavicon
face
Funny NYPD wrote:
> Based on what I knew, I will also try to avoid new (<2 years)
> Microchip PICs on USB, Ethernet, and CAN as far as I can.

I'm planning on migrating this design across to a Cypress EZ-USB chip as
soon as it's out of the "initial testing" stage. Basically I'm going to
have an FX2lp chip on a bodge-board, then write the code, then do the
PCB with the FX2lp. I'm sick of all the gotchas, catches and bugs in the
PIC18F4550.

The catch being that I lose the option of asking Microchip for a VID/PID
Sublicence -- meaning that I then have to pony up the $2k for a USB-IF
Vendor ID allocation. Not an attractive prospect, especially when there
isn't a chance in hell I'm going to find a use for 65,536 Product IDs.
Maybe 10 or 11, but not 2^16...

(65,000 0805 0.1uf capacitors on the other hand... those I could
probably use up quite quickly... :) )

--
Phil.
piclistspamspam_OUTphilpem.me.uk
http://www.philpem.me.uk/

2010\01\14@210112 by Funny NYPD

picon face
Same here.
It is not I don't want to use the USB based PICs or Microchip software stacks. It is I cannot afford for a loss of business due to PIC silicon errata or SW stack bugs. (When I released a product, I want to make sure I will have a nice sleep in the night.)

The only exemption we got, so far, is our BB0703 and BB0703+, they used aged PIC18F2550 in HID. Honestly PK2 is the best design I have ever seen from Microchip. But, that's it, only for BB0703 and BB0703+s. Pains (such as: the original PK2 designer cannot turn on the POR due to reason
123...; cannot turn on BOR due to reason 123...; cannot turn on WDT due
to reason 123 ...; canot...; cannot...;) on this family of USB chips kills all my interest to use it for other applications.  

Everything (important features, such as POR, BOR, WDT) promised on the user manual are denied on the silicon errata or undocumented practices.

Special thanks for PK2 designer who figured out how to make a good/ok product with such a hard-to-believe badly designed silicon. But that's just for him/his team. Not everybody get all his lucky.

I agree, they are all tiny issues, but put them together, I cannot have a nice sleep at night if I put it in my products.

Always try to use FTDI or Silicon Labs single chip solution for USB designs if budget isn't so tight. (By the way, Microchip still doesn't figure out how to make a full-speed USB MCU without crystal, which has been the industry standard for so many years.)

Industry temp (-40-85C) version FX2lp almost cost doubled its commercial (0-70C) version.

Funny N.
Au Group Electronics, http://www.AuElectronics.com
http://www.AuElectronics.com/products
http://augroups.blogspot.com/




________________________________
From: Philip Pemberton <@spam@piclistKILLspamspamphilpem.me.uk>
To: Microcontroller discussion list - Public. <KILLspampiclistKILLspamspammit.edu>
Sent: Thu, January 14, 2010 7:51:29 PM
Subject: Re: [PIC] MCHPFSUSB USB stack bug

Funny NYPD wrote:
> Based on what I knew, I will also try to avoid new (<2 years)
> Microchip PICs on USB, Ethernet, and CAN as far as I can.

I'm planning on migrating this design across to a Cypress EZ-USB chip as
soon as it's out of the "initial testing" stage. Basically I'm going to
have an FX2lp chip on a bodge-board, then write the code, then do the
PCB with the FX2lp. I'm sick of all the gotchas, catches and bugs in the
PIC18F4550.

The catch being that I lose the option of asking Microchip for a VID/PID
Sublicence -- meaning that I then have to pony up the $2k for a USB-IF
Vendor ID allocation. Not an attractive prospect, especially when there
isn't a chance in hell I'm going to find a use for 65,536 Product IDs.
Maybe 10 or 11, but not 2^16...

(65,000 0805 0.1uf capacitors on the other hand... those I could
probably use up quite quickly... :) )

--
Phil.
RemoveMEpiclistTakeThisOuTspamphilpem.me.uk
http://www.philpem.me.uk/

2010\01\14@212915 by Xiaofan Chen

face picon face
On Fri, Jan 15, 2010 at 10:00 AM, Funny NYPD <spamBeGonefunnynypdspamBeGonespamyahoo.com> wrote:

> Always try to use FTDI or Silicon Labs single chip solution for USB designs
> if budget isn't so tight. (By the way, Microchip still doesn't figure out how to
> make a full-speed USB MCU without crystal, which has been the industry
> standard for so many years.)

I would not call that Industrial standard, only a handful of companies are
able to do that (Silabs, FTDI, etc), majority of the companies, even some
other MCU companies with better USB expertise (NXP, Atmel, ST, etc) will still
require you to use Crystal.

> Industry temp (-40-85C) version FX2lp almost cost doubled its
> commercial (0-70C) version.

That is one reason why people are having more interests in the offerings
from other MCU vendors. Yes EZ-USB may be easier in terms of USB
programming and have the clear advantage of longer time in the market.
But now more and more leading USB experts are looking at Microchip
MCU parts, for example, Jan Axelson.

If you look at the Microchip forum USB section, it is very active and people
are having success developing successful product with Microchip USB MCUs.
http://www.microchip.com/forums/tt.aspx?forumid=102



--
Xiaofan http://mcuee.blogspot.com

2010\01\14@222119 by Funny NYPD

picon face
I am curious whether there are some example of seriously designed product based on PIC-USB MCU other than the PK2/PK3 programmers?


By the way, I don't think the PK2 "loss of firmware issue" are totally fixed by V2.4x and later releases (Now, it seems the same ghost is kissing PK3). Walter may be smart to figure out how to reduce the occurancy frequency of this issue and have an internal check/fix when firmware or configuration bits are damaged by unknown reason. But it still happens. When corruption are detected, the software will automatically fix the configuration bit corrupted without user notice, but it does require user re-downloading the os from a PC. So far, nobody knows what's the root cause. If this happens to PIC18F2550, I am pretty confident it will happen to 18F4550 too. And it appears happening more frequently when new computer are used, and it almost happens 100% when the PK2 is being plugged into a PC. Maybe this has something related to ESD or transient voltage as another PIClist thread is discussing.

The bad thing about those issue is: you cannot duplicate in the lab but it happens. I had a few of device tested for thousands of time on plug/unplug, none of them failed. The good thing is, after Walter's PK2 firmware improvement, it is very easy to fix, a few clicks will get the device back.

Won't it be good without those bugs/glitches?

We will do some enhancement on our next BB0703 HardWare release to have ESD protection on both ICSP connector and USB connector as standard feature. For the moment, we will offer ESD protection on both side as an option.

Funny N.
Au Group Electronics, http://www.AuElectronics.com
http://www.AuElectronics.com/products
http://augroups.blogspot.com/




________________________________
From: Xiaofan Chen <TakeThisOuTxiaofancEraseMEspamspam_OUTgmail.com>
To: Microcontroller discussion list - Public. <RemoveMEpiclistspamTakeThisOuTmit.edu>
Sent: Thu, January 14, 2010 9:28:39 PM
Subject: Re: [PIC] MCHPFSUSB USB stack bug

On Fri, Jan 15, 2010 at 10:00 AM, Funny NYPD <funnynypdEraseMEspam.....yahoo.com> wrote:

> Always try to use FTDI or Silicon Labs single chip solution for USB designs
> if budget isn't so tight. (By the way, Microchip still doesn't figure out how to
> make a full-speed USB MCU without crystal, which has been the industry
> standard for so many years.)

I would not call that Industrial standard, only a handful of companies are
able to do that (Silabs, FTDI, etc), majority of the companies, even some
other MCU companies with better USB expertise (NXP, Atmel, ST, etc) will still
require you to use Crystal.

> Industry temp (-40-85C) version FX2lp almost cost doubled its
> commercial (0-70C) version.

That is one reason why people are having more interests in the offerings
from other MCU vendors. Yes EZ-USB may be easier in terms of USB
programming and have the clear advantage of longer time in the market.
But now more and more leading USB experts are looking at Microchip
MCU parts, for example, Jan Axelson.

If you look at the Microchip forum USB section, it is very active and people
are having success developing successful product with Microchip USB MCUs.
http://www.microchip.com/forums/tt.aspx?forumid=102



--
Xiaofan http://mcuee.blogspot.com

2010\01\15@063359 by Philip Pemberton

face
flavicon
face
Funny NYPD wrote:
> Industry temp (-40-85C) version FX2lp almost cost doubled its commercial (0-70C) version.

Pretty irrelevant when you're only designing for the Commercial
temperature range though.

There are a few advantages to the EZ-USB chips as I see it:
  - Firmware is loaded by the host. Load whatever firmware you like,
    if it gets trashed, just reload it. Devices can't be bricked by a
    bad flash upgrade (it's SRAM not FLASH).
  - GPIF module, transferring to RAM buffers or USB. Tell the chip how
    to talk to your FPGA, give it a byte (or word) count, then leave it
    to do the FPGA interfacing while you do something else important.
  - Varying degrees of hardware USB abstraction. Let the hardware do
    everything from enumeration to data transfer for you, or do
    everything yourself (or anything in between).
  - Long time-on-market, well-tested and known stable. The Cypress demo
    driver is apparently pretty shaky, but there's nothing stopping you
    from using libusb-win32 or WinUSB.

The catch(es), of course:
  - You need an external Serial EEPROM to store the VID/PID
  - If the SEEPROM gets corrupted, the VID/PID will probably come up as
    0000:0000, meaning your PC, Mac or whatever won't see the device.
  - No VID/PID sublicensing from Cypress (unlike Mchip)
  - Hardware abstraction limits the possible combinations of endpoint
    count and buffer size. Not really a big deal, though (unless you
    mind having endpoints set up that aren't being used, or
    communicating over EP4 instead of EP0).

--
Phil.
EraseMEpiclistspamphilpem.me.uk
http://www.philpem.me.uk/

2010\01\15@064215 by Chris Emerson

flavicon
face
On Fri, Jan 15, 2010 at 11:33:19AM +0000, Philip Pemberton wrote:
> There are a few advantages to the EZ-USB chips as I see it:
>    - Firmware is loaded by the host. Load whatever firmware you like,
>      if it gets trashed, just reload it. Devices can't be bricked by a
>      bad flash upgrade (it's SRAM not FLASH).

A big possible disadvantage of this (depending on use) is that you always
need a special driver for your device (to load the firmware) on every OS,
even if you want to implement a standard class which the OS would normally
handle by itself.

Cheers,

Chris

2010\01\15@082801 by olin piclist

face picon face
Funny NYPD wrote:
> It is not I don't want to use the USB based PICs or Microchip software
> stacks. It is I cannot afford for a loss of business due to PIC silicon
> errata or SW stack bugs. (When I released a product, I want to make
> sure I will have a nice sleep in the night.)

Then you should consider our USB firmware.  We've used this in close to a
dozen products by now, our own and those of our customers.  Our USBProg,
USBProg2, and LPROG PIC programmers use it, for example.  It was written in
assembler to be careful with resources to maximize the applications it can
support.  It deliberately doesn't use interrupts so as not to get in the way
of low interrupt latency a application may require.

The driver that comes with it exports pipe 1 as a bi-directional stream of
bytes.  To the host application and the firmware application, it therefore
looks a lot like UART or TCP communication.

The firmware uses the ping-pong buffering mode of the USB hardware with
three rolling software buffers, although this is all under the hood and
"just works" from the application's point of view.  The app calls PUT and
GET byte routines.  There are also control options availble, like hold
buffer until full, flush, and others.  Unless you are doing something
unusual, device enumeration is taken care of and all you have to do is fill
in a include file with your static information.  The code is carefully
documented, even if I say so myself.

The version on the web site is for applications that use the main event loop
model.  This version requires the app to call USB_RUN and USB0_RUN to let
the background USB handler and the endpoint 0 logic run.  We also have a
version that uses our cooperative multi-tasking system, where the USB
backround functions are performed in their own task.  This is the version we
used, for example, in our USB to CAN adapter.

The firmware source code, driver, and host example code is available from
http://www.embedinc.com/pic/dload.htm.  Note that there is some cost for
commercial products, but that's the case too if you roll your own or live
with the Microchip problems.  Everything is generally free for hobbyists.
See the license for details.

By the way, we also have other robust firmware subsystems like CAN and a
network stack that actually works without mysterious hangs, and that has
much less onorous restrictions on the application than the Microchip stuff.
The network stack includes a ENC28J60 driver for the packet layer, enough of
ICMP to reply to ping requests, ARP with configurable number of cache
entries, IP, and TCP.  UDP and a DHCP client will likely be added in the
near future.  The TCP layer presents a put byte and get byte interface for
each connection.  Unlike with the Microchip stack, the application does not
need to be aware of packet boundaries or whether other connections have a
receive or transmit packet open at the time.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2010\01\15@083044 by Alan B. Pearce

face picon face
  - Firmware is loaded by the host. Load whatever firmware you like,
    if it gets trashed, just reload it. Devices can't be bricked by a
    bad flash upgrade (it's SRAM not FLASH).

The catch(es), of course:
   - Firmware is not secure, anyone can eavesdrop on the download to
       copy your IP ...

2010\01\15@083346 by Xiaofan Chen

face picon face
On Fri, Jan 15, 2010 at 7:33 PM, Philip Pemberton <RemoveMEpiclistEraseMEspamEraseMEphilpem.me.uk> wrote:
> Funny NYPD wrote:
>> Industry temp (-40-85C) version FX2lp almost cost doubled its commercial (0-70C) version.
>
> Pretty irrelevant when you're only designing for the Commercial
> temperature range though.
>
> There are a few advantages to the EZ-USB chips as I see it:
>   - Firmware is loaded by the host. Load whatever firmware you like,
>     if it gets trashed, just reload it. Devices can't be bricked by a
>     bad flash upgrade (it's SRAM not FLASH).
Good or bad depending on your situation. Luckily the infrastructure
to download the firmware is most likely there, at least for Windows
and Linux.

>   - GPIF module, transferring to RAM buffers or USB. Tell the chip how
>     to talk to your FPGA, give it a byte (or word) count, then leave it
>     to do the FPGA interfacing while you do something else important.
>   - Varying degrees of hardware USB abstraction. Let the hardware do
>     everything from enumeration to data transfer for you, or do
>     everything yourself (or anything in between).

>   - Long time-on-market, well-tested and known stable. The Cypress demo
>     driver is apparently pretty shaky, but there's nothing stopping you
>     from using libusb-win32 or WinUSB.
The Cypress driver is at least better than Microchip's custom driver.

> The catch(es), of course:
>   - You need an external Serial EEPROM to store the VID/PID
>   - If the SEEPROM gets corrupted, the VID/PID will probably come up as
>     0000:0000, meaning your PC, Mac or whatever won't see the device.
>   - No VID/PID sublicensing from Cypress (unlike Mchip)
>   - Hardware abstraction limits the possible combinations of endpoint
>     count and buffer size. Not really a big deal, though (unless you
>     mind having endpoints set up that aren't being used, or
>     communicating over EP4 instead of EP0).

One more disadvantage, the 8051 core can not really handle processing
of the data, especially for high speed USB. That is one reason
why other USB MCUs are catching up, like those from NXP and
maybe Atmel's new ARM/Cortex M3 based USB MCUs with high
speed USB.



--
Xiaofan http://mcuee.blogspot.com

2010\01\15@091720 by Philip Pemberton

face
flavicon
face
Alan B. Pearce wrote:
> The catch(es), of course:
>     - Firmware is not secure, anyone can eavesdrop on the download to
>         copy your IP ...

True.
But in this case, the firmware is basically a protocol converter -- all
the interesting stuff is in the FPGA. You're welcome to dig into the
firmware but all you'll see is USB init, a bit of FPGA init and some
protocol translation logic. The Verilog code for the FPGA, on the other
hand, is much more interesting...

If I wanted to be really nasty, I'd get a bunch of Dallas DS2432 SHA-1
Authenticator chips, solder one to each board, and add an IFF (Identify,
Friend or Foe) module to the FPGA logic. If the IFF doesn't detect a
valid 2432, then it holds the FPGA logic in reset. If the IFF check
passes, the RESET line is released and the FPGA logic starts running.

I think there's a Xilinx appnote on this...

There are also other sneaky things that can be done in (PC) software,
like checking serial numbers. Hide the hardware serial number somewhere
in EEPROM, and keep an encrypted/scrambled/hashed copy elsewhere (maybe
in flash). Don't check it AT ALL in the firmware, just let the device
run. Then when the software boots, check the serial number against a
blacklist. For best results, implement multiple layers of checking, and
add one check per software release.

Apparently this is what CADSOFT did with the EAGLE licenses -- v4.00
keyfiles had a few "unused" words. Someone released a keygen, then CS
released EAGLE 4.01 which enabled an additional check on one of those
"unused" words. Rinse, repeat.

If you want to be really sneaky, run the licence-checking logic inside
an internal virtual machine. Then anyone that wants to bypass the serial
number blacklist will need to reverse engineer the VM first. This type
of system is working (reasonably) well for the Blu-Ray platform (google
BD+). As soon as someone cracks Security Module V1, you turn on a few
more security checks and release Security Module V2.

Then there's the option of keeping software releases "private" to
customers. Log in with serial number and a corresponding "service tag"
number that's stuck to each unit. Again, the blacklist comes into play...

It's like a game of Whack-a-Mole.... or possibly GLOBAL-THERMONUCLEAR-WAR.

--
Phil.
RemoveMEpiclistspam_OUTspamKILLspamphilpem.me.uk
http://www.philpem.me.uk/

2010\01\15@092910 by Philip Pemberton

face
flavicon
face
Xiaofan Chen wrote:
> The Cypress driver is at least better than Microchip's custom driver.

IMO: a one-legged chair is more stable than Microchip's driver.

> One more disadvantage, the 8051 core can not really handle processing
> of the data, especially for high speed USB. That is one reason
> why other USB MCUs are catching up, like those from NXP and
> maybe Atmel's new ARM/Cortex M3 based USB MCUs with high
> speed USB.

But AIUI, the EZ-USB series was designed for interfacing with devices
that are

And it's not a "pureblood" 8051 -- it's an overclocked "turbo" 8051
variant. Same instruction set, but the 12-cycles-per-instruction divider
has been dropped to 4-cycles, and it'll do 12MIPS (at an Fclk of 48MHz).
At the very least, it'll match a PIC for raw performance, and with the
GPIF module it can potentially beat it.

I seem to recall Cypress claiming nearly 30MBytes/sec for their
ATA/ATAPI interface demo using the FX2LP chip (not outside the realms of
possibility with a good software USB Mass Storage implementation).

--
Phil.
RemoveMEpiclistTakeThisOuTspamspamphilpem.me.uk
http://www.philpem.me.uk/

2010\01\15@094334 by Xiaofan Chen

face picon face
On Fri, Jan 15, 2010 at 10:28 PM, Philip Pemberton
<EraseMEpiclistspamspamspamBeGonephilpem.me.uk> wrote:
> And it's not a "pureblood" 8051 -- it's an overclocked "turbo" 8051
> variant. Same instruction set, but the 12-cycles-per-instruction divider
> has been dropped to 4-cycles, and it'll do 12MIPS (at an Fclk of 48MHz).
> At the very least, it'll match a PIC for raw performance, and with the
> GPIF module it can potentially beat it.

A USB PIC24 will beat that. A USB PIC32 will beat that handsomely.

--
Xiaofan http://mcuee.blogspot.com

2010\01\15@095019 by Funny NYPD

picon face
Those are new silicons, no surprise to me, will be full of bugs.
And, as usual, none of the Microchip silicon design engineer will have a clue what's the cause (which means it will be very quite after the issue reported) for a long time. Especially the PIC32 core is from outside of the company, so there is always someone else to blame.

Funny N.
Au Group Electronics, http://www.AuElectronics.com
http://www.AuElectronics.com/products
http://augroups.blogspot.com/




________________________________
From: Xiaofan Chen <RemoveMExiaofancKILLspamspamgmail.com>
To: Microcontroller discussion list - Public. <piclistSTOPspamspamspam_OUTmit.edu>
Sent: Fri, January 15, 2010 9:42:57 AM
Subject: Re: [PIC] MCHPFSUSB USB stack bug

On Fri, Jan 15, 2010 at 10:28 PM, Philip Pemberton
<spamBeGonepiclistSTOPspamspamEraseMEphilpem.me.uk> wrote:
> And it's not a "pureblood" 8051 -- it's an overclocked "turbo" 8051
> variant. Same instruction set, but the 12-cycles-per-instruction divider
> has been dropped to 4-cycles, and it'll do 12MIPS (at an Fclk of 48MHz).
> At the very least, it'll match a PIC for raw performance, and with the
> GPIF module it can potentially beat it.

A USB PIC24 will beat that. A USB PIC32 will beat that handsomely.

--
Xiaofan http://mcuee.blogspot.com

2010\01\15@095413 by Philip Pemberton

face
flavicon
face
Xiaofan Chen wrote:
> A USB PIC24 will beat that. A USB PIC32 will beat that handsomely.

Two problems:
  1) I don't have a PIC24 C compiler
  2) I don't have a PIC32 C compiler

Are there any normal-pitch (i.e. 0.5mm, 0.65mm, 1.27mm...) SMD-packaged
versions of the PIC24 and PIC32?
Do they even have any onboard Flash?
I was under the impression they were meant more as CPUs than MCUs...

--
Phil.
KILLspampiclistspamBeGonespamphilpem.me.uk
http://www.philpem.me.uk/

2010\01\15@100829 by Wouter van Ooijen

face picon face
>    2) I don't have a PIC32 C compiler

then why not download it?

> Are there any normal-pitch (i.e. 0.5mm, 0.65mm, 1.27mm...) SMD-packaged
> versions of the PIC24 and PIC32?

AFAIK yes

> Do they even have any onboard Flash?

maybe a few exceptions don't, but most surely do

--

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu

2010\01\15@104602 by Xiaofan Chen

face picon face
On Fri, Jan 15, 2010 at 10:53 PM, Philip Pemberton
<EraseMEpiclistspamEraseMEphilpem.me.uk> wrote:
> Xiaofan Chen wrote:
>> A USB PIC24 will beat that. A USB PIC32 will beat that handsomely.
>
> Two problems:
>   1) I don't have a PIC24 C compiler
>   2) I don't have a PIC32 C compiler
>
> Are there any normal-pitch (i.e. 0.5mm, 0.65mm, 1.27mm...) SMD-packaged
> versions of the PIC24 and PIC32?
> Do they even have any onboard Flash?
> I was under the impression they were meant more as CPUs than MCUs...
>

Go to http://www.microchip.com/usb and you will know the anwers.
PIC24 and PIC32 both have free GCC based compilers from Microchip,
there are limitation on the optimization, but no code size limit.

They even have DIP package for USB PIC24.

All of them have Flash. They are really MCUs and not MPUS since
they do not have expansion bus.
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2654


--
Xiaofan http://mcuee.blogspot.com

2010\01\15@105052 by Alan B. Pearce

face picon face
>Two problems:
>   1) I don't have a PIC24 C compiler
>   2) I don't have a PIC32 C compiler

Well, both have freely downloadable versions, which do full optimisation for
about 45 days IIRC. After that they don't do optimisation, unless you enter
a registration code that you buy. It is a one-off purchase, that gives you a
code for life, i.e. the upgrades do not need a new key.

>Are there any normal-pitch (i.e. 0.5mm, 0.65mm, 1.27mm...) SMD-packaged
>versions of the PIC24 and PIC32?

Yes, there are some 28 pin PIC24s with USB, which are even available in DIP
IIRC, certainly in hobbyist useable SMD. Check the device selector at
Microchip.

>Do they even have any onboard Flash?

Yes, but what you may need to watch is they don't all have data EEPROM.
There is a method of using program space flash as data EEPROM.

>I was under the impression they were meant more as CPUs than MCUs...

The line is getting very blurred, especially with the new 20 pin PIC24 chips
(don't have USB though).

They do have other nice features like PPS (Peripheral Pin Select) which
allows you to map certain of the peripheral blocks like I2C, SPI and UARTS
to pins where they are the most convenient to you, instead of deciding that
you cannot use the I2C because you need the UART that is on the same pins
...

And having all the RAM in one block instead of paged like the 18F and 16F
chips ...

And a proper vectored interrupt system where you can set the priorities,
along with trap vectors for a number of things ...

and so the list goes on.

2010\01\15@131135 by Vitaliy

face
flavicon
face
Funny NYPD wrote:
> Those are new silicons, no surprise to me, will be full of bugs.

PIC24H has been around for several years now. We had concerns about using a
"new, unproven" chip but so far we've been able to work around the bugs.
Started using 33F/24H back in 2008.

Vitaliy


'[PIC] MCHPFSUSB USB stack bug'
2010\02\09@202933 by oingo456
picon face

I came across this thread and I have extensive experience with the EZusb FX2
using USB2 high speed mode (480MBit) hooked to an FPGA.  I also have a
rather expensive CATC hardware protocol analyzer, so I can verify that some
of the problems that I have are actually with the EZUSB.. but cypress
doesn't care.

Let me tell you, the ezusb usb core has plenty of gotchas on it's own.  (The
8051 core is bug-free it seems though.)

1.  The "sram" download feature that all believe to be a great feature is in
fact a curse in my opinion.  You will probably spend additional development
time developing or modifying bootloaders for every possible operating
system; Windows, MacOS (68K), MacOS (intel), linux.  You also will have to
make sure they work under 64-bit windows.  And 64-bit windows REQUIRES
signed drivers for kernel mode bootloaders.  So right there you need to buy
a verisign signature ($499 per year) and the signing tools are crap and only
run right on windows XP.  You can't use a 3rd party signing certificate like
you can for apps.

2.  The EZUSB FX2 often looses it's serial eeprom, so you have dead boards
in the field that you can't boot or fix, just like your flash problems.
Even if you never write to it, it manages to become corrupted.  But there's
no chance of a backup bootloader like you can do with flash.

3.  We have had a fair share of bad IC's from cypress.  How responsive were
they?  2 months investigating it and I had to call every other day.  They
really don't care.  This is like a side business for them.

4.  The EZUSB engine sometimes duplicates received packets seen by the 8051
core endpoints (GPIF endpoints were OK).  They are not duplicated on the USB
line; it is a hardware bug that is really difficult to catch, but it's the
FX2.  Cypress told me they don't have a CATC analyzer so they can't look
into it.  It is related to the buffering modes.   Quad buffered seems to
work; single or double had some problems.

5.  The hardware engine takes a variable amount of time to compute packet
checksums & send an AK back to the host.  It really limits the amount of
data you can push through;  I would never use this for a hard drive
interface; the dedicated bridge chips would be much better.


I have had some problems with the silicon labs USB products also.  I
generally like them a lot, but
1.  Silicon labs are expensive for production parts
2.  The CPU core can lock up if there is momentary noise (or the clock drops
out) on the USB lines.  Makes your product unreliable.
3.  Just momentarily short the D+ and D- lines going to a silicon labs chip
to simulate this.  The core stops.  Cycling power is the only way to get it
working again.


There are a lot of amazing looking cortex USB parts out now.  All are only
12mbit usb (the atmel at91sam is 480mbit but still not out.)
LPC13xx series for $2.50 is amazing, and the LPC17xx for a little more gets
you extra uarts & flash.

I am trying these out now.. the developer kit with compiler & reusable jtag
is only $30!  Look for the LPCXPRESSO.

I would also highly recommend (if you can), stick with using usb 2.0
full-speed (12Mbit) rather than high speed (480mbit).  You will have fewer
problems caused by your user's poor quality usb cables, questionable hubs,
motherboards, or chipsets.  It seems every month we find another motherboard
that has a hiccup with high speed usb transfers.  

Best luck to all.
Dave



Vitaliy-14 wrote:
{Quote hidden}

> --

2010\02\09@204614 by Mike Harrison

flavicon
face
On Tue, 9 Feb 2010 17:29:31 -0800 (PST), you wrote:

{Quote hidden}

Have you looked at FTDI's FT2232H yet?
I've started using it & looks pretty good so far - for talking to an FPGA  it seems way easier than
Cypress as the host side driver is already done for you.


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