Pulsin and underclocking

[martinn]

Hi
I am using pulsin on an 18x to read an x-band motion sensor (www.parallax.com), it works fine at normal clock speeds, but when I underclock the chip, the program does not run properly, that is, it constantly resets the chip. The underclocking works fine if I comment out the pulsin line, and the program runs fine at 4Mhz.
Is there a problem with underclocking and the pulsin command?

Martin

 

[MartinM57]

...when I underclock the chip....

By doing what?

A minimal, but fully working, code snippet that illustrates the problem would be helpful...

 

[hippy]

The 18X only officially supports 4MHz and 8MHz operation so it may be your means of under-clocking or some other issue arising from that.

It could be that if you under-clock low enough the watchdog timeout expires and resets the chip. This would be more likely for PULSIN etc where the execution delay is excessive and there are no clear watchdog commands in the firmware timing loop.

 

[martinn]

Sorry I should have made it clearer. This stripped down code replicates the problem (I have tested it).
When the "gosub underclock" is commented out the programs stays in the xband1 routine (like it should), when underclocked it cycles back to the init: level


symbol tempdata = w2

init:
sertxd ("In Init", lf)
gosub underclock

xband1:

pulsin 2,1,tempdata
sertxd ("In xband1 ","Pulsin =",#tempdata, lf)
goto xband1


Underclock: '
poke $8F,%01000000 ' 1 MHz 1200bps
nap 0
return

 

[Dippy]

This is just a suggestion.

Have you tred PEEKing 0x8F then bitwising the bin100 into bits <6:4> ?

I'm not sure if you'll upset things by splattng zeroes into the other bit-places in OSCCON....

 

[MartinM57]

Why are you underclocking - just to get 1200bps as your comment suggests?

 

[hippy]

It does seem to be a watchdog timeout issue but will seek clarification on that. This will likely affect all PICAXE types in cases where the command execution time exceeds the watchdog timer period without the watchdog having been cleared.

A workround would be to code in a way not to have this arise, run at a faster speed and switch back to a slower speed once the PULSIN has completed.

 

[Technical]

As hippy states above, your pulsin probably exceeds the watchdog timer timeout as the pulse timeout time is so long at this low clock speed. This causes the chip to reset.

The solution is just don't do it, return to 4MHz for the actual pulsin command!

 

[martinn]

Thank you everyone

I am underclocking because it is for remote, battery powered datalogging, and underclocking reduces power consumption significantly, hence gives a much longer 'in situ' time. Maybe I will have to use bigger batteries.

The pulsin is basically polling continuously (every 0.3secs becuase it is attempting to detect people walking by), so I don't think under and overclocking that frequently is a good thing, maybe inserting a short 'nap' would help.

@ Dippy, I will try your 'PEEKing 0x8F then bitwising the bin100 into bits <6:4> ?' suggestion once I work out what it means!

Martin

 

[Dippy]

Please remember that was only a suggestion; I hadn't thought of the Watchdog timer (WDT) issue.
(When a PIC does something it resets the WDT, when a PIC does nothing the timer is ticking away. If the WDT timer reaches a level it decides that PICAXE has got stuck. In this case it'll trigger a reset. The WDT is useful for popping out of ASM Sleep. That's how you have the Sleep x command and that's why it is never very accurate.)

'bitwise' just means all those ANDs and ORs and logical operator things.
A simpler way to understand it is to use the useful 'bit' facility that PICAXE has.
As in b0 is bit7....bit0. (Look it up in the Manual2)

Before the WDT answer came up it crossed my mind about the other bits in OSCCON.
I hadn't checked it as it was just a thought.

Have you actually looked in the PIC Data Sheet or did you cut'n'paste the POKE command?
Here it is below. You can see the other bits too.



If you PEEK 8Fh first and store it in variable b0 then you can just set the bits 6 ,5 and 4 to 100.
Then you can POKE b0 back to 8Fh.
This leaves any other bits unchanged.
Anyway, it's probably completely irrelevant now, but something to remember for the future.
i.e. just set the bits you have to (= 'Look Before You leap' )


ALSO, strictly speaking, you should wait until IOFS is stable before carrying on.
Myloop: PEEK into b0, IF bit2=0 then back_to_MyLoop ELSE carryon.
(This maybe OK in PICAXE BASIC to do a NAP, but in a compiler you would test the bit AFTER you had read the Data Sheet ).

"Manage Attachments" button won't work right now, so I'll use tinypic.com...

 

[hippy]

The POKESFR to OSCCON looks okay though it would normally be recommended to PAUSE to ensure the change has occurred or wait for the IOFS bit to become set. Doing so is not so important if the speed of execution for a while does not matter.

Rather than lose low-power operation or have to run at a higher speed to use PULSIN a better approach will be to consider how to have low-power, run at a lower speed and still detect the sensor has activated - using a mechanism which does not rely on PULSIN. Do that and you should be able to run at even lower power than currently. Don't forget though tat the sensor itself draws 8mA.

Looking at the data sheet it appears that an input signal greater than 4Hz indicates presence detected. Knowing exactly what the sensor puts out in what conditions, minimum and maximum frequencies, would likely be a prerequisite.

http://www.parallax.com/Portals/0/Downloads/docs/prod/sens/32213-X-BandMotionDetector-v1.1.pdf

It should be possible to detect the presence of such a signal, without using PULSIN or COUNT, by simply polling and even when under-clocked. One of the X1 or X2 PICAXE may be a better choice than the 18X using internal hardware to count input pulses ( SETTIMER COUNT ).