Post by thread:[PIC]Redesigning for 16F88 (instead of 16F84A)

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

>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

Also don't forget to set CMCON0 to 0x07 to turn off the comparators on PORTA Bill Wouter van Ooijen wrote: {Quote hidden}>>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 > > > >

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}>Also don't forget to set CMCON0 to 0x07 to turn off the comparators on PORTA > >Bill > >Wouter van Ooijen 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) >>> >>> >>> >>> >>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 >> >> >> >> >> >> > > >

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 :)

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

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

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

> 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

> 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

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

----- Original Message ----- > > Date: Mon, 3 Jul 2006 23:10:50 +1000 > From: "Josh Green" <spam_OUTthe_real_yoshiTakeThisOuThotmail.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

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

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

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.

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