Fix for Day of Week-Bug in SNTP - W5100/W5200 driver
msrobots
Posts: 3,709
It took me a while to figure this out. The day of the week is 2 days off.
So the writeTime method of S35390A_RTCEngine needs 1-7 for Sunday to Saturday.
Inside the clock it is using 0-6 but the writeTime-method subtracts 1 from the day of the week before setting.
The HumanTime method calculates the days since January 1 1900 a Monday.
So to calculate the correct weekday we need to take one day more to calculate the correct modulus starting at Sunday not Monday.
And we need to add 1 to have the correct value from 1-7 instead 0-6.
voila!
now the weekday is correct
Enjoy!
Mike
So the writeTime method of S35390A_RTCEngine needs 1-7 for Sunday to Saturday.
Inside the clock it is using 0-6 but the writeTime-method subtracts 1 from the day of the week before setting.
The HumanTime method calculates the days since January 1 1900 a Monday.
So to calculate the correct weekday we need to take one day more to calculate the correct modulus starting at Sunday not Monday.
And we need to add 1 to have the correct value from 1-7 instead 0-6.
PUB HumanTime(Offset,TimeStampAddress)|i,Seconds,Days,Years,LYrs,DW,DD,HH,MM,SS,Month,Date,Year Seconds := long[TimeStampAddress] + Offset * 3600 Days := ((Seconds >>= 7)/675) + 1 '<- Days since Jan 1, 1900 ... divide by 86,400 and add 1 ' DW := (Days-1) // 7 ' <--- wrong starting at Monday and giving 0-6 DW := (Days // 7) + 1 ' <--- correct Sunday-Saturday and 1-7
voila!
now the weekday is correct
Enjoy!
Mike
Comments
I was recently alerted to an issue via email related to the UDP protocol and multiple clients. I've been meaning to jump back into the code base - refactor, add comment, write docs, fix the UDP bug.... On the other hand, I really really want to convert the code base to C. Plus I'd like to move the buffer pointer logic from SPIN to PASM. Lot's of wants and little time.
I appreciate the feedback Mike and I can tell ya how much I appreciate that you're using the new driver.
If you don't mind, what are you working on?
They (an him) are using some microcontrollers called c-control from a German company called Conrad. As far as I was able to find out they are something like basic-stamps. (BASIC++ ...?...anyone?)
My goal now is to get them to use Propellers instead. So I am sneaking in some spinnerettes to connect those c-controls to the Ethernet (prob. just intranet) and then to some software I will write for them to capture 'live' data out of the production into a database.
Small step but right direction. The main hindering factor is the language-barrier - none of them is good enough in the English language to read/understand the Propeller documentation.
That Pharma-Company is something like the German version of a startup and still going strong. So there is room to grow and I am sure they will be better off with the Propeller.
IMHO the main problem with the spin code is that the prop-tool is not removing unused functions/methods. (For example the SNTP object: 322 longs. reduced to what we use: 152 longs). Thus we are running out of space. I am not at all a fan of C/C++. All those decades of programming for a living I was able to avoid it. Not that I can't program in C, I can and I did - but just for small stuff at home, never at work.
Working mostly on IBM/370s in Assembler and COBOL for the first decade of programming can mess with your mindset. So I have a hard time with C. Not verbose enough for me. On the other hand I am programming c# since net-framework 1.0 beta so C is not really a hurdle. Its just that most source in c is so ugly to read.
I do understand Parallax's move to C but I personally prefer Spin/Pasm over C/GAS.
But on the third hand it might be time to jump that hurdle and embrace C on the propeller, but I am not sure if I want to.
Because I know myself. I would start to do all the translation work to German and spend all my time with the tools instead of programming for fun.
Enjoy!
Mike
P.S.
and there is that open-source project OpenCobol providing C source and runtime to compile COBOL to C...