Searching \ for '[PIC]Redesigning for 16F88 (instead of 16F84A)' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: techref.massmind.org/techref/microchip/devices.htm?key=16F
Search entire site for: 'Redesigning for 16F88 (instead of 16F84A)'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]Redesigning for 16F88 (instead of 16F84A)'
2006\07\03@070528 by Josh Green

picon face
Hello everyone,

I'm having some issues in porting my project from a 16F84A to work with
a 16F88.
The code compiles fine, and the chip gets programmed fine. But when I
plug it into the circuit
It goes haywire, ie. The LCD screen it is supposed to control goes
crazy, I have LED's running on these data lines and they go crazy as
well

What it should be doing:
Using the 16F84A the LCD displays menus that can be navigated using a
keypad also attached to the LCD's datalines. This all works GREAT, but I
need to expand the program and hence need to upgrade to the 16F88.

The only things on the 16F84A that I use are:
PORTA/B
Timer0

All other things are switched off, including watchdog timer.

Has anyone got any ideas of things that I may have missed in the
differences between the 88 and 84A?
I'm guessing it's something that I havn't initialised properly

Any ideas are welcomed! Thanks everyone

--Josh

2006\07\03@073424 by Alan B. Pearce

face picon face
>Has anyone got any ideas of things that I may have
>missed in the differences between the 88 and 84A?
>I'm guessing it's something that I havn't initialised properly

Turned off the analogue inputs on Port A?

2006\07\03@074933 by Josh Green

picon face
>Turned off the analogue inputs on Port A?

Ah, I remember something about this before..
I've set the ANSEL register to 0, that should so it I believe. And now
SOMETIMES a readable message shows on the screen!

I'm noticing now that it's actually resetting itself, (as it is the
initial message that comes up, then flashes around and comes back) (as
if the watch dog was resetting it)

But the 16F84A had no issues like this..

I've tried disabling the Brown out circuit... But this shouldn't be
activating because the power rails are steady at 4.93V
The master reset has been tied to the positive rail through a 10k
resistor

Thanks, that's got me moving forward :D
More ideas? Do I have to enable pull-ups in the chip at all?

--Josh

2006\07\03@083423 by Wouter van Ooijen

face picon face
> I'm noticing now that it's actually resetting itself, (as it is the
> initial message that comes up, then flashes around and comes back) (as
> if the watch dog was resetting it)

so I guess you did check and double-check your watchdog setting? (not
just in the source code, readback and check the hex value in the chip).

Wouter van Ooijen

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


2006\07\03@084135 by William Bross

picon face
Also don't forget to set CMCON0 to 0x07 to turn off the comparators on PORTA

Bill

Wouter van Ooijen wrote:

{Quote hidden}

2006\07\03@084715 by William Bross

picon face
Sorry... I'm awake now.  F88 defaults to 0x07, F688 defaults to 0x00, so
this shouldn't be the problem.
Bill

William Bross wrote:

{Quote hidden}

2006\07\03@084902 by Maarten Hofman

face picon face
>
> I'm having some issues in porting my project from a 16F84A to work with
> a 16F88.


You're sure you want to use the 16F88 and not the 16F648A, which is "closer"
to the 16F84A in some ways (with a known and documented migration path), not
as expensive, and has less of these peripherals that you're not using
anyway?

Greetings,
Maarten Hofman.

2006\07\03@091022 by Josh Green

picon face
I've tried some more things and put in delays into the code...
The delays seem to fix up the LCD display a bit. So perhaps the 16F88 is
faster than the 16F84A (even though they are on the same crystal?)

The system still restarts though.

Wouter>

I've triple-triple checked the Watch dog timer, hehe
I am using IC-Prog, and the setting is definitly OFF, when I read it
back it also is off, the config word is 0x3FEA

I've also explicitly set SWDTEN = 0 to disable the watchdog timer from
software

I have tried disabling every interupt I can (without losing the timer0
interupt) by doing the following:
RBIE =0; //Disable change on port B interupts
INT0IE =0; //Disable external interupt pin
PEIE = 0; //Disable peripheral interupts
TMR0IE = 1; //Enable TMR0 interupt
GIE = 1; //Enable all selected interupts

William>

And I've just tried the
CMCON = 0x07, even though you did mention it shouldn't do anything..
Which it didn't, thanks for the input though.

Maarten>

Yeah, I'm pretty sure I want to use the 16F88, mainly because I want to
be able to expand into using the UART functionality of it later.
At the moment, I just want to get the original code working on it and
stable.
Thanks for pointing out the other one though, I didn't know of that
option

I'm sooo lost on this one :S

Thanks all, more thoughts?

I've posted the code on my uni site if anyone has the time to go through
it... I can't see anything wrong with what I'm doing
But then again, I havn't been doing this stuff for long either!
http://www.ug.it.usyd.edu.au/~jgre5893/pic/

--Josh

Ps -- This doesn't have anything to do with my uni work, so don't worry
you aren't doing assignments for me, The uni just provides a wonderful
FREE place to put a webpage :)

2006\07\03@100925 by Josh Green

picon face
I've just tried checking the bits in the POR, BOR TO and PD

It would seem that the system is waking from a "WDT Wake-up"...
But it is definitly disabled.

I'm going insane I think :S

Any ideas?
--Josh

2006\07\03@130423 by Jan-Erik Soderholm

face picon face
Josh Green wrote :

> It would seem that the system is waking from a
> "WDT Wake-up"... But it is definitly disabled.

Problem is that you have to prove that for us... :-)

Why do you belive that WDT is "definitly disabled" ?

And what sign do you see that makes you think that
it actualy *is* waking up from WDT-reset ?

Regards,
Jan-Erik.



2006\07\03@184347 by Josh Green

picon face
Problem is that you have to prove that for us... :-)

Why do you belive that WDT is "definitly disabled" ?

And what sign do you see that makes you think that
it actualy *is* waking up from WDT-reset ?

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

Yeah, I know, I've been trying to prove it to myself as well
I have the following code in my initialise routine now:
       msg = "Unknown";
       //What caused the reset?
       if(!POR == 0){
               if(!TO == 0)
                       msg = "Illegal";
               else if(!PD == 0){
                       msg = "Illegal";
               }else{
                       msg = "Power On";
               }
       }else{
               if(!BOR == 0){
                       msg = "Brown OUT!!";
               }else{
                       if                (!TO == 0 && !PD == 1){
                               msg = "WDT Reset";
                       }else if(!TO == 0 && !PD == 0){
                               msg = "WDT Wake up";
                       }else if(!TO == 1 && !PD == 0){
                               msg = "MCLR wake in slp";
                       }else{
                               msg = "Guess MCLR Norm";
                       }
               }
       }
       lcd_printf(msg);

Now, according to page 134 of the PIC16F88 datasheet, the values above
reflect the different types of restart.

I have specifically set SWDTEN = 0, (as can be seen in
http://www.ug.it.usyd.edu.au/~jgre5893/pic/main.c : line 134)
I have tried SETTING the WDT config code (instead of clearing it) and
this just made things worst. I cleared the code and
Now the config word reads back as 0x3FCA, WDTEN is in bit 2, A = 1010
(as you all know) and so WDTEN = 0.

I don't know how I can prove it better...
My only thought is that in the status bits describing the reset flags
are all active low in the table... Perhaps I've converted
This table incorrectly into code.

Also, the MCLR reset during normal operation reset, doesn't seem to be
distinguishable from the other resets?
So perhaps it is that... But I have also tried clearing the MCLR config
bit, so there is NO MCLR pin to worry about. Still
No luck.

I've also tried using a completely separate chip (incase the chip is
faulty) and I got the same results...

I'm soo confused now

--Josh


2006\07\03@184555 by Jim Robertson

flavicon
face

>
>I've just tried checking the bits in the POR, BOR TO and PD
>
>It would seem that the system is waking from a "WDT Wake-up"...
>But it is definitly disabled.
>
>I'm going insane I think :S
>
>Any ideas?
>--Josh

The 16C84 GP. ram starts at 0xC and the 16F88 GP ram starts at 0x20 as it
has a number of important SFRs mapped between 0xb and 0x20.

You've said nothing about the changes you've made. Did you change the
ram assignments?

Regards,

Jim



2006\07\03@190605 by Josh Green

picon face
I'm using MPLAB IDE, and the PICC compiler so they should be making
those changes for me.
The only change I made to the original code to make it compile was:

T0IE --> TMR0IE
T0IF --> TMR0IF

According to the mapfile:

Bank 0 RAM $0020 - $005B (60 bytes)
Bank 0 RAM $0070 - $0074 (5 bytes)
                              (65 bytes) total Bank 0 RAM

So it appears to be in the right place.

Thanks

Would the PIC reset itself if it got some form of overflow or something?

--Josh

>The 16C84 GP. ram starts at 0xC and the 16F88 GP ram starts at 0x20 as
it has a number of important SFRs mapped between 0xb and 0x20.
>You've said nothing about the changes you've made. Did you change the
ram assignments?
>Regards,
>Jim

2006\07\03@191829 by olin piclist

face picon face
Josh Green wrote:
> I'm having some issues in porting my project from a 16F84A to work with
> a 16F88.
>
> ...
>
> The only things on the 16F84A that I use are:
> PORTA/B
> Timer0

Then why not the cheaper 16F648A instead of the 16F88?

> Has anyone got any ideas of things that I may have missed in the
> differences between the 88 and 84A?

The usual suspects:

1 - Used CBLOCK and absolute mode to define variables.  Don't do that.  This
is one good reason why.

2 - Code doesn't check for existence of analog peripherals and initializes
them to disabled.  Always do this.  Since it's done with assembly time
checks, it results in no additional code on a PIC without an analog
peripheral.  If you do want to use an analog peripheral, you set it up and
enable it as desired later in the module that handles that peripheral.

3 - Bad banking, like manually setting RP0 and RP1 instead of letting the
assembler figure out the right bank.  Don't do that.  This is one good
reason why.

Unfortunately most free code out there exhibits all these bad programming
practises.  Remeber, any bozo can put up a web page, and too many do.


******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2006\07\03@192042 by olin piclist

face picon face
Josh Green wrote:
> I'm noticing now that it's actually resetting itself, (as it is the
> initial message that comes up, then flashes around and comes back) (as
> if the watch dog was resetting it)

I forgot to mention #4.  Always re-examine the config bits carefully when
moving code between PICs.  Always assume they are totally different.


******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2006\07\03@192532 by olin piclist

face picon face
Josh Green wrote:
> Yeah, I'm pretty sure I want to use the 16F88, mainly because I want to
> be able to expand into using the UART functionality of it later.

But that makes no sense, since both the 16F88 and 16F648A have a UART.

******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2006\07\03@194734 by Josh Green

picon face

>But that makes no sense, since both the 16F88 and 16F648A have a UART.

I couldn't find this earlier, but upon second look, it does, which
you're right, there is no reason for me to use the F88
Other than the fact that I have one. And I can't find any sources to get
one at this short notice, though I will order some

Meanwhile, where can I find this "documented migration path" from 84A to
648A?

Any other ideas why this F88 hasn't worked?

Thanks everyone
--Josh

2006\07\03@212223 by John Chung

picon face
> 3 - Bad banking, like manually setting RP0 and RP1
> instead of letting the
> assembler figure out the right bank.  Don't do that.
>  This is one good
> reason why.
>
 I agree when you are writing a library code. But if
the environment is fix at a particular bank setting
RP0 and RP1 does make sense sometimes. Best bet it is
use macro to eliminate unwanted instruction like the
extra pagesel or banksel. But for testing and in the
development. Use pagesel and banksel for the variables
to NOT cause a headache to ensure that it gets the
variable correctly. Once the code needs trimming than
you have to revisit your work if it is feasible to cut
the redundant ins. In short, directly setting RP1 and
RP0 in you code src is like specific the req bank and
does not allow adjusting the bank unless you change
all your bank settings again.......

john

 

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

2006\07\04@033711 by Alan B. Pearce

face picon face
>Any other ideas why this F88 hasn't worked?

Is it supported by the compiler? You are using a C compiler, but I haven't
been through the code you posted to check if you have selected the correct
chip.

To determine if it really is the watchdog resetting the chip, try setting
the timer prescaler to the watchdog, and setting it for the maximum divide
ratio. IIRC on the F88 this is quite a long time (several minutes I think).

2006\07\04@060306 by WH Tan

picon face
> Yeah, I know, I've been trying to prove it to myself as well
> I have the following code in my initialise routine now:
>        msg = "Unknown";
>        //What caused the reset?
>        if(!POR == 0){
>                if(!TO == 0)
>                        msg = "Illegal";
>                else if(!PD == 0){
>                        msg = "Illegal";
>                }else{
>                        msg = "Power On";
>                }
>        }else{
>                  .....

Hello Josh,

The logic here seems to be wrong.

When the PIC power on for the first time, it's true that /POR bit will
be cleared.  But you have to set it immediately (inside the true
branch of if).  If the next reset is due to other cause than POR, then
PIC will see /POR set, which will tell that the last reset is not POR
but any other reset.  If you didn't do that, for all kind of reset,
the code execution will enter the true branch because the PIC won't
set /POR bit for you.

Inside that branch, you might need to set/clear other reset flags,
depend on whether you want to monitor that particular reset.  On top
of my head, I can't remember all those things and you have to refer to
the data sheet.  Another thing is that I haven't worked with the reset
detection logic of F88 but have been working for other processor.  I
am not sure if the logic will be the same across different processor.

Hope this helps.


Best regards,

--
WH Tan

2006\07\04@104723 by olin piclist

face picon face
John Chung wrote:
> I agree when you are writing a library code. But if
> the environment is fix at a particular bank setting
> RP0 and RP1 does make sense sometimes.

I strongly disagree.

First, it has nothing do to with library versus other code.  Both need the
banks set correctly.  You are somehow saying that it's OK in your app to
sometimes have the bank wrong, but not in library code?  This makes no
sense.

But the main point is that manually setting the bank is just plain bad
programming.  You have to look up what bank the location you want to address
is in, then set the RP0,RP1 bits accordingly.  That leaves three
possibilities for human error.  BANKSEL does the same thing, but is
guaranteed to always work.

If you try to get cutesy and set only one of the RP0,RP1 bits then you've
added an additional assumption about what bank was previously set.  That
provides another way to screw up.  This is by far the worst because it
depends on earlier code, and in execution not source code order on top of
that.  A minor change to one section of code can suddenly make a later
section fail.  This is just asking for a bug.

> But for testing and in the
> development. Use pagesel and banksel for the variables
> to NOT cause a headache to ensure that it gets the
> variable correctly.

That is a guarantee reliable way to set the banks, although it can result in
redundant instructions.  Newbies should start out with BANKSEL in front of
just about every reference.  Once you get more familiar with PICs and other
confusions are out of the way, there are better ways to manage banks.

> Once the code needs trimming than
> you have to revisit your work if it is feasible to cut
> the redundant ins.

I don't think it's a good idea to go back over code later to remove
sloppiness, add comment, or change the bank setting instructions.  Code
should be written the right way for the intended use up front.  Newbies
should put BANKSEL in front of any banked reference and be done with it.
Once someone gets to the point of caring about execution speed and memory
size, they aren't newbies anymore and are ready for more sophisticated bank
management.

However, this does not mean manually setting RP0,RP1 exept for highly
exceptional conditions.  I use my DBANKIF and related macros in
STD.INS.ASPIC at http://www.embedinc.com/pic.  I think a few others have
created similar constructs.


******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2006\07\04@143041 by John J. McDonough

flavicon
face
----- Original Message -----
>
> Date: Mon, 3 Jul 2006 23:10:50 +1000
> From: "Josh Green" <spam_OUTthe_real_yoshiTakeThisOuTspamhotmail.com>
> Subject: RE: [PIC]Redesigning for 16F88 (instead of 16F84A)

> I have tried disabling every interupt I can (without losing the timer0
> interupt) by doing the following:
> RBIE =0; //Disable change on port B interupts
> INT0IE =0; //Disable external interupt pin
> PEIE = 0; //Disable peripheral interupts
> TMR0IE = 1; //Enable TMR0 interupt
> GIE = 1; //Enable all selected interupts

Since you are evidently using the timer interrupt, you can't turn off GIE,
so you MUST disable or handle all the other sources of interrups.  The 16F88
datasheet says "The PIC16F87/88 has up to 12 sources of interrupt.".  I
don't count 11 things you have disabled.  A stray interrupt could cause the
sort of behavior you describe. (Most of those 11 probably default to
disabled, but check anyway!)

Another poster pointed out that you don't want to just arbitrarily disable
all the analog peripherals.  If you have a pin which COULD be analog, and
you leave that pin floating, or at some intermediate value, and you have
defined the pin as a digital input (i.e. disabled the analog and NOT made it
an output), then the pin could draw excessive current.  This can even
potentially damage the chip, but depending on your supply, could also simply
cause erratic operation.  This is why those analog pins default to analog.

Several posters suggested the 648A instead of the 88.  There are quite a
number of 18 pin alternatives, also the 818/819, 716, 628A and on and on.
The 88 is a very capable part, far more capable than the 648A, and from
hobbyist sources, it is only barely more expensive than the 648A.  It's hard
to think of the 88 as expensive when it costs half what an 84A costs.  Sure,
if you are going to buy a few hundred thousand of them, the extra few cents
matters, but when the shipping costs twice what the part costs, why save a
few pennies (well, OK, maybe 50 cents) and get a less flexible part?  $2.60
is hardly going to break the bank.

I've used 88's as F84 replacements with few issues.  I'm sure there is
something terribly obvious, but when you are using a compiler, if the
compiler doesn't handle all the issues for you, then uncovering them can be
a bit of a challenge.  People say that the compiler lets you move between
parts more easily, and perhaps after you've done it a few dozen times that
might be true.  But until you -really- understand what the compiler is doing
to you, you always need to be suspicious that something is happening that
you aren't aware of.

I would compare the emitted code between the 84 and 88 and look for anything
suspicious.  In particular watch for places where the registers are in
different locations between the processors.  It is quite possible that the
compiler hasn't been all that well tested on all parts ... there are a LOT
of possibilities.

--McD

2006\07\04@222813 by John Chung

picon face
{Quote hidden}

 This part I agree strongly! Page movement in
development is like an earthquake!



>
> However, this does not mean manually setting RP0,RP1
> exept for highly
> exceptional conditions.  I use my DBANKIF and

 There are exception BUT should not be sprinkled
around in the code...... Heck is it an art to
determine whether it is an Exceptional case.

> related macros in
> STD.INS.ASPIC at http://www.embedinc.com/pic.  I
> think a few others have
> created similar constructs.
>
 I will check it out.

Thanks,
John

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

2006\07\05@065949 by olin piclist

face picon face
John Chung wrote:
> This part I agree strongly! Page movement in
> development is like an earthquake!

I don't understand your point since we were talking about banks, not pages.
Handling code moving between pages is another separate issue.  I deal with
this by making each page a separate linker section so that code from any one
code section can not straddle a page boundary.  I then use plain GOTO and
CALL inside a code section, and deal with PCLATH setting to anything
outside.  This is handled in my MCALL, GCALL, and GJUMP macros.

>> However, this does not mean manually setting RP0,RP1
>> exept for highly
>> exceptional conditions.  I use my DBANKIF and
>
> There are exception BUT should not be sprinkled
> around in the code...... Heck is it an art to
> determine whether it is an Exceptional case.

Again your point is not clear.  It sounds like you are agreeing with me
sortof.  What I meant by "highly exceptional" conditions are those that
rarely if ever come up.  I can't remember a single case where I manually set
RP0 or RP1.  Here is a clearer statement: Don't do that.


******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2006\07\05@085125 by Maarten Hofman

face picon face
Several posters suggested the 648A instead of the 88.  There are quite a
> number of 18 pin alternatives, also the 818/819, 716, 628A and on and on.
> The 88 is a very capable part, far more capable than the 648A, and from
> hobbyist sources, it is only barely more expensive than the 648A.  It's
> hard
> to think of the 88 as expensive when it costs half what an 84A
> costs.  Sure,
> if you are going to buy a few hundred thousand of them, the extra few
> cents
> matters, but when the shipping costs twice what the part costs, why save a
> few pennies (well, OK, maybe 50 cents) and get a less flexible
> part?  $2.60
> is hardly going to break the bank.


The reason why I suggested the 16F648A is because there are several on-line
resources (including previous posts to this list) that give a step-by-step
plan on how to change a 16F84A program into one for the 16F648A. As far as I
know, no such resource exists for the 16F88. I agree that the 16F88 has an
A/D converter, but when going from 16F84A to 16F88 such an A/D converter
might actually complicate things. The 16F88 is a much better candidate as a
general purpose PIC, but migrating from 16F84A is not "general purpose".
Note that the 16F648A DOES have an AUSART, so the original poster's desire
for a serial port would be satisfied with the 16F648A as well. I'm glad you
pointed out the other PICmicros, though I would not usually differentiate
between the 16F648A and the 16F628A.

Greetings,
Maarten Hofman.

2006\07\05@120221 by John Chung

picon face
> >> However, this does not mean manually setting
> RP0,RP1
> >> exept for highly
> >> exceptional conditions.  I use my DBANKIF and
> >
> > There are exception BUT should not be sprinkled
> > around in the code...... Heck is it an art to
> > determine whether it is an Exceptional case.
>
> Again your point is not clear.  It sounds like you
> are agreeing with me
> sortof.  What I meant by "highly exceptional"
> conditions are those that
> rarely if ever come up.  I can't remember a single
> case where I manually set
> RP0 or RP1.  Here is a clearer statement: Don't do
> that.
>
Okay, to clear things up I do agree with your
statement. Next time I will be more direct :) Page and
bank handling can be deadly when not handled
properly*I am in agreement with how you handle them*.


John


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

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