| You are not Logged In! |
Difference between revisions of "Public:GitHub/CAN"
| Line 15: | Line 15: | ||
#* In the review your message will be discussed and revised as needed for the CAN Bus | #* In the review your message will be discussed and revised as needed for the CAN Bus | ||
#* Remember: {{Highlight|CAN messages are specified independent of the code!}} '''Code is written to meet the spec, not the reverse!''' | #* Remember: {{Highlight|CAN messages are specified independent of the code!}} '''Code is written to meet the spec, not the reverse!''' | ||
| + | |||
| + | === GitHub Checks / Actions === | ||
| + | |||
| + | ==== Json Schema Validation ==== | ||
| + | This check validates the <code>canDef.json</code> to ensure it is a valid json and that all of the fields meet the requirements (such as required fields, types, valid ranges, etc). It runs on every push, so if you push something broken expect and email! | ||
Revision as of 23:17, 24 September 2020
|
This Page is a Work In Progress |
| All of it - Jonathan | |
IlliniSolarCar/CAN is the shared repository for our CAN specifications. Started for the Brizo Design cycle, this repo is the "one source of truth" of all CAN messages (on a master branch for each car). This list is then used (submoduled) by both the firmware and and telemetry systems. CAN Messages in all systems must comply with the specifications here. The specifications here should be written independently of firmware or telemetry code for what is best for CAN. The code then meets the specification.
Workflow
A major goal of this repo is to get things into the correct master branch (brizo-master for Brizo) quickly. The overall CAN Spec structure for the car is pre-defined in the ReadMe to specify what types of messages get what sort of priority and what messages are reserved. So when a new message or set of messages for a feature need to be added they should be able to be defined, reviewed, and put to master.
Making Changes
Follow the ReadMe for the most specific instructions and example, but the general workflow is:
- Create a branch for your specific CAN Message / set of Messages
- Define your messages both for firmware and telemetry usage: F
can_id.hdefines the message ID and Frequency for firmwarecan_struct.hdefines anl data structs for use in firmwarecanDef.jsondefines everything about messages for Telemetry
- Open a Pull Request for reviewIn the!
- In the review your message will be discussed and revised as needed for the CAN Bus
- Remember: CAN messages are specified independent of the code! Code is written to meet the spec, not the reverse!
GitHub Checks / Actions
Json Schema Validation
This check validates the canDef.json to ensure it is a valid json and that all of the fields meet the requirements (such as required fields, types, valid ranges, etc). It runs on every push, so if you push something broken expect and email!