dev builds
themes manual
device status forums
mailing lists
IRC bugs
dev guide

Rockbox mail archive

Subject: Rocking the box

Rocking the box

From: Björn Stenberg <>
Date: Sat, 20 Apr 2002 02:19:27 +0200 (CEST)

Hi everyone!

Although the list has been rather quiet lately, I can assure you that
project activity has been frantic:

* Linus has finished the gdb stub for the SH-1 processor, so we now have
  full source level debugging on the Archos, with breakpoints and
  everything! Extremely nice!

* Daniel and Gary has written a user interface simulator for X11, which
  allows us to start writing some high-level code even though not all
  low-level drivers are ready yet. For those of you eager to start working
  on high level code, you can start right away using this simulator!

* Myself, I've been occupied with a lot of "house keeping", updating web
  pages and administering the CVS repository. But today I took some time
  off to write a Tetris game for the simulator! There are a few things to
  fix before it can run on the Recorder, but it's actually not far off.

* Also today, Linus got the I2C driver working. This means we can now
  communicate with the MAS MP3 decoder chip, and playing our first sound
  should not be far off.

Rockbox Developer Conference 2002
Well, almost. :-) Me, Linus, Daniel and Kjell sat down at Linus' house
friday night and had a long and fruitful discussion about software design.
Here are a few things that we discussed:

Application Programming Interfaces
We want to try to stick to POSIX where these exist and are practical. The
reason is simply that many people already know these APIs well. Here are a
few which haven't already been defined in the code:

File operations
 - open
 - close
 - read
 - write
 - seek
 - unline
 - rename

Directory operations
 - opendir
 - closedir
 - readdir

Disk operations
 - readblock
 - writeblock
 - spindown
 - diskinfo
 - partitioninfo

We also decided that we will use the 'newlib' standard C library,
replacing some functions with smaller variants as we move forward.

We spent much time discussing and debating task scheduling, or the lack
thereof. First, we went with the idea that we don't really need "real"
scheduling. Instead, a simple "tree-task" system would be used: A
main-loop, a timer tick and a "bottom half" low-priority interrupt, each
with an event queue.

Pretty soon we realized that we will want to:

  a) Use a timer tick to poll disk I/O (assuming we can't get an interrupt)
  b) Perform slow disk operations in both the MP3->DAC feeder and the user
     interface, sometimes at the same time.
  c) Not lock up the user interface during I/O.

At the same time, we agreed that we should not walk into the common trap
of engaging in "job splitting". That is, to split up jobs in small chunks
so they don't take so long to finish. The problem with job splitting is
that it makes the code flow very complex.

After much scratching our collective heads over how to make a primitive
"three-task" system be able to do everything we wanted without resorting
to complex job splitting, we finally came to the conclusion that we were
heading down the wrong road:

  We need threading.

Even though a scheduler adds complexity, it makes the rest of the code so
much more straight-forward that the total net result is less overall

To keep it simple, we decided to use a cooperative scheduler. That is, one
in which the threads themselves decide when scheduling is performed. The
big gain from this, apart from making the scheduler itself less complex,
is that we don't have to worry as much about making all code "multithread

Affording ourselves the luxury of threads, we soon identified four basic

 - Disk thread, performing all disk operations
 - UI thread, handling the user interface
 - MP3 feed thread, making sure the MAS is fed with data at all times
 - I2C thread, handling the sometimes very relaxed timing of the I2C bus

Threads use message passing between them and each have a message queue
associated to it.

In addition to the threads, we need a timer interrupt with the ability to
send messages to threads at specific intervals. This will also be used to
scan the keys of the jukebox and handle key repeat detection (when a key
has been pressed for a number of ticks).

None of these things are, of course, written in stone. Feel free to
comment, discuss and argue about them!

We are currently 89 subscribers to this list. If you want to get more
deeply involved in what's going on, I encourage you to:

 - Subscribe to the rockbox-cvs list, to see all code that goes in.
 - Join the #rockbox channel on There are always a
couple of us in there.

I have written a set of guidelines for contributing code to the project.
Take a look at them in CVS or here:

Received on 2002-04-20

Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy