Post by thread:[PIC] Basic MPASM Questions

I am looking at some of the code that came with the PICKit 2 to get a feel for what it's doing. This is with a PIC16F690 microcontroller. At the beginning we have: cblock 0x20 Delay1 ; Define two file registers for the Delay2 ; delay loop endc Assuming I read the datasheet right, looks like mpasm will assign two general purpose registers in bank 0 to Delay1 and Delay2. Later in the code, a delay loop uses decfsz on Delay1. It seems that for the code to work right, these two registers would need to initialize to either 0x00(rolling over to 0xFF on the decfsz before the zero test), or 0xFF. If it where to initialize to some random state, the result could be unpredictable - but perhaps that's not important as it should only affect the first time the delay loop is run, then the registers would be in a known state afterwards, methinks. My question, chiefly, is this: Does Microchip explicitly state what the value in the general purpose registers will be after power on? I haven't seen mention of it in the datasheet thus far. Thanks for any thoughts you may have. -- Paul Anderson VE6HOP spam_OUTwackyvorlonTakeThisOuTgmail.com http://www.oldschoolhacker.com "May the electromotive force be with you."

Paul Anderson wrote: > cblock 0x20 > Delay1 ; Define two file registers for the > Delay2 ; delay loop > endc > > Assuming I read the datasheet right, looks like mpasm will assign two > general purpose registers in bank 0 to Delay1 and Delay2. No, no, no !! It just creates to assembly constants with the values h'20' and h'21'. MPASM has *NO IDEA WHATSOEVER* that those two values actualy corresponds to two general purpose registers. h'20' and h'21' could mean just about anything... If you want real memory assignment, look up the RES directive (and relocatable code). > Later in > the code, a delay loop uses decfsz on Delay1. It seems that for the > code to work right, these two registers would need to initialize to > either 0x00(rolling over to 0xFF on the decfsz before the zero test), > or 0xFF. If it where to initialize to some random state, the result > could be unpredictable - but perhaps that's not important as it should > only affect the first time the delay loop is run, then the registers > would be in a known state afterwards, methinks. If the first loop *is* important, intialize them. If not, don't. > My question, chiefly, is this: Does Microchip explicitly state what > the value in the general purpose registers will be after power on? Yes they do. The values are "unknown". Jan-Erik.

On 02/10/2007, Paul Anderson <.....wackyvorlonKILLspam@spam@gmail.com> wrote: > My question, chiefly, is this: Does Microchip explicitly state what > the value in the general purpose registers will be after power on? I > haven't seen mention of it in the datasheet thus far. Thanks for any > thoughts you may have. I don't think the datasheet will have any information on this. Check the MPLAB Assembler documentation. Read about "UDATA" and "IDATA"-section identifiers. Shortly put; if you use variables in an IDATA-section, you are guaranteed that those registers will have an initial value of zero. -- - Rikard - http://bos.hack.org/cv/

> My question, chiefly, is this: Does Microchip explicitly > state what the value in the general purpose registers will be > after power on? I haven't seen mention of it in the > datasheet thus far. AFAIK they state explicitly that the RAM values are not defined. But I don't remember where. The RAM values are certainly not affected by a reset. My ZPL and the watchdog-temperature-sensor (who's was that?) depend on this. In the old days this was a frequently reported problem for windowed EPROM chip users: erasing and/or ambient light tended to clear (or set, I don't remember) the RAM, so code relying on this got unnoticed, but failed once it was burned in an OTP. Wouter van Ooijen -- ------------------------------------------- Van Ooijen Technische Informatica: http://www.voti.nl consultancy, development, PICmicro products docent Hogeschool van Utrecht: http://www.voti.nl/hvu

Hi Paul, There is a sample code in Mid-range MCU Family Reference Manual how to initialize the entire data memory (if you rely on initialized/cleared general purpose registers). It's up to you to decide which reset condition you would like to clear up your memory. Tamas On 10/2/07, wouter van ooijen <wouterKILLspamvoti.nl> wrote: {Quote hidden}> > > My question, chiefly, is this: Does Microchip explicitly > > state what the value in the general purpose registers will be > > after power on? I haven't seen mention of it in the > > datasheet thus far. > > AFAIK they state explicitly that the RAM values are not defined. But I > don't remember where. > > The RAM values are certainly not affected by a reset. My ZPL and the > watchdog-temperature-sensor (who's was that?) depend on this. > > In the old days this was a frequently reported problem for windowed > EPROM chip users: erasing and/or ambient light tended to clear (or set, > I don't remember) the RAM, so code relying on this got unnoticed, but > failed once it was burned in an OTP. > > Wouter van Ooijen > > -- ------------------------------------------- > Van Ooijen Technische Informatica: http://www.voti.nl > consultancy, development, PICmicro products > docent Hogeschool van Utrecht: http://www.voti.nl/hvu > > > > -

Hi. Rikard Bosnjakovic wrote: > On 02/10/2007, Paul Anderson <.....wackyvorlonKILLspam.....gmail.com> wrote: > >> My question, chiefly, is this: Does Microchip explicitly state what >> the value in the general purpose registers will be after power on? I >> haven't seen mention of it in the datasheet thus far. Thanks for any >> thoughts you may have. > > I don't think the datasheet will have any information on this. After checking a few datasheet, I'm not that sure myself either. Maybe they don't say anything explicitly about it. But for any practical uses they are unknown after a POR (power-on reset). Other ("soft") resets leaves them unchanged, but I'd not rely on them efter an BOR (brown-out reset). Jan-Erik.

----- Original Message ----- From: "Paul Anderson" <EraseMEwackyvorlonspam_OUTTakeThisOuTgmail.com> To: <piclistspam_OUTmit.edu> Sent: Tuesday, October 02, 2007 4:27 AM Subject: [PIC] Basic MPASM Questions <snip> > > My question, chiefly, is this: Does Microchip explicitly state what > the value in the general purpose registers will be after power on? I > haven't seen mention of it in the datasheet thus far. Thanks for any > thoughts you may have. > > -- > Paul Anderson > VE6HOP Paul, Section 6.3.1 of the PIC mid-range reference manual states, "GPRs are not initialized by a Power-on Reset and are unchanged on all other resets." So, while not explicitly stating what IS in there at power on, you can pretty much rely on the fact that, if it is really important, it will be something you don't want! Richard

Paul Anderson wrote: {Quote hidden}> I am looking at some of the code that came with the PICKit 2 to get a > feel for what it's doing. This is with a PIC16F690 microcontroller. > At the beginning we have: > > cblock 0x20 > Delay1 ; Define two file registers for the > Delay2 ; delay loop > endc > > Assuming I read the datasheet right, looks like mpasm will assign two > general purpose registers in bank 0 to Delay1 and Delay2. Later in > the code, a delay loop uses decfsz on Delay1. It seems that for the > code to work right, these two registers would need to initialize to > either 0x00(rolling over to 0xFF on the decfsz before the zero test), > or 0xFF. If it where to initialize to some random state, the result > could be unpredictable - but perhaps that's not important as it should > only affect the first time the delay loop is run, then the registers > would be in a known state afterwards, methinks. > > My question, chiefly, is this: Does Microchip explicitly state what > the value in the general purpose registers will be after power on? I > haven't seen mention of it in the datasheet thus far. Thanks for any > thoughts you may have. > > Microchip DOES so state power-up values in the spec sheets. For most variables, the value is unknown, so you should initialize them before use. --Bob A