Electra One firmware sources

Developers
1

As promised, the Electra One firmware source code has been made available:

It comes with a few demo/tutorial applications. Please note, we are still in an early days of this. I might be still changing the API. If you wanted to make any serious work, please be in touch with me.

The source code covers Electra’s base firmware. ie. the Midi controller app that you have been using so far runs on top of that. I will provide the sources of that application a little bit later. I want to make sure that it runs smoothly on the latest base firmware.

A few remarks:

  1. Anybody who wanted to contribute is welcome.
  2. A new website dedicated to the Electra One app development will be launched. The documentation and app repository will be there.
  3. Even though this provides the C++ JUCE like API, the Lua interpreter is available in the firmware. I will be working on extending that part. My goal is to make it possible to create full-blown apps in Lua too.
  4. The base firmware has been extracted from the current Midi controller firmware and made somewhat more generic. It is a work in progress. There are still things that need cleaning up, improving, changing.
  5. The sources contains Doxygen comments. I will keep working on them in coming days so that full documentation is available soon.
  6. The build toolchain work perfectly on MacOS X. Windows and Linux still need some doing. It is possible to get it going though.

I would like to say thank you to @thetechnobear, @akira, @shankar, @joris.roling, @ziv for pushing me to go this direction, helping me, and providing tons of valuable input!

Any questions or suggestions. Let me know. Happy coding!

10 Likes
2

I have it compiling, yeah! :smiley:

build directory contains a firmware.elf and firmware.hex (no firmware.img though, like the docs suggest)

1 Like
3

check the .bin folder in the ./firmware. The hex2k66img tool should be there. If not you can build it. it is part of the sources.

running ./scripts/install-tools should do that.

4

The tool is there, but no firmware.img (even) after

make clean
make

I’ve sent you the make output via PM

5

run make upload, it will generate the binary firmware image and will transfer it to the controller.

martinpavlas:firmware (main)$ make upload
Electra firmware loader, v1.0
Programming mode entered
Waiting for Electra to appear
Uploading firmware: ..............................................................................
...............................................................................................................
.....................................................
Restarting Electra
martinpavlas:firmware (main)$
6

I got the image making working by making a make target like:

image: $(BUILDDIR)/$(TARGET).hex
	@$(HEX2IMAGE) $< $(basename $<).img

and then

make image
7

The make upload call gives me this:

Electra firmware loader, v1.0
Error opening HID Manager
Programming mode entered
Waiting for Electra to appear

Uploading the firmware.img using Electra One Console gives me a demo app, is this expected? (I was expecting the ctrlv2 app)

PS In the makefile I did change the CTRL_PORT to Electra Controller A Electra CTRL, as I’m running two Electra One’s :wink:

8

that is correct, the base firmware comes with the demo app.

I think this will be about the permissions to access the HID interface. New MacOS X systems block that by default. Will review that, I do belive that I had to grant permission to “access keyboard (HID)” in the past. Maybe @thetechnobear knows, he did that recently.

9

I will move .img creation to the default make rule.

2 Likes
10

Yes, I was asked to allow Input Monitoring for Terminal, I did allow that.

11

yup that was all that was required…

I think it tells you that you have to reboot for it to take effect.
but iirc, you just have to make sure the Terminal process is restarted. (not just closing windows/tabs)

generally if you see waiting for Electra to appear, the reason is its not in update mode.
usually because the sysex that is sent to force it into update mode has not work, either because the sendmidi didn’t work or because the E1 has ‘crashed’ so is not responding to it.
in either case, you can powercycle e1 with update button pressed and it’ll then load the firmware.

Ive not checked latest makefile - but you should not need to edit the makefile - usually you can just override it from the command line.

if this is not possible on that var at the moment, then we should make it so it is…

1 Like
12

congratulations!

Ive had family visiting, so not been playing with this since Superbooth, but Ive see how much work you have put into this over last couple of weeks - a tremendous effort !

my plan is this week to update the Orac firmware to reflect all these changes!
once that’s done and tested, then that can be released…
(it also be open source so provide another ‘example’ firmware app for devs to look over)

3 Likes
13

Ah, I stand corrected :smiley: Thnx for clearing that up to me.

14

I will make sure that the ctrlv2 works perfectly with the new base firmware. Once it is done, I will upload it to the GitHub too.

1 Like
15

make image has been added and it is also part of the make all. ie. the firmware.img file is created by default.

1 Like
16

started to look at new latest source to move over to it :slight_smile:

two quick observations for new devs (assuming on MacOS)

a) use homebrew

the easy way to get started is to use homebrew as a package manager, rather than installing the ARM tools directly, as this has everything you need.

you then want the arm embedded library

you will then need to compile with the COMPILERPATH set
e.g.

make COMPILERPATH="/opt/homebrew/bin"  (etc)

we could change MAKEFILE to perhaps look for these as an alternative source for compiler?

note: homebrew uses two different locations
/usr/local/homebrew is used for Intel
/opt/homebrew is used for Apple Silicon

b) you don’t need to link the application into the firmware directory.

I personally really dislike changing the contents of a repo Im using
(esp. since git will then report its as altered)

so rather than using symbolic links, APPPATH can be set to directory containing

so I use

make COMPILERPATH="/opt/homebrew/bin" APPPATH=../HelloWorldApp upload
2 Likes
17

Perfect, will add brew install to the README

I haven’t mentioned that one as the relative path ../ will cause the app directory to be copied outside the build. Therfore the repo will be affected too. I will fix it in the Makefile. The main goal is to be able to build a static library with a suite of header files. Then, the firmware repo would be needed only when one wanted to work on the base firmware itself.

18

I do like that don’t ‘depend’ on anything other than the embedded arm toolchain.
but yeah, I think most that aren’t doing other embedded work, will find homebrew fantastic :slight_smile:

APPPATH
yeah, i did have a look at that ‘issue’, but its not easy to fix with the way the makefile currently works.

can I suggest an alternative approach :slight_smile: (as its how I work , with other projects. )

expect the firmware to be contained in a subdirectory (I’ll get to why, in a moment)

so we have a project structure like
~/Projects/HelloWorld/HelloWorld/src
~/Projects/HelloWorld/external/firmware

basically I put any ‘external’ library/dependancies in a separate subdirectory to keep them separate.

why do i do it like this?
because git supports something called ‘submodules’ , these allow you to have a repo containing references to other repos.

so when we create our helloworld directory, we do

mkdir external
git submodule add https://github.com/electraone/firmware external

now when another dev wants to use our hello world app, all they need to do is

git clone  https://github.com/electraone/helloworld
cd helloworld
git submodule update --init --recursive

this clones the repo, and then retrieves all submodules defined

what’s cool about this approach, is the firmware is tagged to a particular version NOT to main (!) - so the build is ‘complete’ even if the firmware moves on.

(the dev can of course at anytime update the firmware submodule, and push it, so that HelloWorld now uses the latest firmware source)

submodule are very cool!

important note:
putting firmware in ./external/firmware does not obligate devs to use submodules,
they could of course do a symbolic link, or just copy the source code there if they like.

Id also suggest we ‘invert’ the makefile

so have the main makefile in HelloWorld/makefile , and perhaps then just ‘include’ external/firmware/Makefile … so use that firmware makefile for convenient macros etc.
(devs can then use the HelloWorld makefile as an example to get started)

all that said, I think you have now made firmware pretty much standalone…
if so, then i could look at creating an example that uses cmake, which as we discussed previously, I think will be much cleaner :slight_smile:

1 Like
19

Little late to the party, but I followed your path with using home-brew to install the gcc arm embedded stuff, but have issues on that the internet tells me, its a bug in gcc :frowning:

jk@MacBook-Air-von-Jens firmware % make COMPILERPATH=/opt/homebrew/bin
-e [CXX] src/App.cpp
In file included from /Applications/ARM/arm-none-eabi/include/c++/11.2.1/bits/specfun.h:46,
from /Applications/ARM/arm-none-eabi/include/c++/11.2.1/cmath:1935,
from /Applications/ARM/arm-none-eabi/include/c++/11.2.1/math.h:36,
from base/WProgram.h:6,
from base/Arduino.h:6,
from lib/ADC/ADC_Module.h:34,
from lib/ADC/ADC.h:45,
from src/Hardware/Pot.h:3,
from src/Hardware/Pots.h:4,
from src/Hardware/Hardware.h:4,
from src/App.h:3,
from src/App.cpp:1:
/Applications/ARM/arm-none-eabi/include/c++/11.2.1/limits:1673:7: internal compiler error: Illegal instruction: 4
1673 | min() _GLIBCXX_USE_NOEXCEPT { return FLT_MIN; }
| ^~~
Please submit a full bug report,
with preprocessed source if appropriate.
See https://bugs.linaro.org/ for instructions.
make: *** [build/src/App.o] Error 1

I am on a M1 Mac (as you are, it seems). Didn’t you had that issues? Or did you find a solution?

20

Installed the toolchain from the Website Martin links in the README and it worked