This is the bug/patch tracker for Rockbox. Click here for more information.
Quick links: Bugs · Patches · Rockbox frontpage
FS#9611 - Sansa Clip radio code
Attached to Project:
Rockbox
Opened by Bertrik Sikken (bertrik) - Monday, 08 December 2008, 00:08 GMT+2
Last edited by Bertrik Sikken (bertrik) - Thursday, 05 February 2009, 20:58 GMT+2
Opened by Bertrik Sikken (bertrik) - Monday, 08 December 2008, 00:08 GMT+2
Last edited by Bertrik Sikken (bertrik) - Thursday, 05 February 2009, 20:58 GMT+2
|
DetailsThis patch is an initial attempt to get the radio to work on the Sansa Clip (and later possibly also on the other AMS Sansas).
Basically the only thing it does right now, is to demonstrate communication with the radio chip over i2c and show that the radio chip is detected. It doesn't produce sound (not even noise) at this moment. Remarks: * uses the c200 keymap for the fm radio screen (except for REC button, clip doesn't have it). * contains initial work by Nils Wallmenius for controlling the si470x tuner, which I attempted to hack for making it work on the Clip (e.g. enable the 32 kHz oscillator, disable all mute bits, add a timeout to tuning). * reverts svn r19353 (no longer use GPIO B6) because it's giving me display problems * implements fmradio-i2c.h which in turn uses the generic_i2c.c driver for communication with the radio chip. * updates the as3514 driver, to make sure codec AUDIOSET registers are set first, because some codec registers cannot be written to unless enabled in AUDIOSET1. 
clip_radio1.patch
(16.4 KiB)
apps/keymaps/keymap-clip.c | 19 + firmware/export/config-clip.h | 8 firmware/export/si4700.h | 11 + firmware/SOURCES | 2 firmware/target/arm/as3525/system-as3525.c | 4 firmware/target/arm/as3525/sansa-clip/lcd-ssd1303.c | 2 firmware/target/arm/as3525/sansa-clip/fmradio-i2c-clip.c | 112 ++++++++++ firmware/drivers/generic_i2c.c | 4 firmware/drivers/audio/as3514.c | 33 +-- firmware/drivers/tuner/si4700.c | 155 ++++++++++++++- firmware/tuner.c | 15 + 11 files changed, 330 insertions(+), 35 deletions(-) |
This task depends upon
Closed by Bertrik Sikken (bertrik)
Thursday, 05 February 2009, 20:58 GMT+2
Reason for closing: Accepted
Additional comments about closing: Committed as svn r19927.
Thursday, 05 February 2009, 20:58 GMT+2
Reason for closing: Accepted
Additional comments about closing: Committed as svn r19927.
Perhaps it needs to be hacky since we don't have recording yet
Things done to make it work:
* Added info in FM debug menu to ease debugging (simply shows all registers)
* Radio is powered down and up again during init, then the 32 kHz is enabled
* The radio output is apparently connected to the LINE2 input of the codec, so I temporarily hacked as3514.c
I believe a simple way to modify as3514.c would be to define a model specific default line (1 or 2), so we don't have code for the unused line in each model (I do believe that line2 is unused on other models than Sansa AMS since it was not mentioned in the driver)
Also I wonder what to do about the target specific audio-as3525.c & audio-c200_e200.c : if they have the same content they should be put in common and go one level down in target/ ; but since it's as3514 code, it probably should go into as3514.c
But; audio-c200_e200.c uses one PP register, and target specific code shouldn't go in firmware/driver ..
Just my 2 cents ^^
This version of si4700.c now contains a 16-bit register cache, so register indexes used in the code correspond directly with register indexes in the datasheet.
sound when writing to register 7. If i change line 128 in si4700.c to
si4700_write(5); it works fine though so i guess the write should go
in the #ifdef.
Some minor nits.
* The read in si4700_tune does not seem to be necessary anymore.
* I find constructs like this "(i + 0x02) % 16" weird because of
the mix of decimal and hex constants, might just be me though.
* Some trailing whitespace.
What do you think about the 16-bit radio register cache? useful or overkill? My next patch will use #defines for the register indexes.
In this patch, tuning is assumed to be finished after waiting a fixed delay (other options are polling or using an interrupt line). An errata in the datasheet advises not to generate bus activity (poll) during tuning when using the internal oscillator. I don't know yet how bad polling really is for tuning performance. I also don't know yet if an interrupt line from the tuner is connected back to the as3525 in the AMS sansas.
I found that in some cases, the radio does not work quite well on the clip yet (tunes badly). I think I'll need to experiment a bit more with the initialisation/powerup/powerdown sequence.
but may be more error prone so if you like the 16 bit thing more i am totally fine with that :)
Tuning seems to work as well with your patch as with svn for me on the beast.
Things to do:
* implement proper audio routing through audiohw-as3525 and as3514 (LINE2 instead of LINE1)
* complete the clip keymap for the radio
FS#9641Good work so far! Nice to hear radio on my Fuze, a bit weird that it's more reliable than normal audio playback though ;)
* The required changes in si4700.c (enable internal 32 kHz oscillator) have now been committed so they are no longer part of this patch.
* Reworked the as3514 codec a bit for cleaner support of LINEIN2 on AMS sansas. It's not quite clear what API should be used to switch between normal audio playback and LINEIN, this patch works around it by using the audiohw_set_monitor function which is normally only available for targets with recording.