Voting resources, early voting, and poll worker information - VOTE. ... Adafruit is open and shipping.
0

Monochron, the next generation?
Moderators: adafruit_support_bill, adafruit

Please be positive and constructive with your questions and comments.

Monochron, the next generation?

by Algolosaur on Sat May 08, 2010 2:10 pm

While awaiting word of the return of Monochron, I have seen my concept of new firmware undergo several mutations. From variations on the display (an abacus font), to alternate use of the hardware (a Game of Life), to new devices entirely (a tide calculator), I am finally at the stage of desperation where I am doing something actually ~useful~.

The Algolosaur is prone to night blindness. Monochron should be able to handle a twilight calculator. That would be useful.

So far, that little project has been more fun than I usually have without needing extensive hospitalization. Even got to wrassle me a bull FORTRAN. And I still haven't got the hardware.

Well, to the point, and I actually have one.

These "second generation" projects have two common dimensions. They would benefit from having the RTC keep GMT instead of local time, and they require a set of parameters (latitude, longitude, GMT offset, DST rules, ...) which suffer from weak definitions and which seem a near perfect application of the EEPROM.

As far as weak definitions, everybody knows that longitude is negative if it is West (East). And everybody knows that you add (subtract) the GMT offset to get local time. So. It would be good if the necessary truces could be reached early so various projects might be blendable.

As for the EEPROM, things like the Civil Twilight calculator require geographical location information. Since the EEPROM can be programmed separately from the program flash, it seems to me to be an ideal place to stash one or several place descriptions. While I have been happy enough using a hacked version of avra, it does get tacky when you try to put together floats. So, "I have wrotten little program" to produce .hex files for avrdude.

Currently it has more than a few bugs and is gcc on a G5 PPC. I expect to port it over to x86 Linux in a week or so. Windows I cannot do. As a veteran of the Endian Wars, I fear there may be more than a simple changing of the end of line character and re-compile involved. [gcc floats on the G5 and AVR have the same format except for the little detail of byte-reversal. I haven't looked at x86 yet.] Perhaps someone would be interested in doing a Windows port.

The program takes input such as:

Code: Select all | TOGGLE FULL SIZE
org      $0100

char[32]   "Trondheim  Norway"
float      63.42972      //  longitude
float      10.39333      //  latitude
float      -1         //  GMT offset
int      2         //  EU DST rules
char[6]      "CET"         //  Standard Time
char[6]      "CEST"         //  DST

and produces an Intel Hex file:

Code: Select all | TOGGLE FULL SIZE
:1001000054726F6E646865696D20204E6F727761FE
:100110007900000000000000000000000000000066
:1001200009B87D42144B2641000080BF02004345C0
:0A0130005400000043455354000042
:00000001FF

Currently, it has reached the "Worked once in a row!" threshold.


If we can get this right perhaps we can manage a blending of code-head skills and actual artistry to produce things like a traditional Japanese hour clock. (They had variable length hours based on daylight length, I get the numbers free with the twilight code I'm messing with, but I doubt very much I could produce a decent display). Or lunar calculator code to produce any of the traditional and ritual lunar calendars (here the graphic display offers the possibility of appropriate alphabetics). Mission time clocks for fans of NASA, ESA, JAXA, ISRO and such...

I see many possibilities. Monochron is not just a clock, it is also a computer.


Algolosaur
Veritas Vos Fugere Facet
Algolosaur
 
Posts: 67
Joined: Sun Apr 05, 2009 11:29 am
Location: Butler PA

Please be positive and constructive with your questions and comments.