Lcd_update rect was hanging during horizontal screen update x = 238 and width = 2
which was within the bounds of the screen, this seems to be a weird corner case
but more testing needs done.
Update_rect now properly bounded between 0 - screen w/h
--Cleaned up code
Pixels in x are now multiples of 4.
Datasheet states:
-------------------------------------------------------------------------------------------
WORD_LENGTH=0 implies the input frame buffer is RGB 16 bits per pixel.
DATA_FORMAT_16_BIT field indicates if the pixels are in RGB 555 or RGB 565 format.
Limitations:
— BYTE_PACKING_FORMAT [3:0] should be 0x3 or 0xC if there is only one pixel per word.
— If there are two pixels per word, BYTE_PACKING_FORMAT [3:0] should be 0xF and
H_COUNT will be restricted to be a multiple of 2 pixels.
and
WORD_LENGTH=3 indicates that the input frame-buffer is RGB 24 bits per pixel (RGB 888). If
BYTE_PACKING_FORMAT [3:0] is 0x7, it indicates that there is only one pixel per 32-bit word
and there is no restriction on H_COUNT.
Limitations:
— If BYTE_PACKING_FORMAT [3:0] is 0xF, it indicates that the pixels are packed, i.e. there
are 4 pixels in 3 words or 12 bytes. In that case, H_COUNT must be a multiple of 4 pixels.
-------------------------------------------------------------------------------------------
We are using 16 bits per pixel and byte_packing = 0xF but device crashes with multiple of 2 pixels
Behaviour can be verified with plugin - oscilloscope, Horizontal mode device hangs as indicator
reaches right of screen
Change-Id: I1445f5334f4e7fe59304c65c76b47d0daa0614b2
At normal loads:
- disabling auto slow boosts performance at the cost of runtime (~ -5%)
- disabling at max cpu does not noticibly decrease runtime
Change-Id: I5de80201c9a24ce556862151cbd6b21b01708b63
Bootdata is a special location in the Firmware marked by a magic header
The bootloader is able to copy information to the firmware by locating
this struct and passing data to the firmware when it is loaded but
before it is actually executed
Data is verified by a crc of the bootdata
Change-Id: Ib3d78cc0c3a9d47d6fe73be4747a11b7ad6f0a9e
Playing AAC-HE files resulted in a race condition between
audio/codec/buffering for set_cpu_frequency
Change-Id: I35e1c1fd18db623e2990c305acdca03f57184d0d
* Editing a bunch of drivers' thread routines in order to
implement a new feature is tedious.
* No matter the number of storage drivers, they share one thread.
No extra threads needed for CONFIG_STORAGE_MULTI.
* Each has an event callback called by the storage thread.
* A default callback is provided to fake sleeping in order to
trigger idle callbacks. It could also do other default processing.
Changes to it will be part of driver code without editing each
one.
* Drivers may sleep and wake as they please as long as they give
a low pulse on their storage bit to ask to go into sleep mode.
Idle callback is called on its behalf and driver immediately put
into sleep mode.
* Drivers may indicate they are to continue receiving events in
USB mode, otherwise they receve nothing until disconnect (they
do receive SYS_USB_DISCONNECTED no matter what).
* Rework a few things to keep the callback implementation sane
and maintainable. ata.c was dreadful with all those bools; make
it a state machine and easier to follow. Remove last_user_activity;
it has no purpose that isn't served by keeping the disk active
through last_disk_activity instead.
* Even-out stack sizes partly because of a lack of a decent place
to define them by driver or SoC or whatever; it doesn't seem too
critical to do that anyway. Many are simply too large while at
least one isn't really adequate. They may be individually
overridden if necessary (figure out where). The thread uses the
greatest size demanded. Newer file code is much more frugal with
stack space. I barely see use crack 50% after idle callbacks
(usually mid-40s). Card insert/eject doesn't demand much.
* No forcing of idle callbacks. If it isn't necessary for one or
more non-disk storage types, it really isn't any more necessary for
disk storage. Besides, it makes the whole thing easier to implement.
Change-Id: Id30c284d82a8af66e47f2cfe104c52cbd8aa7215
Due to some undocumented behavior, the touchscreen was almost unusable in point
mode. Now it's much better but still not very nice to use, probably it needs some
filtering.
Change-Id: Idc8a0214b09f268e6be907ee6ec3126cc0d88773
The ZEN/X-Fi (STMP3700) don't handle memory frequency scaling really well, for
this reason we run it at a fixed frequency. That frequency was previously set
to 64Mhz because when the CPU run at its lowest frequency, we set the VDD voltage
to 0.975 V and on STMP3700, VDDD=VDDDMEM and this is too low to run EMI at 130Mhz.
This is not a good solution because under heavy load, running the EMI at 64Mhz
results in frame drops and a sluggish device. Thus we now run the EMI at 130Mhz
all the time now. To do so, increase the minimum VDD voltage to 1.275 V.
This may result is a decreased battery life on those targets but it will also
avoid all sorts of glictches and all the device to truly run at full speed.
Change-Id: Ia8391492c29fe67bc2701aa7d8cfd00a9df349e8
One cannot call lradc_acquire in IRQ context. The solution is to reserve the
channel once at init. There is an additional complication on STMP3600 where
channel mapping is fixed.
Change-Id: Idccbac634a4d9002703e2b1d57748beb9b245cbb
After compiling the ypz5 target, I have discovered that the keypad
system was refusing to compile, due to a much newer button API.
This patch adapts the target to the current imx233 implementation.
Additonally, some ADC button values have been re-adjusted.
Change-Id: Ib9bfd6aeec5e9e8dfef5887c4147201dd9028a44
Many includes of fat.h are pointless. Some includes are just for
SECTOR_SIZE. Add a file 'firmware/include/fs_defines.h' for that
and to define tuneable values that were scattered amongst various
headers.
Remove some local definitions of SECTOR_SIZE since they have to be
in agreement with the rest of the fs code anyway.
(We'll see what's in fact pointless in a moment ;)
Change-Id: I9ba183bf58bd87f5c45eba7bd675c7e2c1c18ed5
* 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
Running at 130MHz is unsafe since on those targets, we disable memory frequency
scaling because it is unstable. That leads to situation where cpu is running at
64MHz and VDD is at 1.050V. But on STMP3700, the EMI uses the VDD rail instead
of a dedicated VDDMEM rail as on STMP3780. Thus we are essentially running the
EMI at 130MHz at 1.050V when the minimum recommened voltage is 1.2V. This commit
runs the EMI at 64MHz all the time on the ZEN and ZEN X-Fi which will lead to
reduce performance but hopefully increases stability.
Change-Id: Ida6c2ec130b1778973e383d7c44a06a6ca8f9268
This feature was never used and it is not even working because weak linking
doesn't work in-between files in a library.
Change-Id: I389ea5f17be1d9db0e2150828d704be5a091e09d
It handles GPIO and PWM based LEDs, possibly with several channels (red-green
LED for example). The debug allows one to play with the setting.
Currently the code supports the ZEN, ZEN X-Fi, and ZEN Mozaic.
Change-Id: I8c3b66e6ba21778acdb123daabb724280a7d1a4f
On STMP3700 there is no dedicated speaker amplifier but speaker is always on
lineout so it makes sense to report volume and power down of lineout.
Change-Id: If666bccf36d3a5ecc6d892823522d023f3206184
There are lot IRQ and most are unused most of the time, this is annoying on
devices with small screens.
Change-Id: I7f3453f2768b8e35a5a367fbcf1e4cf3cf73bcd7
Those new statistics give the maximum time an IRQ took and also the total
time spent in IRQ, for each IRQ. Hopefully those do not take took much time
or space to collect. If this is the case, it can be enabled in debug builds only
the future.
Change-Id: I05af172897c5cb7ffcc9322452f974d8f968e29d
The IRQ handler saves registers on the IRQ stack, saves the old PC to imx233
HW_DIGCTL_SCRATCH0 register and switcht to SVC for the actual handling. The
old code had a problem in that if the unwinder is called during the IRQ (for
example by the watchdog), then __get_sp() will use SPSR_svc to discover the
previous mode, switch to it and recover SP. But SPSR_svc is invalid, it should
be SPSR_irq but we switch from IRQ to SVC mode. The new code copies SPSR_irq
to SPSR_svc in IRQ to fix this problem. It also saves/restore SCRATCH0 in
case I one day renable nested interrupts or use SCRATCH0 for other purposes.
I also changed the old watchdog code to call UIE directly instead of trying
to make the code crash with a SWI.
Change-Id: Id87462d410764b019bd2aa9adc71cb917ade32e3
The old code made the setting appear as 0dB, 1.5dB, 3dB and 4.5dB when
in fact it is 0dB, 3dB, 4.5dB and 6dB. This commit clarifies the code and
also fix this at the same time. This imx233 3D enhancement is complete crap anyway
but now you can satisfy yourself with 6 dB of pure crap, clearly an enhancement.
Change-Id: Ia3e088987c1ff0cdde228905ff70f46476a499a2
This commit adds the necessary code in the dualboot stub (bootloader) to
let rockbox control the boot process. In particular, rockbox can now choose
if the next boot will be normal (boot rockbox or OF on magic key), to OF
or to updater.
The intents (to be added in follow-up commits) are:
1) Let the user more easily reboot to the OF. On some targets it is not trivial,
especially in USB mode.
2) Automatically reboot to updater when the user drop firmware.sb at the root
of the drive (currently, the user needs to do that in OF USB mode)
3) Document this OF magic
Change-Id: I86df651dec048c318c6a22de74abb8c6b41aa9ad
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
For some reason, there was a mismatch between the setting (decibel) and the
audiohw code (centicel). This resulted in a gain divided by 10. This may
explain why some people experienced low volume with the mic on the fuze+.
Change-Id: I138ac18dd93c36f43a7dfce735efc826405c598c
Apparently I simply forgot to calibrate it when the port was done and the
current values are just plain wrong, especially for the charging curve.
Change-Id: Ied3cafa52f31f182f953714e28edc4c5e891255f
There are two very suspicious things in the power off code:
- it does not properly unlock the power register, so it should fail (!)
- it does not disable sw/hw watchdog so if register fails, the device will
most probably crash horribly because of the watchdog
I don't even understand how it worked before.
Change-Id: I9f3f94bd012e52c3b50cd5b658d68b5eb907f79b
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
