rio car dot org

Welcome to riocar.org!

Friday, August 6th

Main Menu

· Web Links
· Downloads
· BBS/Forums
· Lens Compare
· Boot Logos
· Button Guide
· Developer Info
· Drive Upgrade
· FAQ
· Geek Guide
· Photo Gallery

rio car dot org Developer Information

Category: Main -> Kernel Facts & Features


· The `/proc` filesystem · The Empeg State Block

· The /proc filesystem

On any Linux machine, the /proc filesystem is your friend. Much valuable information can be obtained simply by poking around and looking at the informative virtual files which exist under /proc. These can also be read by user programs to obtain various information about the player's devices and status. Here is a lost of the more interesting entries in /proc.

File	Purpose	Comments
`/proc/empeg_id`	Information about your Empeg's hardware	Includes the hardware revision, how much RAM and flash you have, etc. Of particular interest is the `hwrev` from which you can tell programatically what kind of Empeg you're running on. The valid hwrev numbers to test for are: 4 Empeg Mark I 7 Empeg Mark II 9 RioCar (Empeg Mark IIa) Intermediate hwrev's are Empeg prototypes. Some fun historical information is available about those prototypes over at the Empeg Geek Site.
`/proc/empeg_power`	Power status (AC or DC, cell phone mute, lights sense, etc)	Sample contents of empeg_power: 0 (AC Power) 1 (Powerfail enabled) 0 (Accessory line low) 0 (Subsequent boot) 1 (External mute high) 1 (Lights sense high) 1 (Display on) All flags: 0x72 So the first character (or first line) of empeg_power can be read to determine whether the player is running on AC or DC power. Similarly, status of the other lines such as the car's cell phone mute line can be obtained from `/proc/empeg_power`.
`/proc/empeg_therm`	On-board temperature sensor reading	In degrees Celsius.

There are many other files in /proc, poke around to find all sorts of goodies about your Empeg's hardware.

Contributed by Tony Cebzanov

· The Empeg State Block

The player opens /dev/empeg_state and can store up to 126 bytes of info (well, it has a 128 byte block but there's a CRC-16 at the end). In case of a power fail, the kernel dumps the latest complete /dev/empeg_state 128 byte block to flash.

On power up, the kernel finds the latest valid block in flash and makes it available in /dev/empeg_state.

The kernel has to do it as there are, well, hard real-time constraints on the task - like running out of power to the CPU and flash :)

The following diagram shows some of the more interesting areas of the 128-byte flash save area. It's not complete yet but it's getting there.

The Y axis denotes the hex offset from the flash base address, the X axis denotes the bit position within that byte. Because some settings go across byte boundaries, the diagram is color-coded.

Some details...

The bit labelled "shuf" is always 1 when any shuffle mode is active, and there seem to be various other bits and bytes which change based on the custom shuffle modes. I couldn't get a handle on those.. But when shuffle is off, the "shuf" bit (Offset 0x0F, bit 3) is 0, when any shuffle mode is active, that bit is 1.

Bytes 24 and 25 constitute a 16-bit sequential index into the current running order on the player. I hope to eventually use this index to grab the current FID number somehow.

Bytes 29 and 2A constitute a 16-bit number which represents the position within the current track. This might be the number of MP3 frames, or some number of milliseconds or something like that, not sure.

Numbers like balance and fader are 0 if they're in the center, negative if they're (right | rear), positive if they're (left, front). So if your balance setting is one "tick" to the left, the value in this byte is 0000001. If the balance is one tick to the right, it's 11111111.

Contributed by Hugo Fiennes and Tony Cebzanov

[ Back to the index ]