Possible Picaxe Software Problem?

BillBWann

Member
I have an 08M2 picaxe that is acting quite strangely and I’m starting to think it’s a problem with the picaxe and not me. I know the odds are against me but ...

The attached is a slight variant of a program that I’m currently using to monitor a water meter fitted with a reed switch that opens after every ½ a litre of flow. The version currently operating suffers from the occasional random reset every few days (which I can live with) but the attached one should reset within 8 minutes. The difference between the two versions is line 181 (nap 2) has been commented out and the HC-12 sleep test in the SleepMod subroutine has been altered so that the program can run on an 08M2 that isn’t connected to an HC-12 transceiver - so you can check it out.

The program simple transmits some numbers (incremental pulse counter and battery voltages) every time the reed switch in the meter opens. It also periodically checks that the 2 * 25 mA solar panels aren’t overcharging the battery and if the battery voltage is high, it doesn’t put the HC-12 to sleep.

The program worked fine while I was simulating water meter reed switch pulses for high flow rates through the meter using a relay and another 08m2 but when I was checking for periods of no water use, the program kept continually resetting while the relay was open but not when it was closed. And the resetting was occurring at regular precise times (about every 14 minutes). I initially suspected it was something to do with my periodic battery overvoltage checking although I wondered how that could ever get the program to reset.

Anyway, I played around with a number of things trying to isolate the problem and changed a few things and added sertxd statements at various points in the program. Making these changes sometimes made the problem disappear and other times changed the resetting period. For example, changing the nap period in the section of code where its looping around step 9, from “nap 3” to “nap 2” halved the reset period down to a regular 7 minutes while changing it to “nap 1” made a problem disappear as did substituting 2 lots of “nap 2” (which is the version I’m currently using). Also adding a sertxd as it entered the bit of code that checks for battery over-voltage in step 9 stopped the resets.

I don’t think its hardware related as I’ve tried it on a couple of 08M2’s with different power supplies and the behaviour is the same. I had a similar problem way back in early 2007 soon after I first used an 08m2. Then it involved the use of the sleep command which caused the 08m2 to restart at fixed intervals – just like this present case. I wrote to the forum about it and you fixed it. I can’t refer to that thread as they don’t go back that far. I just wondered if the” nap” command had anything to do with it. Certainly, changing it to “pause” appeared to stop the restarts but as I say, other program changes that I would have thought should have no effect on the restarts also stopped it. I’d prefer to use “nap” in order to minimize power use as in winter, solar input could be quite low.

I’m using PE5 (version 5.5.5) as I’ve not got around to upgrading to PE6. I realize that you regard PE5 as obsolete but hopefully you’ll still consider this problem.

Actually, it looks like I can't include the code here as it make the submission too big so I'll send it in the next post.
 

BillBWann

Member
Here is a version of the program that dosn't need an HC-12 to be attached that you can test to see if you get the same result as I got.

Code:
#rem
This version includes a check for high battery voltages which are periodically done in steps 2 & 9.

This program initially displays (@19200 baud) its set-up mode
Start
BPTR=61
OK+B9600
OK+RC001
OK+RP:+20dBm

1.	Initialize
2.	Raise pullup on c.4; Readadc C.4 and reset c.4 pullup
3.	If adc reading is low then nap 2 for 72 msecs and goto 2.
4.	Nap 1 for 32 msecs and then readadc again to confirm that its high. If low, goto 2
5.	Wake up HC-12
6.	Increment water pulse counter (WPC) and calculate battery voltage (BV)
7.	Transmit #WPC, #Battery voltages and #WPC again for redundancy (but later use without # when received by 08M2)
8.	Put HC-12 to sleep
9.	Check reed switch (as per 2.). If closed, goto 2 else nap 3 for 144 msecs and goto 9. 

The module draws about 0.7 mA when the battery voltage is about 4 volts and the HC-12 is asleep.

If the HC-12 can't be put to sleep after 5 attempts, the program simply transmits "Can't sleep HC-12" every 67 secs and naps between times.

#endrem

#picaxe 08M2
#no_data

symbol rx = c.3		'connected to Txd on module
symbol tx = c.2		'connected to Rxd on module
symbol con = c.1	'connected to Con on module
symbol GreenLED=c.0	'connected to green LED and also used here as an earth return for the reed switch

'bytes b0-b2 used
symbol suppmin=b3
symbol WaterCnt=w2
symbol suppvol=w3
symbol suppmax=b8
symbol temp=b9
symbol BatVoltInt=w5	'counter to trigger a battery over-voltage check
symbol BatOvrVolt=b12	'=0 if less than 215 (ie 4.15 volts)

symbol BattHigh=215
symbol BattLow=210


'check the HC-12 parameters

high Tx
low con	'put into command mode (to communicate at previouslt set baud rate)
pause 40	'wait for module to go into command mode

setfreq M16	'seems to need 16MHz to operate at 9600

sertxd ("Start",cr,lf)

serout tx,T9600_16,("AT+RX")  

bptr=28
serin [1000],rx,T9600_16,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc

b0=bptr-1
bptr=28
sertxd ("BPTR=",#b0,cr,lf)
for b1=bptr to b0
	sertxd (@bptrinc)
next b1

input con	'take out of command mode and tri-state c.1
pause 160	'wait 40 msecs for module to go into pass through mode

BatOvrVolt=0	'set over voltage flag off
gosub sleepmod	'put HC-12 to sleep to save power

'-----------------------------------------------------------------------------------

stp1:
low GreenLED	'used as earth return for reed switch in water meter
suppmin=255
symbol reedmin=50

stp2:
BatVoltInt=BatVoltInt+1 and $0FFF	'should overflow about every 5 minutes
if BatVoltInt=0 then
	calibadc10 suppvol
	suppvol=64*1023/suppvol*200/125	'Supply Voltage
	suppvol=suppvol-200
	if suppvol>BattHigh then
		if BatOvrVolt=0 then
			BatOvrVolt=1
			low con		'put into command mode (to communicate at previouslt set baud rate)
			pause 160	'wait 40 msecs for module to go into command mode
			input con	'take out of command mode and tri-state c.1
			pause 160	'wait 40 msecs for module to go into pass through mode
		endif
	endif
	if suppvol<BattLow then
		if BatOvrVolt>0 then
			BatOvrVolt=0
			call sleepmod
		endif
	endif
else
	nap 2	'nap for 72 msecs
endif		
	
pullup %00010000
readadc c.4,b0
pullup %00000000
'sertxd (#b0,cr,lf)
if b0<reedmin then : goto stp2: endif	'nap for 72 msecs if contacts closed

stp4:
nap 1	'nap for 32 msecs
pullup %00010000
readadc c.4,b0
pullup %00000000
if b0<reedmin then stp2	'pulse needs to be high for at least 32 msecs

stp5:
high c.0	'green led on
high Tx
low con		'put into command mode (to communicate at previouslt set baud rate)
pause 160	'wait 40 msecs for module to go into command mode
'nap 2	'nap for 72 msecs
input con	'take out of command mode and tri-state c.1
pause 160	'wait 40 msecs for module to go into pass through mode
'nap 2	'nap for 72 msecs
low c.0	'green led off

stp6:
inc WaterCnt	'increment the water meter pulse counter

calibadc10 suppvol
suppvol=64*1023/suppvol*200/125	'Supply Voltage
suppvol=suppvol-200
suppmax=suppvol min suppmax
suppmin=suppvol max suppmin
'	sertxd (#Suppvol,",",#suppmax,",",#suppmin,cr,lf)


stp7:
serout tx,T9600_16,(#WaterCnt," - ",#suppvol,",",#suppmax,",",#suppmin,",",#WaterCnt,cr,lf)
'input tx		'tri-state tx pin c.2
pause 150	'it just seems to need a pause here of at least 50 for it to work

stp8:
if BatOvrVolt=0 then: gosub sleepmod:endif	'put HC-12 to sleep to save power if battery not overcharged

stp9:
pullup %00010000
readadc c.4,b0
pullup %00000000
if b0<reedmin then
	goto stp2
else
	BatVoltInt=BatVoltInt+1 and $0FFF	'should overflow about every 5 minutes
	if BatVoltInt=0 then
'sertxd ("Stp 9 - BatVoltInt=0",cr,lf)
		calibadc10 suppvol
		suppvol=64*1023/suppvol*200/125	'Supply Voltage
		suppvol=suppvol-200
		if suppvol>BattHigh then
			if BatOvrVolt=0 then
				BatOvrVolt=1
				low con		'put into command mode (to communicate at previouslt set baud rate)
				pause 160	'wait 40 msecs for module to go into command mode
				input con	'take out of command mode and tri-state c.1
				pause 160	'wait 40 msecs for module to go into pass through mode
			endif
		endif
		if suppvol<BattLow then
			if BatOvrVolt>0 then
				BatOvrVolt=0
				call sleepmod
			endif
		endif
	else
		nap 2		'nap for 144 msecs if contacts still open
'		nap 2		'nap for 144 msecs if contacts still open
	endif		
	
	goto stp9	'loop here indefinitely until contacts close again
endif


'-----------------------------------------------------------------------------------
sleepmod:	'Puts module to sleep - takes about 150 msecs and leaves it in pass through mode
temp=5
rpt:high Tx
low con	'put into command mode (to communicate at previouslt set baud rate)
pause 160	'wait 40 msecs for module to go into command mode
'sertxd ("Go to sleep",cr,lf)

serout tx,T9600_16,("AT+SLEEP")  

bptr=28
serin [150],rx,T9600_16,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc

b0=bptr-1
pause 160	'wait 40 msecs to action sleep command before going back to pass through mode
input con	'take out of command mode by tri-stating c.1

#rem
bptr=28
sertxd ("BPTR=",#b0,cr,lf)
for b1=bptr to b0
	sertxd (@bptrinc)
next b1
#endrem

'if b0<>37 then
if b0=0 then
	low con		'put into command mode (to communicate at previouslt set baud rate)
	pause 160	'wait 40 msecs for module to go into command mode
	'nap 2	'nap for 72 msecs
	input con	'take out of command mode and tri-state c.1
	pause 160	'wait 40 msecs for module to go into pass through mode
	'nap 2	'nap for 72 msecs
	serout tx,T9600_16,("Can't sleep ",#b0,cr,lf)
	sertxd ("Can't sleep ",#b0,cr,lf)
	pause 150	'it just seems to need a pause here of at least 50 for it to work
	if temp>0 then
		dec temp
		goto rpt	'repeat straight away if haven't tried 5 times already
	else
		nap 12	'nap for 67 secs
		goto rpt	'repeat after 67 secs if have tried 5 times already
	endif
endif

input tx  	'tri-state c.2 while asleep

return
'-----------------------------------------------------------------------------------
 

techElder

Well-known member
Bill, be careful with these serout vs. serin commands for the HC-12.

Code:
serout tx,T9600_16,("AT+SLEEP")  

bptr=28
serin [150],rx,T9600_16,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc
You are sending out "AT+SLEEP", the HC-12 is returning "OK+SLEEP" (8 characters), but your serin (without a timeout parameter) is waiting for "@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc" (10 characters.)
 

hippy

Technical Support
Staff member
Code:
bptr=28
serin [150],rx,T9600_16,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc
b0=bptr-1
if b0=0 then
I can't see how that's condition is ever going to evaluate true.
 

Buzby

Senior Member
... I can't see how that's condition is ever going to evaluate true.
What he needs is a BBW ( Branch Both Ways ) instruction :)

I thought BBW was a joke, until I learnt a bit more about the Spectre and Meltdown exploits.
These use info gained when your CPU executes both paths of a yes/no descision simultaneously.

Modern tech - too clever by half !
 

BillBWann

Member
I can't see how that's condition is ever going to evaluate true.
That's the point, it can't be true for the version of the program I posted. The real statement is the adjacent one that is commented out. I only changed the statement so that the version that I hope you'll try out won't get caught up in the "Can't sleep" portion of the program because you won't have an HC-12 connected to the 08M2.
 

BESQUEUT

Senior Member
goto stp9
will continue to
Sleepmod :

same problem with :
goto rpt

But Sleepmod end with a RETURN, called where ?

Answer this question and maybe you can understand why some behaviour where "strange" ...
IMHO, one GOTO within that kind of program is one GOTO in excess...
 
Last edited:

hippy

Technical Support
Staff member
goto stp9
will continue to
Sleepmod :
I don't think so; there are GOTO commands which are tucked inside the IF-ELSE-ENDIF blocks which will prevent that. But those and other GOTO commands do make the program flow rather difficult to follow.

As PE5 is being used I would suggest trying PE6 to see if that does change things.
 

BESQUEUT

Senior Member
I don't think so; there are GOTO commands which are tucked inside the IF-ELSE-ENDIF blocks which will prevent that. But those and other GOTO commands do make the program flow rather difficult to follow.

As PE5 is being used I would suggest trying PE6 to see if that does change things.
You are true, and as of #4, no problem with the goto rpt...

Not sure that this program is strictly equivalent, but easier to read :
Code:
#picaxe 08M2
#no_data

symbol rx = c.3		'connected to Txd on module
symbol tx = c.2		'connected to Rxd on module
symbol con = c.1	'connected to Con on module
symbol GreenLED=c.0	'connected to green LED and also used here as an earth return for the reed switch

'bytes b0-b2 used
symbol suppmin=b3
symbol WaterCnt=w2
symbol suppvol=w3
symbol suppmax=b8
symbol temp=b9
symbol BatVoltInt=w5	'counter to trigger a battery over-voltage check
symbol BatOvrVolt=b12	'=0 if less than 215 (ie 4.15 volts)

symbol BattHigh=215
symbol BattLow=210


'check the HC-12 parameters

high Tx
low con	'put into command mode (to communicate at previouslt set baud rate)
pause 40	'wait for module to go into command mode

setfreq M16	'seems to need 16MHz to operate at 9600

sertxd ("Start",cr,lf)

serout tx,T9600_16,("AT+RX")  

bptr=28
serin [1000],rx,T9600_16,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc

b0=bptr-1
bptr=28
sertxd ("BPTR=",#b0,cr,lf)
for b1=bptr to b0
	sertxd (@bptrinc)
next b1

input con	'take out of command mode and tri-state c.1
pause 160	'wait 40 msecs for module to go into pass through mode

BatOvrVolt=0	'set over voltage flag off
gosub sleepmod	'put HC-12 to sleep to save power


low GreenLED	'used as earth return for reed switch in water meter
suppmin=255
symbol reedmin=50



do
	gosub Bat
	high c.0	'green led on
	high Tx
	low con	'put into command mode (to communicate at previouslt set baud rate)
	pause 160	'wait 40 msecs for module to go into command mode

	input con	'take out of command mode and tri-state c.1
	pause 160	'wait 40 msecs for module to go into pass through mode

	low c.0	'green led off

	inc WaterCnt	'increment the water meter pulse counter

	calibadc10 suppvol
	suppvol=64*1023/suppvol*200/125	'Supply Voltage
	suppvol=suppvol-200
	suppmax=suppvol min suppmax
	suppmin=suppvol max suppmin


	serout tx,T9600_16,(#WaterCnt," - ",#suppvol,",",#suppmax,",",#suppmin,",",#WaterCnt,cr,lf)
	pause 150	'it just seems to need a pause here of at least 50 for it to work


	if BatOvrVolt=0 then: gosub sleepmod:endif	'put HC-12 to sleep to save power if battery not overcharged
loop



Bat:
do
  	pullup %00010000
 	readadc c.4,b0
 	pullup %00000000
	BatVoltInt=BatVoltInt+1 and $0FFF	'should overflow about every 5 minutes
	if BatVoltInt=0 then
		calibadc10 suppvol
		suppvol=64*1023/suppvol*200/125	'Supply Voltage
		suppvol=suppvol-200
		if suppvol>BattHigh then
			if BatOvrVolt=0 then
				BatOvrVolt=1
				low con		'put into command mode (to communicate at previouslt set baud rate)
				pause 160	'wait 40 msecs for module to go into command mode
				input con	'take out of command mode and tri-state c.1
				pause 160	'wait 40 msecs for module to go into pass through mode
			endif
		endif
	
		if suppvol<BattLow then
			if BatOvrVolt>0 then
				BatOvrVolt=0
				call sleepmod
			endif
		endif
	
	else
		nap 2		'nap for 144 msecs if contacts still open
      endif

loop until b0<reedmin
RETURN

'-----------------------------------------------------------------------------------
sleepmod:	'Puts module to sleep - takes about 150 msecs and leaves it in pass through mode
temp=5

high Tx
low con	'put into command mode (to communicate at previouslt set baud rate)
pause 160	'wait 40 msecs for module to go into command mode

serout tx,T9600_16,("AT+SLEEP")  
bptr=28
serin [150],rx,T9600_16,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc

b0=bptr-1
pause 160	'wait 40 msecs to action sleep command before going back to pass through mode
input con	'take out of command mode by tri-stating c.1
input tx  	'tri-state c.2 while asleep

RETURN
 
Last edited:

BillBWann

Member
Thanks Besqueut for your alternative code. I don’t think it is equivalent and it needs an inverse version of your Bat subroutine to wait until the reed switch opens. However I take yours and Hippy’s point that structured code would be easier for everyone (including me) to understand. My excuse is that old habits die hard and this program started life as a quick and dirty replacement of a wired connection that had become buried in foliage and just about impossible to maintain. I hoped that I could re-use some existing hardware I had and the program evolved to something more complex when I added battery voltage checking and realized that that needed to be done independently of flow through the meter. The battery checking would ideally be done as an independent second task but in this case I needed the higher operating speed and I also wasn’t too sure how the timing of this second task would go with naps (instead of pauses) in the main program.

While I agree that my code isn’t pretty, I do think it’s logical and should be capable of being compiled without causing periodic restarts. I managed to get the code working – principally by changing a single “nap 3” command into two consecutive “nap 2” commands - and its currently meeting my requirements of maintaining a real time, in-house record of our water consumption. At some point, I will look at improving this communication link which, in addition to better structured code, should also involve sending binary rather than ASCII data, a slower transmission speed with more error checking and less HC-12 transmission power.

The reason that I started this thread was to advise others of the possibility that there was a bug with the use of the nap command in PE5. As I stated earlier, I have no immediate plans to install PE6 as, until now at least, PE5 has worked quite satisfactorily for my simple needs and at my age the novelty of learning (and unlearning) new operating systems has well and truly passed. I'm an engineer and really just want to use computers to solve my problems and I need some convincing that a new system really has sufficient advantages for me personally before I buy into it.

I spent some time to provide the forum with a simple version of my program which still failed for me and that needed minimal testing hardware in the hope that some kind soul could confirm that they also got continual program restarts under PE5 and then to try it under PE6 and tell me if that solved the problem. Mind you, even if a PE6 compile did solve the problem, I still wouldn’t be totally convinced that there was no problem as I think the “fix” I found under PE5 of using two consecutive “nap 2” commands instead of a single “nap 3” isn’t a logical method of solving the problem in PE5 either. The “fix” in the move to PE6 might similarly just be a fluke.

Ideally, I’d like to know the reasons for this restarting problem in PE5 so that it can be confirmed that a move to PE6 is the only reliable alternative to overcome this problem.
 

BESQUEUT

Senior Member
Ideally, I&#8217;d like to know the reasons for this restarting problem in PE5 so that it can be confirmed that a move to PE6 is the only reliable alternative to overcome this problem.
We too...
So : how are you detecting that the Picaxe is restarting ?
Picaxes are doing exactly the same things even if the code is made by PE5 or PE6.
==> so if there is a problem with a code made by PE5, it will be present on the same Picaxe with a code made by PE6...
The only difference is that PE6 may prevent you from doing bad things...
But I suspect a code problem very more than a Picaxe problem.
So we will be happy to understand how this code work...
 
Last edited:

BESQUEUT

Senior Member
I don&#8217;t think it is equivalent and it needs an inverse version of your Bat subroutine to wait until the reed switch opens.
Code:
stp9:
readadc c.4,b0
if b0<reedmin then
	goto stp2
else
...
	goto stp9	'loop here indefinitely until contacts close again
endif
Your code loop until b0<reedmin...
(But due to the goto command, this is not as evident as with a do loop ...)
 

hippy

Technical Support
Staff member
My excuse is that old habits die hard and this program started life as a quick and dirty replacement of a wired connection that had become buried in foliage and just about impossible to maintain.
That is understandable and not always that unusual. I am sure though that if you find it difficult to maintain then you understand that others having not been involved at all find it hard to work out what is going on.

I managed to get the code working – principally by changing a single “nap 3” command into two consecutive “nap 2” commands - and its currently meeting my requirements of maintaining a real time, in-house record of our water consumption.

The reason that I started this thread was to advise others of the possibility that there was a bug with the use of the nap command in PE5.
It does not seem likely that NAP would be the problem if you simply replace one NAP with two NAP and that works. It will however be the case that doing that has other consequences; alters timing, program memory and perhaps other things as well, use and it's actually one of those which is causing the problem.

In changing the NAP you may not have actually fixed things, just altered the frequency or likelihood of restarting unexpectedly.

Ideally, I’d like to know the reasons for this restarting problem in PE5 so that it can be confirmed that a move to PE6 is the only reliable alternative to overcome this problem.
PE5 is superseded software which is no longer used by most PICAXE users so there is little incentive or gain for ourselves to investigate or even resolve the issue if it is a problem purely with PE5, which doesn't appear to be affecting anyone else, or is an issue which, at the end of the day, turns out not to be anything to do with PE5.

That's not to say we don't also want to know what the cause of the issue is, don't want to help you solve your problem, but it does affect what resources can be reasonably committed to that.
 

hippy

Technical Support
Staff member
Here is a version of the program that dosn't need an HC-12 to be attached that you can test to see if you get the same result as I got...
Can you produce a version of that which demonstrates that it produces an unexpected restart in PE5 which does not require the attachment of any peripherals or hardware nor needs any specific operational conditions such as power supply voltage ?

Basically a version which runs and unexpectedly restarts on a bare unconnected 08M2 no matter what its power supply.

If you can produce a version which anyone can try no matter what their setup is it will be easier to run that and confirm that the same issue is seen by them if that is the case.
 

hippy

Technical Support
Staff member
After investigation it does appear there may be an issue with NAP under some circumstances on an 08M2. It appears that it may be a firmware issue so can occur when using PE5 or PE6 if it does. It will require further investigations to discover what the cause of that issue is and how it may be possible to avoid it.

The best recommendation for now would be to code things so there can be a recovery to having things work as required if the PICAXE resets.
 

AllyCat

Senior Member
Hi,

Picaxes are doing exactly the same things even if the code is made by PE5 or PE6.
That's not entirely correct, there are some bugs in PE5 (which will never be fixed) that have been corrected in PE6. The most obvious is READINTERNALTEMP which generates almost twice as many program bytes (IMHO unnecessarily) to fix the two minor bugs when PE5 was used.

However, READINTERNALTEMP is basically a "useless" command, unless a precision regulated supply rail is available, but the "PE6 fix" has made it much more difficult to calculate the chip temperature "properly" (because of the different results returned by PE5 and PE6). And no, the program cannot identify which PE was used, except by comparing the READINTERNALTEMP results with the original SFR values (which rather defeats the object of the exercise). :(

Cheers, Alan.
 

hippy

Technical Support
Staff member
And no, the program cannot identify which PE was used, except by comparing the READINTERNALTEMP results with the original SFR values (which rather defeats the object of the exercise). :(
That's not entirely true; it is possible for a program to know if it was created using PE5 or PE6 -

Code:
#Picaxe 18M2

#IfDef _18M2 ; Name must match above, with leading underscore
  #Define PE6
#Else
  #Define PE5
#EndIf

#Terminal 4800

Do
  #IfDef PE5
    SerTxd( "Created  in PE5 (FIVE)", CR, LF )
  #EndIf
  #IfDef PE6
    SerTxd( "Created  in PE6 (SIX)", CR, LF )
  #EndIf
Loop
That code should run as expected in both a real chip and in simulation using PE5 and PE6.

If you want to identify PE5 or PE6 by changing the #PICAXE directive without having to change anything else you can do that with a list of #IFDEF's for all the PICAXE types it could be ...

Code:
#IfDef _08M2
  #Define PE6
#EndIf
#IfDef _14M2
  #Define PE6
#EndIf
#IfDef _18M2
  #Define PE6
#EndIf
#IfDef _20M2
  #Define PE6
#EndIf
#IfNDef PE6
  #Define PE5
#EndIf
This is one of the changes which came about in the addition of the preprocessor. In PE5, when an 18M2 is used as here, a "18M2" symbol is silently created so "#IFDEF 18M2" can be used and works with PE5.

Moving to PE6 and the preprocessor those silently created symbols have a leading "_" added, as in "_18M2", and "#IFDEF _18M2" can be used and works with PE6.

PE5 accepts "#IFDEF _18M2" but will not have silently created a "_18M2" ( it creates "18M2" ), so if it's an 18M2 but "_18M2" is not defined then it must be PE5.

It doesn't work the other way round because PE6 won't accept "#IFDEF 18M2". That prompts to insert the leading underscore to help with porting code from PE5 to PE6.

One doesn't need to have separate "#IFDEF PE5" and "#IFDEF PE6", a "#ELSE can be used. The "#DEFINE PE5" doesn't need to be created either if one uses only "#IFDEF PE6" and "#IFNDEF PE6".
 

AllyCat

Senior Member
Hi hippy,

Thanks for that. I can't test it at the moment (no access to any PE) but my statement was based on a previous specific thread. ;)

Which also reminds me, what about the AxePad version number?

Cheers, Alan.
 

hippy

Technical Support
Staff member
I guess it has taken two years for an automatic PE5/PE6 determining solution to rattle itself around my head and emerge. That thread did remind me that it would be wise to also check that either PE6 or PE5 has been specified ...

Code:
#IfNDef PE5
  #IfNDef PE6
    #Error Must include #DEFINE PE5 or #DEFINE PE6
  #EndIf
#Else
  #IfDef PE6
    #Error Cannot include both #DEFINE PE5 and #DEFINE PE6
  #EndIf
#EndIf
I still can't off-hand think of any solution to distinguish AXEpad creation from PE creation. I'll think about it. Maybe in another two years ... :)
 

techElder

Well-known member
Hippy, OT a little bit, but after all these years of witnessing, I'm still amazed at the things you come up with. Thanks.
 

BillBWann

Member
After investigation it does appear there may be an issue with NAP under some circumstances on an 08M2. It appears that it may be a firmware issue so can occur when using PE5 or PE6 if it does. It will require further investigations to discover what the cause of that issue is and how it may be possible to avoid it.

The best recommendation for now would be to code things so there can be a recovery to having things work as required if the PICAXE resets.
Thanks Hippy for this confirmation.

I assume that either you or Technical ran the program that I posted back in #2 and found that a bare 08M2 fitted with only the 2 programming resistors and connected to a power supply did reset at an interval of about 7-8 minutes?

Thanks to everyone for their contributions.
 
Top