Pause period shortened when used in a Macro

inglewoodpete

Senior Member
This problem is a bit obscure. I'm developing software to use the HC-12 transceiver with 28X2s at either end of a wireless link. I've chosen the 28X2 because of its background serial reception capability. The 28X2 has firmware B.3 (probably not relevant) and is running at the default speed of 8MHz.

I have loosely based my startup based on example code provided by contributor PhilHornby, here. Phil's code was written for an M2-series PICAXE, with macros performing the various functions required to configure the HC-12.

Due to the nature of background serial data reception you don't know what you've got when it doesn't work, until you have a look at the data with the SerTxd command. However, the use of bit-banged SerTxd will almost certainly upset the firmware's handling of hSerial's data reception. So the simplest solution was to add a large enough delay to ensure that the HC-12 had completed its response before processing the response. Checks with the oscilloscope showed that I needed to allow a minimum of 30mS for the HC-12 to process a command and complete its response.

So, to be sure of waiting the 30mS delay for that last data bit, I inserted a 40mS delay. When run in the chip, the code sat in a loop: the (incomplete) received data did not match what was expected, so it would loop and resend the command to the HC-12. So I extended the delay to 80mS, then 1000mS. It's then that I discovered that there was no 1000mS delay occurring. Reconnecting the oscilloscope showed that the pause was being truncated at about 25mS. It was only when I inserted two consecutive "Pause 25"s into the macro did the macro run and exit correctly.

I have tried to replicate the code as a really simple demonstration of the issue but, you guessed it, the problem went away - the 1000mS delay was 1000mS long. I suspect that the issue is a compound one where delays within a macro are truncated when the macro contains a GoSub (or something like that). My code is nearly 600 lines long, so posting it is likely to be a bit daunting for other forum members. I'll try to create a shorter piece of code to demonstrate the problem.
 

oracacle

Senior Member
out of interest, if you replace the macro calls with the code (that happens when compiled anyway) do you think it would replicate. My thinking maybe there is either a fault or a max limit to the pause duration within a compiled macro.
 

Technical

Technical Support
Staff member
A macro simply expands to 'normal' code via the preprocessor, you can view the post generated code via Options>Diagnostics setting if you wish to check it.
 

inglewoodpete

Senior Member
out of interest, if you replace the macro calls with the code (that happens when compiled anyway) do you think it would replicate. My thinking maybe there is either a fault or a max limit to the pause duration within a compiled macro.
I moved the code from the offending macro to a subroutine and the 50mS pause is now the correct duration.

I have not been able to replicate the errored macro behaviour in a shorter piece of code yet.

Edit: Just saw Technical's tip after posting. I'll have a look and respond.
 

AllyCat

Senior Member
Hi,

I don't know about X2s, but doesn't a polled interrupt (M2) occurring during a pause automatically terminate that pause (which is not restarted after the return) ? Hence the pause should be split into several smaller elements.

Cheers, Alan.
 

inglewoodpete

Senior Member
A macro simply expands to 'normal' code via the preprocessor, you can view the post generated code via Options>Diagnostics setting if you wish to check it.
I have now viewed the output of the preprocessor and it appears to be true to the input instructions. I'll investigate further...
 

inglewoodpete

Senior Member
Err...yes...Egg on face

I don't know about X2s, but doesn't a polled interrupt (M2) occurring during a pause automatically terminate that pause (which is not restarted after the return) ? Hence the pause should be split into several smaller elements.
My first thought when I read your post was: Nah - I have a timer interrupt but that's only occurring once every second. Then I realised that I have hSerial interrupts occurring on incoming serial data - exactly what I'm waiting for during the (ineffective) pause statement!

It's not the first time I've been caught out by the side effects of interrupts. I'll replace the single pause statement with a loop structure. Now I remember why I normally avoid Pauses:confused:.

It's been a useful learning exercise - the preprocessor diagnostic output will be useful in the future.

Thanks Technical and AllyCat for the insights and reminders.
 
Top