Rockbox mail archiveSubject: Re: RDS support in Rockbox
Re: RDS support in Rockbox
From: Bertrik Sikken <bertrik_at_sikken.nl>
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