1. 19 Nov, 2019 1 commit
  2. 13 Nov, 2019 1 commit
  3. 10 Nov, 2019 1 commit
  4. 03 Nov, 2019 5 commits
    • 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: Rahix's avatarRahix <rahix@rahix.de>
      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: Rahix's avatarRahix <rahix@rahix.de>
      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: Rahix's avatarRahix <rahix@rahix.de>
      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: Rahix's avatarRahix <rahix@rahix.de>
      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: Rahix's avatarRahix <rahix@rahix.de>
      9a5a46cd
  5. 19 Oct, 2019 1 commit
  6. 06 Oct, 2019 1 commit
  7. 05 Oct, 2019 8 commits
    • fleur's avatar
      led feedback on top and bottom pcb on boot for people with broken displays · 31a8277b
      fleur authored and dx's avatar dx committed
      31a8277b
    • Rahix's avatar
      fix(docs): Fix a docs-build warning · 51d40ee1
      Rahix authored
      
      
      Signed-off-by: Rahix's avatarRahix <rahix@rahix.de>
      51d40ee1
    • Rahix's avatar
      chore(epicardium): Use panic() for all critical errors · 0e5c6243
      Rahix authored
      
      
      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's avatarRahix <rahix@rahix.de>
      0e5c6243
    • Rahix's avatar
      chore(epicardium): Switch from MXC_ASSERT to assert · 070867f8
      Rahix authored
      
      
      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's avatarRahix <rahix@rahix.de>
      070867f8
    • Rahix's avatar
      feat(epicardium): Use panic() for assertion failures · 9d44017b
      Rahix authored
      
      
      Define `__assert_func()` so a failing `assert()` will trigger a panic.
      
      Signed-off-by: Rahix's avatarRahix <rahix@rahix.de>
      9d44017b
    • Rahix's avatar
      feat(epicardium): Add a panic() function · 1536da34
      Rahix authored
      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's avatarRahix <rahix@rahix.de>
      1536da34
    • Rahix's avatar
      feat(serial): Add function to switch serial to synchronous · 5e25bc89
      Rahix authored
      
      
      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's avatarRahix <rahix@rahix.de>
      5e25bc89
    • Philip Stewart's avatar
      fix(gfx/display): Draw partially clipped primitives · 14d5abcc
      Philip Stewart authored and Rahix's avatar Rahix committed
      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.
      14d5abcc
  8. 04 Oct, 2019 1 commit
  9. 03 Oct, 2019 1 commit
  10. 01 Oct, 2019 2 commits
  11. 24 Sep, 2019 1 commit
  12. 22 Sep, 2019 2 commits
  13. 21 Sep, 2019 1 commit
    • Ferdinand Bachmann's avatar
      feat(rtc): Add monotonic clock · f1251d66
      Ferdinand Bachmann authored and Rahix's avatar Rahix committed
      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
      f1251d66
  14. 16 Sep, 2019 1 commit
  15. 15 Sep, 2019 2 commits
    • Rahix's avatar
      feat(serial): Add serial_flush function · 86c8339e
      Rahix authored
      
      
      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's avatarRahix <rahix@rahix.de>
      86c8339e
    • schneider's avatar
      fix(ble): Increase BLE task priority · 3a0b7452
      schneider authored
      Also decrease the time needed to update the LEDs
      3a0b7452
  16. 14 Sep, 2019 7 commits
  17. 06 Sep, 2019 1 commit
  18. 05 Sep, 2019 3 commits