@jpanhalt First of all, kudos on your industry and scholarship! And as you have demonstrated, it's not always easy to know what issues apply to a particular PIC, even after reading the errata.
My personal solution, for lots of reasons based on lots of experience is to always apply any fix / workaround to all chips. For example, my DI (disable interrupts) macro always does the loop and test regardless of the chip, even 18F. I don't know which, if any, of the later parts have the defect but I don't care. My view is that it's pointless to expend lots of research/test time when the fix is easy and well understood. I consider it cheap insurance.

Here are a few of my personal rules/observations gleaned from 25+ years of using PIC almost exclusively :
Avoid rev. Ax silicon.
Remember that errata is frequently incomplete.
uCHIP is frequently slow to get known bugs to errata - it really hacks me off when I spend day or two drilling down to a silicon bug, report it only to be told that 'Yeah we know. We gotta get that to the errata sometime'. They are prone to pencil-whip issues.
Just because they're on the same datasheet doesn't mean that the chips described have the same set of bugs.
Workarounds for hard to test/fix stuff (like the DI) are always incorporated from day one whether they are 'needed' or not. Belt and suspenders.
Always shadow the outputs on baseline/midrange.
Never bit-flip the TRIS registers on a port that shares peripherals.
Avoid outputs on PORTC when I2C is in use.
Remember that debug headers and emulators may also have or remove silicon bugs.

Just thinking out loud.

 

No, for the 16F's I believe the problem is fixed, though I still use the while loop just be sure. If it is fixed this only adds one test and one jump.

 

@JohnInTX Thank you for the compliment.

Sometimes, I like a challenge. What is the highest frequency in Tcy that one can call an interrupt, say using one of the timers? I am game to write a test for the "problem," but I will need a positive control. Is there any chip besides the 16C84 for which the problem has clearly been documented?

John

 

@John P Post #15) and

Finally, turning off the interrupts in this dog are not as simple as clearing GIE. You have to retest GIE and ensure that an interrupt did not occur during the bcf INTCON,GIE instruction. .

This may be nitpicking, but the recommended procedure is to re-clear GIE, not just retest it, until it is found on a single test to be clear. Simply retesting, such as "btfsc INTCON,GIE, bra $-1" does not solve the problem. The recommended sequence is

bcf     INTCON, GIE
btfsc   INTCON, GIE
bra     $-2                        ;not $-1
rest of code

John

 

@jpanhalt You're welcome - credit where credit is due. As for whether a given chip has the GIE - I don't know and I wouldn't rely solely on errata either. A quick glance at the Midrange Reference manual and the errata for the 16F886 is silent on the issue but the EEPROM write example in the '886 datasheet incorporates the loop fix with AN576 referenced. It's hard to know if the GIE issue is a silicon bug affecting some chips or an outright design error that can't be fixed. As I said, I just incorporate the workarounds for everything and move on. But if you want to mess with it, AN576 describes the problem and you can go from there. Good luck.

EDIT: your code above testing in a loop is what I do as well. Sorry if I didn't make that clear. Here are the macros I use. I avoid the $-x construct because different offsets are needed for 18F vs the others. Also, using a macro allows any chip-specific requirements to be handled while maintaining portability.

DI  macro
  local lup
lup
  bcf  INTCON,GIE
  btfsc  INTCON,GIE
  bra  lup
  endm

EI  macro
  bsf  INTCON,GIE
  endm

@R!f@@ Don't let these discussions discourage you. These things are manageable if you know about them and now you do. As for considering other PICs, the 18F is still my favorite of the 8 bit PICs. Enhanced midrange seems to be where things are going in the highly integrated mixed analog stuff and the wonderful -ME2 debuggers but they are not without their issues either. But by comparison, baseline and standard midrange fare poorly against either. Since you can get enhanced midrange in 10F sized and priced packages and up, I don't know why any new designs would use baseline/midrange.
Just my .02

 

I am not discouraged.
Just enjoying what you guys are talking about even somethings are just bouncing inside my brain.
No matter what it's all Good. Very informative.
Like you said I am planning to move to a 18F series.
I had to move to 40 pin from 28 pin one too. Customer said they might need to advance the project which means more peripherals.
I already had the schema drawn and was going to make proto on vero to start the coding but now I have to redesign the whole thing for a 40 pin one
Just gonna look into my stock to see what I have.

 

OK I got 18LF4550...Enough.
Questions.
1. 18F4550 and 18LF4550 are same. Right ? Just the "LF' can operate from 2 to 5.5V and 18F4550 operating at 5V?
2. I will need the serial port in the future.
It says, " Addressable USART module: - LIN bus support". I am new so like to ask if it can work as a normal USART to send "AT" Commands ?
3. I won't be using the all the peripherals in the PIC. Just USART, Two Timers and possibly 1 to 2 Analogs. And rest is all Digital IO's.
Will it be way different than a 16F ones that I have been playing with all my life ?

{ed}
One more thing...The F4550 has LAT Registers. What about shadowing them ? Like we did before.

 

1) I took a quick look at the datasheet and it looks like the main difference between LF and F is the Vdd range. Either will run at >4.2V.
2) No problemo. It works like the USART in other PICs. I think I have some MikroC code that provides interrupt-driven buffering both ways for the serial comms which you can have.
3) Not really, especially in C. There may be a few different names and/or additional registers to deal with but not a problem. I often hear how guys don't want to migrate to the 18F because its more complicated - and it does have some extra stuff. But the time it takes to master ALL of it is way less than the time it takes to compensate for the shortcomings of the lesser architectures IMHO. I started with the 18F when it was the 18C (long ago) and as I have said, I don't do any new stuff on midrange any more. I feel strongly enough about it that I have turned down jobs when clients insisted on a midrange when a comparable 18F would do. It's not that I don't understand midrange. On the contrary, I know midrange thoroughly inside and out and in this case familiarity breeds contempt. I also prefer 18F to Enhanced Midrange when I don't need all of the cool analog stuff. Just my .02 again.

 

Hmmm !

What about the shadowing ? I edited my post #27

 

No need. Write outputs to LATx. Read inputs from PORTx. Done.
EDIT: Same for enhanced midrange and in C its easy.

 

I knew you would have an answer for that

I checked the prices.....4550 is 3X the price of a 887 to me and the quantity I need is not small.
@JohnInTX
I know you like me to move and study it and believe I want to, but I need to factor in the price since the budget is fixed and am on a tight schedule. I believe I can do what needs to be done with a 16F887.
I need to consult this with my customer.
They might even dunno what a PIC is but believe me, they understand "$$"
I will get back tomorrow.
Thanks @JohnInTX

Thank you all.

 

I checked the prices.....4550 is 3X the price of a 887 to me and the quantity I need is not small.
@JohnInTX
I know you like me to move and study it and believe I want to, but I need to factor in the price since the budget is fixed and with limited. I believe I can do what needs to be done with a 16F887.
I need to consult this with my customer.
They might even dunno what a PIC is but believe me, they understand "$$"
I will get back tomorrow.

Thank you all.
TTFN.

Of course. The end cost matters. I should have qualified my comments with 'at comparable cost'. I'd be surprised if you couldn't find a suitable 18F in the range but if you can't, enhanced midrange is usually way cheaper feature for feature than the older midrange stuff. I just moved a some stuff of the '887 range to enhanced midrange and it was way cheaper. I'll look up the PNs I used.

EDIT: Do you need the USB of the 4550??

 

One more thing.....I cannot wait a month to buy a new PIC for a prototype.
18LF4550 & 16F887 is the only 40 pins I have at my disposal.
I believe I am the only one with so many PIC's in Maldives, limited as they may be.
The project landed on my Lap just like that, few days before I was about to leave to India

 

Umm ! No need for USB ...just the USART.

 

One more thing.....I cannot wait a month to buy a new PIC for a prototype.
18LF4550 & 16F887 is the only 40 pins I have at my disposal.
I believe I am the only one with so many PIC's in Maldives, limited as they may be.
The project landed on my Lap just like that, few days before I was about to leave to India

I guess that limits us to the 887 seeing as how the 4550 is too expensive. No worries then.
I would recommend that you write the code to be as chip-independent as possible, especially in the IO/peripherals. For example, rather than writing an output explicitly, write it as a function or macro (#define) with the IO function/macro in its own file. Something like
RA6.6 = 1; // turn on LED
becomes

LED_ON;

where LED_ON is a macro or function that might be a shadowed port operation for the '877 IO file or something that writes to LATx for enhanced mid/18F if you migrate later.

Either way, you can do it.
PS read you other post re: India. Good luck with that.

 

I am always using the method you taught me..
Using #define for everything...like ON, OFF, TOGGLE, PWM.
I like the shadow method...simple and effective...Just not the LCD port though. Shadowing causes LCD characters to go berserk.. .
Not a problem though cause I am always using PORTB for LCD and ICSP. Rest I shadow. Still I wonder why it drives the LCD mad ?

It's 1:40 am..Gotta sleep.
I will change the schema tomorrow.
Thank you @JohnInTX.
Good night.

 

@John P Post #15) and
This may be nitpicking, but the recommended procedure is to re-clear GIE, not just retest it...
John

You mentioned my post #15, but you've missed what's in it. I said:

#define GLOBAL_INT_DISABLE  intcon.GIE =  0
#define TEST_GIE intcon.GIE

   do {
       GLOBAL_INT_DISABLE;
   }  while(TEST_GIE);

It compiles to produce this in the List file:

;Tuout.c,480 ::      do
L_my_eeprom_write69:
;Tuout.c,482 ::      GLOBAL_INT_DISABLE;
0x0138   0x138B     BCF  INTCON, 7
;Tuout.c,483 ::      } while(TEST_GIE);
0x0139   0x1B8B     BTFSC  INTCON, 7
0x013A   0x2938     GOTO  L_my_eeprom_write69

As I said, always clear it once, maybe clear it more than once.