GP2X Can Anyone (with Gph's Toolchain 2.95 For Linux) Compile This?


it implements a kernel module which do cache-related operations (caches upper 32mb, flush the cache, etc..) and implement an i2c interface (I wonder if would not be better to implement that inside the i2c kernel interface instead of a minimal-lib specific interface?

I wonder what rlyeh is up to whithin i2c bus.... there are no i2c components on the gp2x bus AFAIK, right?

damn, I can't compile this on my 2.95 toolchain, I wonder why the hell arm-linux-gcc is unable to find any #included file... even if I specifically #include "/with/a/full/pathname" it still refuses do include the header files...
 
Actually, if we have a useable i2c bus, it could be real fun attaching different i2c devices to it. A million different low-level peripherals use an i2c interface. Anyone have some good ideas ?

The clk and data pins should be accessible from the flash chip pins even if the traces are not exposed. Power and ground can taken from the regulator.
 
- i2c realtime clock (wire up backup power to the battery contacts, or use a big capacitor & diode)
- i2c PWM controller for robotics applications (might be better suited to being external though)
- i2c battery charging controller (you'd have to devise a whole system to charge the battery off an AC adapter however, but this could be a fun project) This might work as an ammeter to test current consumption under different conditions too, and possibly even let you get an accurate battery state indication.
 
I think that i2c pins are avaiable in the ext connector, right? (not sure)

anyway:
realtime clock - only if it's battery backed, a capacitor is not a good option
pwm controller - yeah, that's a option, but I was thinking in something more game-minded
charging controller - I don't think you'll need any interface with the software for that, but if you want to, you could use the serial port instead

I think the only good idea would be to include i2c accelerometers on the console, that could be fun, but still MUCH specific

anyway, now I know what's up with i2c bus...
 
capacitor backed might not be a terrible idea for the RTC - it can last a week depending on the chip and capacitor used - much longer than the batteries once you remove them to charge them :) I think dreamcast used this idea.
 
but the capacitor's voltage is directly proportional to it's charge state, in other words, as soon as the rtc (or anything else) starts to discharge the capacitor, the voltage will be going lower and lower, while on a battery the voltage will not change(coarse as the cap) as long as the battery have a reasonable amount of charge (at least 5%), so we must therefore have to have a specific rtc that operate in any voltage from 0.5 to 4vdc

also a capacitor of the size of a C battery still holds less energy than a AAA sized battery (to be exact, any battery actually sold holds more energy than a capacitor of the size of a C battery) so definitely a capacitor is huge

ultra-capacitors can be used, but they are pretty expensive and hard to buy (at least on a third-world country)
we can use a capacitor to hold rtc for 2 to 5 minutes while you change the batteries, that would be no problem I think, but still a cell-shaped battery (that tiny one) would take less space and hold it up for hours, altough they're not rechargeable
 
Some RTC's are low enough power that a basic button cell looking "supercapacitor" from digikey could power them for days.
 
Back
Top