Cooperation with an external editor and debugger (e.g. Platformio)
Quote from kordik on September 5, 2024, 12:54 pmYes, I use Simulide 1.1.0 R1912 (installed from Debian repositories). By the way, moving and renaming hex/elf file can be probably done using the python script, which is in the top directory ("extra_script.py"). The script can be configured to run post-compiled actions. In my case it creates the .lst file, I hope that the renaming can be done similarly.
Yes, that seems a good idea.
But you probably don't need to move the files if you use buildPath="../.pio/build/nanoatmega328"
You can also run commands from simulide before debug start.
Instead of:
<step
command="avr-gcc"
arguments=" -v"
/>You can rename, move files or whatever.
Or call an script specific for debugging in Simulide.
You can add several steps if you want, have a look at simulide/data/codeeditor/compilers/compilers/avrgcc.xml.
More info about compiler.xml here (scrolling down a bit):
https://simulide.com/p/compiler/#compiling
I used following settings in the xml file:
<compiler name="Avrgcc-2" type="avrgcc" buildPath="../.pio/build/nanoatmega328/" >
<step
command="avr-gcc"
arguments=" -v"
/>
<step
command="echo"
arguments=" Copying hex and elf files..."
/>
<step
command="cp"
arguments=" $buildPathfirmware.elf $buildPath$fileName.elf"
/>
<step
command="cp"
arguments=" $buildPathfirmware.hex $buildPath$fileName.hex"
/>
</compiler>
and the debugging works.
Great!
Note that the first "step" is not needed if you add other steps.
That one is a "dummy" step, because 1.1.0 will not start Debugger if there is no command to execute.
In Development version it will work with no steps at all.
Also I forgot to mention that you don't need to generate .lst file in this case (you commented something about the python script doing it).
Simulide has support for avr-gcc and will use the elf file.
I think you already realized, but could be useful for others reading this.
Yes, I noticed that the lst file is not necessary, so the pio project can be without the post-compile python script. The only requirement is to compile the project in a debug mode.
I am looking forward to the new version of Simulide.
Best regards, J. Kordik
Let someone with 25 years of embedded development, contributions to FreeRTOS, ArduinoFreeRTOS, JUnit, Android, etc. drop in their 2 cents.
I understand that the most of your user base is hobby developers who don't really need interoperability like GDB because they don't even use CLion of VS Code. Layered architecture, modularity, unit testing, CI builds, Git - for them all this stuff is a far cry barely making sense; they would be perfectly fine with a simple integrated debugger. But with all due respect, hobbyists will never push your product forward. It's the small fraction of professionals who happen to enjoy the open source who is moving things.
Atmel's MCUs (yes, I'm that old to still call it Atmel) is a very solid and time-proven choice for industrial designs even in 2026. SimulIDE would be a great tool in the toolbox if it was able to properly integrate into the "big" development process.
I use Proteus for circuit design and in-circuit simulation. But Proteus is a heavy thing, not very suitable for routine debugging; I use it only for a final stage verification, when the coding is 95% done. A lightweight tool capable of simulating and debugging inside a simplified circuit would be an invaluable addition to the toolbox. It would streamline the firmware development process a lot.
Refusing this need will effectively lock SimulIDE to the hobby segment, depriving it all opportunities to grow and realise its potential, and eventually die out - which would be pity!