|
Rockbox mail archiveSubject: Re: RDS support in RockboxRe: 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 dependency. 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...) Regards, Bertrik Received on 2011-11-05 Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy |