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>

See merge request card10/firmware!333

electrodes unfiltered

See merge request card10/firmware!347

Makes the `color` module page a lot more colorful!

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

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

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

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

See merge request card10/firmware!346

Add a menu entry that opens USB storage.  Pressing any button will
return to the menu and disable USB storage again.

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

Add a mechanism for "favorite apps" which are shown at the top of the
app-list no matter what.

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

When a traveller has many apps installed, loading the menu takes some
time.  To give them feedback that card10 is in fact loading the menu
right now, immediately display a loading message before starting to
enumerate the app list.

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

fleur authored 5 years ago and rahix committed 5 years ago

Fix menu entries being ordered by directory name instead of display
name.

Co-authored-by: Rahix <rahix@rahix.de>

This reverts commit be820c07.

See merge request card10/firmware!343

See merge request card10/firmware!344

See merge request card10/firmware!342

Add a --set-time flag to allow setting card10 system time via the
USB-Serial connection.  Use like this:

    ./tools/pycard10.py --set-time

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

See merge request card10/firmware!338

See merge request card10/firmware!335

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

See merge request !334

See merge request !327

See merge request !326

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>