Development Environment

Hi all,

I was wondering what everyone (especially Olivier) is using as a code editor and other tools for development. I’ve seen there is a great suite of plugins for Eclipse (gnuarmeclipse.github.io). However, the github.com/pinchettes/eurorack repository is very clean project-wise and looks like it was created with a simple editor and separate command-line building (make) and possibly separate debugging tools?

((This topic is not so much Shruthi related, but it does fall in the Firmware development / hacking category. Couldn’t find a better fit…))

I’ve been using vim (later alternating with Textmate), and command line tools for the past 15 years.

Command line and TextWrangler and/or Vim. I admit to using the GitHub Desktop GUI sometimes, but no IDE for MI stuff. I’m collaborating on another project that uses the Teensy, and for that, the Arduino IDE is required, but it is pretty horrible as an IDE, and the plan is to avoid it for future projects.

I do use the excellent RStudio IDE for writing R code at work, but that is nothing to do with module hacking.

I like atom. There’s a lot of debate about it but its fast enough for my needs.

@Bennelong

I’m using Atom with PlatformIO for my teensy programming. It works nicely for my needs, and has a good import function for arduino sketch folders.

I can vouch for Atom- it’s a great application!

a|x

Cool, an “editor war” thread :wink:
I’ve used Emacs for as long as I can remember. Everything happens within it: coding, compiling, debugging (interfaces well with gdb), running tests and computing stats (there is an integrated shell and elisp, the PL is stands on is decent), writing memos and whitepapers (org mode)… I’d really recommend the yournger devs to invest the 1-2 years it takes to get familiar with it, it’s an asset for life :slight_smile:

I wish i had taken some basic programming classes when I was younger, and not gone through the Arduino/Processing way. It’s seems counter productive to NOT learn how to properly compile your code, and there are so many bad habits.

@mqtthiqs haha, let’s hope we don’t make any casualties :wink:

Thanks everyone for the answers! It’s nice to have a bit of insight…

I’ve used a lot of different setups. A long time ago I did a bit of C with Microchip’s IDE. I’ve also used Eclipse for both PHP and Java. Since a 2010 I mostly write Go (golang.org). First with Sublime Text, and now with Atom (atom.io). Building and most other stuff is executed directly in a terminal (urxvt+zsh to be precise).

A bit more back on-topic: ARM programming.
I’ve followed the Getting Started tutorials of gnuarmeclipse.github.io. The plugins look really nice and seems to take care of a lot of stuff, but therefore also hides a lot of what’s happening under the hood. Initially I thought that would be necessary to be useful/efficient for coders, but when I looked at Olivier’s stmlib makefile.inc I found the whole process is actually quite simple. So for now I think I’ll stick with atom and command-line. For sure I’ll learn more that way.

Another question for Olivier and everyone: what tool do you use for debugging? If it’s not in the IDE, do you still manage to walk through paused code easily?

First of all, keep in mind that the core functionality of the module is always in a C++ class that can be compiled and used on your desktop computer. For each module, there’s a /test directory, which contains a “test bench” program allowing you to do experiments with inputs/outputs in .wav files or constants specified in the code. 90% of the development time is spent in this environment.

But even with that, for the kind of code I write, walking through the program step by step or monitoring variables is of little value - good luck describing a watch condition for an audio glitch… My favourite debugging tool is the “audio printf” - generating multichannel .wav files with intermediary results at various stages of the DSP algorithm.

What’s left is the code specific to the actual hardware - which is either tricky hardware peripheral initialization, or super dumb LED/button management which would be hard to get wrong. Again, walking through code is of little value for the code of the first kind - the bugs I make are typically reading/writing to the wrong pin, forgetting to power on a GPIO clock or to remap a pin’s alternate function mux, sometimes reading an ADC too fast… this kind of subtleties.

The makefile has commands for gdb sessions through openocd - you can type make -f project/makefile debug_server ; and make -f project/makefile debug_client in another terminal to start a gdb session. I use this only a couple of times a year.

1 Like

> My favourite debugging tool is the “audio printf”

What I still find lacking as an intermediate between this method and loading on the hardware is a way to interact with the code: feeding live audio in, or turning (virtual) knobs. It would interface with the audio interface and UI and, why not, with a MIDI controller. Developing such a tool has tickled me for a while, I might start soon…

> I use this only a couple of times a year.

Hmm, that’s interesting! So do you repeatedly run “make upload_combo_jtag”? I basically run everything from inside GDB: you can upload the code directly to RAM without writing to flash, which is faster than wiping then writing bootloader+fw, and saves a few wipe cycles (just in case). And then when you encounter a bug, just hit C-c and you’re paused and ready to debug. The only thing I miss from GDB is a way to print repeated values of a variables (say, every ms), without pausing. Watchpoints are not ideal in this context.

> So do you repeatedly run “make upload_combo_jtag”?

Yes.

> upload the code directly to RAM

For which module is there enough available RAM to have the entire firmware stored there?