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>

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.

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>

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>

As discussed in !316, this commit prevents I2C lockup by
discarding overflowing samples instead of blocking until they have been
read.  This is not ideal as the samples read will not be the most recent
ones.  A deeper refactor of the sensor-stream internal API can fix this
in the future.

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

Ferdinand Bachmann authored 5 years ago and rahix committed 5 years ago

Squashed commits:

e94f7bf9 epicardium/rtc: add monotonic time
e0691c6d pycardium/modules/utime.c: add bindings for monotonic time
756c13df epicardium/rtc: fix numerically unstable subsecond decoding

         the subsecond encoding function from epic_rtc_set_milliseconds
         and the corresponding decoding function from
         epic_rtc_get_milliseconds are not numerically stable.

         i.e., encoding 5 milliseconds to 20 subsecs and immediately
         afterwards decoding that yields 4 milliseconds.

         Adding a bias of 999 (0.24 milliseconds) to the decoding
         function makes it numerically stable, while never decoding any
         subsecond value to more than 999 milliseconds.

e99e278b epicardium/rtc: only poll time once for calculating monotonic_offset
18936b7e pycardium/modules/utime.c: run clang-format
869ac617 epicardium/rtc: add explanation comment for numerically stable subsecond decode

serial_flush() allows flushing the serial buffer from anywhere in
Epicardium.

- When run from thread mode it will flush to UART, CDC-ACM and BLE.
  This is similar to what the serial task would do once it is
  rescheduled.
- When run inside an exception handler, it will only flush to UART
  because CDC-ACM and BLE cannot be flushed from an ISR.  Note that
  characters flushed this way will never appear on the other outputs,
  even if the serial task is scheduled at some point afterwards.

The main use of this function is to ensure output of messages even in
cases of critical failures.

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

Closes #50

Closes #109

Due to a known issue (#133) the first call to bhy_mapping_matrix_set
can fail. This is a quick fix.

Also modifies the PMIC UI code to be more intuitive

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

Fixes #156

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