Ers zephyr work#19
Open
tedhavelka wants to merge 126 commits into
Open
Conversation
… . . board firmware. These files comprise three sample apps in a source tree which somewhat mirrors Zephyr RTOS source tree organization. These files are added in `lv3.1-recovery/controlSystem/RecoveryBoard/firmware-zephyr`. This directory exists alongside as indicated by the command named 'tree': . ├── firmware ├── firmware-zephyr ├── pcb └── README.md Note these tiny samples assume there is a Zephyr workspace, or Zephyr source tree in some parent directory above the directory in which these ERS firmware project files are cloned.
ERS application in progress, with all basic peripherals such as ADC, DAC, CANBus, GPIO in code base. What remains to be completed: (1) logic to lock and to unlock drogue chute lock ring. (2) API to drive the motor at various currents and in both directions. (3) full testing of lock ring position determination.
…and . . . perform some organizing and clean up in ERS shell commands module.
…o . . . update TODO.txt.
…tion . . . determination. The timer allows for an easier way to enable and disable ring position figuring, as well as to set its frequency at build time and at run time by changing a single parameter.
…nd . . . add comments to "keeper" module about three kinds of data stored in this module: configuration, readings, and run time state data.
Simple error to fix, needed to ensure we do not fall through to successive IF constructs in comparison tests of Hall reading with Hall sensor defined limits.
…to . . . change lock ring position detection interval at run time. Note also observing a problem with work element submission. The work element only runs for a few seconds, then continues to be submitted but no longer runs. Tried: (1) confirming that routine body of submitted work runs. (2) checked return values of k_work_submit() call. (3) added call to k_work_flush() and checked its return values. (4) commented out mutex in keeper module protecting Hall readings access. Still no success. Investigation underway . . .
…ge in . . . lines of code but a significant change in scheduling.
… . . . reading limits. Also noting that motor turns over at a minimum DAC output somewhere between 350 DAC steps and 450 DAC steps.
…for . . . implementing commands to lock and to unlock drogue (or main) parachute ring.
…a . . . duplicate module logging symbol code for ADC module. Set arbiter log level to "ERR".
… yet . . . connected to code which detects ring position.
…2.0. Note, there is some problem in which on two of Ted's localhosts a call to `west update` checks all of Zephyr's third party modules but skips Zephyr RTOS itself.
…c . . . and adjust DAC setting for motor in situ. Observing ring to lock and to unlock over about 300 milliseconds. Checking ring position every 10 ms. DAC setting is 800. But unsure whether ring position test is getting correct data as motion always stops at the maximum count of ring position checks, a kind of "hard" timeout.
…or . . . ring lock and unlock operations.
… . . necessary in order to make use of these values in a given firmware run time.
… . . . the preprocessor built-in paste macro `##`.
… . . . some or even many of these configuration items could be moved into Kconfig, and be useful this way so long as firmware is Zephyr based or built in a larger system which supports Kconfig.
in comment to accompany each command.
status LED code from `main.c`.
tedhavelka
force-pushed
the
ers-zephyr-work
branch
from
afcc1a1 to
d3a6f8a
Compare
…mit . . . Zephyr third party modules to those needed by ERS and a few more. Reduces download tie and disk space by many hundreds of megabytes.
directories: bootloader, modules, tools, zephyr.
… off . . . the injection of spoofed sender board heart CAN frames. Add a helper script to start venv and set a Zephyr envvar that's unset on a particular localhost.
…each . . . with RING_POS_ instead of RING_ to make them more distinct from ring state enum element names.
…ephyr, which should be set up by some other means for the ERS Zephyr workspace.
while hacky will help "tame" Zephyr shell module which echoes all Zephyr log messages.
…essage frames in green.
…mprove response time to system state changes.
…gue chute firmware from same code base.
…age with the 0x720 frame id.
This is a more involved commit, and unexpected. After a month away from ERS code (for mag card work and L1 rocket certification) Ted performs `west udpate`. The Zephyr ERS app happens to be building against Zephyr 3.7.0 LTS which sees very few changes as a stable release. But something must have changed as the compilation after a month's time failed with many doubly defined symbols. The repeat definitions were reported in a couple of header files of Pico standard C library. Zephyr supports multiple reduced footprint C libraries, newlibc among them. The ERS hardware is also not Raspberry Pi Pico based, so this commit switches embedded C libraries from picolibc to newlibc. (Unsure why Zephyr's build system would default to picolibc in first place.) Newlibc requires for its printf family functions an explicit pound include of stdio.h. This include added to two source files where needed. The ERS app then compiled and ran for a short while but hard-faulted. Gdb shows that the arbiter module was overflowing its stack space, so increase that from 512 bytes to 1024 bytes. On the support and utils side, rename 'build.sh' to 'compile.sh'. This is a tiny script to capture the handful of options to 'west build' which take a little time to type and are easy to forget. This renaming supports tab completion which is hampered by cmake's default behavior of making an output directory named 'build', which in our situation then looks similar to 'build.sh'.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This pull request introduces a Zephyr RTOS based ERS drogue board firmware application.
Pending tasks to change this PR to "Open":
[ ] update top level README design document
[ ] retest code with lock ring assembly and sister ERS boards
[ ] apply any code amendments needed based on tests with LV3.1 avionics
Note, while it is simple to add a configuration flag and have this code base support both drogue parachute and main parachute ERS firmware apps, the code does not implement the ERS "Sender" application. This could be done, but is already implemented in William Jeffrey's Rust language ERS project.
This Zephyr application written in large part to compare C and Zephyr implementation with Rust and Embassy implementation.