Building Firmware

rudeog

Hi all, I've got the firmware building and have been doing some minor tweaking on my own. Here are some instructions for others that may want to get this going:

Overview: There are two pieces of firmware, one for the AVR chip and one
for the STM32 chip. There is a program that combines these into a
single file that can be uploaded to the unit. If you take the stock
sources, you will need to have Eclipse, Visual Studio, and Atmel AVR
studio installed, along with GNU ARM toolchain, and gnu make. I've made a
fork of the repos that reduces the requirement to Eclipse, and the AVR
and ARM toolchains. My plans for this fork are mainly to tinker with the
code and try different things out.


1. Install Eclipse Juno CDT (You could install a later version, but this is the version I have working)
2. Install the Eclipse GNU ARM plugin. Go into the help menu, Install new Software, add a site: http://gnuarmeclipse.sourceforge.net/updates. Then check the box to install that plugin.

3. Download and install the GCC ARM toolchain https://launchpad.net/gcc-arm-embedded/+download
4. Download and install gnu make: http://gnuwin32.sourceforge.net/packages/make.htm

5. Download and install Atmel AVR toolchain from http://www.atmel.com/tools/ATMELAVRTOOLCHAINFORWINDOWS.aspx (you don't need the headers package)

6. Ensure that the bin directory from 3, 4, and 5 are on the path. I
made a batch file that adds these 3 bin directories to my path and
launches eclipse.
7. Fetch the LXR sources from github. You can
either install git and do it the git way, or download a zip and unzip
it. The sonic potions git site is https://github.com/SonicPotions/LXR or you can fetch from my repos https://github.com/rudeog/LXR
(my repos has some fixes that might save some effort, and I plan to
keep it synced with the other, or hopefully get my fixes merged into the
other, see below)


If you got the repos from rudeog, follow with these steps:

8. In Eclipse, create a workspace in root folder of whole tree that you unzipped (or git'd).
9. Add two project dirs mainboard\firmware\DrumSynth_FPU
and front\AVR to the workspace. To do this, use
File/Import/General/Existing projects into workspace. Then select root
directory and browse to these dirs. Do this step once for each of these
two dirs. You will end up with two projects in your workspace.

10. These should build. Eclipse is a bit squirrely, so you might need to
do a make clean first to create the first makefiles, or rebuild
indexes.
11. I've built the firmwareimagebuilder.exe in the \tools\bin folder. I've also put a batch file that launches it and copies
the binaries from the respective output directories to create
FIRMWARE.BIN in that same dir. If you don't trust the .EXE I built, you
will need to build it from tools\FirmwareImageBuilder\FirmwareImageBuilder.
As is you will need visual studio. If you don't have it, you can try to
install the free version, mingw, etc and compile the one file
FirmwareImageBuilder.cpp (I've fixed it so it should build with any
tool) and make your own exe and copy it to that dir.

12. Thats it, after running the batch file you will have your firmware file.

If you got the sources from SonicPotions, you will need to install AVR Studio for the AVR project. You can download this from atmel.com.
It involves installing .net, and a few other things. At that point, you
will have the AVR project which you should be able to build. You will
need to recreate the Eclipse project for the mainboard (unless Julian
has added this project to his repos at some point). I won't get into how
to do this. You might want to grab 2 files from the rudeog repos which
are .cproject and .project in the DrumSynth_FPU folder and put them in
that location to save you some time. Then create an eclipse workspace
that has that project (see step 9 above but just do it for the
DrumSynth_FPU project). At this point you will need to build
FirmWareImageBuilder, and will need Visual Studio. Once built, Julian
has a bat file called makeFirmware.bat in the Debug dir which can be
run.

mokomo

Followed your steps and now have my LXR running on your build with no problems.

The code looks well-commented too which is great.

Wish I knew a lot more C and could get involved in experimenting!

If you come up with some interesting tweaks, could you post up how you did it? Would be very useful to help learning how to modify the code without knocking something over. 

rudeog

Glad it worked for you. The easiest type of customization to make would be to modify strings that are displayed. You could do this without any great in depth knowledge of the code, and your results would be visible. Also, you don't have to worry about permanent damage, as you can always go back and load the old firmware. Both of these CPU's have a flash endurance of 10000 erases/writes, so you could upload many firmwares before you had problems.
The most recent change I made was to change the note parameter to display actual note names (like C#) instead of a number. If you want to see how simple it was, look at this link. The green shows the additional code:
https://github.com/rudeog/LXR/commit/876255ba5f62f9929251b0d5d86176143f3da060

julian

great to see someone tackle the code
I'm currently in the middle of a big code mess due to a new feature.
When things are sorted out i'll try to include you additions.
thanks a lot for the fixes and the lengthy explanation!

borfo

Cool.  Thanks for this.

Is it safe to assume that pretty much all the button handling code for all buttons in all modes is in /front/avr/buttonhandler.c and .h?  Should I be looking anywhere else?

julian

the firmware image builder should be compilable with gcc.
It's been a while but I don't think there are special visual studio features used.
In the end it's just a little bit shuffling.

mokomo

Glad it worked for you. The easiest type of customization to make would be to modify strings that are displayed. You could do this without any great in depth knowledge of the code, and your results would be visible. Also, you don't have to worry about permanent damage, as you can always go back and load the old firmware. Both of these CPU's have a flash endurance of 10000 erases/writes, so you could upload many firmwares before you had problems.
The most recent change I made was to change the note parameter to display actual note names (like C#) instead of a number. If you want to see how simple it was, look at this link. The green shows the additional code:
https://github.com/rudeog/LXR/commit/876255ba5f62f9929251b0d5d86176143f3da060

Yes, I was trying to change the encoder-selected parameter to show as all capitals, or inverted black font/white bg, rather than just capitalize the first letter ( menu.c line 1022 seems to be the place to do it) but I'll have to figure out what the '32' value does (reference to the ascii table). 

It is going to be interesting to figure out how everything works...

Thanks for putting the instructions together.

julian

32 is the offset between upper and lower case in ASCII

mokomo

ah, thought it might be that.

So I can just do

editDisplayBuffer[0][(activeParameter%4)*4] -= 32;

editDisplayBuffer[1][(activeParameter%4)*4] -= 32;

editDisplayBuffer[2][(activeParameter%4)*4] -= 32;

To change all 3 characters?

rudeog

@borfo I think that is a safe assumption. Julian seems to have the code pretty logically separated.

@julian The firmware image builder has some minor changes to make it work with gcc (remove the stdafx.h and change the tchar and tmain stuff to char and main).

@mokomo I believe the second dimension controls the characters on the line and the first dimension is for which line (0 or 1), so you might try something like this (I haven't tried this):
                editDisplayBuffer[0][(activeParameter%4)*4] -= 32;
                editDisplayBuffer[0][((activeParameter%4)*4)+1] -= 32;
                editDisplayBuffer[0][((activeParameter%4)*4)+2] -= 32;

I think the inverted background color will be difficult (but not impossible) because the display unit itself is character based (that is to say you can only send characters, and you can't directly access pixels). I think the all uppercase letters is a good idea though, so I might try the above as well to see how it looks next time I burn a new one.

mokomo

inverted background might be difficult, involving creating custom characters on the LCD which might have a limitation in the number of characters available. 

maybe blinking text might be easier; set the text to alternate from blank (or 3 * ASCII code 219 = ███ )  to text every half second.

In the blinking case, it might be nicer to blink the value you are adjusting rather than the parameter text, if the blink is fast enough not to make the value less legible ...

borfo

Soooooo...  I'm guessing neither of you guys are linux/unix people?  I'm getting a bunch of errors building, so far all related to use of windows slashes "\" in paths...  Unix likes "/" - the first build errors I see are in AVR/Preset/presetManager.cc 

forward slashes and backslashes are all mixed up in here - Linux won't find the files with the backslashes (\).  Linux filenames/paths are also case sensitive - I haven't seen any errors yet due to case sensitivity, but I've only checked/fixed the first few.

##################################

#include "../config.h"

#include "PresetManager.h"

#include "../Hardware\SD/ff.h"

#include <stdio.h>

#include "../Menu/CcNr2Text.h"

#include "..\Menu\menu.h"

#include <util\delay.h>

#include "..\Hardware\lcd.h"

#include <avr/pgmspace.h>

#include "../frontPanelParser.h"

#include <stdlib.h>

#include <util/atomic.h> 

#include "../IO/uart.h"

#include "../IO/din.h"

#include "../IO/dout.h"

###############################

I fixed all the slashes in presetManager.c, and now it's showing backslash related errors in ../frontPanelParser.h - I imagine they're probably all through the code.  ...so, kind of stalled here.  Any thoughts on an easy fix?  Could we just search replace "\"s with "/"s? (or does anyone know a way to force the compiler to interpret \s as /s when compiling on linux?)

borfo

For the record, a translation of Rudeog's instructions for linux people (well, Ubuntu people anyway) Step 1-7 are:

Follow Rudeog's step 1 and 2.

install GCC ARM, avr toolchain, build essential

sudo apt-get install gcc-arm-linux-gnueabi gcc-avr avr-libc binutils-avr build-essential

It's possible you might need some other stuff I had already installed...

Follow Rudeog's step 7, 8, 9

When you try to build (step 10) you'll get a bunch of "no such file or directory" and related errors because of the backslash/forwardslash thing.

borfo

Ok, so I'm dumb - I just searched/replaced "\"s across the project and now I'm getting all kinds of "pragma takes a parenthesized string literal" errors...  I imagine I wiped out "some \"escape\" characters" or something. 

Only useful information I got out of that endeavour (other than that I am dumb) is that there is at least one case-sensitive filename error in the code /AVR/Menu/menu.c - I think "menuPages.h" was referred to as "MenuPages.h"

borfo

...so, digging a little further, I fixed a few spots where I replaced [\"] with [/"], and got rid of the pragma errors, but there are a lot of case sensitive filename issues - sometimes the .c file is named using a different case from the .h file - eg: /AVR/Hardware/SD/SD_routines.c and sd_routines.h

I'm going to stop here and see what you guys think should be done about this - if you want unix/linux or mac people to contribute to the code, this stuff probably has to be fixed, since the path issues will make it so the code won't compile on their machines...  Probably better to fix sooner than later, I guess.  I suppose that might be a good dumb job for me to do, but I'd need to know which branch of the code to work on at least, and what naming conventions you'd like to use.  I am not really familiar with how to push to github either, so one of you would have to deal with that if I do the path fixing.  It might be more trouble than it's worth to have me do this rather than one of you guys who know a little more about what you're doing.

It would pretty much just be the #includes and the filenames we'd have to look at, right?  do filenames and paths appear anywhere else?

rudeog

What really needs to happen is we need to either rename all the files (and directories) to be lowercase or fix all includes to reflect the case of the header files (the latter might be simpler). And we need to change all backslashes to forward slashes.
If you want to fork my repos and make the fixes (change slashes and case in the #include lines), and submit that as one commit, I will be happy to merge it into my repos.
Also, if you come up with a good full description of building on linux (I assume you are using ubuntu?) I'll be happy to add it to my description. Julian should be merging my stuff in soon, so we can eventually have an official repository which can compile on all platforms. Another user is trying to get it going on mac as well.

borfo

Yeah, I think filenames and directories should change and follow a naming convention, rather than just fixing the includes - it's bound to be confusing to have stuff like /AVR/Hardware/SD/SD_routines.c and sd_routines.h

...all lower case would probably be the easiest thing to do actually - that way I can just change all #include text to lowercase instead of having to retype it manually, and I can run a script to rename files and directories.

I'll put together build instructions once I can build it...  haha.  I saw the mac thread - I'm sure that guy's having trouble because of the file path issues.

I'll pull a fresh copy from your repo and give it a shot.

borfo

Actually, there aren't all that many filenames that are messed up.  I'll rename them manually.  They don't all have to be lowercase, just the .c and .h files should be consistent.

niklasni1

I don't want to use Eclipse, so I'm writing a makefile. I had some issues with SlopeEg2.c and .h being referred to as SlopeEG2..

borfo

This may be a bigger project than expected...  I might be a bit out of my depth.  I've cleaned up most of the \ /s and filenames, but now I'm getting a bunch of other path errors.  There are all the .mk files, which all have a shitload of bad file names and slashes, but they say they're automatically generated, and I don't know what controls their generation, and what files to look in to fix the paths there, and there are includes in quotes (like #include "string.h"  or "math.h") that look to me like they should be in <> (ie: #include <string.h>)...  but I don't really know C all that well, so I really have no idea.

Might be best if someone who understands the code and C a bit better than I do did this code cleanup - I'm afraid I might be breaking the code at this point.

rudeog

Well, you have to break stuff before you can understand it and fix it :-)
The mk files are automatically generated by eclipse, so probably best to not modify them. Once you get the eclipse build settings sorted out, it's all easy street. Eclipse is cool too because it speeds up the workflow with coding, compiling and checking errors etc. Although it might be good to have a pure makefile build to lower the barrier for people to get it compiling (less to install and configure). I think it should be able to sit alongside the eclipse stuff with no problem. We are not maintaining a file list in eclipse (and actually the files are all pretty much the same files now as when I started looking at this). That means it should be pretty easy to maintain a makefile as well as the eclipse workspace.

borfo

I'm all for breaking stuff and fixing it, but it's a big codebase for an inexperienced person to be running though and making semi-arbitrary changes to...  It won't be particularly well-spent time for any of us if I can't hand you guys back a working version of the code.  ...and given that the code won't compile on Linux to begin with, it will be tough for me to know whether a build failure is a code problem, a toolchain problem, or just a me-being-inexperienced-with-eclipse-or-c problem.  It'd be easier if I could start knowing my toolchain was good.

A makefile version would be more flexible for linux people, I think, but eclipse also works fine on linux.  The forward slash and case sensitivity path stuff is a pretty solid barrier to linux and mac people getting involved though. 

niklasni1

Got it to build with my makefile (on Linux). Had to add a bunch of includes in places. Don't think it runs yet, need to include the hardfault.S file somehow (just pass it to GCC, maybe?) and ld says:

/usr/lib/gcc/arm-none-eabi/4.8.1/../../../../arm-none-eabi/bin/ld: warning: cannot find entry symbol Reset_Handler; defaulting to 0000000008004000

So I might be missing a definition or include somewhere.

There's also a couple of megagrams of errors about unused parameters, 'volatile's begin discarded and such, but I assume that's not related to the makefile

borfo

I got as far as cleaning up the filenames and the slashes and case insensitivity in the includes, but then got boatloads of errors that seemed in part to be missing core includes.  I started adding and changing includes to deal with that, and that was when I gave up, thinking that there's no point in plugging away at that given that I had no idea whether it would eventually result in working code or not. 

rudeog

The .S files need to be compiled with the assembler (arm-none-eabi-as). The Reset_Handler symbol is in one of the .S files so once you have that going it should link.

niklasni1

Yeah, have it built now.

There's some troubles cos I'm running it on different hardware, though. But I think I can fix those.

julian

Sorry, I've been ill and spend the last few days in bed instead of in front of the computer

/usr/lib/gcc/arm-none-eabi/4.8.1/../../../../arm-none-eabi/bin/ld: warning: cannot find entry symbol Reset_Handler; defaulting to 0000000008004000

The reset handler is defined in the .S assembler file startup_stm32f4xx.S

niklasni1

Hm.. so I have the code running on my Discovery board now, patched the codec related files with ST's sample code, so I think it's should be running... connecting with GDB it looks like the main loop is running. It shows up as a MIDI device. In the completely bare, just-booted state, should I be able to hear noises when I send it notes? Which channel?

niklasni1

(I want to build my own hardware with some extra features, that's why I don't have one of the real mainboards. Just want a known-good starting point first)

dlyline

do you have some patches on a sdcard? you could use the pc editor to make some too, its hidden somewhere in the forum. hope it works i have a discovery board that isn't being used so if you want to send me the necessary files i'll have a go..

tb323

Just built the firmware from rudeog's repository on Arch Linux with Eclipse after a bit of confusion regarding toolchains. Fixed backslashes and some upper/lower-case errors. 

I put a repository here in case anyone running linux wants to try it: https://github.com/tb323/LXR