RFC: Proper Mutexes

See merge request card10/firmware!345

Allow calling buttons.read() without an argument.  This is equivalent to
a mask with all bits set (that is, buttons.read(255)).  Additionally,
add a check that the mask is within the limits (< 256).

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

For convenience, allow calling os.listdir() without any argument.
This is equivalent to calling os.listdir("").

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

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>

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 !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 !338

See merge request !335

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

See merge request card10/firmware!334

See merge request card10/firmware!327