GP2X Rtc Module

[dominicbeesley]

One of the more annoying things (for a dev) on the gp2x is the lack of Real Time Clock. I was wondering if any of you would find the following useful:

A module / deamon that records the current time (every second / ten seconds / configurable) to a file in nand memory. On a reboot, load the last recorded time increment by a preset (an hour / configurable) amount and set the RTC to this?

This will not give us a Real Real Time Clock but at least would make time go forwards, meaning the file date will mean something (and stop some of the weirdness I've been encountering!)

Questions
========

1) Is this useful?
2) Module or daemon?
3) Is there any penalty for lots of NAND writes (i.e. does it wear out easily?!?)
4) Is there anywhere better to store the information
5) Is there something better already?

Cheers

Dom

 

[___]

It is dangerous to write to the NAND. It only allows a certain number of writes before it wears out. Not a good idea.

 

[Daid]

Last time I looked it was something like 10.000 writes for flash memory, but I could be of by a 0

 

[PokeParadox]

Last time I looked it was something like 10.000 writes for flash memory, but I could be of by a 0

The NAND writes thing is more paranoia than anything. But just don't abuse writes to it. The main reason for this being since it is embedded in the GP2X it's difficult to replace...

It's better to write to the SD card.

 

[sehs33]

A better solution I guess is to let users input the time manually everytime they switch on the system or run the application that needs time, a default value can be set, so users can skip the time input if they are not interested in rtc features.

God, GPH only needed a damn battery

 

[Alex.]

I agree, the absence of a RTC takes a bit away from the 2X. Imagine the possibilitis of also using it as a PDA, as well as for a lot of other software...

- Alex

 

[BradN]

If GPH had exposed the battery backup pins, one could probably connect up a button cell or supercapacitor, but I kinda doubt they did.

 

[torpor]

i think it'd be more productive to just have a quick app insert itself in the bootup which allows the user to enter the date/time on boot/start .. maybe a hotkey to bypass it when needed .. i don't for one like the idea of putting a timestamp on NAND and trying to calcute from that point on ..

really too bad about the RTC thing ..

 

[dominicbeesley]

i think it'd be more productive to just have a quick app insert itself in the bootup which allows the user to enter the date/time on boot/start .. maybe a hotkey to bypass it when needed .. i don't for one like the idea of putting a timestamp on NAND and trying to calcute from that point on ..

really too bad about the RTC thing ..

I started to do an enter date thing - but got hacked off with it about the third time I reset! I really just want to make sure that newer files get a newer date (I've had all sorts of issues with software getting confused after a reset.)

I guess for now I'll:
Give the user the option to set date at boot up (or press any key to continue with incorrect but sequential date)
Store the date in a 1k ring buffer in the root of the SD card if present.
Only store it once every 10 minutes by default with a 20 minute advance at boot time.

I think I may also look at hacking a capacitor onto the board!

 

[Daid]

How about reading the current time from the SD on boot, at a day, then write it back and don't think about it again. Time would advance then, if you only care about that files get newer and not about the actual time then that would be enough.

 

[BradN]

How about this idea... Scan the filesystems and find the most recent changed file (I believe on linux filesystems you can just check the last modified time for the root of the partition, not sure for fat32 though). It certainly can't be that slow to scan through a flash device anyway... no seek times and all. This could be a better approach, since files could be modified say, in a card reader, and this wouldn't be noticed unless it was actually scanned for.

I just checked, and it appears modification times don't automatically propagate to the root, at least on my gentoo machine with reiser3.

 

[Alex.]

The only "true" solution would be an SD card with a built-in battery-powered clock. That would provide a clean solution, although an improbable one

- Alex

 

[BradN]

Serial clock module wired to the RS-232? Could make debugging more problematic, but one could include a physical switch to disable it.

 

[dominicbeesley]

How about this idea... Scan the filesystems and find the most recent changed file (I believe on linux filesystems you can just check the last modified time for the root of the partition, not sure for fat32 though). It certainly can't be that slow to scan through a flash device anyway... no seek times and all. This could be a better approach, since files could be modified say, in a card reader, and this wouldn't be noticed unless it was actually scanned for.

I just checked, and it appears modification times don't automatically propagate to the root, at least on my gentoo machine with reiser3.

Looking at the gp2x filesystem this is a no - go. - virtually nothing seems to get written. Nearly anything that can get written to (/var /tmp are on a tmpfs (which gets wiped on a reset by the looks of things)

Nice idea though

I think I'll go for the 10 minutes write idea, that should give 10*1 million minutes == 19 years continuous life for my SD card - I can live with that! Configurable to once per boot write (a bit better, unless I'm developing my own software in which case I tend to reboot more than once every 10 minutes :unsure: )

Dom

 

[Dingo_aus]

From memory there is an I2C bus inside the GP2X, all you need to do is hook up a Dallas RTC chip and it will handle the battery backup (Li-on cell) and hold the time. Then just access the time via Linux's i2c routines. Would have dates and leap years etc etc

 

[BradN]

How about this idea... Scan the filesystems and find the most recent changed file (I believe on linux filesystems you can just check the last modified time for the root of the partition, not sure for fat32 though). It certainly can't be that slow to scan through a flash device anyway... no seek times and all. This could be a better approach, since files could be modified say, in a card reader, and this wouldn't be noticed unless it was actually scanned for.

I just checked, and it appears modification times don't automatically propagate to the root, at least on my gentoo machine with reiser3.

Looking at the gp2x filesystem this is a no - go. - virtually nothing seems to get written. Nearly anything that can get written to (/var /tmp are on a tmpfs (which gets wiped on a reset by the looks of things)

Nice idea though

I think I'll go for the 10 minutes write idea, that should give 10*1 million minutes == 19 years continuous life for my SD card - I can live with that! Configurable to once per boot write (a bit better, unless I'm developing my own software in which case I tend to reboot more than once every 10 minutes :unsure: )

Dom

Well, if the aim is only to have the file dates chronologically consistent within the GP2X itself (this is suffecient for things like sorting by modification time, or gp2x side build tools that care about modification times), then scanning for the most recent file and taking that time should work fine. But if you need it consistent with another device (computer), I think only a real time clock, or date/time entry interface, or network time sync would be useful. 10 minutes (plus power off time) can be a lot when you're doing repeated compile/test debugging, and if things are picky about file modification times, I don't think it'll cut it.

 

[dominicbeesley]

From memory there is an I2C bus inside the GP2X, all you need to do is hook up a Dallas RTC chip and it will handle the battery backup (Li-on cell) and hold the time. Then just access the time via Linux's i2c routines. Would have dates and leap years etc etc

There's a RTC in the MMSP2 as well, not sure if the relevant pins are soldered though...not got round to taking my gp2x to bits yet :blink:

However, I have knocked something together, managing to brick my gp2x for the first time in the process! (note to self - do NOT use rm * in the /etc directory!)

I'll upload what I've done in the beta test area. I'd be very grateful if (even if you don't want or need it) any experts could have a look to see if what I've done is sane! There doesn't seem to be a _nice_ way of adding a daemon on the gp2x!

Cheers

Dom

 

[Dimacus]

As brahms said, there is a RTC controller onboard the mmsp2.
However, if i have understood the documentation correctly, it starts to count when the reset pin goes low, which means that whenever it goes into a reset state, it stops counting. and if you turn it off, it looses all information in the time registers, and as far as i can see, there is no pin for a backup battery.

So i guess it's just counting how long it has been since the last reset.

Instead of using an expensive dallas chip one could use a smaller and probably cheaper RTC like the M41T81 (http://www.elfa.se/pdf/73/737/07373922.pdf).

 

[sephiroth111]

assuming that someone wanted to put an I2C chip into the GP2x, where would one go to locate the solder point, and / or start programming a driver. I'm new to this i2c idea, and i'm just kinda wondering.

 

[BradN]

If the gp2x has an I2C EEPROM chip, this would be the best way to locate the lines. I'm not sure if it uses one of these or the main flash chip to store the serial number, etc.