View previous topic :: View next topic |
Author |
Message |
njepsen
Joined: 13 Aug 2007 Posts: 469
|
Posted: Sat Aug 06, 2022 6:17 am Post subject: sysec() |
|
|
I am unsure on the use of the var = sysec() commands set.
In the code below, several times per day, I get the time from a server and use the mm,hh,ss,DD,MM,YY variables to update time$ and date$. The var my_secL is used to update time$ every 1 second.
The following is a snip of my relevant code.
Code: |
'****************************************
$regfile = "m1284pdef.dat"
$crystal = 9830400
$framesize =1500
$hwstack = 400 '
$swstack = 400
.
Config Timer1 = timer , Prescale = 1024 '
On Timer1 Timer1overflow
enable timer1
Config Clock = User
Config Date = DMY , Separator = SLASH
dim my_secL as long
'main loop:
do
'lots of code
' several times per day , get real time from server and update my variables hh, mm,ss,YY,MM,DD
disable interrupts
time$ = hh:mm:ss
date$ = DD/MM/YY
enable interrupts
my_secL = sysec()
loop
'******************************************************************************
timer1overflow:
timer1 = 55936
Incr my_secl
time$= time(my_secL)
return
'*************************************************************************************** |
My questions is:
which is the correct instruction: Code: |
my_secL = sysec()
'OR
my_secL = sysec(time$,Date$)
| because the help seems to suggest that both will work because every time I update Time$ and date$ in the 1 sec ISR, the system variables _sec,_Hour,_min are updated automatically (according to the help) and this target = sysec() shouldnt need any parmeters??
(BASCOM-AVR version : 2.0.8.5 ) _________________ Neil |
|
Back to top |
|
|
MWS
Joined: 22 Aug 2009 Posts: 2262
|
Posted: Sat Aug 06, 2022 8:25 am Post subject: Re: sysec() |
|
|
njepsen wrote: | which is the correct instruction: Code: |
my_secL = sysec()
'OR
my_secL = sysec(time$,Date$)
|
| Version 1 does implicitly the same which version 2 explicitly does with $-parameters.
2 is suitable for determining syssec of a targeted date/time, not necessarily the actual one.
If you want to set up an alarm, you would use version 2 and create syssec_alarm, which constantly is compared with actual syssec.
But it's well described, why the uncertainty?
Quote: | 1. Without any parameter. The internal Time and Date of SOFTCLOCK (_sec, _min, _hour, _day, _month, _year) is used.
...
3. With a time-String and a date-string. The time-string must be in the Format „hh:mm:ss". The date-string must be in the format specified in the Config Date statement |
Quote: | suggest that both will work because every time I update Time$ and date$ in the 1 sec ISR, the system variables _sec,_Hour,_min are updated automatically |
Every time a read access to time$/date$ is issued, the internal variables _sec, _min, a.s.o. are read and time$/date$-string is composed and updated.
Update is always done before time$/date$ is evaluated or assigned by/to other code.
Every time a write access to time$/date$ is issued, the new time$/date$-string is read and the internal variables _sec, _min, a.s.o. are calculated and updated. |
|
Back to top |
|
|
njepsen
Joined: 13 Aug 2007 Posts: 469
|
Posted: Sun Aug 07, 2022 7:05 am Post subject: |
|
|
Thanks for your input mws. Valuable as usual.
Quote: |
But it's well described, why the uncertainty?
Quote:
1. Without any parameter. The internal Time and Date of SOFTCLOCK (_sec, _min, _hour, _day, _month, _year) is used.
...
3. With a time-String and a date-string. The time-string must be in the Format „hh:mm:ss". The date-string must be in the format specified in the Config Date statement |
Thats my point - its not actually all that clear (to me), because maybe (?) - _sec,_min a.s.o. (the six variables) could point to a different date and time than time$ and date$.
That is until you read the help under Time$ which tells us that these _sec,_min,_hour are updated as soon as time$ is changed or assigned.
But is it possible that any of the six var can be changed without updating time$ and date$ - you say that when time$ is read, it accesses the 'six' and updates itself before giving up its answer,
Quote: |
Every time a read access to time$/date$ is issued, the internal variables _sec, _min, a.s.o. are read and time$/date$-string is composed and updated.
|
but I haven't managed to find this in the help anywhere??
If your summation is correct, and I'm sure it is and it certainly is logical that it would work that way, then it is therefore not possible that time$ and date$ can be out of sync with the 'six' variables. Therefore - why do we even have the option of 1 and 3 when they both do the same job. Hence my question. Does one use fewer machine cycles ? is one option faster or with less overhead etc _________________ Neil |
|
Back to top |
|
|
MWS
Joined: 22 Aug 2009 Posts: 2262
|
Posted: Sun Aug 07, 2022 10:00 am Post subject: |
|
|
njepsen wrote: | Thats my point - its not actually all that clear (to me), because maybe (?) - _sec,_min a.s.o. (the six variables) could point to a different date and time than time$ and date$. |
Think about the internal vars being the clockwork and time$/date$ as its hands.
The internal six belong to time$/date$ only and vice versa.
Quote: | But is it possible that any of the six var can be changed without updating time$ and date$ |
The internal six - if not user-code accesses them directly - are only accessed by softclock code. *
As already said, update of time$/date$ happens in the moment of their access.
Quote: | but I haven't managed to find this in the help anywhere?? |
Disassembling to machine code tells such.
Quote: | If your summation is correct, and I'm sure it is and it certainly is logical that it would work that way, then it is therefore not possible that time$ and date$ can be out of sync with the 'six' variables. |
Glitches are possible, as with any variable being accessed in interrupt- and as well as in user-code.
You made already time$/date$ access atomic, I would suggest to include my_secL = sysec() into the atomic block.
Both this and interrupt code may access the six internals at the same time, which may result in said glitches.
Quote: | Therefore - why do we even have the option of 1 and 3 when they both do the same job. |
Explained it already. Version 1 implicitly and only uses time$/date$ as parameters, version 3 gives the freedom of using my_time/my_date to calculate any desired system second. However by using time$/date$ as parameters with version 3, you make a version 1 out of it.
Quote: | Does one use fewer machine cycles ? is one option faster or with less overhead etc |
Don't know. If of interest for you, run some versions within the simulator, use breakpoints, bottom left you see executed cycles, right-click resets them.
* In softclock mode 'user' no other than user created code accesses the internal six time and date vars.. |
|
Back to top |
|
|
njepsen
Joined: 13 Aug 2007 Posts: 469
|
Posted: Sun Aug 07, 2022 11:52 pm Post subject: |
|
|
Thanks MWS. Great help.
neil _________________ Neil |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You cannot download files in this forum
|
|