Jakob authored 5 years ago and Arist committed 5 years ago

Epicardium API for max86150 aligned with latest state of sensor
development on card10.

Co-Authored-by: Arist <aristkojevnikov@gmail.com>

Using a FreeRTOS mutex directly is deprecated.  Replace it with a
`struct mutex`.  Similarly, the deprecated `hwlock_acquire_timeout()`
is replaced with `hwlock_acquire()`.

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

Re-add a `hwlock_acquire()` method, but this time without a timeout
parameter.  From a functional point of view, this is just a wrapper
around `mutex_lock()`.

Additionally, add `hwlock_acquire_nonblock()` which behaves like
`mutex_trylock()`.

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

Rename hwlock_acquire() to hwlock_acquire_timeout() in preparation for
future changes to the hw-lock API.  Change all uses of the hw-lock API
to reflect this change.

This commit does not introduce any functional changes, except getting
rid of the timeout usage warnings.  This change is no-op, because the
hwlock_acquire() implementation already replaces any non-zero timeout
value with portMAX_DELAY.

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

With the switch to the new mutex API, hwlock_release() cannot fail under
any circumstances.  To emphasize this, make it return void instead of
int (Previously it just always returned 0).

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>

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>

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>

Also modifies the PMIC UI code to be more intuitive

danukeru authored 5 years ago and rahix committed 5 years ago

Previously, race-conditions between multiple serial writes could lead to
memory corruption and weird artifacts like I2C getting stuck.  This
patch introduces a write-streambuffer which queues all messages.

Co-authored-by: Rahix <rahix@rahix.de>
Signed-off-by: danukeru <danukeru@foulab.org>

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

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

Related to #20.

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

Fixes #73.

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

rahix authored 5 years ago and schneider committed 5 years ago

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

rahix authored 5 years ago and schneider committed 5 years ago

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

This includes a new RTOS task to animate the personal state LED
independently of pycardium. While the animation is running pycardium
can't control the personal state LED.

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>

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

This commit introduces a lifecycle for core 1.  Based on the new loading
system, a few APIs are made available to control the payload running on
core 1.  These are:

1. From core 1 (Pycardium, L0dable):

    - `epic_exec(name)` API Call:  Request loading of a new payload by
      name.  If the file does not exist, the call will return with an
      error code.  Otherwise, control will go to the new payload.
    - `epic_exit(retcode)` API Call:  Return from payload
      unconditionally.  This call should be called whenever a payload is
      done or when it has hit an unrecoverable error.  On `epic_exit`,
      Epicardium will reset the core back into the menu.

2. From inside Epicardium:

    - `epic_exec(name)`: This is **not** the same as the API call, as it
      needs a different implementation underneath.  It will load a new
      payload and wait until this load actually completed (synchroneous).
    - `return_to_menu()`: Return core 1 to the menu script no matter
      what it is currently doing.  This call is asynchroneous and will
      return immediately after scheduling the lifecycle task.  This task
      will then take care of actually performing the load.

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

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

Also add a mutex around API calls in preparation for future changes.

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

swym authored 5 years ago and rahix committed 5 years ago

- Implement de-initialization
- Wrap filesystem operations in semaphore
- Introduce EpicFileSystem object and move epic_file_FOO(...)
  imlementations into efs_FOO(EpicFileSystem*, ...) functions.
- epic_file_FOO(...) functions are now wrappers around the _fs_
  functions, but lock and unlock the global filesystem object before &
  after calls.  This way, all efs_ functions can assume that the
  necessary lock has been acquired.
- libff: don't use FF_FS_REENTRANT, our own FS lock is enough