Rockbox

  • Status Closed
  • Percent Complete
    100%
  • Task Type Patches
  • Category FM Tuner
  • Assigned To No-one
  • Operating System All players
  • Severity Low
  • Priority Very Low
  • Reported Version Release 3.0
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by bertrik - 2008-12-07
Last edited by bertrik - 2009-02-05

FS#9611 - Sansa Clip radio code

This 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.

Closed by  bertrik
2009-02-05 19:58
Reason for closing:  Accepted
Additional comments about closing:  

Committed as svn r19927.

it looks like tuning always fails, but if I bypass the si4700 code and set the tune bit myself (0×3[15]), the tuned bit (0xA[14]) is eventually set. pretty weird

I just thought: we should write audio-as3525.c , perhaps based on / or a copy of sandisk/audio_c200_e200.c ; in order to get an audio signal.

Perhaps it needs to be hacky since we don’t have recording yet

Resynced to r19366 (which now includes fmradio-i2c interface for clip), with latest si4700 from n1s.

Crude but effective… this patch works to tune the radio and hear stations.

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

Thanks ! I could listen to some radio here as well (by the way the crude hack miss muting the line2, so if you want to listen to music after FM you’ll have funny effects ;) )

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 ^^

Synced to SVN r19371, still quite hacky.

Ok, last patch for today, mostly changes in si4700.c, with an improved initialisation sequence. It turns out that the register that contains the XOSCEN bit (to enable the 32 kHz oscillator) does not have a correct value before the chip is fully powered on. So the initialisation sequence is now: power up chip, read all registers into cache, set volume, optionally set the XOSCEN bit (only for clip and m200v4 now). I have good hope this version of si4700.c also works on the gigabeast.

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.

nls commented on 2008-12-11 16:28

I tried a gigabeat build with your patch attached and it still has no
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 + 0×02) % 16” weird because of
the mix of decimal and hex constants, might just be me though.
* Some trailing whitespace.

Thanks Nils. I’ll fix the issues you mentioned.
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.

nls commented on 2008-12-14 11:59

I don’t have a strong opinion about the 16 bit reg cache, i made it with bytes because i thought it was easier
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.

Enable oscillator _before_ doing the power-up sequence. This should fix poor tuning. The si4700.c should also work for the gigabeat.

Things to do:
* implement proper audio routing through audiohw-as3525 and as3514 (LINE2 instead of LINE1)
* complete the clip keymap for the radio

Bertrik, if you would like to include code for the e200v2, I have a patch with the needed changes -  FS#9641 

So, this is the patch to make your patch work with Fuze and e200v2 (thanks to Michael Chicoine). Please include in your next patch if possible.

Good work so far! Nice to hear radio on my Fuze, a bit weird that it’s more reliable than normal audio playback though ;)

Hm, the as3514.c change shouldn’t be in that patch (even though the radio needs that too ofc ;) )

Radio patch synced against r19550, including support for fuze and e200v2.

Updated to svn r19563.
* 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.

My Fuze has recording in the OF, so it’s not too bad :)

Updated against svn r19642. This one is a little smaller because a si4700 debug menu was added to SVN and audio-as3525.c was cleaned up a little. Can’t make up my mind yet about the API between audio-as3525 and as3514 to enable/disable the line in.

Ok, this should be one of the last patches. I added a function audiohw_set_linein_bypass to as3514.h that is called from audio-as3525.c to enable/disable a line input for FM audio.

synced to as3514 changes, use Clip’s HOME button instead of C200’s REC

The recent as3514 changes broke the line-in volume settings again, by making the assumption that line-in is only used for recording. Maybe, instead of trying to decouple radio support and recording support, we should just fake recording support for now? Recording will eventually be implemented for AMS sansa targets, since the hardware supports it.

The stable parts of the patch have been committed to SVN. Work left to do is enabling the LINE IN input by connecting audio-as3525.c to the as3514.c codec code. See attached patch, it enables function audiohw_set_monitor not just for targets that HAVE_RECORDING but also for HAVE_FMRADIO_IN.

Please make up your mind and commit this finally :D

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing