Post by thread:[PIC:] 18F1320 speed problem admitted

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

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

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

> 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

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

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_piclistTakeThisOuTEMBEDINC.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

Thats nothing; what about someone that might of fielded these processors? (no not me) ----- Original Message ----- From: "Herbert Graf" <.....mailinglistKILLspam@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

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

> -----Original Message----- > From: Herbert Graf [mailinglistKILLspamFARCITE.NET] > Sent: 30 October 2003 15:16 > To: .....PICLISTKILLspam.....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_OUTTakeThisOuTbookham.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

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

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

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

> 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

> 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

> 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

> 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

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

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

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

> 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

{Quote hidden}> > 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. 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

> 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?=

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

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.kubekspam_OUTFLINTAB.COM> wrote: {Quote hidden}> 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. __________________________________ 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

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

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

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

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

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...