BeanieBots
Moderator
I wasn't as sharp eyed as Dippy but it proves my point about having only ONE point were sensors are read. Even if that is called many times by a subroutine.
readadc or readadc10
- Thread starter davidwf
- Start date
westaust55
Moderator
SERTXD is on page 153 in the latest version of the manual 2.
... it's the new Glass Polish I got from Ebay. I've stopped using it on my specs and now I can see.
It also reinforces the use of 'test prints' when the going gets tough. If you'd done test prints (sertxd) all over the place you'd have seen stupid numbers... and wondered why... and then looked closely.
PS. I think we've mentioned SERTXD enough times by now
Actually WestAust, to be precise: As of 13:25 on 12th Sept 2008 it IS on page 146 of the on-line BASIC Manual, and on page 153 (as you so beautifully point out) in the BASIC Manual with V5.2.1 .
If we're going to be pernickety lets do it properly eh?
(Gee, I hope I spelt that correctly...)
It also reinforces the use of 'test prints' when the going gets tough. If you'd done test prints (sertxd) all over the place you'd have seen stupid numbers... and wondered why... and then looked closely.
PS. I think we've mentioned SERTXD enough times by now
Actually WestAust, to be precise: As of 13:25 on 12th Sept 2008 it IS on page 146 of the on-line BASIC Manual, and on page 153 (as you so beautifully point out) in the BASIC Manual with V5.2.1 .
If we're going to be pernickety lets do it properly eh?
(Gee, I hope I spelt that correctly...)
Last edited:
BeanieBots
Moderator
It probably is, but the link at the top of the forum still shows it on page 146.
Dippy, I hope you're not using that polish on your Xtal Ball.
OK, done that...and eventually figured I needed to (and how to) turn the terminal screen on so I could actually see it !....looks damn useful stuff
What is the purpose of the ,13,10 at the end of the line ?
Also I am getting a column of data which then ocassionally turns into a continuous line (see attached "sertxd buffer output.txt") - seems like it could be missing a <CR> command .... have I missed something or am I trying to send too much / too fast - I have it reporting the value of a loop (see attached "sertxd listing.txt")
thanks
so it's still light then?
13,10 = ASCII cr/lf
Yes, I guess it's whipping in a bit fast.
If you'd done:
sertxd("line 105 still light",13,10 ) or sertxd("line 105 still light", cr,lf ) it wouldo it on a new line.
I'd have done sertxd("line 105 still light" , #w0,13,10)
And it implies that the ADC value never gets below dark_level.
Odd. Well, keep at it.
13,10 = ASCII cr/lf
Yes, I guess it's whipping in a bit fast.
If you'd done:
sertxd("line 105 still light",13,10 ) or sertxd("line 105 still light", cr,lf ) it wouldo it on a new line.
I'd have done sertxd("line 105 still light" , #w0,13,10)
And it implies that the ADC value never gets below dark_level.
Odd. Well, keep at it.
Last edited:
Pausing a running program
Only way I can see to do it is to de-power the cct otherwise you lose the terminal window
.....???? anyone ?????......
yes...or a pause function
Only way I can see to do it is to de-power the cct otherwise you lose the terminal window
.....???? anyone ?????......
Reset ???
OK, dumbass question I expect but I want to force a once only reset after the power is applied and before anything else happens so I looked in the manual (2 page 135) and found that you just enter the word reset
so, my listing now says
reset
main :
....the program....
when I run it or syntax check it, it says syntax error (on the reset line), the word reset is in black text, I'd have thought it should be blue ?
huh
OK, dumbass question I expect but I want to force a once only reset after the power is applied and before anything else happens so I looked in the manual (2 page 135) and found that you just enter the word reset
so, my listing now says
reset
main :
....the program....
when I run it or syntax check it, it says syntax error (on the reset line), the word reset is in black text, I'd have thought it should be blue ?
huh
Last edited:
Why use an op-amp when you can use a transistor.
But you can prolly get away with just a parallel resistor. Say…
“…I have noticed that under a constant light level they very considerably… 100uF cap across the LDR seemed to be the answer - EVEN WITH the buffered circuit (!)....don't ask me why”
Are you bench testing under artificial AC powered lights? I bet if you scope the LDR without the capacitor, you see a nice 50Hz sine wave. Also remember that the ADC essentially compares the voltage on the ADC pin with the voltage on the +V pin, so variation on either will effect readings. Also, figures received by your PC from the PICAXE ADC will be effected by the programming cable connection and will not represent accurate thresholds for not-connected-to-pc readings.
But you can prolly get away with just a parallel resistor. Say…
“…I have noticed that under a constant light level they very considerably… 100uF cap across the LDR seemed to be the answer - EVEN WITH the buffered circuit (!)....don't ask me why”
Are you bench testing under artificial AC powered lights? I bet if you scope the LDR without the capacitor, you see a nice 50Hz sine wave. Also remember that the ADC essentially compares the voltage on the ADC pin with the voltage on the +V pin, so variation on either will effect readings. Also, figures received by your PC from the PICAXE ADC will be effected by the programming cable connection and will not represent accurate thresholds for not-connected-to-pc readings.
Well spotted that man, I wondered when you'd see my deliberate mistake
...I have now made all the read commands "readldr" and put them in one sub-routine as suggested by yourself and Beaniebots...I can see the benefit of this now.I have also put loads of sertxd lines in and, again can see the benefit of seeing what is happening and when.
Guess I must be picking this up gradually
THANK YOU all once again for your help and suggestions, once finalised I will of course re-submit the project.
....ps....ongoing testing looks like the ADC may function OK with just the LDR (slugged by a 100uF cap) and an 82K source resistor but I am still finalising it.
Dave F
"de-power"... love it.
Seriously though, as I haven't heard any advice from the Old Lags (and I'm sure some have read it) re; Controlling Data Displayed on the terminal window:-
Technical, how about it? A button on the Terminal Window to control the display. So you can stop great fast lumps of serial so you can take a quick squiz?
(Though I guess if we're going down the "de-power" route I should say a "snapshot" or a "time-halted-data-visualisation")
Seriously though, as I haven't heard any advice from the Old Lags (and I'm sure some have read it) re; Controlling Data Displayed on the terminal window:-
Technical, how about it? A button on the Terminal Window to control the display. So you can stop great fast lumps of serial so you can take a quick squiz?
(Though I guess if we're going down the "de-power" route I should say a "snapshot" or a "time-halted-data-visualisation"
)....or perhaps directing it into a file so you can save and go over it later ?
I (obviously
) don't know how to do it but I am sure it can't be that difficult - I seem to recall some comms programs have the facility of a log file........or perhaps directing it into a file so you can save and go over it later ?
- yes, that would be nice.
I assume "Copy Input Buffer" stuffs it into clipboard?
Another option saying "Send input Buffer to..." and a File Option would be nice, yes.
May I ask a d/a question too David.
Why do you want to do that at the start of the programme?
- yes, that would be nice.
I assume "Copy Input Buffer" stuffs it into clipboard?
Another option saying "Send input Buffer to..." and a File Option would be nice, yes.
May I ask a d/a question too David.
Why do you want to do that at the start of the programme?
Last edited:
Yes it appears to....but only the visible part at the time you request it
Seemed like a good idea at the time.....also when you have the terminal window open it seems to miss capturing the first few operations......I am thinking a reset after the prog starts would overcome this
Edit.....I put a pause 2000 at the top of the program and it seems to have delayed it enough for the terminal window to initialise OK...sorted.
Still interested to know why reset fails syntax though....and another problem I noticed is that the PICAXE program seems to intermittently lock up when I am using sertxd, needing to close the whole program down and restart
Any ideas on that please
Last edited:
"the PICAXE program .."
- is that the code on your PICAXE or the Programme Editor?
For testing, and I know it's inefficient, but I'd be tempted to put in a Pause or a few extra lines so that data wasn't sent so often.
... yes I was going to suggest a pause at the start. That's what I do when doing testing.
I forget which PICAXE you are using but BASIC Manual says 'reset' only for X1s and the mysterious X2s. Simulates OK.
- is that the code on your PICAXE or the Programme Editor?
For testing, and I know it's inefficient, but I'd be tempted to put in a Pause or a few extra lines so that data wasn't sent so often.
... yes I was going to suggest a pause at the start. That's what I do when doing testing.
I forget which PICAXE you are using but BASIC Manual says 'reset' only for X1s and the mysterious X2s. Simulates OK.
.... the program editor - which is then sent to the PIC with F5 and the program editor then locks up on the PC (and on my laptop), both are using the USB lead as I don't have any serial ports
I am using a PIC18X - that may explain it then !
Last edited:
Certainly if you try to send too much serial data back from a picaxe it will lock up.
But you can't read the data that fast anyway, unless you have super x-ray eyes coupled to a 50Ghz brain!
Some generic coding principles. I like to build up a program in stages using subroutines that have been tested and are known to work. So you might have a very simple sub, and sometimes you have to test it line by line. Many times I've taken code and added "pause 2000" and then "debug" (or sertxt) between every line of code. Even then, it can get confusing. Sometimes you have to use "debug" then "end", and then really go through each of the registers carefully to check things are exactly as they should be at that point in the program.
Once a subroutine is working, delete the pauses and debugs and ends one by one, and when it is working perfectly, add a comment to that effect.
Re the reset, I'm not sure I understand the question. If you want to restart a picaxe, why not have "start:" at the beginning, and do a "goto start" somewhere in the code. Reset also resets variables etc, but you can do that in code. Indeed, I tend to do that anyway at the beginning of a program so I know what the variables are. Or am I misunderstanding something?
But you can't read the data that fast anyway, unless you have super x-ray eyes coupled to a 50Ghz brain!
Some generic coding principles. I like to build up a program in stages using subroutines that have been tested and are known to work. So you might have a very simple sub, and sometimes you have to test it line by line. Many times I've taken code and added "pause 2000" and then "debug" (or sertxt) between every line of code. Even then, it can get confusing. Sometimes you have to use "debug" then "end", and then really go through each of the registers carefully to check things are exactly as they should be at that point in the program.
Once a subroutine is working, delete the pauses and debugs and ends one by one, and when it is working perfectly, add a comment to that effect.
Re the reset, I'm not sure I understand the question. If you want to restart a picaxe, why not have "start:" at the beginning, and do a "goto start" somewhere in the code. Reset also resets variables etc, but you can do that in code. Indeed, I tend to do that anyway at the beginning of a program so I know what the variables are. Or am I misunderstanding something?
Last edited:
I am trying to see the result of a continuing READADC function - maybe that's the reason
....which is precisely why I asked whether a "pause" function or a "write to file" option could be added to the terminal program window !
Thanks for the programming tips
demonicpicaxeguy
Senior Member
assuming hyper terminal is installed you can use that to capture everything to a text file that way you avoid the limitations of the clipboard and the programming editor terminal textbox
Aha sounds good....any clues as to how please - I am not up to speed on setting up HT although I have used it - I am using the USB interface lead (no serial ports)
Thanks
Fire up hyterterminal. Select a name (you can find the little .ht file it creates, then drag a shortcut to the desktop so next time you don't need to add all the settings - just click on that). Select your com port. That might be a bit tricky if you are using USB, but it will be the same number as the com port in the picaxe editor settings (View/Options/Serial tab). For real serial connections, it usually is COM 1.
Now set up the baud rate to 4800, 8 data bits, no parity, one stop bit and set Flow Control to none.
If text starts appearing on the screen because the picaxe is sending it, you can go to the Transfer menu and "save to text file".
However, this does seem the hard way of doing things. Just put pauses in your code. Make them long enough that you really can check things are doing what they should.
Now set up the baud rate to 4800, 8 data bits, no parity, one stop bit and set Flow Control to none.
If text starts appearing on the screen because the picaxe is sending it, you can go to the Transfer menu and "save to text file".
However, this does seem the hard way of doing things. Just put pauses in your code. Make them long enough that you really can check things are doing what they should.
demonicpicaxeguy
Senior Member
just don't forget to close the picaxe program editor as it will not release the com port until you do
BeanieBots
Moderator
I think post 110 on "how to read an LDR" says it all really.
Enough theory, let's try it shall we?
Enough theory, let's try it shall we?
Snapshot / Snipshot.
Pauses are, as advised, the best.
And to read or preserve the display for analysis:
Vista only.
Open the Snip tool. Minimize.
Run the Picaxe program, with Sertxd.
Restore the Snip tool. Press New.
The display freezes, but the program continues.
Press New again, to continue.
Other Windows: Use ALT PrtScr and paste.
(But a lot more fuss).
e
Pauses are, as advised, the best.
And to read or preserve the display for analysis:
Vista only.
Open the Snip tool. Minimize.
Run the Picaxe program, with Sertxd.
Restore the Snip tool. Press New.
The display freezes, but the program continues.
Press New again, to continue.
Other Windows: Use ALT PrtScr and paste.
(But a lot more fuss).
e
This IS post 110 ???
I replied to that yesterday - post #95 ...has it gone un-read ?
As above !
perhaps this thread has got too big ?
Glad to hear it works, as I must confess I didn't actually test it first!
As mentioned before you still need to shut down the programmer to hand over control of the com port. And swapping back and forth between hyperterminal and the picaxe programmer is going to be a real pain.
Personally I'd be using this if I was debugging an LDR.
main:readadc n,w1' where n is the input pin.
debug
pause 1000
goto main
As mentioned before you still need to shut down the programmer to hand over control of the com port. And swapping back and forth between hyperterminal and the picaxe programmer is going to be a real pain.
Personally I'd be using this if I was debugging an LDR.
main:readadc n,w1' where n is the input pin.
debug
pause 1000
goto main
Actually I found it easier to switch between them as you can't delve into the listing to see what is happening or make any changes without closing the terminal window first !
Obviously you will have to close down HT before downloading again but I still found it easier.
Is it possible (or feasible) to add a time stamp to the sertxd command - either in terminal window or (better for me) using HyperTerminal, either real time or elapsed time from startup ?
It would be useful to be able to leave it running (monitoring the ADC value), doesn't need to be super accurate, just an indication
thanks
It would be useful to be able to leave it running (monitoring the ADC value), doesn't need to be super accurate, just an indication
thanks
Sure. You need the real time clock chip (and its battery). The instructions are in the manual. Then read the hour/minute/second and add this to the sertxd text.
If you don't need a super accurate clock, you can set up delays and counters. Eg if you have a main loop that has a pause 1000 in it then it will tick once a second. Increment a counter and when it gets to 60, reset it and add one to a minute counter. Then hours, then days. You can tweak the 1000 value to get running very close to accurate. I like to flash a led once a second and then listen to my watch ticking and if the flash is getting ahead of the clock, change a variable slightly. Once they stay in phase over a minute then it is getting pretty accurate.
If you don't need a super accurate clock, you can set up delays and counters. Eg if you have a main loop that has a pause 1000 in it then it will tick once a second. Increment a counter and when it gets to 60, reset it and add one to a minute counter. Then hours, then days. You can tweak the 1000 value to get running very close to accurate. I like to flash a led once a second and then listen to my watch ticking and if the flash is getting ahead of the clock, change a variable slightly. Once they stay in phase over a minute then it is getting pretty accurate.
Just found this on another thread
http://www.selmaware.com/selmaDAQ/home.htm
haven't tried it (yet) but it looks promising