1. 19 Nov, 2019 1 commit
  2. 13 Nov, 2019 1 commit
  3. 10 Nov, 2019 1 commit
  4. 03 Nov, 2019 4 commits
    • 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. 06 Oct, 2019 1 commit
  6. 05 Oct, 2019 7 commits
    • 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
  7. 04 Oct, 2019 1 commit
  8. 01 Oct, 2019 1 commit
  9. 22 Sep, 2019 1 commit
  10. 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
  11. 16 Sep, 2019 1 commit
  12. 15 Sep, 2019 1 commit
    • 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
  13. 14 Sep, 2019 6 commits
  14. 05 Sep, 2019 2 commits
  15. 31 Aug, 2019 5 commits
  16. 30 Aug, 2019 3 commits
  17. 28 Aug, 2019 2 commits
    • swym's avatar
      feat(epicardium): read card10.cfg · f1d63669
      swym authored and Rahix's avatar Rahix committed
      Adds simple config parser along with config_ API that:
      
      - supports default values for options
      - allows typed querying of config values
      - types supported: boolean, integer, floating point and string
      
      unknown options are ignored and LOG_WARNed on the console
      f1d63669
    • swym's avatar
      feat(epicardium): GPIOs are configurable as ADC · 490ffdc3
      swym authored and Rahix's avatar Rahix committed
      closes #82
      490ffdc3
  18. 27 Aug, 2019 1 commit