poking stuff....poke command that is :)
- Thread starter 212
- Start date
westaust55
Moderator
PEEK and POKE commands work on registers and memory in the SFR (special fucntion register area).
I have generated a list covering a lot about memory and variables for the PICAXE microcontrollers. Started life mainly for the 40X1 but became an expanded project.
Have a look at: http://www.picaxeforum.co.uk/showthread.php?t=9525
Hippy also has some lists on another thread. Suggest you try a search for SFR (may need to use SFR* )
Also suggest that you have a look at the specific PIC microcontroller datasheet from the microchip website for the PICAXE you using.
I have generated a list covering a lot about memory and variables for the PICAXE microcontrollers. Started life mainly for the 40X1 but became an expanded project.
Have a look at: http://www.picaxeforum.co.uk/showthread.php?t=9525
Hippy also has some lists on another thread. Suggest you try a search for SFR (may need to use SFR* )
Also suggest that you have a look at the specific PIC microcontroller datasheet from the microchip website for the PICAXE you using.
medvampire
New Member
How bad can I screw up the chip using peek?
poke?
Can I change the bootstrap and kill the down load?
How do I revert back to the stock values if I have poked new values.
Steve
poke?
Can I change the bootstrap and kill the down load?
How do I revert back to the stock values if I have poked new values.
Steve
westaust55
Moderator
Using PEEK and POKE
POKE'ing into the registers used by the BASIC interpreter will chage SFR data which may cause disruption to a running program, will likely case the program to act incorrectly unless you are careful with what you are doing and at the worst may require a hardware reset to get control of the PICAXE (and change your program to correct the “offending” poke command).
If you have read the documentation and know what you are doing (using information from others threads), then you can modify a timer or IO safely.
PEEK'ing is only looking as the name implies. That will never cause problems.
POKE'ing into the registers used by the BASIC interpreter will chage SFR data which may cause disruption to a running program, will likely case the program to act incorrectly unless you are careful with what you are doing and at the worst may require a hardware reset to get control of the PICAXE (and change your program to correct the “offending” poke command).
If you have read the documentation and know what you are doing (using information from others threads), then you can modify a timer or IO safely.
Not always true, reading (peeking) some special system registers will alter the code operation.
westaust55
Moderator
Ah yes, so true, Technical.
I recall now reading that in some PIC's at least, there is a feature that if a location is modified will erase the entire PICAXE. Not just the BASIC program but also the BASIC interpreter that Rev.Ed. install. Part of a protection schem and no double there are others with less disasterous results.
Just gotta learn to remember all that I have read all the time!
I recall now reading that in some PIC's at least, there is a feature that if a location is modified will erase the entire PICAXE. Not just the BASIC program but also the BASIC interpreter that Rev.Ed. install. Part of a protection schem and no double there are others with less disasterous results.
Just gotta learn to remember all that I have read all the time!
hippy
Ex-Staff (retired)
There are three PEEK and POKE possibilities; to general purpose RAM ($50-$7F,$C0-$FF) which is entirely safe, of firmware data ($20-$4F,$A0-$BF) and of the Special Function Registers ($00-$1F,$80-$9F) both of which can alter firmware and/or chip configuration.
There are a few locations of firmware data which are safe to POKE but beyond those doing so can lead to bad things happening. PEEK is safe in that area.
For POKE to SFR one needs to refer to the applicable PICmicro datasheet. PEEK is generally safe but it does depend on what is being accessed.
There are a few locations of firmware data which are safe to POKE but beyond those doing so can lead to bad things happening. PEEK is safe in that area.
For POKE to SFR one needs to refer to the applicable PICmicro datasheet. PEEK is generally safe but it does depend on what is being accessed.
medvampire
New Member
I can see I have a lot to learn before I go poking around these chips
but I will have to take a few peeks here and there
Thanks for the info.
Steve
but I will have to take a few peeks here and thereThanks for the info.
Steve
Re "I recall now reading that in some PIC's at least, there is a feature that if a location is modified will erase the entire PICAXE."
- if that is true then someone doing a POKE in a loop might hit it anyway?
So, can Technical please confirm this?
It would be a good idea if a list/range of POKEs were published - inlcuding 'prohibited' ones. It is then up the user if he/she/it/teacher wishes to muck it up.
Would it not be a good idea for the compiler to refuse access to any 'dangerous' ones?
And, of course, for more info about registers (GPRs and SFRs) look in the appropriate PIC Data Sheet.
- if that is true then someone doing a POKE in a loop might hit it anyway?
So, can Technical please confirm this?
It would be a good idea if a list/range of POKEs were published - inlcuding 'prohibited' ones. It is then up the user if he/she/it/teacher wishes to muck it up.
Would it not be a good idea for the compiler to refuse access to any 'dangerous' ones?
And, of course, for more info about registers (GPRs and SFRs) look in the appropriate PIC Data Sheet.
westaust55
Moderator
Had another quick look at the datasheet for the 40X1. Recall some other PICs are the same (maybe different addresses).
The feature is part of the security or Code Protection Microchip provide to help people and companies protect their code. Aim is to stop people from copying the likes of Rev Eds code using say a PIC programmer to read the code in the chip.
From the datasheet:
The feature is part of the security or Code Protection Microchip provide to help people and companies protect their code. Aim is to stop people from copying the likes of Rev Eds code using say a PIC programmer to read the code in the chip.
From the datasheet:
So I presume that those doing peeks and pokes will never get into so much trouble as to totally earase their PICAXE's. May cause a crash but nothing too fatal.
hippy
Ex-Staff (retired)
I think we have that already with the "only poke to the $50-$7F and $C0-$FF" range in the manual. I haven't checked to see what it exactly says.
It could curtail lots of fun hacking and would also have to be done in firmware rather than in the compiler, this could be quite easily trapped as an error by the compiler -
- POKE $00,$FF
but this couldn't and it does exactly the same thing -
- b0 = b0-b0
- b1 = b0-1
- POKE b0,b1
If any limitation were added ( as with "HIGH pin1" being trapped ) I'd want to see a good argument for doing so and an ability to over-ride the option within the programming Editor.
Alright then, replace "prevent" with "warn". And, of course, many things are circumventable. I was just thinking of Newbies rather than experienced old lags.
True, things are mentioned in the manual. Sadly, they don't get read much and there are such things as typing mistakes, forgetting $ and things that I have seen 18 zillion times on the Forum.
Second thoughts: do nothing. Anyone can argue black is white.
"and it does not like me to poke things" - your mamma should have told you
True, things are mentioned in the manual. Sadly, they don't get read much and there are such things as typing mistakes, forgetting $ and things that I have seen 18 zillion times on the Forum.
Second thoughts: do nothing. Anyone can argue black is white.
"and it does not like me to poke things" - your mamma should have told you
Last edited:
No peeks will delete the firmware (as far as we are aware, but some SFR are undocumented in the Microchip datasheets).
However on some parts peeking some addresses can affect the program (e.g. peeking the serial receive buffer will mark it as 'read' in the PIC and could therefore affect the operation of hserin)
However on some parts peeking some addresses can affect the program (e.g. peeking the serial receive buffer will mark it as 'read' in the PIC and could therefore affect the operation of hserin)