 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. |
Forum Index : Microcontroller and PC projects : using HC-12
  Page 2 of 3   |
|||||
| Author | Message | ||||
palcal Guru  Joined: 12/10/2011 Location: AustraliaPosts: 1970 |
Thanks all, I now see what was happening I was thinking the string would be over written but it was just being added to. Thanks again. "It is better to be ignorant and ask a stupid question than to be plain Stupid and not ask at all" |
||||
Grogster Admin Group  Joined: 31/12/2012 Location: New ZealandPosts: 9512 |
Me WAY too slow!  Yes, if you don't clear the string you are using to suck the data from the buffer into, then....  EDIT: If it makes you feel any better, I fell into the same little trap when I started playing with the COM port buffers. Forgetting to clear strings when you are finished with them can cause some interesting head-scratching bugs. Smoke makes things work. When the smoke gets out, it stops! |
||||
| palcal Guru Joined: 12/10/2011 Location: AustraliaPosts: 1970 |
At the bottom of my last post I wrote Can any one advise. I get an error message at the VAR RESTORE line that it wants a variable but if I supply the variable it throws another error, can't remember what. "It is better to be ignorant and ask a stupid question than to be plain Stupid and not ask at all" |
||||
| erbp Senior Member  Joined: 03/05/2016 Location: AustraliaPosts: 195 |
You need to have done a VAR SAVE var [, var] ... before you can use VAR RESTORE. In VAR SAVE you specify the names of the variables that you want to have saved. a subsequent VAR RESTORE doesn't need (and won't accept) a list of variable names, it just restores the variables named in the previous VAR SAVE from their saved values. You can use VAR SAVE in multiple places within your program if you need to - just be sure to specify the same list of variables each time, otherwise you might end up with some rather unexpected results! Cheers, Phil. |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2409 |
you also need to clear D$: Open "COM1:9600" As #1 Information$="" ' ******** CLEAR BUFFER Do If Loc(#1)<>0 Then D$=Input$(1,#1) Information$=Information$+D$ ' Information$ contains all the data EndIf Loop Until D$=Chr$(13) D$="" ' ******** CLEAR END-OF-LINE FLAG Close #1 [ ... ] Pause 58000 ' ******** WAIT 58 SECONDS THEN LOOP and your pause statement at the end of the main loop needs to be slightly shorter than the pause you are using at the transmiting end, so that you get ready to start collecting the transmitted data just before the transmitting end starts sending it. cheers, rob :-) |
||||
| palcal Guru Joined: 12/10/2011 Location: AustraliaPosts: 1970 |
Thanks Robert I was having problems until I did as you said and cleared the end of line flag. Now running OK. @ erbp I don't see how I can do what you say, if I put a VAR SAVE at the beginning of the code so that the VAR RESTORE has something to restore, if I lose power, at start up Var Save will save a nil value and so nil will be restored. I probably have the VAR SAVE in the wrong place anyway as the manual says to only save about once per day so as not to wear out the flash memory. I have an RTC connected so will look at saving there but I would still like to know how to use VAR SAVE and VAR RESTORE. If I do use the "RTC SETREG reg,value" command what value do I use for reg. "It is better to be ignorant and ask a stupid question than to be plain Stupid and not ask at all" |
||||
Turbo46 Guru Joined: 24/12/2017 Location: AustraliaPosts: 1636 |
Hi Palcal, Geoff said in a post when I had a problem with VAR RESTORE: Maybe that is the source of your problem and perhaps a PAUSE before opening the com channel would help. Anyway saving to an RTC register would be better than wearing out the flash. Bill Keep safe. Live long and prosper. |
||||
| palcal Guru Joined: 12/10/2011 Location: AustraliaPosts: 1970 |
Looking at the DS3231 Datasheet it seems I can use any value from 0 to 222 to store a value in NVRAM. I might give that a go. "It is better to be ignorant and ask a stupid question than to be plain Stupid and not ask at all" |
||||
CaptainBoing Guru Joined: 07/09/2016 Location: United KingdomPosts: 2150 |
Hi Palcal. My datasheet doesn't mention any NVRAM in the 3231... could you post yours here? (do you mean the 3232?) cheers |
||||
bigmik Guru Joined: 20/06/2011 Location: AustraliaPosts: 2946 |
GDay Rob, All, You all know I am not much good at programming but why do you need the D$="" statement? The way I see it D$ would get reset to the next Chr to read when there is one to read.. I don't see the reason to clear it.. Can you please explain why (Just trying to learn a bit here) Kind Regards, Mick Mick's uMite Stuff can be found >>> HERE (Kindly hosted by Dontronics) <<< |
||||
| erbp Senior Member Joined: 03/05/2016 Location: AustraliaPosts: 195 |
Hi Palcal, Yes, you are right - my suggestion was way off course  I was going just on my memory of how I had used VAR SAVE/RESTORE in a project about a year ago. Obviously I should have confirmed my recollections by re-checking my code! And checking the Micromite Manual it does say that you can use VAR RESTORE without having previously saved any variables - I have also just re-tested on an E28 module running firmware 5.05.02 Beta release and I don't get any error reported when executing VAR RESTORE without any previous save. So, I don't know why you would be getting an error reported when you attempt to use VAR RESTORE. Sounds like for your particular requirement saving the rain value to a RTC register would be a better solution and not risk wearing out the flash. Apologies for the bum steer. Phil. |
||||
| palcal Guru Joined: 12/10/2011 Location: AustraliaPosts: 1970 |
@ bigmik I would also like to know... @ CaptainBoing Sorry it wasn't the data sheet it was this web site DS3231 @erbp I just tried again and get this error MM.Ver 5.04.01 I did find this in the Change Log for 5.04.01 "It is better to be ignorant and ask a stupid question than to be plain Stupid and not ask at all" |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2409 |
lets say the D$="" statement is not there... first time through the program will run correctly - the DO [...] Loop Until D$=Chr$(13) will keep going until a carriage return is received and when we drop out of the loop the variable Information$ will contain the data we are looking for. this data will be displayed and the program will then sit idle at the Pause 58000 statement until just before the next block of data is sent from the transmitting end. now, after the Pause 58000 statement we will loop back around to the beginning of the receive loop: Do If Loc(#1)<>0 Then D$=Input$(1,#1) Information$=Information$+D$ ' Information$ contains all the data EndIf Loop Until D$=Chr$(13) if there is no data coming in (we get there too early, or too late), then the If Loc(#1)<>0 Then [...] statement will be false (there is no data in the buffer) and the last thing stored in D$ (carriage return) will be unchanged. we will drop straight out of the receive loop, update the dispay with invalid data (at this point Information$ will be empty), and proceed to wait another 58 or so seconds. we will carry on like this until it just so happens that we open the serial port just at the exact same moment there is new data arriving from the transmitting end. does this make sense? cheers, rob :-) |
||||
| palcal Guru Joined: 12/10/2011 Location: AustraliaPosts: 1970 |
Thanks Rob I understand, Does anyone have a source for genuine DHT22 I have bought many and they either fail or are not accurate. The temperature seems OK but the one I am using now the humidity reads about 20% high. "It is better to be ignorant and ask a stupid question than to be plain Stupid and not ask at all" |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9512 |
About the only thing I would change with this code, is to leave the COM port OPEN. Then the buffer can hang onto ANY data received at ANY time, and the DO/LOOP will deal with it whenever it runs. Clearing D$ still aplies at the end of each run of the loop, but this just ensures that you ALWAYS catch all the data(provided you don't overflow the COM port buffer), and the messages just queue up in the buffer and can be processed on a FIFO(first in first out) basis. You then don't need to ever worry about making sure you open the port BEFORE the transmitter tries to send something, as the buffer will always catch any valid transmission. If closing and re-opening works for you, fine. But I have found the COM port buffers to be a thing of beauty for auto-queuing messages if you leave the port open. Just my 2c. Smoke makes things work. When the smoke gets out, it stops! |
||||
| palcal Guru Joined: 12/10/2011 Location: AustraliaPosts: 1970 |
Thanks for that Grogs it is working fine as is so I will leave as is. I scrapped the DHT22 because I found I had some HTU21D sensors that Davec166 put me onto some time ago. He generously shared his code and they seem to work well. Do you have any comment on the VAR RESTORE error I mentioned above, I tried the RTC SETREG command and whilst it ran OK it did not return the value I set. "It is better to be ignorant and ask a stupid question than to be plain Stupid and not ask at all" |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9512 |
I've never played with the battery-backed RAM in the RTC modules, but I expect others have. In fact, I think the latest MMBASIC even has a command just for that. I am using some AM3202 temp/humidity sensors, and they seem to work OK for me. How were you comparing DHT22's humidity to know it was out by 20%? This would be useful for me to test at my end too, as I don't want the same problem you are having. On VAR RESTORE, have you declared any array's FIRST? From the manual, page 75: "Saved arrays must be declared(using DIM) before they can be restored." Standard strings or other variables NOT arrays, will be created or overwritten when you use VAR RESTORE. It would seem that arrays are the only exception to that, and they must be specifically declared with DIM first, before you issue the VAR RESTORE command. That is about the only thing I can think of that would be causing this. I will have another look at your code on the previous page. Smoke makes things work. When the smoke gets out, it stops! |
||||
| Turbo46 Guru Joined: 24/12/2017 Location: AustraliaPosts: 1636 |
Palcal, I tried your SEND code with MMBASIC version 5.05.1. I had to comment out the HUMID instruction and the two RTC GETTIME instructions plus I have nothing connected to COM2 and I had no complaints when I ran the program. It printed three lines: 0 0 00:16:24 0 0 55 55172 every 30 seconds. Bill Keep safe. Live long and prosper. |
||||
| palcal Guru Joined: 12/10/2011 Location: AustraliaPosts: 1970 |
@Turbo46 That is what I would expect with no sensor or RTC, but did you still have VAR RESTORE commented out or did it run OK. @ Grogster I am only trying to save the variable RM$ that contains the monthly rainfalll in case of a power cut. "It is better to be ignorant and ask a stupid question than to be plain Stupid and not ask at all" |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9512 |
How many bytes long is RM$? It is always the same length? Smoke makes things work. When the smoke gets out, it stops! |
||||
| Page 2 of 3 |
|||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
