And no pun intended, take your time, be methodical, analyse, test, measure but mainly slow down and give yourself time to think.
If you are really stuck perhaps if you could extract the essential elements into a test program (one that does not require all the other elements) you could test more easily and also provide some code that is easy for others to have a quick look at.
Graham, I can write a little program that just gets the time and displays it.· I can·delete· the serined temp from the BS2E and the writing to the LCD and the writing to Hyper.· Would that reduce it to the "essential" elements?
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Yesterday is history, tomorrow is a mystery, and today is a gift.
Graham, I wrote a liitle program that just read the time and displayed it.· No temp from Stamp, no LCD, no menu, no nothing but read time and display it. I wrote:
It is displaying the time exactly every 60 seconds.·There is a little overhead in there so the display·increased 1 secomd in 36 minutes.· That's an overhead of 1000/36 = 27.7ms.· It's going to take a couple of days to add the other elements back in one by one, but I will keep running notes and send them to you when I am back to square one.
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Yesterday is history, tomorrow is a mystery, and today is a gift.
Sid,
Once you've figured out where the extra time goes, read the section of the Propeller manual on the WAITCNT statement in Spin, particularly the part on synchronized timing. There are ways to do timing that allow the overhead to overlap the time delay, but with what you were seeing in terms of weird timing, I didn't want to complicate things any more.
Mike
Graham and Mike, this is weird.· After 36 minutes the display increased 1 second, then it started increasing 1 second every 7 minutes.· Nothing was changed - I didn't even stop the program.
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Yesterday is history, tomorrow is a mystery, and today is a gift.
Graham, here is the program.· I added six lines so the Proto Board could communicate with Hyper.· The increased the overhad a bit - the display is now increasing a second every six minutes.
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Yesterday is history, tomorrow is a mystery, and today is a gift.
I think this is the basic gist of what you need to do:
repeat
cnt0 = cnt
do coms, reading seconds first then minutes then hours etc
waitcnt(clkfreq*30 + cnt0)
waitcnt(clkfreq*30 + cnt)
Basically you are taking a note of the clock before you do your communications this means that the first 30 second period includes the time taken to do the display stuff, this makes the latency irrelevant (as long as it is less than 30 seconds). This is what Mike was talking about in his last post.
Also notice I suggest that you read seconds first, this is the fastest changing variable and so you should read it as soon as possible. It is unlikely that a second will pass during the other reads but it may be just ready to change.
I made the two changes you suggested. A copy of Rev A is attached.
There was a slight change in the display. It increased 1 second in 25 minutes (was 1 in 24), then 1 in 16 (was 1 in 17), then 1 in 6 (same).
Now I’m going to add in the LCD writing routines. That writes 4 lines to the LCD two times (total of 8 lines), with a 250ms pause between each LCD line. I’ll send you a report.
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Yesterday is history, tomorrow is a mystery, and today is a gift.
As I expected, the display increased about 5 seconds with each read. I’m going to change:
cnto:= cnt
if key.gotkey
start2
waitcnt(clkfreq*30 + cnto)
if key.gotkey
start2
waitcnt(clkfreq*30 + cnt)
to read:
cnto:= cnt
if key.gotkey
start2
waitcnt(clkfreq*30 + cnto)
if key.gotkey
start2
waitcnt(clkfreq*25 + cnt)······‘5 sec decrease in total wait time
The display decreased 1 second in 6 minutes, then 1 second in 7 minutes, then 1 second in 7 minutes. I’m going to hold up on any more testing until you have read my posts and had a chance to comment on them.
A copy of the program with the LCD write – Rev B – is attached. Please note the extended wait in Line 229. This is to give me a chance to read the LCD before it changes.
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Yesterday is history, tomorrow is a mystery, and today is a gift.
Waitcnt waits until the clock equals the argument of waitcnt the argument is formed from the "current time" with a bit added on to provide the time the function waits for. When you do the cnt0:=cnt you are storing the current time to use after you have done your reads and writes, the clock keeps on ticking during this time.
So yes is should go right after the repeat before you do any of the other stuff
Graham, it looks like moving cnto to just after the repeat did the trick.· The display hasn't changed 1 second in an hour.· Now I'll go back to my original program, make the same change, and see what happens.· And thanks for explaining cnto - I didn't really know how it worked.· Course there is a lot of Spin that I don't understand how it works, but as long as I can figure out to use it, I'm happy.
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Yesterday is history, tomorrow is a mystery, and today is a gift.
Graham, I incorporated the cnto change into my original program.· The seconds display bounced around a bit - 01,00,00,01,02,01 and so on, but at the end of 30 minues the variation was 0, so that's good enough for me.· However, I was curious about the boucing, so I commented out the lines that got the temp from the Stamp and made the temp variables fixed values.· This display still bounced around, so with that, I just quit looking for the reason.· What I've got now is just fine.· Thanks for your help.
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Yesterday is history, tomorrow is a mystery, and today is a gift.
Newzed said...
And thanks for explaining cnto - I didn't really know how it worked. Sid
I just want to point out that Mike suggested that you read the bit of the propeller manual about syncronized delays (within waitcnt description) but you didn't, this would have explained it all to you.
Also when I gave you my initial solution I was careful to explain it well but I am not convinced your really read it and even after I asked you to read it again you still came back for the answer from me.
I hope you will understand that this can be really frustrating, I think you are a clever guy and you certainly have lots of enthusiasm but you really need to read what people are writing and to try and understand things rather than just jump to the solution. Now you do understand the waitcnt command you can see its really very easy, nothing confusing at all and I am sure you will be able to use it with much greater power than you had done before.
As for the jumping I don't know anything about that program but whatever it is you can probably work it out logically and perform tests with the same logic rather than random ones.
Correction, Graham.· There two lines that request data from the Stmp, and I had only commented out one of them.· I commented out the other and re-ran the program.· No more bouncing!!· Now I know that the Stamp portion is causing the bounce.· I don't think there is anything I cn do about that but I'll give it a good think - there is a way that I could reduce the Stamp transmission from two events to one event.· Maybe I'll try that.· As I said, right now I'm happy with what I've got.
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Yesterday is history, tomorrow is a mystery, and today is a gift.
Just to play devil's advocate ... I've "given up" a number of times over the years and restarted a project completely from "ground zero" ... In one case, I threw out all my notes as well ... ended up with a great result. Obviously, the trick is to start with a fresh, well rested and uncluttered mind ... and to really, deliberately not start down the same path again ... just solve the same problem. With software it's easier since there's no mess or clutter ... the bits really do disappear. With hardware it's messier and more work if you want to reuse the expensive pieces.
I changed the waitcnts to 40 and 20, but the display still bounces.· I disabled the Prop command that requests the data from the Stamp, set ad0 and ad1 to fixed values, and the display is rock-solid.·
Why?
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Yesterday is history, tomorrow is a mystery, and today is a gift.
The fact that you don't get any errors in the overall time means that your loop is working fine, but the time between the start of the loop and the time at which you measure the seconds must be changing probably due to variable times taken to talk to the stamp.
Make sure you get the times right at the start of the loop and ensure that you take the seconds first, then hours etc as I suggested before.
If that doesn't work post some code I don't really understand where the serial ins and outs are happening from your description.
Graham, I am attaching the complete program, less all the objects.· When I press G - see Line 161 - the program jumps to gettime - see Line 361 - gets the temp,·gets the time and date, then proceeds with the display and storage of the data.
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Yesterday is history, tomorrow is a mystery, and today is a gift.
Graham, I moved the two lines to just after the lines that read the clock and just before the lines that start the VGA display.· I'll let it run for a few minutes.
In the meantime, the computer on my workbench has Windows ME, and I do not have a spare VGA there.· I was thinking that if I could get the Proto Board to communicate with Hyperterminal via the Prop Plug on that computer, I could use Hyper as a subsitute for a VGA.· I have the Parallax USB Oscilloscope working there using Com4, but I am unable to write a Hyper program that works with the Prop Plug.· I think I need some kind of USB driver installed on the ME computer.· I plugged in the Prop Plug to the USB port just to see what would happen - in setting up a new Hyper program the only ports available are Com1 thru Com4, but Hyper could not open any of those.· Any suggestions?
The program has been running for 20 minutes and the display is rock-steady - no bounce.· Why did just moving those two lines correct the bounce problem?
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Yesterday is history, tomorrow is a mystery, and today is a gift.
Graham, don't worry too much about the ME/USB/Prop Plug thing.· I really wanted the Hyper so I could see what I was doing when I set the clock, but · I thought about it for awhile, then I modified my LCD display so that when I select the set clock option, the LCD displays essentially the same information as the VGA.· Tried it out and it works quite well.· I would have preferred Hyper because of its much higher visibility, but now the urgency is gone.· I'll putter along with this for awhile.
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Yesterday is history, tomorrow is a mystery, and today is a gift.
The program has been running for 20 minutes and the display is rock-steady - no bounce. Why did just moving those two lines correct the bounce problem?
Because those lines take time, so time will have passed before you read the time, possibly a slightly varying amount of time depending on the exact communications going on.
Graham, I liked the LCD display in setting the clock so much, I incorporated it into all the menu commands.· The method to clear the EEPROM had a fixed value to clear to, so I had to go into the program and change it if I ever wanted to clear past the programmed value.· I modified·the method·so now I can select the address I want to clear to, and all of the prompts are displayed on the LCD.· I can do anything on the bench, with the LCD assists, that I could do at the desk using the VGA.· Everything except change the program, of course.· And I'm not getting any bounce!
I think this completes this little project.· Now on to something new.· Thanks for all of your help ·and to Mike for his.
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Yesterday is history, tomorrow is a mystery, and today is a gift.
Comments
If you are really stuck perhaps if you could extract the essential elements into a test program (one that does not require all the other elements) you could test more easily and also provide some code that is easy for others to have a quick look at.
Graham
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Yesterday is history, tomorrow is a mystery, and today is a gift.
That is why they call it the present.
Don't have VGA?
Newzed@aol.com
·
··· waitcnt(clkfreq*30 + cnt)
··· waitcnt(clkfreq*30 + cnt)
It is displaying the time exactly every 60 seconds.·There is a little overhead in there so the display·increased 1 secomd in 36 minutes.· That's an overhead of 1000/36 = 27.7ms.· It's going to take a couple of days to add the other elements back in one by one, but I will keep running notes and send them to you when I am back to square one.
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Yesterday is history, tomorrow is a mystery, and today is a gift.
That is why they call it the present.
Don't have VGA?
Newzed@aol.com
·
Once you've figured out where the extra time goes, read the section of the Propeller manual on the WAITCNT statement in Spin, particularly the part on synchronized timing. There are ways to do timing that allow the overhead to overlap the time delay, but with what you were seeing in terms of weird timing, I didn't want to complicate things any more.
Mike
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Yesterday is history, tomorrow is a mystery, and today is a gift.
That is why they call it the present.
Don't have VGA?
Newzed@aol.com
·
Graham
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Yesterday is history, tomorrow is a mystery, and today is a gift.
That is why they call it the present.
Don't have VGA?
Newzed@aol.com
Basically you are taking a note of the clock before you do your communications this means that the first 30 second period includes the time taken to do the display stuff, this makes the latency irrelevant (as long as it is less than 30 seconds). This is what Mike was talking about in his last post.
Also notice I suggest that you read seconds first, this is the fastest changing variable and so you should read it as soon as possible. It is unlikely that a second will pass during the other reads but it may be just ready to change.
Graham
Graham:
Added six lines so Proto could talk to Hyper. Added four lines to waitcnt to permit key interrupt.
if key.gotkey
start2
waitcnt(clkfreq*30 + cnt)
if key.gotkey
start2
waitcnt(clkfreq*30 + cnt)
Display increased 1 second in 24 mins, then increased 1 second in 17 minutes, then increased 1 second in 6 minutes. Stopped read.
Cycled power off for about 5 seconds, then repeated read with NO changes to program. Display changes were the same – 1 in 24, 1 in 17 and 1 in 6.
I’m going to make the two changes you suggested and run the program again. I’ll send you the results.
I have attached a copy of the program used in the above test.
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Yesterday is history, tomorrow is a mystery, and today is a gift.
That is why they call it the present.
Don't have VGA?
Newzed@aol.com
Graham:
I made the two changes you suggested. A copy of Rev A is attached.
There was a slight change in the display. It increased 1 second in 25 minutes (was 1 in 24), then 1 in 16 (was 1 in 17), then 1 in 6 (same).
Now I’m going to add in the LCD writing routines. That writes 4 lines to the LCD two times (total of 8 lines), with a 250ms pause between each LCD line. I’ll send you a report.
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Yesterday is history, tomorrow is a mystery, and today is a gift.
That is why they call it the present.
Don't have VGA?
Newzed@aol.com
Graham:
As I expected, the display increased about 5 seconds with each read. I’m going to change:
cnto:= cnt
if key.gotkey
start2
waitcnt(clkfreq*30 + cnto)
if key.gotkey
start2
waitcnt(clkfreq*30 + cnt)
to read:
cnto:= cnt
if key.gotkey
start2
waitcnt(clkfreq*30 + cnto)
if key.gotkey
start2
waitcnt(clkfreq*25 + cnt)····· ·‘5 sec decrease in total wait time
The display decreased 1 second in 6 minutes, then 1 second in 7 minutes, then 1 second in 7 minutes. I’m going to hold up on any more testing until you have read my posts and had a chance to comment on them.
A copy of the program with the LCD write – Rev B – is attached. Please note the extended wait in Line 229. This is to give me a chance to read the LCD before it changes.
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Yesterday is history, tomorrow is a mystery, and today is a gift.
That is why they call it the present.
Don't have VGA?
Newzed@aol.com
has to go BEFORE you do the communications!!
Please read what I wrote again (notice "do comms") and have a think about it and the way waitcnt works
Graham
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Yesterday is history, tomorrow is a mystery, and today is a gift.
That is why they call it the present.
Don't have VGA?
Newzed@aol.com
·
So yes is should go right after the repeat before you do any of the other stuff
Graham
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Yesterday is history, tomorrow is a mystery, and today is a gift.
That is why they call it the present.
Don't have VGA?
Newzed@aol.com
·
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Yesterday is history, tomorrow is a mystery, and today is a gift.
That is why they call it the present.
Don't have VGA?
Newzed@aol.com
·
I just want to point out that Mike suggested that you read the bit of the propeller manual about syncronized delays (within waitcnt description) but you didn't, this would have explained it all to you.
Also when I gave you my initial solution I was careful to explain it well but I am not convinced your really read it and even after I asked you to read it again you still came back for the answer from me.
I hope you will understand that this can be really frustrating, I think you are a clever guy and you certainly have lots of enthusiasm but you really need to read what people are writing and to try and understand things rather than just jump to the solution. Now you do understand the waitcnt command you can see its really very easy, nothing confusing at all and I am sure you will be able to use it with much greater power than you had done before.
As for the jumping I don't know anything about that program but whatever it is you can probably work it out logically and perform tests with the same logic rather than random ones.
Good luck
Graham
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Yesterday is history, tomorrow is a mystery, and today is a gift.
That is why they call it the present.
Don't have VGA?
Newzed@aol.com
·
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Yesterday is history, tomorrow is a mystery, and today is a gift.
That is why they call it the present.
Don't have VGA?
Newzed@aol.com
·
Well you didn't give up posting.
Graham
······· 1 cool project·········
Complexity2· x
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
E3 = Thought
http://folding.stanford.edu/·- Donating some CPU/GPU downtime just might lead to a cure for cancer! My team stats.
I have one final question and then we'll move on to other things.
When the Prop is receiving data from the Stamp, the displayed seconds bounce arount a bit - +1, -1, 0, 0, +2, -1, and so on.· The Stamp serouts:
SEROUT so, baud1, [noparse][[/noparse] ad0/10,ad1]
and the Prop receives the data:
PUB gettemp
··· serialIn(7,stampBaud,sim#nInv,8)
··· ad0 := byteval
··· serialIn(7,stampBaud,sim#nInv,8)
··· ad1 := byteval
I have two waitcnt commands:
··· waitcnt(clkfreq * 30 + cnto)
··· waitcnt(clkfreq*30 + cnt)
I changed the waitcnts to 40 and 20, but the display still bounces.· I disabled the Prop command that requests the data from the Stamp, set ad0 and ad1 to fixed values, and the display is rock-solid.·
Why?
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Yesterday is history, tomorrow is a mystery, and today is a gift.
That is why they call it the present.
Don't have VGA?
Newzed@aol.com
·
The fact that you don't get any errors in the overall time means that your loop is working fine, but the time between the start of the loop and the time at which you measure the seconds must be changing probably due to variable times taken to talk to the stamp.
Make sure you get the times right at the start of the loop and ensure that you take the seconds first, then hours etc as I suggested before.
If that doesn't work post some code I don't really understand where the serial ins and outs are happening from your description.
Graham
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Yesterday is history, tomorrow is a mystery, and today is a gift.
That is why they call it the present.
Don't have VGA?
Newzed@aol.com
sendstrH(string("Date/Time/Temperature/Address: "))
could be after the reads of time as could the call to gettemp.
Did you try that?
Graham
In the meantime, the computer on my workbench has Windows ME, and I do not have a spare VGA there.· I was thinking that if I could get the Proto Board to communicate with Hyperterminal via the Prop Plug on that computer, I could use Hyper as a subsitute for a VGA.· I have the Parallax USB Oscilloscope working there using Com4, but I am unable to write a Hyper program that works with the Prop Plug.· I think I need some kind of USB driver installed on the ME computer.· I plugged in the Prop Plug to the USB port just to see what would happen - in setting up a new Hyper program the only ports available are Com1 thru Com4, but Hyper could not open any of those.· Any suggestions?
The program has been running for 20 minutes and the display is rock-steady - no bounce.· Why did just moving those two lines correct the bounce problem?
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Yesterday is history, tomorrow is a mystery, and today is a gift.
That is why they call it the present.
Don't have VGA?
Newzed@aol.com
·
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Yesterday is history, tomorrow is a mystery, and today is a gift.
That is why they call it the present.
Don't have VGA?
Newzed@aol.com
·
Because those lines take time, so time will have passed before you read the time, possibly a slightly varying amount of time depending on the exact communications going on.
Graham
I think this completes this little project.· Now on to something new.· Thanks for all of your help ·and to Mike for his.
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Yesterday is history, tomorrow is a mystery, and today is a gift.
That is why they call it the present.
Don't have VGA?
Newzed@aol.com
·