Foreword

You can refrain from downloading anything on the linked websites unless it is in the Installation section, we have set up a template package that already contains most of the libraries and it should be straightforward to get set up on the rest of the development environment. This guide is meant to help you understand the layout of the template and understand the toolchain required for developing embedded software for the solar car. It aims to be a comprehensive guide to getting you to the point where you can start developing as soon as you feel comfortable with the C paradigms for embedded programming. 

...

• Compiler: GCC ARM
  • A compiler builds human readable source code into a machine readable target language, usually a machine executable or binary for a specific architecture. GCC ARM compiles C code into machine readable .elf, .hex or .bin files which can be flashed onto the MCU. GCC ARM is the standard open source compiler for ARM architecture. Compilers are powerful and often catch typos, errors, and warnings; they also optimize code for efficiency or size. The compiler flags set these behaviors of the compiler.
• Build Tools: GNU Make and GNU Linker aka ld
  • Build tools usually instruct the compiler on where the source files it is building are located and which files to look at in order to build the target program. Often a Linker will be used with a Makefile to build a collection of C and header files into a standard library which can be included in your program. GNU Make and Linker are long-standing open source standard build tools used by many developers, although many alternatives do exist.
• Linter: cpplint (modified)
  • A linter is a program that checks the style of source code for errors. Some linters also perform static analysis, ours does not, which look to catch programming errors before the code is executed. cpplint is Google's open source linter for C/C++ programs, note that our Coding Standards closely follow Google's and as a result, this linter works well for us. The linter has been modified to support some slightly different standards and will be less pedantic.
• Flasher: st-link/GDB or OpenOCD
  • A flasher will transfer firmware (our compiled program) onto the MCU. Typically, this is done with a special cable or by a chip on the PCB and requires flashing software to transfer the contents of the source code into the memory of the MCU. For our purposes, we will be using st-link with GDB for debug which is the chip manufacturer supported method or OpenOCD the open source version.
• IDEs: Eclipse or any text editor (Core members like: Vim, Sublime Text and Visual Studio Code)
  • Anyone just starting out and especially those using Windows are strongly encouraged to use the Eclipse IDE which is one of the few ways to get a working Toolchain on a Windows machine. Note that we will not be supporting any issues you may encounter using other methods on Windows although, we will also support Linux if you want a VM or dual boot but you will need to figure out the install on your own. 
• Source Control: GitHub
  • We use GitHub for our source and versioning control. In order to contribute to the codebase, you will also need to start using GitHub. If you are new to GitHub you may want to check out these guides. We have tight controls on out git repositories and require all commits to come from pull requests and that they are squashed prior to submitting. We are also now using Git Hooks, for now these will be run locally but web hooks may be enforced.

Installation

General Instructions:

...

Word of Warning: This install is probably the most painful and likely to break/not work do your best and if you get stuck just ask

...

Step 2: Follow this guide to install the correct build tools and the GCC ARM compiler and set them up in your environment. You may want to disregard the comments about not adding the programs to the system environment path as I had trouble without doing that. Also, make sure you prepend the path variables if you do add them as if they are at the end they have a tendency not to work. 

Step 3: Install Python version 2.7 you will need to add both Python 2.7 to it to your environment path so that the makefile runs the lint correctly.

Step 4: In theory that should be everything. Try it by cloning a copy of the template from here and building it in Eclipse. If you can't build then you may have to use bash for Windows 10 to build (goto step 6).

If building in Eclipse works for you then you can stop here.

Step 5: Follow this guide to set up bash for Windows 10. If you don't have Windows 10 I suggest getting a Linux VM at this point.

Step 6: Goto step 1 of the Linux guide and follow it (I only needed to install gcc-arm-none-eabi and make). You can skip step 4 as Bash for Windows does not support usb interfaces. You will have to debug from Eclipse. 

Step 7: Run make and watch success happen (I almost guarantee this will work).

Congrats if you made it this far without actually dual-booting or getting a Linux VM!

Linux:

In theory, this is the easiest install method. For that reason, those interested in running a VM or dual-booting their machine to get Linux are welcome to do so. Although, we don't explicitly support either we can probably provide guidance if you get really stuck. However, if you break anything doing it we are not liable!

...

Step 1: Install 32 bit C libraries and some of the build tools if you don't have them. There may be more if you aren't on Ubuntu (if you are on Arch you many need all of multilib :'( )

$ sudo apt-get -y install lib32z1 lib32ncurses5 lib32bz2-1.0 binutils gdb python2 gcc-arm-none-eabi

Python may be called python or python2 or python2.7 depending on your distro.

Step 2:  Download and unpack If you weren't able to download the gcc toolchain download, unpack and install the GCC ARM Linux tarball from here. Alternatively install it from your package repository if you have one.Step 3: Download Add Python 2.7 (if you didn't in step 1) and add it to your ~/.bashrc or ~/.bash_profile if is isn't already in your PATH. . Also give is the bash alias python2 if it isn't already accessible under that name.

Step 4: Install st-link or OpenOCD, they may be in your package repository but you can always build from source. 

Step 5: In theory that is everything, assuming your distribution is sane and already has gcc and make installed. Feel free to grab Grab an IDE or text editor if you don't already have one you like. The link in Step step 2 of the Windows guide has a tutorial for setting up in Eclipse if that is your preferred IDE.

Step 6: Try cloning a copy of the template from here and building it by navigating to the directory and typing 

...

If it compiles you did everything right (except perhaps the linter (check this by running make lint) if not you need to fix or add something. You should produce a file called main.elf.

Mac OSXOS X:

I don't own a Mac nor do any of the software core members. All the tools should, in theory, be OS X compatible so you can try building the same tools that those using the Linux guide do. Alternatively, you can follow the Windows instructions although you shouldn't have to fiddle with Path variables as much.following a different section of the guide in step 2. 

A more detailed guide is coming Soon^TM 

...

The package template contains five seven directories, a Makefile, a linter and a README. Use this for starting new projects only. Existing projects will have their own repositories which will share a copy of libraries, linker, and extra. 

...

As mentioned linting checks to ensure code meets our style guides. A custom version of cpplint.py is included in the package template it has been altered to support our styleguide. Calder Kitagawa is the maintainer so if you think there is a bug or style violation it is too pedantic/permissive reach out and ask. A Git hook will prevent you from pushing any code with errors so lint often you don't want to rewrite a whole file just because you messed up on style! The Git Hook in the hooks directory should be copied into .git/hooks directory so that you auto-lint when you submit code.

$ make lint
OR
$ python cpplint.py <file(s)>
OR
$ python2 cpplint.py <file(s)>

Running make lint executes cpplint on all files in src and inc. If you want to just lint specific files use python cpplint. Note the cpplint will accept wildcards in the file definitions.

...

Removes the .elf, .map and .bin files from the bin folder of the package

$ make reallyclean

...

Builds the OpenOCD binary (may be broken right now)