Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me.
Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9749
Posted: 09:12pm 30 Nov 2017
Copy link to clipboard
Print this post
Hi all.
To save me some time when churning out call-points that use the HC-12 RF module, I have just started including these three subs at the bottom of my code.
You run these subs directly from the command-line, but as they are part of the main code, when I read the finished chip using IPE to make a HEX I can program into each unit, these setup routines then are part of the MMBASIC program code within the HEX file. Although, they are never called as part of the running program.
So, all I have to do, is program the HEX into the unit using pic32prog, and then use these subs to setup the HC-12. The setup really only needs you to issue ONE command - SETUP_HC12 at the command prompt, and this will call that sub, and configure the HC-12 module in a few seconds. You will need to change the AT commands to suit whatever you need. The HC-12 SET line MUST be connected to a MM I/O pin setup as an output. CHECK_HC12 will readback the current settings to confirm. Note that in CHECK_HC12, if you changed the baud-rate as part of the SETUP_HC12 sub, you will need to change that in the CHECK_HC12 sub before the module will respond correctly.
The process for me is:
1) Flash the HEX into the PIC32 2) Connect Console, and CTRL-C to stop the running code 3) SETUP_HC12 at the console, module is configured.
Cycle power and the unit is ready to use.
This might prove useful for others who might want to play with the HC-12 settings from inside their program.
Smoke makes things work. When the smoke gets out, it stops!
panky Guru Joined: 02/10/2012 Location: AustraliaPosts: 1116
Posted: 12:27am 01 Dec 2017
Copy link to clipboard
Print this post
G,
Nice idea - a comment/observation - d$ and e$ are dim'd in both subs and this will throw an error of "Already defined". Also, if you try to run a second time, same error (as it should).
If both are used only within the subroutines, would it be better to declare them using LOCAL in each?
panky
Edit: As you need to display e$ outside the subroutine it was created in, could you make the third sub a function instead?
Edit2: Thinking further, the global CLEAR at the start could have unintended repercussions - I assume it is to get around the re DIM issue I raised earlier - would ERASE E$,D$ being more specific, be a better way? Just some thoughts Edited by panky 2017-12-02... almost all of the Maximites, the MicromMites, the MM Extremes, the ArmMites, the PicoMite and loving it!
Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9749
Posted: 12:59am 01 Dec 2017
Copy link to clipboard
Print this post
No, there won't be any DIM problems, cos of the CLEAR command you have picked up on in your 2nd edit. Remember that these routines are BY DESIGN only to be run from the command prompt to setup the module. Assuming you DON'T change the HC12 settings again once done.
If you need to change the HC12 setting from within a running program, these subs WILL NOT work, as they will throw those errors you were talking about.
This is a "Set it, and forget it" solution for configuring the HC12 in-house. Smoke makes things work. When the smoke gets out, it stops!
Azure Guru Joined: 09/11/2017 Location: AustraliaPosts: 446
Posted: 01:00am 01 Dec 2017
Copy link to clipboard
Print this post
Nice looking routines.
I think they are paste residue from multiple files like Panky pointed out.
I would also remove the end statements at the end of the each of the first 2 subs.
Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9749
Posted: 01:05am 01 Dec 2017
Copy link to clipboard
Print this post
END statements REQUIRED in this application, as you DON'T want the SETUP_HC12 sub to finish, then run the next sub below it.
See my point above about how these subs were designed to be used.
I think members are thinking these are subs to use inside a running code - they are not.
They just save me having to program the HC12 outside of the project, THEN put it in the project. With this method, I can put factory-fresh HC12's in the project as part of normal assembly, and configure them after I have programmed the HEX into the pic32.Smoke makes things work. When the smoke gets out, it stops!
Azure Guru Joined: 09/11/2017 Location: AustraliaPosts: 446
Posted: 01:18am 01 Dec 2017
Copy link to clipboard
Print this post
I read your description and it made sense. They are subs so one will not run into the other like part of the program flow. They will be read and parsed as subs (ignored) as part of program flow until called by name at a command prompt or within the program. If that were not the case it would run Setup_HC12 and you would not need to Ctrl C and type Setup_HC12 at the command prompt.
That is unless I am having a moment and missing something entirely :)
panky Guru Joined: 02/10/2012 Location: AustraliaPosts: 1116
Posted: 01:19am 01 Dec 2017
Copy link to clipboard
Print this post
Grogster,
Don't get me wrong - it's a neat solution - I just think that as a general programming practice, using CLEAR, a globally acting command to clear out just two variables, D$ and E$ is an overkill whereas a specific command, ERASE D$,E$ would be safer. It's the old chestnut of unintended consequences - yes, you would normally under almost any circumstances only call the subroutines once BUT, although Geoff (and all other programmers) didn't explicitly put a MURPHYcommand in MMBasic, one lurks there to catch the unsuspecting
No criticism intended for anyone, just some observations, Regards, panky. ... almost all of the Maximites, the MicromMites, the MM Extremes, the ArmMites, the PicoMite and loving it!
erbp Senior Member Joined: 03/05/2016 Location: AustraliaPosts: 195
Posted: 01:48am 01 Dec 2017
Copy link to clipboard
Print this post
Actually I don't think the DIM statements are required at all.
In SETUP_HC12, the variables D$ and E$ are not referenced, so don't need to be declared.
In CHECK_HC12, E$ is not referenced, D$ is referenced but only within the Sub, so replace DIM D$, E$ with LOCAL D$
In SET_HC12(E$) E$ is implicitly declared (essentially as a LOCAL) as it is an argument being passed to the subroutine. The reference to E$ within SET_HC12 will reference the (local) E$ argument not any globally DIMmed E$ in any other sub, and the (local) E$ argument will be set to point to the string value being passed in whenever SET_HC12 is called - in this case these are all literal string values.
SET_HC12 does reference D$, but it is only used within the sub - i.e. the value placed in D$ in this sub is not passed back for use in CHECK_HC12. So again just make D$ a LOCAL variable to this sub - i.e. add LOCAL D$ to the start of SET_HC12.
Then the CLEAR / ERASE is totally redundant and can be removed.
Note: I have not tested this and am relying on an "eyeball" parsing of the code, but I don't think I missed an references to these variables that would invalidate the above suggestions.
Also I believe the two END statements are not required, as when you execute a subroutine from the command line, it ONLY executes code WITHIN that subroutine (and any subs/functions called by the one you executed). These END statements are OUTSIDE the subroutines, so will never be executed. Control will return to the command prompt when the execution flow exits the specified subroutine (i.e. reaches the end of or encounters an EXIT SUB)
Cheers, Phil.
EDIT: With the above suggestions in place, I believe you could call the SETUP_HC12 and/or CHECK_HC12 subs multiple times without problems. So if you had to replace a faulty HC-12 module, you could then re-use SETUP_HC12 to configure the new one. Edited by erbp 2017-12-02
Alastair Senior Member Joined: 03/04/2017 Location: AustraliaPosts: 161
Posted: 02:00am 01 Dec 2017
Copy link to clipboard
Print this post
Grogs, I can see where you are coming from with this. It is very different when doing one or two HC-12s for a home project to when you are doing many modules regularly and want to make setup easy and consistent. Good one Cheers, Alastair
Azure Guru Joined: 09/11/2017 Location: AustraliaPosts: 446
Posted: 11:07am 01 Dec 2017
Copy link to clipboard
Print this post
@Grogster I think that since there was all that feedback we think it is a great idea we just have our own ideas about how each of us might use and implement it ourselves.
Thank you for sharing, I know I will use these great tips you shared when I get to play with these modules.
lew247 Guru Joined: 23/12/2015 Location: United KingdomPosts: 1702
Posted: 11:34am 01 Dec 2017
Copy link to clipboard
Print this post
I think it's brilliant, and will be a great help for many people
Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9749
Posted: 10:59pm 01 Dec 2017
Copy link to clipboard
Print this post
[Quote=erbp]Also I believe the two END statements are not required, as when you execute a subroutine from the command line, it ONLY executes code WITHIN that subroutine (and any subs/functions called by the one you executed). These END statements are OUTSIDE the subroutines, so will never be executed. Control will return to the command prompt when the execution flow exits the specified subroutine (i.e. reaches the end of or encounters an EXIT SUB)[/Quote]
Really? If that is indeed the case, then you are quite correct about the END statements, and I stand corrected. I never thought to try it, expecting that once one sub was finished, if you did NOT have that END, it would just run the next sub after the first one. You also have a point about the stings.
@ Azure - Oh, I fully get where you and others were coming from. I had just not thought it through enough me thinks. People reading the title of this thread would imaging they were routines for use INSIDE running code, so....yeah. Smoke makes things work. When the smoke gets out, it stops!
Quazee137 Guru Joined: 07/08/2016 Location: United StatesPosts: 600
Posted: 06:14am 02 Dec 2017
Copy link to clipboard
Print this post
Grogster THANKS!!! I agree with lew247.
This saves me from having to hand out crib notes when the smart probes need to be setup. I will expand on your concept to menu 4 probe types.Edited by Quazee137 2017-12-03
Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me.
Print this post
