Picaxe PE6 "Blocking' commands?

jims

Senior Member
Is there a list of the Blocking Commands in PE6? I've searched Manual 2 & found only the "RFIN" command listed as blocking.
Thank you, JimS
 

nick12ab

Senior Member
A list of such commands can be found here.

Commands do not change whether they're blocking or non-blocking based on which version of the editor you're using.
 

hippy

Technical Support
Staff member
To an extent it depends on what one means by "blocking". I would classify those as commands which are expecting input and will wait until that input arrives, preventing other commands for executing until that occurs. Off-hand, the non-timeout versions of -

SERIN, SERXD, IRIN, INFRAIN, INFRAIN2, KBIN, KEYIN, HSERIN for non-M2

A slightly looser definition of "blocking" would include those commands which take an appreciably long time to execute but which do complete and continue of their own accord.
 

jims

Senior Member
Thank you Nick... & Hippy. The only specific reference that I could find about "blocking" commands is this from the RFIN command. (Note this command is blocking, no other commands will process whilst the rfin command is waiting for RF data to be received. If a system that can process other...). Wanted to know if other non-timeout commands might be hiding somewhere waiting to grab me sometime. JimS
 

f2cf1g

Member
No luck tracing a definitive list of "blocking" commands so I have to ask, is pulsout blocking? By blocking I mean, does execution stay within the command until the the pulse has completed? The chip is an 08M2. Is the answer the same on all chips? Thanks.
 

hippy

Technical Support
Staff member
is pulsout blocking? By blocking I mean, does execution stay within the command until the the pulse has completed?
Execution stays within the command until the pulse completes. That is the same for all PICAXE and is the case for all commands; even those commands which initiate things which then execute independently in the background.

In most cases the execution time within a command will be as short as it can be, but things like PULSIN, PULSOUT, COUNT, SERIN, SEROUT etc take longer.
 

bobladell

New Member
Hi all - Can anyone confirm whether pulsin is blocking or not please ?

I'm trying to use "time" on 08M2 running at 8MHz to measure a 30S slot during which I'm using pulsin to measure the width of inbound pulses that are supposed to be in the range 5mS to 100mS per pulse, accumulating the total pulse time in a separate word variable.

The time seems to be several times longer than the 30S "time" loop that I've set up.

main:
time = 0 ;time remains as 1S increments at 8MHz

measure:
pulsin PM25,0,duration ; hi to low starts measurement
lowpulseoccupancy = lowpulseoccupancy + duration
; add up the total low duration
; use 16MHz 0.16384s timeout 2.5uS resolution
if time < 30 then ; if time < 30S measure again
goto measure
endif

Thanks
 

hippy

Technical Support
Staff member
Hi all - Can anyone confirm whether pulsin is blocking or not please ?
Again, it depends on what one means by "blocking". In the sense of 'will it indefinitely wait within the PULSIN command until some condition' is met then "no". In the sense of 'will it wait within the PULSIN until the command completes' then "yes".

While the PULSIN is executing the PICAXE will dedicate itself to looking for an input pulse and while that is occurring it is not able to respond to other things happening, such as timer ticks. This can cause the 'time' variable not to increment as quickly as it otherwise would which is what appears to be happening here.

It's a bit like you playing at being a clock with a push button counter and a metronome going "tick" every second. That works fine until you go down the shop and can no longer hear the metronome. If you spend most of your time out shopping - or in this case within a PULSIN command - your 'being a clock' won't be very accurate, will run slow.

As your pulses are 5ms to 100ms in duration there may be other ways to accumulate the pulse periods.

You will likely have to use some other mechanism anyway because the PULSIN command cannot handle pulses longer than 32ms at 8MHz and trying to accumulate those pulse duration measurements will likely soon cause overflow errors.

Perhaps if you describe what you are attempting to achieve members may be able to suggest ways of best achieving that.
 

bobladell

New Member
Thanks for yet another prompt reply hippy.

So the answer is yes, it is blocking as the PICAXE can do nothing else, not even increment the "time" one second tick in the background, while waiting for pulsin to execute. Explains 30S turning into minutes.


Will have to revert to polling the pin and timing the do loop with a stopwatch to get about 30S window or use an external 555.......
 

erco

Senior Member
Pulsin has an optional timeout which may or may not help. Kinda depends on your input signal and if you can afford to miss a pulse or accuracy on the first pulse. While you're waiting long periods for a pulse, you could avoid using pulsin and just have a tight loop looking at the pin state (if pinb.1=0 then...), that would keep your TIME clock going. If you can manipulate whatever's sending the data, you might have it send a nice long wakeup pulse first to alert your receiver before sending critical data. Otherwise, send a data packet multiple times so you can error check. Or get a RTC module. Or an extra Picaxe dedicated to watching pulses. Many ways to skin that ornery cat.
 
Top