Skip to content
Snippets Groups Projects
  1. Nov 09, 2019
  2. Nov 03, 2019
    • rahix's avatar
      chore(fatfs): Port to new mutex API · 86c7418a
      rahix authored
      
      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: default avatarRahix <rahix@rahix.de>
      Verified
      86c7418a
    • rahix's avatar
      chore(api-lock): Port to new mutex API · 75278836
      rahix authored
      
      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: default avatarRahix <rahix@rahix.de>
      Verified
      75278836
    • rahix's avatar
      chore(sensor-streams): Port to new mutex API · 44ea81f2
      rahix authored
      
      Using a bare FreeRTOS mutex is deprecated.  Replace it with the new
      `struct mutex`.  This should increase stability of the module.
      
      Signed-off-by: default avatarRahix <rahix@rahix.de>
      Verified
      44ea81f2
    • rahix's avatar
      chore(lifecycle): Port to new mutex API · cc5f0e29
      rahix authored
      
      Using a bare FreeRTOS mutex is deprecated.  Replace it with the new
      `struct mutex`.  This should increase stability of the module.
      
      Signed-off-by: default avatarRahix <rahix@rahix.de>
      Verified
      cc5f0e29
    • rahix's avatar
      feat(epicardium): Add a proper mutex implementation · 9a5a46cd
      rahix authored
      
      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: default avatarRahix <rahix@rahix.de>
      Verified
      9a5a46cd
    • rahix's avatar
      Merge 'Super basic ECG log plotter' · c7e40e27
      rahix authored
      See merge request card10/firmware!333
      c7e40e27
  3. Nov 02, 2019
  4. Oct 23, 2019
  5. Oct 22, 2019
  6. Oct 19, 2019
  7. Oct 18, 2019
  8. Oct 10, 2019
  9. Oct 09, 2019
  10. Oct 06, 2019
  11. Oct 05, 2019
Loading