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

Rockbox mail archive

Subject: Re: RDS support in Rockbox

Re: RDS support in Rockbox

From: Bertrik Sikken <>
Date: Sat, 05 Nov 2011 20:43:57 +0100

On 5-11-2011 4:40, Michael Sevakis wrote:
>>> I think you misunderstood my point, you can implement it differently
>>> with another hardware without any problem. The proposed rds_
>>> interface doen't imply a particular way of doing things, is it ?
> It was not specific as far as what level had a thread. If it's at the
> bottom layer in the driver and not in the generic layer then cool!
>>> I think that what bertrik proposed is to call it from the driver and
>>> not from the UI. Calling it from the UI would make no sense.

Yes, the idea is that the UI<->driver interface stays the same
(for now just getting the 8-char station name and 64-char radio text)

The rds_* thing is just a helper module, which concerns itself only
with aggregating raw RDS packets into useful messages (e.g. the
station name won't fit in one packet) and has no target or hardware
This module is only called from the fm tuner driver and is
(hopefully) generic enough for future RDS fm tuner chips.

The interrupt/rds thread thing is how I planned to do prototype it
for the si4703. This seems to work now for the clip zip, but I ran
into some other problems:
* the spec recommends the fm stations to use the station name (ps) in
  a consistent manner and for station identification only. Instead it
  appears that a lot of alternative info is sent in the station name
  message (like currently playing song, warning about speed traps, etc.)
* the fmradio_i2c_read/write functions are now being accessed from
  two threads, the rds thread and the ui thread, so some kind of
  contention control is needed (my quick hack on the clip zip works
  without it, because the reads/writes don't yield...)

Received on 2011-11-05

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