On 27/10/11 08:31, Björn Stenberg wrote:
Alex Parker wrote:
Speaking of which, where are we with this? Any show stoppers people
are aware of? Things that need focussing on?
We are in pretty poor shape, with a number of regressions. The way I see it, at
least the following bugs need to be
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
Am 05.11.2011 11:47, schrieb Alex Parker:
Hi guys,
So, FS#12325, FS#12337 and FS#12279 are marked as being fixed which is
good news, leaving FS#12310 outstanding as a blocker.
My feeling is that it would be handy to get that fixed before
branching, what do people think?
I tend to
On 05/11/11 11:04, Thomas Martitz wrote:
Am 05.11.2011 11:47, schrieb Alex Parker:
Hi guys,
So, FS#12325, FS#12337 and FS#12279 are marked as being fixed which is
good news, leaving FS#12310 outstanding as a blocker.
My feeling is that it would be handy to get that fixed before
branching,
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
On 5-11-2011 12:53, Michael Sevakis wrote:
- Original Message - From: Bertrik Sikken bert...@sikken.nl
The Si4703 can be configured to capture one RDS packet, then
raise an pin voltage for 5 ms. My plan is to attach an interrupt
to this event that wakes up a high-prio thread to read
I don't know how to do an async i2c driver.
Queue transfer descriptors in a linked list and have the i2c interrupt
service them, in queue order, calling a callback when each is completed.
Yes, it must be interrupt based.
I guess it's just the codec i2c driver on AMS that is like that. On
