Public:GitHub/CAN - Revision history

Adityaj5: Adityaj5 moved page GitHub/CAN to Public:GitHub/CAN

2021-09-11T04:27:51Z

Adityaj5 moved page GitHub/CAN to Public:GitHub/CAN

Jonathan at 18:34, 4 October 2020

2020-10-04T18:34:40Z

Jonathan: Update about checks

2020-09-30T02:55:04Z

Update about checks

Jonathan: Platforms Navbox

2020-09-26T01:28:46Z

Platforms Navbox

Jonathan: minor errors

2020-09-25T04:21:16Z

minor errors

Jonathan: Finished up most basic info

2020-09-25T04:20:39Z

Finished up most basic info

Jonathan at 04:17, 25 September 2020

2020-09-25T04:17:02Z

Jonathan at 04:09, 25 September 2020

2020-09-25T04:09:04Z

Jonathan: Created page with "{{WIP|All of it|Jonathan}}"

2020-09-24T04:05:26Z

Created page with "{{WIP|All of it|Jonathan}}"

New page

← Older revision		Revision as of 18:34, 4 October 2020
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 9: @@
 # Define your messages both for firmware and telemetry usage:
 #* <code>can_id.h</code> defines the message ID and Frequency for firmware
-#* <code>can_struct.h</code> defines anl data structs for use in firmware
+#* <code>can_data.h</code> defines any data structs for use in firmware
 #* <code>canDef.json</code> defines everything about messages for Telemetry
 # Open a Pull Request for review!
@@ Line 18: / Line 18: @@
 ==== 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!
+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!
 == Initial Setup ==

← Older revision		Revision as of 01:28, 26 September 2020
Line 24:		Line 24:

	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=}}

@@ Line 7: / Line 7: @@
 Follow the [https://github.com/IlliniSolarCar/CAN/blob/brizo-master/README.md 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
+# Define your messages both for firmware and telemetry usage:
 #* <code>can_id.h</code> defines the message ID and Frequency for firmware
 #* <code>can_struct.h</code> defines anl data structs for use in firmware
 #* <code>canDef.json</code> defines everything about messages for Telemetry
-# Open a Pull Request for reviewIn the!
+# Open a Pull Request for review!
 #* 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!'''

@@ Line 1: / Line 1: @@
 {{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 20: / Line 19: @@
 ==== 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!

← Older revision		Revision as of 04:17, 25 September 2020
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!

← Older revision		Revision as of 04:09, 25 September 2020
Line 1:		Line 1:
	{{WIP\|All of it\|Jonathan}}		{{WIP\|All of it\|Jonathan}}
		+	{{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.
		+
		+	== Workflow ==
		+	A major goal of this repo is to get things into the correct master branch (<code>brizo-master</code> for Brizo) quickly. The overall CAN Spec structure for the car is pre-defined in the [https://github.com/IlliniSolarCar/CAN/blob/brizo-master/README.md 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 [https://github.com/IlliniSolarCar/CAN/blob/brizo-master/README.md 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
		+	#* <code>can_id.h</code> defines the message ID and Frequency for firmware
		+	#* <code>can_struct.h</code> defines anl data structs for use in firmware
		+	#* <code>canDef.json</code> defines 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: {{Highlight\|CAN messages are specified independent of the code!}} '''Code is written to meet the spec, not the reverse!'''