Using another thread is probably (maybe) overkill on AMSv2 and i.MX31 and
RDS isn't exactly a data flood so doing it without a thread from an I2C
interrupt callback is probably economical. I'm not sure if any AMSv2 players
actually have an int line from the tuner chip though. The latter as I recall
does have it (it's been awhile).
I think the proposed implementation is specific to this hardware.
...
The Driver pushes raw packets to the parser and the UI Code ask the
generic parser what is data available.
If all this goes through, I'll be pleased to do the work to change things
around for i.MX31 since it's not difficult to convert things but how each
buffer gets pushed to the raw parsing function should be target-defined. If
a thread is absolutely needed for some reason, don't impose it on every
device.
The point is that when you change the frequency you need to tell the
generic RDS parser that its data is invalid because it might have some
partials packet pending and need to work them I guess.
RDS data can be cleared from the tuner driver with better timing control
(like when to mask it and unmask it for tuning to avoid races), probably
with less error proneness and more importantly proper operation should not
depend on being inside a particular UI-- it's akin to key playback features
only working inside the WPS. Why continue down that path? It's finally
showing its obvious limitations as far as control from other screens. Just
add another event callback definition that the UI can register for.
Mike
