Searching \ for '[PIC:] 18F1320 speed problem admitted' 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=18F
Search entire site for: '18F1320 speed problem admitted'.

Exact match. Not showing close matches.
PICList Thread
'[PIC:] 18F1320 speed problem admitted'
2003\10\30@075149 by Olin Lathrop

face picon face
Microchip has finally fessed up that the 18F1320/1220 does not run at full
speed, over 7 months after I sent them a test case demonstrating this
problem.  Better late than never I guess.  The new errata was apparently
released Friday 24 October, and is available at
http://www.microchip.com/download/lit/suppdoc/errata/80160b.pdf.

The problem is even worse than I thought.  The maximum speed is only 4MHz,
unless you don't mind an occasional "corruption of fetched instructions".

The good news is that new silicon is being tested and seems to work now.

I can understand an occasional screwup getting shipped.  It's a little
harder to understand how something this blatantly busted ever made it out
the door.  What really pisses me off, however, is that they apparently
waited until they had fixed silicon in hand before admitting the problem.
That's inexcusable.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\10\30@101011 by Ken Pergola

flavicon
face
Olin Lathrop wrote:

> The good news is that new silicon is being tested and seems to work now.

Hi Olin,

Just was curious, is this new silicon that you personally are testing?
I hope you have seen the problem you saw disappear.

Best regards,

Ken Pergola

P.S. I'm anxiously waiting until the PIC18FXX20 devices have a silicon fix
to allow 40 MHz operation (instead of 25 MHz). Maybe the fix is not too far
behind?

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\10\30@101630 by Herbert Graf

flavicon
face
> Microchip has finally fessed up that the 18F1320/1220 does not run at full
> speed, over 7 months after I sent them a test case demonstrating this
> problem.  Better late than never I guess.  The new errata was apparently
> released Friday 24 October, and is available at
> http://www.microchip.com/download/lit/suppdoc/errata/80160b.pdf.
>
> The problem is even worse than I thought.  The maximum speed is only 4MHz,
> unless you don't mind an occasional "corruption of fetched instructions".
>
> The good news is that new silicon is being tested and seems to work now.
>
> I can understand an occasional screwup getting shipped.  It's a little
> harder to understand how something this blatantly busted ever made it out
> the door.  What really pisses me off, however, is that they apparently
> waited until they had fixed silicon in hand before admitting the problem.
> That's inexcusable.

       I must ask, which is probably an obvious question: what the bleeping h$&%$
is wrong with Microchip? If they knew about the problem for so long WHY
haven't they admitted to it until now? This is simply ridiculous. People may
have been working for weeks trying to find a problem in their code that
simply wasn't there.

       Frankly, my opinion of MChip has taken a large dive. I had a look at the
errata sheet and I can't believe how many there are. Sad, simply sad. If
their silicon is that Beta they should have never released it. They are
turning into another Microsoft.

       I wonder what kind of compensation they are willing to offer to people who
bought these parts speced for above 4MHz yet won't run reliably at above
4MHz? TTYL

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\10\30@102419 by

picon face
A replacement program maybe ?
Jan-Erik.

Herbert Graf wrote:
> I wonder what kind of compensation they are willing to offer to people who
> bought these parts speced for above 4MHz yet won't run reliably at above
> 4MHz? TTYL

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\10\30@104120 by Dal Wheeler

flavicon
face
So, in light of this how are we to know how long to wait until we decide to
"adopt" newer silicon coming out of microchip?  This is really silly of
them.  They don't have the benifit/cost ratio that they used to.  Why would
they risk alienating their remaining loyal developers?  I make enough
mistakes without having to second guess the @%%^&!! processor itself.

----- Original Message -----
From: "Olin Lathrop" <spam_OUTolin_piclistTakeThisOuTspamEMBEDINC.COM>

> Microchip has finally fessed up that the 18F1320/1220 does not run at full
> speed, over 7 months after I sent them a test case demonstrating this
> problem.  Better late than never I guess.  The new errata was apparently

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\10\30@104532 by Dal Wheeler

flavicon
face
Thats nothing; what about someone that might of fielded these processors?
(no not me)
----- Original Message -----
From: "Herbert Graf" <.....mailinglistKILLspamspam@spam@FARCITE.NET>
>         I wonder what kind of compensation they are willing to offer to
people who
> bought these parts speced for above 4MHz yet won't run reliably at above
> 4MHz? TTYL

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\10\30@105120 by

picon face
And what about the silicon you get through the
sample service ? Are they OK ?
Jan-Erik.

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\10\30@110415 by hael Rigby-Jones

picon face
> -----Original Message-----
> From: Herbert Graf [mailinglistspamKILLspamFARCITE.NET]
> Sent: 30 October 2003 15:16
> To: .....PICLISTKILLspamspam.....MITVMA.MIT.EDU
> Subject: Re: [PIC:] 18F1320 speed problem admitted
>
>
>         I wonder what kind of compensation they are willing
> to offer to people who
> bought these parts speced for above 4MHz yet won't run
> reliably at above
> 4MHz? TTYL

A lot (most? all?) of these parts that can no longer run reliably over 4MHz
were originaly specced to run at 40MHz!  Just a slight moving of the
specs...

Mike




=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================
Any questions about Bookham's E-Mail service should be directed to
EraseMEpostmasterspam_OUTspamTakeThisOuTbookham.com.

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\10\30@113454 by Herbert Graf

flavicon
face
Perhaps, but considering the pain some developers may have had do to the
delay something more might be a "good idea" for them. TTYL

> A replacement program maybe ?
> Jan-Erik.
>
> Herbert Graf wrote:
> > I wonder what kind of compensation they are willing to offer to
> people who
> > bought these parts speced for above 4MHz yet won't run reliably at above
> > 4MHz? TTYL
>
> --
> http://www.piclist.com hint: The list server can filter out subtopics
> (like ads or off topics) for you. See http://www.piclist.com/#topics
>

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\10\30@113703 by Herbert Graf

flavicon
face
Actually I'm not sure I'd pity people in that situation since it would point
to them not having properly tested their product before releasing it. I
haven't been exposed to the problem but from the sounds of it "normal"
testing should have shown an "issue". TTYL

> Thats nothing; what about someone that might of fielded these processors?
> (no not me)
> {Original Message removed}

2003\10\30@115946 by

picon face
Herbert Graf wrote:
> I haven't been exposed to the problem but from the
> sounds of it "normal" testing should have shown an "issue". TTYL

Not if operating inside the "safe" limits. If you design for
1 Mhz, why test at 10 or 20 Mhz ?

Jan-Erik.

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\10\30@120743 by Herbert Graf

flavicon
face
> Herbert Graf wrote:
> > I haven't been exposed to the problem but from the
> > sounds of it "normal" testing should have shown an "issue". TTYL
>
> Not if operating inside the "safe" limits. If you design for
> 1 Mhz, why test at 10 or 20 Mhz ?

       Since they wouldn't be effected (according to MChip) they have nothing to
worry about, except of course if there are MORE problems...

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\10\30@124613 by amg amg

picon face
> A lot (most? all?) of these parts that can no longer run reliably
> over 4MHz were originaly specced to run at 40MHz!  Just a slight moving
of
> the specs...

Just think of what it would look like if our nose was an order of
magnitude off in its length...

________________________________________________________________
The best thing to hit the internet in years - Juno SpeedBand!
Surf the web up to FIVE TIMES FASTER!
Only $14.95/ month - visit http://www.juno.com to sign up today!

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\10\30@130538 by Olin Lathrop

face picon face
> Just was curious, is this new silicon that you personally are testing?
> I hope you have seen the problem you saw disappear.

I will be personally testing pre-release versions of this silicon,
probably next week.  Microchip of course has run all kinds of tests
already specifically looking for this problem and hasn't found it.  I
expect the problem I saw is fixed, especially since they have the test
case I sent them in March.  It sounds redundant to me that I test these
chips too, but I agreed to do it.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\10\30@130744 by Olin Lathrop

face picon face
> And what about the silicon you get through the
> sample service ? Are they OK ?

Not yet.  All currently available 18F1320/1220 are 4MHz parts max.

*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\10\30@131741 by Dal Wheeler

flavicon
face
But, from what I gathered, the problem does not have a hard problem
threshold at 4mhz.  I could see a situation where someone chose a frequency
a bit higher and not seen problems in "normal" testing only to get burned
later.  I'm sure no one here ships anything without *extensive* testing.
;')

{Original Message removed}

2003\10\30@132607 by David VanHorn
flavicon
face
At 11:16 AM 10/30/2003 -0700, Dal Wheeler wrote:

>But, from what I gathered, the problem does not have a hard problem
>threshold at 4mhz.  I could see a situation where someone chose a frequency
>a bit higher and not seen problems in "normal" testing only to get burned
>later.  I'm sure no one here ships anything without *extensive* testing.
>;')

Does Mchip now state a new maximum speed for the devices?
If so, then you ought to be able to rely on it absolutely.
Of course that's how you got here in the first place..

Still, their testing is going to be far more definitive than anything an end user can do.  Simply clocking it up till it fails might be indicative of a particular chip, but you wouldn't know anything useful about the next chip, or the next production batch.

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\10\30@145821 by Mike Singer

picon face
Herbert Graf wrote:
> ...Frankly, my opinion of MChip has taken a large dive.
> ... They are turning into another Microsoft.

"Delenda est Carthago". - "Delenda est Microsoft".

  Any example of MS have been told for 7 months about
some severe issue and did not confirm it?

Mike.

PS. From some post year ago:
"Plato is my friend, Aristotle is my friend, but my best
friend is truth." Isaac (and I hope James) Newton.

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\10\30@180352 by Russell McMahon

face
flavicon
face
> Actually I'm not sure I'd pity people in that situation since it would
point
> to them not having properly tested their product before releasing it. I
> haven't been exposed to the problem but from the sounds of it "normal"
> testing should have shown an "issue". TTYL

You obviously haven't been badly burnt (as I have) by processors which run
apparently perfectly during testing but which cause intermittent problems in
customers equipment (which happens to be located about 15,000 km away)
entirely because the processor (non-Microchip in my case) fails to meet its
guaranteed specifications.

Once a manufacturer fails to honour their guaranteed specification and
decides to hide the fact from you, there can be no guarantee that "normal"
testing will reveal the problem.

While anyone with even a trace of prudence will perform extensive tests, it
is unreasonable to suggest that these should be required to catch
manufacturers' gross failures to perform.



       Russell McMahon

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\10\30@193608 by Herbert Graf

flavicon
face
{Quote hidden}

       To each his/her own I suppose. You're right, I haven't been burnt, which is
what gives me a unique alternative point of view.

       All indications in the errata point to this flaw easily being caught in
"proper" testing, therefore testing which DIDN'T catch the flaw is obviously
flawed itself.

       Again, I'm looking at this from a completely different point of view. This
whole issue is, in the end, probably a good thing, it'll make people more
willing to accept that the PIC isn't perfect. TTYL

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\10\31@024636 by Wouter van Ooijen

face picon face
>         All indications in the errata point to this flaw
> easily being caught in
> "proper" testing, therefore testing which DIDN'T catch the
> flaw is obviously
> flawed itself.

They suggest 'statistical' testing with some 100 units for an
unspecified number of hours, presumably with an (equally unspecified)
perfect failure detection mechanism.

Now how does this apply to the project I just finished, where the
customer wanted 10 units, so I build 12 (one to get wrong, one for me to
keep for testing code changes, 10 for the customer). Am I required to
build 111 instead, build a perfect test rig, and test for a week or so
after each code change before releasing to my customer?

For a project like this (where development cost is much more important
than unit cost, at least initially - the customer might want 50 or 1000
units lateron) the 18F's are the PICs of my choice because they are much
easier to work with. But when unexpected trouble can pop up that offeset
all advantages.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\10\31@030742 by o-8859-1?Q?Tony_K=FCbek?=

flavicon
face
Olin Lathrop wrote:
<snip>
> I can understand an occasional screwup getting shipped.  It's a little
> harder to understand how something this blatantly busted ever made it out
> the door.  What really pisses me off, however, is that they apparently
> waited until they had fixed silicon in hand before admitting the problem.
> That's inexcusable.
<snip>

Yes I agree, and it's not the first time, this started around the time for the new gen
18Fxx and above. I (well me and my company) was bitten by the crossing half program
memory of the initial 18F452, we had to (to this date) replace about 100 units
already in service, some of those costs around $3000-$4000 to 'fix' ( there is govermenmt regulations/re-calibration/re-verification involved). I even haven't got
microchip (or atleast the local supplier) to get me new chips !
Also the other week I think I stumbled onto a new bug in the 18F452 (date code: 031129G),
it could still be my programmer(labtool48XP), but the evidence sofar points to an problem in the chip.
These settings:

;Program Configuration Register 5H
       ;a) data eeprom no code protect
       ;b) bootblock code protect 0x00000 - 0x00200
               __CONFIG    _CONFIG5H, _CPB_ON_5H & _CPD_OFF_5H

;Program Configuration Register 6L
       ;a) write protect 0x00000 - 0x07FFF
               __CONFIG    _CONFIG6L, _WRT0_ON_6L & _WRT1_ON_6L & _WRT2_ON_6L & _WRT3_ON_6L
;Program Configuration Register 6H
       ;a) data eeprom not write protected, boot block 0x000-0x1FF, configregs write protected
               __CONFIG    _CONFIG6H, _WRTC_ON_6H & _WRTB_ON_6H & _WRTD_OFF_6H
.
.

caused *any* ee write to fail (i.e. data not stored in eeram), bits and flags
were set correctly and no error flags were set, tha data just wasn't there.
(Trapped by an ee verify routine) Mind you these settings works flawlessly in the ICE2k the problem only arises
onboard the real chip.

Changing to these settings:
.
.
;Program Configuration Register 5H
       ;a) data eeprom no code protect
       ;b) bootblock no code protect 0x00000 - 0x00200
               __CONFIG    _CONFIG5H, _CPB_OFF_5H & _CPD_OFF_5H

;Program Configuration Register 6L
       ;a) write protect 0x00000 - 0x07FFF
               __CONFIG    _CONFIG6L, _WRT0_ON_6L & _WRT1_ON_6L & _WRT2_ON_6L & _WRT3_ON_6L
;Program Configuration Register 6H
       ;a) data eeprom, boot block 0x000-0x1FF, configregs not write protected
               __CONFIG    _CONFIG6H, _WRTC_OFF_6H & _WRTB_OFF_6H & _WRTD_OFF_6H

Made the write to eeram work.
Sofar I do not put blame on microchip as the programmer cannot be ruled out.

Anyone else seen this ?

/Tony

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\10\31@071045 by Peter Anderson

picon face
Tony,

I had a somewhat similar experience with writing to
the EEPROM on the PIC18F1320. (4 MHz).  All went well
when I was using the ICD2.

But when I programmed devices using other programmers,
the WARP13 and the Olimex PG2, my write verify routine
indicated between 5 and 1000 tries to write before it
was successful and for this product I resorted to
using the ICD2 as the programmer.  I suspect that
although I believe the config settings to be the same
on the ICD2, the WARP13 and the PG2, only the ICD2 is
writing them correctly.  It is disconcerting to find
that using one set of programmers, the write EEPROM
function doesn't work as anticipated (works
stubbornly) and yet when using another programmer, the
feature works.  BTW, everything else worked with all
programmers.

Another source of frustration.  I was using about 80
percent of the PIC18F1320.  If I added a few lines of
very simple code, the device would hang.  Of course,
this could be many things, but again, disconcerting
and I am inclined to steer clear of this device in the
future.

On the next design I used the PIC16F648A and it was a
real confidence lifter to have things work as
advertised (at so I think) and not be spending 80
percent of my time chasing what I think are device
problems.

Peter H Anderson, http://www.phanderson.com

--- Tony_K|bek <tony.kubekspamspam_OUTFLINTAB.COM> wrote:
{Quote hidden}

details.


__________________________________
Do you Yahoo!?
Exclusive Video Premiere - Britney Spears
http://launch.yahoo.com/promos/britneyspears/

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\10\31@074821 by Olin Lathrop

face picon face
Herbert Graf wrote:
>         To each his/her own I suppose. You're right, I haven't been
> burnt, which is what gives me a unique alternative point of view.
>
>         All indications in the errata point to this flaw easily being
> caught in "proper" testing, therefore testing which DIDN'T catch the
> flaw is obviously flawed itself.

True, but then again all testing if flawed in some way by that definition.
In most cases it is impossible to reproduce all conditions during testing.
Even when it is theoretically possible, it is usually prohibitively
expensive.  So in the end you do the amount of testing that is warranted
given the price of the product, its volume, and the cost of a failure.

When I'm developing firmware for a customer, I of course perform tests to
make sure the firmware reacts as it should in as many ways as is
reasonable.  In addition, I use knowledge of its structure to test it in
ways that exercise different blocks of code.  I want to make sure the
customer gets used to when we release code, it "just works".

However, we don't test specifically looking for devices not performing to
the manufacturers specifications, and we certainly don't test over the
full range of environmental conditions unless the customer specifically
asks for (and pays for) this.  This kind of testing can be quite
expensive, and is not done in the vast majority of products.

The problem with the 18F1320 is a good example.  I discovered the problem
during debugging.  The first symptom was that the unit wouldn't respond to
serial commands, although the conditions that caused this seemed to be
unpredictable.  Naturally I didn't start out suspecting the chip.  If I
remember right, it took over a day on a fixed price job to track down this
problem.  Eventually I could show that everything worked right when run at
20MHz, but not a 40MHz.  (Unfortunately 40MHz was needed to do all the
processing, so I had to switch to a 18F252 all for the same fixed price).

Note the lurking problem here.  Suppose the project only needed 20MHz in
the first place.  Everything may have appeared fine on my bench and in the
customer's hands, but 1 in 100 could have a flaky problem in the field.
Or maybe 1 in 10 flake out at higher or lower temperature.  The point is
that reasonable testing regimes given the nature of this product might not
have uncovered the PIC not performing to specifications.  Except in
extreme cases perhaps, who is reasonably going to spend the money worrying
about a PIC failing at 20MHz when it's rated at 40MHz?  In all cases I've
ever worked on that would be considered a generous margin.

Since March I had been considering the 18F1320/1220 20MHz devices.  I even
labeled the drawers they were in with "20MHz" to make sure they didn't
accidentally get used at higher speed.  I didn't know either until
yesterday that in fact they were only 4MHz devices.  I knew there was a
speed problem.  I had seen it at 40MHz and 32MHz but not at 20MHz.  2:1
seemed like enough margin.  It's only by pure luck that I didn't use one
of these chips at 10MHz in some project.  It's not clear to me at all that
reasonable testing would have uncovered at problem at 10MHz with the one
or two units I might use during testing and debugging.

------------------------

By the way, I was not sure what Microchip's reaction would be when I told
them their chip didn't run at full speed.  I was expecting a lot of
skeptisism and a response like "Yeah, yeah, let us know when you think the
sky is falling too".  To their credit and my great relief, my local FAE
took me seriously right form the start.  He gave me a PICdem board I could
put a test case on, and made sure it got sent to the right person in
Arizona.  About a month later I got confirmation that the engineer in
Arizona could reproduce the problem and agreed there was definitely
something wrong with the chip.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\10\31@080615 by Olin Lathrop

face picon face
Peter Anderson wrote:
> Another source of frustration.  I was using about 80
> percent of the PIC18F1320.  If I added a few lines of
> very simple code, the device would hang.

What clock rate were you running the 18F1320 at?

*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\10\31@083118 by

picon face
Hi.
I'v been developing an app using the 18F1220/1320 for some
time. I'm running at 8Mhz using INTOSC. Even if I havn't
seen anything suspicious yet, I still think I'll take
a second look at the "older" 18-series chips...
Damn, the 1220/1320 looked so good...
Jan-Erik.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\10\31@092519 by Olin Lathrop

face picon face
Jan-Erik Soderholm XA (TN/PAC) wrote:
> I'v been developing an app using the 18F1220/1320 for some
> time. I'm running at 8Mhz using INTOSC. Even if I havn't
> seen anything suspicious yet, I still think I'll take
> a second look at the "older" 18-series chips...
> Damn, the 1220/1320 looked so good...

When does the customer need to ship?  Perhaps you can continue developing
at 8MHz with the units you have now, then replace with B4 silicon for
production.  If you have a good relationship with your local FAE, you
might be able to get a few B4 parts for development very soon.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\10\31@095236 by

picon face
Olin Lathrop wrote:

> Jan-Erik Soderholm XA (TN/PAC) wrote:
> > I'v been developing an app using the 18F1220/1320 for some
> > time. I'm running at 8Mhz using INTOSC. Even if I havn't
> > seen anything suspicious yet, I still think I'll take
> > a second look at the "older" 18-series chips...
> > Damn, the 1220/1320 looked so good...
>
> When does the customer need to ship?

:-)

Well, the customer is, for the moment, actualy me.
I'm working on a little "thing" I'm hoping
to be able to sell some of. If not, it's been
an entertaining project anyway!

I'm making my *main* living on other things (for the moment at least).

Anyway, waiting for the new silicon might very well be an option.
I don't know any FAE, but maybe there is some estimate on when
the new silicon will be generaly available ?

Jan-Erik.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

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