| You are not Logged In! |
Difference between revisions of "Public:GitHub/CAN"
m (minor errors) |
m (Adityaj5 moved page GitHub/CAN to Public:GitHub/CAN) |
||
| (3 intermediate revisions by one other user not shown) | |||
| Line 1: | Line 1: | ||
| + | {{Infobox GitHub Repo|org=IlliniSolarCar|repo=CAN|status=Active|content=CAN Spec Definition for each car|forkOrg=|forkRepo=|defaultBranch=brizo-master|access=Private|license=All Rights Reserved to ISC|branching=Topic / Feature Branches|maintainer=Electrical and Telemetry Groups|checks=* Reviews Required to master | ||
| + | * JSon Schema Validation | ||
| + | * Header File Validation}} | ||
| + | |||
{{GithubRepo|org=IlliniSolarCar|repo=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. | {{GithubRepo|org=IlliniSolarCar|repo=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. | ||
| Line 9: | Line 13: | ||
# Define your messages both for firmware and telemetry usage: | # Define your messages both for firmware and telemetry usage: | ||
#* <code>can_id.h</code> defines the message ID and Frequency for firmware | #* <code>can_id.h</code> defines the message ID and Frequency for firmware | ||
| − | #* <code> | + | #* <code>can_data.h</code> defines any data structs for use in firmware |
#* <code>canDef.json</code> defines everything about messages for Telemetry | #* <code>canDef.json</code> defines everything about messages for Telemetry | ||
# Open a Pull Request for review! | # Open a Pull Request for review! | ||
| Line 18: | Line 22: | ||
==== Json Schema Validation ==== | ==== 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 | + | 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 an email! |
| + | |||
| + | This check must pass in order to merge a pull request! | ||
| + | |||
| + | ==== Header File Validation ==== | ||
| + | This check validates the header files to verify they are valid headers - i.e. data types are valid and correct and syntax is all good. This means that, at the very least, any header that makes it to master will be a valid header file that can be used. Since this check has to download and install the arm embedded build tools, which takes a while, this check only runs on pull requests to master. | ||
| + | |||
| + | This check must pass in order to merge a pull request! | ||
== Initial Setup == | == Initial Setup == | ||
| Line 24: | Line 35: | ||
You can also clone it separately, <code>git clone https://github.com/IlliniSolarCar/CAN.git <optional custom folder name></code> to work on. Working on the CAN repo doesn't require any additional setup, you can edit the json or .h files in pretty much any text editor, although some are nicer than others. | You can also clone it separately, <code>git clone https://github.com/IlliniSolarCar/CAN.git <optional custom folder name></code> to work on. Working on the CAN repo doesn't require any additional setup, you can edit the json or .h files in pretty much any text editor, although some are nicer than others. | ||
| + | |||
| + | {{Platforms Navbox|collapsed=}} | ||
Latest revision as of 23:27, 10 September 2021
 IlliniSolarCar/CAN
Active | |
|---|---|
| ReadMe | |
| Content: | CAN Spec Definition for each car |
| Access: | Private |
| License: | All Rights Reserved to ISC |
| Branching Strategy: | Topic / Feature Branches |
| Maintained By: | Electrical and Telemetry Groups |
| Actions & Checks: |
|
|
View All ISC Repos
| |
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:
can_id.hdefines the message ID and Frequency for firmwarecan_data.hdefines any data structs for use in firmwarecanDef.jsondefines everything about messages for Telemetry
- Open a Pull Request for review!
- 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 an email!
This check must pass in order to merge a pull request!
Header File Validation
This check validates the header files to verify they are valid headers - i.e. data types are valid and correct and syntax is all good. This means that, at the very least, any header that makes it to master will be a valid header file that can be used. Since this check has to download and install the arm embedded build tools, which takes a while, this check only runs on pull requests to master.
This check must pass in order to merge a pull request!
Initial Setup
You can work on this repo from the GitHub/b-fw or GitHub/Telemetry repos - it is a submodule in both.
You can also clone it separately, git clone https://github.com/IlliniSolarCar/CAN.git <optional custom folder name> to work on. Working on the CAN repo doesn't require any additional setup, you can edit the json or .h files in pretty much any text editor, although some are nicer than others.
| |||||||||||||||