Inplementing calendar in 8 bit micro

Homework?

Google for 'Julian date' for starters.

Why? As far as I know, there are always 7 days in a week. If you know one day, you know all the rest.

I am sure I have had a couple of 6 day weeks, although the missing day has always followed the consumption of _some_ beer ;-)

For practical purposes in the western business world, that's probably right. But if you have a couple of hours to kill, browse

And hope you don't even have to get started on time zones.

I know there were a few exceptions, but practically insignificant in the modem world. Anyway, any uC can handle those exceptions.

Many real time clock chips keep track of the date internally. If that's all you need then it simplifies things dramatically.

To calculate the day of the week, look up Zeller's algorithm.

I posted a particularly compact form of calculating month lengths to comp.unix.shell a couple of months ago. Should be easy enough to find on Google Groups.

... snip ...

Tighter than a 12 byte array and exception code?

unsigned char mlgh[] = {31,28,31,30,31,30,31,31,30,31,30,31};

if (leap && (mon == 1)) monlgh = 29; else monlgh = mlgh[mon];

I think it might be a tad faster if "leap" were a byte that was set to either 0 or 1, that way you could have:

monlgh =3D mlgh[mon]; monlgh +=3D leap & mon;

Using the PIC C compiler, here's what I get for your code, CBFalconer:

MOVF leap, F BTFSC STATUS, 0x2 GOTO a DECFSZ mon, W GOTO a MOVLW 0x1d GOTO b a: MOVF mon, W ADDLW 0x24 MOVWF FSR MOVF INDF, W b: MOVWF monlgh

And here's what I get for mine:

MOVF mon, W ADDLW 0x24 MOVWF FSR MOVF INDF, W MOVWF monlgh MOVF leap, W ANDWF mon, W ADDWF monlgh, F

Except that doesn't work. Try it in Apr, Jun, Aug, Oct, Dec. of a leap year. Until 2100 the calculation of leap can be simplified to "leap = |(year % 4);".

Wups I didn't think of months that would have the lowest bit set.

That's why they say that premature optimisation is the root of all evil. Write code that works first. Then test it in practice. If it is too slow, profile it to see where the problem lies. *Then* consider source code optimisations where relevant.

too

Or then again you can always just optimise the code and then see if it works.

That's how you end up with code that works in January when you wrote it, works in February when you tested it, works in March during production of the systems, and fails in April when you've got hundreds of the systems installed at customer sites.

You have to *think* about what you write - there is no place in this field for a smart Alec who likes to write fancy code and is more obsessed with small and fast object code and absurd "portability" notions than in writing code that is clear, maintainable, testable, and actually *works*.

I hate "Me too" posts, so I'll have to go with "Amen, Brother!" Trying to micro-optimize during development is a fool's game.

While not wanting to defend the particular example under discussion I have suffered from code that was not optimised at all, where an aweful lot of it was written and run on a PC before it ever got to the embedded system. It was about 100 times too slow because it used floating point completely inappropriately because it seemed natural (to the programmer). Needless to say the target system did not have hardware support for floating point.

The point is that if you know, or a pretty sure, that an algorithm or ideom is *going to be* too slow then there is little point in writing it that way and then rewriting it when it turns out just so.

Peter

e=20

it=20

=20

o=20

LOL! Boy, does that ring a bell! I'm in the middle of converting an algorithm written and tested in MATLAB/SIMULINK on a PC for an embedded=20 Linux system where floating point ops are in software reached by kernel=20 exceptions. Sorting out all the MATLAB global variables, converting implicit array operations to iterative C code and modularizing some

om=20

ay=20

Mark Borgerson

True. I was thinking more along the lines of things like writing for-loops "backwards," counting down to zero in a possibly mistaken belief that a cycle or two might be saved at the compare step by testing against zero at the expense of readability.

Certainly one should take advantage of a knowledge of the target architecture, e.g., using a char for the loop index in an 8-bitter where the "as-if" rule applies and the compiler can determine that the index can remain as a single byte.

In my case, yes, but YMMV. Given suitably defined m and y the month's length is given by:

(m==2 ? 28+!(y%4)-!(y%100)+!(y%400) : 30 + (m%2 != m>7))

It might look a bit of a mouthful but most of the expression is checking for February and then determining whether it is a leap year or not, which needs doing however you do it. The key issue is whether (30 + (m%2 != m>7)) can be coded in under 12 bytes.