No idea. perhaps post your code then members can look at what you have, may be able to figure out why one works and the other doesn't.When I use them in a pgm the first one runs OK, but the second does not. Why?
It depends on what you are trying to achieve.I use the sleep function because I want to not having to change anything when I go from 16 LHz to 8 MHz. Is that OK?
No idea. Both of these work for me, send an "X" every 4 seconds or so up the download cable on the 18M2 I have so there's no obvious reason that nothing is sent for your code after the SLEEP.If I use "pause 16000", TX is carried out. If I use the second option, processing stops until next beat record . Why?
#Picaxe 18M2 #Terminal 9600 SetFreq M16 Pause 16000 SerOut C.3, N9600_16, ("Restart - Pause 1600", CR, LF ) Do Pause 16000 SerOut C.3, N9600_16, ( "X" ) Loop
#Picaxe 18M2 #Terminal 9600 SetFreq M16 Pause 16000 SerOut C.3, N9600_16, ("Restart - Sleep 2", CR, LF ) Do DisableBod Sleep 2 EnableBod SerOut C.3, N9600_16, ( "X" ) Loop
The DISABLEBOD is not necessary (it is only included to save the last few uA of supply current drain during very long periods of time) and is "Not Recommended" because it can allow the micro to "crash".2.: disablebod. sleep 4.enablebod. That also gives 4 sec
I use the sleep function ...... Is that OK?.
The problem with using SLEEP is that, as AllyCat noted, the accuracy of the sleep period is not certain. A "SLEEP 10" should nominally last 23 seconds, but could last anything from 11 to 46 seconds. In most cases it probably won't be so extreme but could be. "SLEEP 10" lasts 20 seconds on my PICAXE-18M2, 4 seconds shorter than on yours. A different 18M2 could easily last 4 seconds longer, 28 seconds.I also wanted to use sleep because that would allow me to change all 3 pgms from freq M16 to M8 without disturbing their synchronisation.
Your "Skip" label is whereWhen I say that the former does not work I mean that the pgm goes to Skip without receiving anything even though it has plenty of time to receive the transaction.
serinis supposed to branch to if no characters are received before "20000". Your description is accurate for the code shown.
It would seem to be an inter-byte gap timing issue. That "U" is being received correctly means it has caught that okay in both cases, and it's ready for the following back-to-back byte when using no timeout but not when using a timeout.I get the right result (U[C5] ) when I use "serin RXpin,HC12BaudRate,PreAmbleByte...." and some times the right result when I use "serin [16000,Skip], RXpin,HC12BaudRate,PreAmbleByteRec..." and other times I get U[F1]
C5 = 10100011 F1 = 10001111
1 0 1 0 1 0 1 0 1 0 1 0 0 0 1 1 ___ _ _ _ _ _ _ _ __________ |_| |_| |_| |_| |_| |_| |_| |_____| S 0 1 2 3 4 5 6 7 P S 0 1 2 3 4 5 6 7 P `-----------------' `-----------------'
1 0 1 0 1 0 1 0 1 0 0 0 1 1 1 1 ___ _ _ _ _ _ _ _ __________ |_| |_| |_| |_| |_| |_| |_| |_____| S 0 1 2 3 4 5 6 7 P S 0 1 2 3 4 5 6 7 P `-----------------' `-----------------'
Yes, K250 is the "alias" for a byte value (number) which you can check by running SERTXD (#K250) in the simulator (it should print "50"). So the compiler is quite happy with the syntax, but the program will not run correctly with a value of 250.In my test pgms I had a statement "setfreq 250". The compiler did not complain, but the pgm would not run. Only when I changed it to "setfreq K250" would the pgm run.
The program probably did run, just not how you expected it to, not in a way which delivered the results you wanted.It surprises me that I can compile a pgm that will not run.
Quite possibly, though I would have expected a few more mA. How calibrated is your equipment ?I did all this in order to save batteries, but it turns out that the consumption is 0.001 Amps whether I run at K250 or M16 and using "pause" all the while. Can that be right?
No, it doesn't seem to. We will update the online documentation.It occured to me, but I think the manual does not mention the effect of freq. on Timeout (it does with Pause).
Running at lower speeds will reduce power but the program execution will slow down. In the case of K31 this may be so slow as to allow the internal watchdog to timeout and reset the PICAXE before a command completes. This can particularly be the case with PAUSE commands and others which take longer to execute than the internal watchdog timeout period.To reduce power consumption of the Picaxe chip should one not reduce the freq. as much as possible - wether the Picaxe chip is computing or pausing? Going to K31 when pausing should do the job?
It is probably sensible to use #IFDEF-#ENDIF conditional compilation so they can be automatically included while debugging but removed from the final code.And I should comment out all of my SERTXDs out?