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.
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.