* Remove unused bits like the radio event and simplify basic
radio interface. It can be more self-contained with rds.h only
required by radio and tuner code.
* Add post-processing to text a-la Silicon Labs AN243. The chip's
error correction can only do so much; additional checks are highly
recommended. Simply testing for two identical messages in a row
is extremely effective and I've never seen corrupted text since
doing that, even with mediocre reception.
Groups segments must arrive in order, not randomly; logic change
only accepts them in order, starting at 0.
Time readout was made a bit better but really we'd need to use
verbose mode and ensure that no errors were seen during receiving
of time and more checks would be need to have a stable PI. The
text is the important bit anyway.
* Time out of stale text.
* Text is no longer updated until a complete group has been
received, as is specified in the standard. Perhaps go back to
scrolling text lines in the radio screen?
* Add proper character conversion to UTF-8. Only the default G0
table for the moment. The other two could be added in.
* Add variants "RDS_CFG_PROCESS" and "RDS_CFG_PUSH" to allow
the option for processed RDS data to be pushed to the driver and
still do proper post-processing (only text conversion for now for
the latter).
Change-Id: I4d83f8b2e89a209a5096d15ec266477318c66925
This clearly fixes recording on targets where the bias pin was wrong. It may
also improve recording on targets where the bias voltage was wrong. I was unable
to find those parameters on the ZEN Mozaic, which fallback to default values.
Change-Id: Ifb5f823c9cbd01f0d9a80fa5d49d93972c8b7cfe
The old driver was bad in many respect, it had some race conditions, it was
using a thread to serialize transfers because of the legacy i2c interface.
It also had huge latency (typically 50ms but delays up to 300ms can happen),
thus some presses were missed.
The new driver takes advantage of the new i2c driver to do everything
asynchronously. It also does not need a thread anymore because queueing
ensures proper serialization. It provides much better and reliable latency
(typically ~2ms).
Also fix the debug screen which was horribly broken. The new screen also
displays the deadzones.
Change-Id: I69b7f99b75053e6b1d3d56beb4453c004fd2076e
To stop erroneous button presses, allow users to add a deadzone between
the button via the Settings > General > System menu > Touch Dead Zone.
The configuration was chosen this way: the touchpad has the same DPI
in both direction so the setting applies the same on both the X and Y
axis. The setting ranges from 0 to 100 and is internally multiplied by 2
giving a maximum deadzone of 2*100 = 200 around each button, which
account for 400 total (once around each button), effectively reducing
each virtual button from 1000x600 to 600x200 when using the maximum value.
Change-Id: I8683c63d2950200eb32d1dda0a00bbd92d83d5be
Reviewed-on: http://gerrit.rockbox.org/677
Reviewed-by: Benjamin Brown <foolshperson@gmail.com>
Tested: Benjamin Brown <foolshperson@gmail.com>
Reviewed-by: Amaury Pouly <amaury.pouly@gmail.com>
Choices are limited for those: i2c is either generic software or imx233
hardware and power is either none or with a gpio. So factor ever possible
combination in a single common file and use fmradio-target.h to supply the
required parameters. This will remove a bunch of duplicate code.
Change-Id: If12faeb2e371631cd39cc18a4c1d859812007934
The old code allowed each target to specify its adc targets but this proved
useless since the target rely directly on imx233/lradc for input method and
generic adc is mostly used for battery and debug. Remove all target specific
files and provide a generic implemenation. The targets can still specify a
battery temperature channel in powermgmt-target.h
Change-Id: I68cf2e3e46379d174ac6d774ffb237bb15a19ae3
Target that have a touchpad/touchscreen should disable it while
being locked (In order to avoid LCD to drain battery power due to
"key locked" constant reporting messages. If they a have a keylock
button this was already handled at driver level. If not (e.g. fuze+),
they will have to implement a switch at driver level that action.c
can operate on softlock.
This patch does the following for any target having a touchpad
or a touchscreen and no HAS_BUTTON_HOLD (ie any softlock target)
1) it implements the code to call button_enable_touch(bool en) in
action.c.
2) button_enable_touch is implemented in button.c and call
either touchpad_enable or touchscreen_enable
3) those two function are implemented respectively in touchscreen.c
and a new touchpad.c file. They provide a generic way to silents touch's
device and call a function at driver level where target specific code
can be implemented if possible/needed (for power saving for instance).
Those function name are touchpad_enable_device and touchscreen_enable_device
4) we implement an empty function at driver level of targets that need it
to have them still being able to compiled.
Change-Id: I9ead78a25bd33466a8533f5b9f259b395cb5ce49
Reviewed-on: http://gerrit.rockbox.org/569
Reviewed-by: Thomas Martitz <kugel@rockbox.org>
Reviewed-by: Amaury Pouly <amaury.pouly@gmail.com>
- take advantage of the new rmi power function implemented to:
1) lower usual power_mode to low_power as it seems to be enough and might save
some battery
2) implement a system that lower that state to very_low_power
after 1 minute of inactivity.
3) implement touchdev_enable(bool) that can be use later to disable the
touchpad when needed
4) improve the debug screen report of the current power state and
changing the power state using volume keys
Change-Id: I0b372696d4b2bef5360c778d0500870fd9badee1
Reviewed-on: http://gerrit.rockbox.org/525
Reviewed-by: Amaury Pouly <amaury.pouly@gmail.com>
The lcd data line were not setup as input anymore, making register
reading plain broken and probably lead to bad lcd detection.
Change-Id: I281460f845537c58045f3893261ded5c9c6e53b5
Factorise pin setup, rewrite PIO code, add support for lcdif irq,
handle all the various differences between the stmps, drop yuv
blitting code since it already exists in the common lcd drivers.
Change-Id: Ifc40aed9b3b12f16611ce960602e46a5bc87ae53
The clkctrl functions were becoming a mess. Normalise the names,
get rid of the xtal derived as special case and use the same
interface.
Change-Id: Ib954a8d30a6bd691914b5e0d97774ec9fc560c50
The current pinctrl functions were a mess. Normalise the functions
names to make them shorter and clearer.
Change-Id: Iac6ff84625ef2b7610268e3a5802dc0088de3167
For some reason it is the responsability of the driver to send
this event so do it. This might fix some non-updating screens.
Change-Id: Ib5fdc94bf266c3497a8ac4e89d0418c0e876ff9f
The lcd kind is always set to st7783 in case we can't read the ID
so don't bother handling impossible cases
Change-Id: I352fd43b26068b460e69190d37c4cd4627e1db9a
The flip and invert settings can potentially be reset to their
value accross a disable/enable cycle, so save the value of the
impacted registers and apply it after each enable. Also avoid
poking registers when the lcd is not on.
Change-Id: Ica98f166c060aade7eb205f5628b58aae692024f
When chaging the cpu and memory frequency we need to disable the
external memory interface (EMI) for a small time. This can
underflow the dma and cause some breakage. Hopefully the SSP
controller handles this gracefully by stopping the clock and the
I2C probably handles this naturally because the clock can be
streched anyway. However the LCDIF has a special setting for this
which needs to be enable, otherwise it will send garbage to the
LCD. No other block is known to suffer from this currently but
this issue might have more unexpected consequences.
Change-Id: Ide154cad87929f2bf6cc419ac1d2ff33e30eec66
The lcd driver does not wait for the refresh to be done to return
from lcd_update(). This means that changing a register is unsafe
if done in the middle of the redraw. This could happen when
disabling the lcd for example. Make sure it doesn't happen by
waiting for the lcdif to be ready.
Change-Id: I43ec62a637dd61c3b2a3a6e131c1a9e8035524b1
I successfully identified the STC/RDS pin as B2P27.
Strangely the OF uses polling instead of interrupts
but since they routed it, let's use it! On the fuze+
the fmradio i2c uses bit toggling so we can't read
the RDS data in the interrupt context. Instead we
defer the work to a thread.
Change-Id: Iedfa425320e6c91b4351b72e97c732696bdb2b73
Reviewed-on: http://gerrit.rockbox.org/236
Reviewed-by: Bertrik Sikken <bertrik@sikken.nl>
Reviewed-by: Amaury Pouly <amaury.pouly@gmail.com>
Past development has proved that one can mistakely use
the same pin for two uses without noticing. Since this
causes extremely hard to find bugs, the infrastructure
will allow to register pin uses and panic when a conflict
is detected. The pinctrl debug now shows the pin uses
when its support is compiled in.
Change-Id: Idb2d5235ce09207d77aa474d6f158e72b933761a
Rework code to be more useful:
- move battery channel init to lradc
- always init lradc from system (previously from adc)
- don't reserve channels for vddio, nmos or pmos
- implement external temperature sensing using current source
- use this for battery sensing on the Fuze+ (calibration needed)
Change-Id: I5f9a24b9243db7d1e6bdb16b84bc891e61d0c318
imx233: always divide physical channels by two for wider range
The Fuze+ OF monitors channel 2 but I'm unable to determine the meaning of it.
Print the value on the debug menu so that people can have a look at it.
Change-Id: I8a942febeafbce06014178abda12e38a16c26664
