Fix sign-compare warnings for these constants.

Signed-off-by: Rahix <rahix@rahix.de>

Signed-off-by: Rahix <rahix@rahix.de>

It does not make sense for the filesize to be given as `int`; it cannot
ever be negative.  Instead, use `size_t` which is unsigned.

Signed-off-by: Rahix <rahix@rahix.de>

Fix all warnings in epicardium/modules.

Signed-off-by: Rahix <rahix@rahix.de>

Make the length parameter a `size_t` instead of a `intptr_t`.  A signed
value does not make any sense here and just leads to weird behavior if a
negative value is given nonetheless.

See issue card10/firmware#192

Signed-off-by: Rahix <rahix@rahix.de>

Signed-off-by: Rahix <rahix@rahix.de>

Fix all warnings found by `-Wsign-compare` in epicardium/api.

Signed-off-by: Rahix <rahix@rahix.de>

Signed-off-by: Rahix <rahix@rahix.de>

As opposed to defining all possible keys at compile time.

In preparation for next commit

Mostly changing things like if { ... return} else { ... } to not have
an extra indentation level of the else part.

The diff is probably very weird even with stripped whitespace.

Fix the display backlight staying off while the pmic task prints its
messages (power-off/sleep & battery critial).

Signed-off-by: Rahix <rahix@rahix.de>

Using a bare FreeRTOS mutex is deprecated.  Replace it with the new
`struct mutex`.  This should increase stability of the module.  In the
process of switching, also remove the `EPIC_FAT_STATIC_SEMAPHORE` define
as it is no longer needed with the new mutex API.

Signed-off-by: Rahix <rahix@rahix.de>

Using a bare FreeRTOS mutex is deprecated.  Replace it with the new
`struct mutex`.  This should increase stability.

Additionally, fix a bug in `lifecycle.c:do_load()` where the function
would return without unlocking the API mutex if `hardware_reset()`
returns an error.

Signed-off-by: Rahix <rahix@rahix.de>

Using a bare FreeRTOS mutex is deprecated.  Replace it with the new
`struct mutex`.  This should increase stability of the module.

Signed-off-by: Rahix <rahix@rahix.de>

Using a bare FreeRTOS mutex is deprecated.  Replace it with the new
`struct mutex`.  This should increase stability of the module.

Signed-off-by: Rahix <rahix@rahix.de>

In the current firmware, different locking mechanisms a littered around
the code-base.  Among them are bare FreeRTOS mutexes and the hw-locks.
The callers for these often specify timeouts but don't make much effort
in A) picking robust values for the timeout and B) recovering gracefully
from a timeout happening.  Most of the time, we return -EBUSY to _Python
code_.  This is really really bad API design.  The firmware needs to
have enough integrity to ensure these situations can't ever occur.

To combat this, add a new locking primitive: The `struct mutex`.  The
intention is to replace all other locking and synchronization APIs with
this one.  This will provide one central place to debug any sort of
locking issues.

The `struct mutex` API is based on a few assumptions about locking.
Those are detailed in `Documentation/epicardium/mutex.rst`, which is
part of this commit.  The most important one is:

    Locking can **never** fail.

By requiring this to be true, we eliminate the need for drivers to
contain (often incorrect) logic for dealing with locking fails.  This
should drastically improve the stability of the firmware in regards to
lock-related bugs.

This commit does not introduce any functional changes yet.

Signed-off-by: Rahix <rahix@rahix.de>

Signed-off-by: Rahix <rahix@rahix.de>

Signed-off-by: Rahix <rahix@rahix.de>

Unify unrecoverable errors to use panic() in all cases.  This will allow
further changes to panic() to work for all critical errors.

Signed-off-by: Rahix <rahix@rahix.de>

Newlib assert uses __assert_func and thus our panic() function while
MXC_ASSERT uses a custom assertion logic.  Newlib assert is also more
portable as it works in expression position while MXC_ASSERT only works
as a statement.

Signed-off-by: Rahix <rahix@rahix.de>

Define `__assert_func()` so a failing `assert()` will trigger a panic.

Signed-off-by: Rahix <rahix@rahix.de>

In unrecoverable situations we should provide a common way to output the
cause of the error and then reset the CPU.  The panic() function is
mean to be exactly that.  It outputs the error-cause, stack-trace, and
firmware revision, accompanied by a link to the issue-tracker to
encourage people to report the error.  After a timeout of ~1.5s it
resets the CPU and reboots.

Future Work:

 - Right now, the stack-trace only has a depth of one which is the
   return address from where panic() was called.  In the future it might
   make sense to provide a deeper stack-trace if a robust implementation
   is possible.
 - Integration of @msgctl's faultscreen (!79) so users who don't have
   the serial console open at all times can also see what happened.

Signed-off-by: Rahix <rahix@rahix.de>

In severe error conditions, asynchronous prints will never work.  For
such cases we need a way to make prints happen synchronously again, the
same way it works during early boot.  Add a serial_return_to_synchronous()
function which unconditionally switches the serial driver code to
synchronous mode.

Only use this function in unrecoverable error conditions!

Signed-off-by: Rahix <rahix@rahix.de>

Philip Stewart authored 5 years ago and rahix committed 5 years ago

Fix two bugs in the display/gfx module:

1. The animation of the simple_menu used in the main menu had the issue
   that there is a black line visible at the top.  This is due the
   gfx_puts method ignoring lines, where the top pixel of the string is
   above the top of the screen.  As gfx_puts uses gfx_setpixel which in
   turn ignores pixels outside of the screen, remove the check in
   gfx_puts.
2. X and Y coordinates were cast to unsigned-ints before being given to
   the gfx-library which means calls like circ(0, -10, 30) would be draw
   at coordinates like [0,65526].  Fix this by changing the data-type of
   all coordinates to signed-integers.

Also remove the x and y ranges from the documentation of the individual
python functions and instead add a general documentation about the
screen and it's size/coordinate system.

Signed-off-by: Rahix <rahix@rahix.de>

Mateusz Zalega authored 5 years ago and rahix committed 5 years ago

Signed-off-by: Mateusz Zalega <mateusz@appliedsourcery.com>