You are not Logged In!

Difference between revisions of "Public:Firmware"

From Illini Solar Car Wiki
Jump to navigation Jump to search
(Created)
 
(Outline and first sections)
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''.

Revision as of 23:02, 30 November 2020

Tool-Icon.svg This Page is a Work In Progress
Creating - Jonathan

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.


InfoIcon.png Firmware Standards
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:

  • Is this something that we could reasonably use on other boards? 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.
  • Am I able to write and test this code in a sufficiently generic manor? 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)

  • ECE220 Course page
  • CProgramming.com tutorials - you should be familiar with all the parts listed under Intro and Pointers/Arrays/Strings
  • 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