Public:Firmware - Revision history

Scottjg3: Scottjg3 moved page General:Firmware to Public:Firmware: Allow public access to firmware pages

2026-09-09T01:16:51Z

Scottjg3 moved page General:Firmware to Public:Firmware: Allow public access to firmware pages

Gvi2: /* Communication Protocols */ Typo Fix

2023-09-06T21:02:31Z

Communication Protocols: Typo Fix

Jsh3 at 05:27, 14 February 2021

2021-02-14T05:27:48Z

Jonathan: Remove incorrect statement

2021-01-19T05:43:09Z

Remove incorrect statement

Jonathan: Remove WIP

2020-12-02T03:17:40Z

Remove WIP

Jonathan: UART and MBed Links

2020-12-02T03:17:27Z

UART and MBed Links

Jonathan: minor clarification

2020-12-01T06:43:49Z

minor clarification

Jonathan: Comunication protocols

2020-12-01T06:40:36Z

Comunication protocols

Jonathan: Save due to visual editor error

2020-12-01T05:07:09Z

Save due to visual editor error

Jonathan: Outline and first sections

2020-12-01T04:02:41Z

Outline and first sections

@@ Line 46: / Line 46: @@
 At the very least you should know the following high level information, the low level stuff for CAN is implemented by MBed so you just need to know how the system works at a high level so you can use it effectively:
-CAN is a highlyrobust network protocol designed for high electrical noise environments, especially vehicles. We also use highly robust cabling to augment this, with shielding, isolated power, etc. Each CAN message has an ID and a payload of 1 to 8 bytes. The CAN controller (hardware on the MCU) then transforms this into a CAN frame which includes this ID and Data as well as some more start/end frames, CRC for data integrity, and some more control information.
+CAN is a highly robust network protocol designed for high electrical noise environments, especially vehicles. We also use highly robust cabling to augment this, with shielding, isolated power, etc. Each CAN message has an ID and a payload of 1 to 8 bytes. The CAN controller (hardware on the MCU) then transforms this into a CAN frame which includes this ID and Data as well as some more start/end frames, CRC for data integrity, and some more control information.
 The messages are sent on the bus with a priority system, the lower ID the higher the priority. Therefore we organize the bus carefully (see [[GitHub/CAN]] for more info). On our CAN bus we primarily use messages that are sent are regular intervals for most data and some messages that are sent only when a certain condition is met.

← Older revision		Revision as of 05:27, 14 February 2021
Line 78:		Line 78:

	On our microcontrollers there are two ways to do UART. You can bit bang it (not ideal) or you can use the USB driver which is essentially the same thing. MBed has a serial driver that does pretty much all the work from a firmware standpoint of UART. UART is a pretty strictly defined and simple protocol so you don't have much freedom anyhow. The MBed class for implementing UART is the Serial Class. [https://www.circuitbasics.com/basics-uart-communication/ MBed OS2 Serial Documentation]		On our microcontrollers there are two ways to do UART. You can bit bang it (not ideal) or you can use the USB driver which is essentially the same thing. MBed has a serial driver that does pretty much all the work from a firmware standpoint of UART. UART is a pretty strictly defined and simple protocol so you don't have much freedom anyhow. The MBed class for implementing UART is the Serial Class. [https://www.circuitbasics.com/basics-uart-communication/ MBed OS2 Serial Documentation]
		+
		+	== Common (and uncommon) Issues ==
		+	Code will always have issues until it is very rigorously tested. Even the best programmers make mistakes and mistakes can still exist after countless reviews. Of course there are almost an infinite set of posible bugs in any piece of code so it's impossible to provide a guide of all possible problems but this list will attempt to provide some guidance.
		+
		+	* Pin assignments
		+	** make sure all pins are correctly assigned
		+	*** make sure not to mix up for exampl P0_4 and P1_4
		+	*** make sure you're looking at the correct version board schematic
		+	*** make sure no pins are being used twice
		+	* tickThreshold(...) != threshold(...)
		+	** for threshold you need to update the last time
		+	* Check for any build warnings
		+	** there are a few expected build warnings with our current setup but make sure there are no others.

	== Firmware Resources ==		== Firmware Resources ==

@@ Line 50: / Line 50: @@
 The messages are sent on the bus with a priority system, the lower ID the higher the priority. Therefore we organize the bus carefully (see [[GitHub/CAN]] for more info). On our CAN bus we primarily use messages that are sent are regular intervals for most data and some messages that are sent only when a certain condition is met.
-Every board received every message (including the ones it sends itself) and has to handle them. The CAN controller will hold a few in the buffer, but it needs to be serviced regularly to clear that buffer. Each board needs to know how to "unpack" the data for a given message. It will get the message from the controller with the ID and the raw data, it must know how to interpret the data.
+Every board received every message and has to handle them. The CAN controller will hold a few in the buffer, but it needs to be serviced regularly to clear that buffer. Each board needs to know how to "unpack" the data for a given message. It will get the message from the controller with the ID and the raw data, it must know how to interpret the data.
 [https://os.mbed.com/handbook/CAN See the MBed OS2 CAN Documentation]

← Older revision		Revision as of 03:17, 2 December 2020
Line 1:		Line 1:
−	~~{{WIP\|Creating\|Jonathan}}~~
	[[Wikipedia:Firmware\|Firmware]] is the code we write for the embedded controllers on the car. Some of this code is perhaps high enough level to be considered software, but we write is as one integrated system and refer to it all as firmware. Our firmware is all in C/C++ and we run it with the ARM Mbed OS. Our firmware setup thus far has been heavily based off of that from [[CalSol]]'s [[Zephyr]].		[[Wikipedia:Firmware\|Firmware]] is the code we write for the embedded controllers on the car. Some of this code is perhaps high enough level to be considered software, but we write is as one integrated system and refer to it all as firmware. Our firmware is all in C/C++ and we run it with the ARM Mbed OS. Our firmware setup thus far has been heavily based off of that from [[CalSol]]'s [[Zephyr]].

@@ Line 29: / Line 29: @@
 C++ has added some nifty features in recent versions, especially 11 and 14, however it also deprecated a lot of things leaving code not compilable with the new version. Keep in mind the version we are using when writing your code, this varies by project/library:
-* MBed OS2: C++0x (compiled with a compiler version from before it was officially 11 - originally it was going to be 08 or 09, hence 0x)
+* MBed OS2: C++0x (compiled with a compiler version from before it was officially 11 - originally, before delay, it was going to be 08 or 09, hence 0x)
-* Common: C++11
+* Argo and Brizo Common: C++11
-* Various Projects: C++11 (although probably could update to C++14 without much work)
+* Argo Projects: C++11
 === Hardware ===
@@ Line 51: / Line 52: @@
 Every board received every message (including the ones it sends itself) and has to handle them. The CAN controller will hold a few in the buffer, but it needs to be serviced regularly to clear that buffer. Each board needs to know how to "unpack" the data for a given message. It will get the message from the controller with the ID and the raw data, it must know how to interpret the data.
 === I2C ===
@@ Line 58: / Line 61: @@
 Each device has an address that is included in the message to indicate that the message is for that device. On some devices this will be set in hardware on the chip, in others you can change some or all of it by pulling pins high or low. Address clashes are one of the biggest problems with I2C, you may want to use 4 of a device but it only has two address options, which makes that impossible. However, make sure to check as some manufacturers will sell the same device with different address options under different product numbers.
 === SPI ===
-Serial Peripheral interface is the other most common communication protocol to use between MCUs and peripheral devices. Unlike I2C it is rated for off-board use for a short distance, for example to devices like an encoder that might be embedded in a mechanical device a dozen cm away. For technical details the [[Wikipedia:Serial Peripheral Interface|wikipedia article on SPI]] is one of the better Wikipedia articles. Generally, you can thing of each device as just a shift register shifting data in/out.
+Serial Peripheral interface is the other most common communication protocol to use between MCUs and peripheral devices. Unlike I2C it is rated for off-board use for a short distance, for example to devices like an encoder that might be embedded in a mechanical device a dozen cm away. For technical details the [[Wikipedia:Serial Peripheral Interface|wikipedia article on SPI]] is one of the better Wikipedia articles. Generally, you can thing of each device as just a shift register shifting data in/out. It sends the data serially, one at a time.
 SPI buses have at least 4 signals. In fact they have 3 + N signals where N is the number of independent slave devices as you need a chip select signal for each of device. There will then be shared Clock, MOSI (Master Out, Slave In), and MISO (Master In, Slave Out) lines. The speed of a SPI bus is limited by the hardware, the definition itself has no max speed like I2C. You can also change speeds per device as they should ignore everything when their select signal is not on. Additionally, the separate data lines are utilized
@@ Line 67: / Line 72: @@
 The biggest challenge with SPI is that you need a slave select signal for each device, this can eat up a lot of I/O pins. To help remedy this, many devices intended to be used in groups, support daisy chaining. This would allow you to, for example, send one 32bit frame instead of two 16 bits ones. The hardware is configured to allow data shifts through the first device into the next. This saves a select pin and speeds up communication as switching devices takes some time.
 === UART ===
 == Firmware Resources ==

@@ Line 1: / Line 1: @@
 {{WIP|Creating|Jonathan}}
-[[Wikipedia:Firmware|Firmware]] is the code we write for the embedded controllers on the car. Some of this code is perhaps high enough level to be considered software, but we write is as one integrated system and refer to it all as firmware. Our firmware is all in C/C++ and we run it with the ARM Mbed OS. Our firmware has been heavily based off of that from [[CalSol]]'s [[Zephyr]].
+[[Wikipedia:Firmware|Firmware]] is the code we write for the embedded controllers on the car. Some of this code is perhaps high enough level to be considered software, but we write is as one integrated system and refer to it all as firmware. Our firmware is all in C/C++ and we run it with the ARM Mbed OS. Our firmware setup thus far has been heavily based off of that from [[CalSol]]'s [[Zephyr]].
 {{RemarksBox Info|Title=Firmware Standards|Text=Make sure to see also our current standards for writing firmware: [[Firmware Standards]]}}

← Older revision		Revision as of 04:02, 1 December 2020
Line 1:		Line 1:
−	{{WIP\|Creating\|Jonathan}}{{RemarksBox Info\|Title=Firmware Standards\|Text=Make sure to see also our current standards for writing firmware: [[Firmware Standards]]}}	+	{{WIP\|Creating\|Jonathan}}
		+	[[Wikipedia:Firmware\|Firmware]] is the code we write for the embedded controllers on the car. Some of this code is perhaps high enough level to be considered software, but we write is as one integrated system and refer to it all as firmware. Our firmware is all in C/C++ and we run it with the ARM Mbed OS.
		+
		+	{{RemarksBox Info\|Title=Firmware Standards\|Text=Make sure to see also our current standards for writing firmware: [[Firmware Standards]]}}
		+
		+	== Overview ==
		+	We write firmware for each system on the car (Battery Management, Dash, etc.). Each system has its own special requirements and hardware that it has to work on, but we have standardized many things for each board and try to use a similar style for each. For one, we base code for each project on the same starter project so that people can change projects and still be familiar with what is where. Additionally, we use the same Operating System, same Micro controllers, and same tool chain across them all.
		+
		+	=== Structure ===
		+	For each project that is built there are actually three different things being built - MBed, Common, and the project. MBed and Common are compiled as static libraries and then linked to the main binary for the project. MBed and Common are consumed by every project, and thus changes there must be incorporated to every project and should be made with that in mind.
		+
		+	Within each project we maintain a similar structure as well. See [[Firmware Standards]] for current standards for firmware.
		+
		+	'''''FAQ: Should my class/driver be in Common or my specific project?''''' It should be in your project unless the answers to each of the following is yes:
		+	* ''<u>Is this something that we could reasonably use on other boards?</u>'' For example a driver for the battery voltage measurement chip probably does not have a use anywhere else in a solar car while the Analog to Digital converter used for current measurement could also be used for other things on other boards.
		+	* ''<u>Am I able to write and test this code in a sufficiently generic manor?</u>'' Code in common should be relatively generic and tested for more generic usages. If the board implements this hardware in a very specific way and you don't have the ability to write or test for anything else the code is probably not ready for common. If extended in the future it is always easy to move.
		+
		+	=== MBed ===
		+
		+	=== C++ Versions and Libraries ===
		+
		+	=== Hardware ===
		+
		+	== Communication Protocols ==
		+
		+	=== CAN ===
		+
		+	=== I2C ===
		+
		+	=== SPI ===
		+
		+	=== UART ===
		+
		+	== Firmware Resources ==
		+
		+	=== Coding and C++ Basics: ===
		+	Most of the code you write in solar car is likely stuff you can learn yourself from the internet or reading out other code. However, it is good to know the basics of coding taught in ECE220/CS125 and the data structures in CS225. If you have not taken these yet here are some resources for each:
		+
		+	''ECE220 content'' (this is the ECE coding intro like CS125, but in C/C++ so more relevant to solar car)
		+	* [https://wiki.illinois.edu//wiki/display/ece220/Home ECE220 Course page]
		+	* [https://www.cprogramming.com/tutorial/c-tutorial.html CProgramming.com tutorials] - you should be familiar with all the parts listed under Intro and Pointers/Arrays/Strings
		+	* [http://www.tutorialspoint.com/ansi_c/c_introduction.htm Tutorials Point info] - its good to know ''Program Structure'', ''Basic Data Types'', ''Variable Types'', ''Using Constants'', ''Control Statements'', ''Operator Types'', ''Pointing to Data'', ''Using Functions'', and ''Structured Datatypes''
		+	''CS225 content''
		+	* [https://courses.engr.illinois.edu/cs225 CS225 course website]
		+	* [http://www.cplusplus.com/doc/tutorial/ CPlusPlus.com tutorials] - stuff here that you should know (assuming you know the above from ECE220) is ''Data Structures'', ''Classes (I)'', ''Classes (II)'', and ''Special Members''.