Multiple Targets, Part 2

[thestumbler]

My earlier question about multiple targets focused on phony targets to control the target (adding erase, reset, etc.). I have a partial flash.mk that I just append to the LBUILD-generated make file for that.

Now I about multiple real targets. I have a small test "hello world" application that I'm using to test my boot loader. For standalone testing I build for the usual H7 start address of 0x800,0000. For use with the boot loader I build it with start address of 0x802,0000 (the address of sector 1 (the second sector).

In my previous experience this something all the the IDEs and Makefiles handle. I'm not entirely clear if / how to do this the natural way with MODM. I've been doing the following:

(1) Comment out or not the flash offset option of 0x2,0000 in project.xml depending on the desired target.

(2) Do a complete clean of everything. Then re-LBUILD and MAKE / SCONS the project.

(3) Manually generate an Intel Hex and binary file using ARM-NONE-EABI-OBJCOPY using a shell script. I see this is going to branch out to setting up to four different subdirectories: release / debug for both scons and make. I'm doing this because the program option in the make/scons files doesn't appear to program these offset files correctly. So I'm using the generated HEX file to program the app with another tool.

It seems like I'm missing something basic. I've searched the issues and discussions about multiple targets and these mostly focus on the phony kinds of targets.

Side question -- it's probably a matter of style, but I usually do not make separate subfolders based on the build system used. In the few odd cases where I've had multiple build systems, I just made two build folders at the project's root level, like build-gcc and build-Keil. Also why is there an extra (unneeded?) directory immediately under build? Like this HELLO project has modm-test/hello/build/hello/.... Are there circumstances where there would be multiple directories at this level in the tree? Somewhat related I've also usually split up the object files, listing files, etc in a separate folder and only have the top level files on the "main" build directory, all the hello.* files in this example. A trivial thing but cuts down on the visual clutter.

Is this a trivial thing to do in LBUILD or not.

[salkinium]

It seems like I'm missing something basic. I've searched the issues and discussions about multiple targets and these mostly focus on the phony kinds of targets.

You would have two independent projects, one for the bootloader without the flash offset and one for the application with the flash offset.

I usually do not make separate subfolders based on the build system used.

We need to otherwise the build systems overwrite each others intermediary build artifacts leading to inscrutable build failures (we've had such bug reports before). It just reduces the maintenance burden when devs or ourselves use two build systems in the same project (accidentally or for testing).

Also why is there an extra (unneeded?) directory immediately under build?

Probably not intentional, likely just the path of least resistance to redirect the build path for a build system. For example, SCons copies the folder structure because it builds the files in-place by default. But we redirect only the top-level build path, thus the replication. I don't usually need to look into the build subfolders, only the top-level build and yeah it's a little annoying.

Is this a trivial thing to do in LBUILD or not.

lbuild is just a modular code generator, it has no understanding of anything else. The modm:build module and submodules control all the build system configuration.
For example the modm:build:build.path is converted into a Makefile path here. Maybe a duplicate directory can be cut from there?

[thestumbler]

I think that's all I need to know at this point. I have a very basic grasp of LBUILD, enough to get my work done. I am now at peace with that situation, and realize that down the road it seems that I can dig deeper into this and tweak things as needed.

[thestumbler]

Okay it is time to revisit this. It's getting to be a pain, and now I'm paranoid that I'll accidentally brick a board again by mistakenly flashing the wrong image (the LDO / SMPS differences between the H723 and H735).

I've discovered discussions about this and similar topics like choosing which SWD debugger to use, and it looks like much of those features have been implemented. I see several discussions about multiple targets with different approaches regarding project directory and Makefile / Scons management. If that specific issue has been "solved", it's not clear to me.

**What is the best advice now in 2023 for handling multiple targets, and are there any examples I can see? **

On one thread, the developer was trying to build for both the PC and an embedded target, an understandably complicated situation that clearly warranted using different main.cpp files and perhaps a separate library containing the common code. But my case is more narrowly focused. I'm only trying to target (1) two different boards (Nucleo H723 and custom H735), and (2) different program start base addresses (0x800,0000 or 0x802,0000).

Right now I'm just manually editing the project.xml file by commenting / uncommenting the key entries when I need to switch, and hope that I don't forget.

Lest you wonder why I'm doing that, it's because the custom board is a headache to work with because of its small size and that it has laser diodes which can be a safety hazard. It's much easier to do main development on the Nucleo board.

Random thoughts and comments.

I know I said only two targets variables, but it's looking like a third one could be needed for me: Windows vs Linux/Mac. You said before that you keep the object and listing files from Make and Scons in separate build folders because you don't want them to mix. I also think you probably wouldn't want the objects to mix from different platforms. In my mind, I'm seeing this too-deep-for-my-liking build directory tree:

build
- [target1|target2|target3...]
  - [windows|macos|linux]
    - scons-release
    - scons-debug
    - makefile-release
    - makefile-debug

I've found myself doing the following...

I build, program, and debug using SCONS. For other pseudo targets, I use the Makefile. Anytime I wipe out the Makefile by LBUILD, I modify it as follows:

$ cat Flash-stlink.mk >> Makefile
$ cat Flash-usart.mk >> Makefile 

This gives me commands things like make serase or make ureset Some of this duplicates the available SCONS pseudo targets, but some things like ERASE aren't available, nor are commands via the USART boot loader, something essential for my project because it is a USART boot loader.

Another idea I've had, lacking a better grasp of the LBUILD process, is to manage the project.xml file differences and build file locations using the M4 preprocessor. That at least would eliminate errors when manually editing the file.

Final last-minute thought, I do have a Discovery H735 board, which is a beast. It is so big that I immediately set it aside and ordered the Nucleo instead. Maybe I'll try that board and see how it works.

[salkinium]

What is the best advice now in 2023 for handling multiple targets

You would use one project.xml per target. You can use the <extends> flag to inherit from a shared lbuild.xml file and overwrited/add the differences. The modm/example/lbuild.xml does it that way.
If you have shared code, you need to put it in a folder and include it via a modified SConstruct for every target.

I also think you probably wouldn't want the objects to mix from different platforms.

Are you synchronizing your build folder across Windows and Unix?

Anytime I wipe out the Makefile by LBUILD, I modify it as follows:

Add it to your fork of modm, then it won't get wiped. Adapt the fork with your customizations, then it'll be easier later to upstream the useful bits that stood the test of time.

to manage the project.xml file differences and build file locations using the M4 preprocessor.

No? Use project.xml that inherit from a common config to encode differences. That's the clean method. You can inherit from multiple configs btw, they get overwritten in the order of inclusion.

[thestumbler]

I also think you probably wouldn't want the objects to mix from different platforms.
Are you synchronizing your build folder across Windows and Unix?

Not normally, since I have build and modm in the 'gitignore file. It's my usual practice not to include build products like intermediate object files, libraries, and the end result executable files in the repository. I'm not certain yet how I feel about excluding the generated modm, which is source code and not OS/processor-specific binary files, but for now it's not an issue.

But there are two cases when this can happen, in my experience, one of which I've been avoiding entirely lately. On my MacBook, I have virtual machines for Windows and Linux. All machines, virtual or not, use the same /file/... directory tree which I've been using for many years for user and project files. If I jump back and forth between Windows and MacOS, it is possible things could mix. Fortunately I don't do that intentionally, and if there a reason to switch I will do a deep clean before building. Even this is not common, I try to do any Windows work on a separate, real Windows computer when I can.

The second situation this can arise if you use a mirrored drive setup with a central file server, like a NAS. For example, the Synology tools have this feature. I used to use this quite a bit, but it became a nightmare for other unrelated reasons -- mostly keeping it from synching things it shouldn't. GIT repositories come to mind, but also build directories as well.

But there's another reason one might want to keep directories for different platforms in the build tree, and that is for generating the each platform's target files. But for the MODM project, those targets are all identical since this is a cross compiler. We're not making any executables, libraries, or shell scripts -- I think the final output (binary / ELF) should be identical no matter which IS built it.

[thestumbler]

I think you've provided enough information to help me sort it out. Thanks.

[thestumbler]

I want to report some success in configuring a multiple target project. My project layout is as follows:

project
  .vscode
  project.code_workspace
  linkerscript.ld
  lbuild.xml
  src
  ext
    modm
  h723
    SConstruct
    Makefile
    project.xml
    modm
  h735
    SConstruct 
    Makefile
    project.xml
    modm
  build
    h723
      release
      debug
    h735
      release
      debug

For now, I have manually tailored the Make and Scons files for each flavor and set it not to overwrite them, as suggested above. In the future, I think I can eventually coax LBUILD (maybe with post processing) to generate than for me.

Of note here is the VSCode folder, which was a real struggle to get right. Not only am I a novice at VSCode, but the multiple target, embedded systems paradigm is outside the normal VSCode use-case. I used the MODM-generated .vscode as a starting point, but because of the multiple targets my files are almost completely unrecognizable now.

When I started doing this, I saw a lot of almost-identical json files in the main project and its subfolders. That bothered me, so I figured out how to make them the same, by using the INPUTS feature which lets you set custom variables in each configuration and consume them in your tasks and launch json files.

This now gave me multiple sets of identical files. I remembered reading that these settings files inherit from their parent, so I gave that a shot. Cut it down to just one set of json files in the root. After a lot of troubleshooting, I had it working.

With this setup, you click on the frameworks button in the lower right of the screen, and can select your target -- in this project either of the four combinations h723/h735 + debug/release. In the VSCode, there are now only one set of tasks such as build, clean, etc. Those tasks operate on the currently selected "framework", as does the debug launcher.

This concept extends to different load addresses, to. The release / debug folders shown above should really be [scons|makefile]-[debug|release]

I haven't tried the makefile yet but it should work if added, as it works from the command line.

I also need to double-check this on Windows, but I'm not expecting too much of an issue. A colleague fired it up Friday on Windows and we were expecting some hiccups, but it seemed to work well (it was in a partially competed state however).

I'm behind schedule and swamped with real project work -- sorting out these VSCode issues was necessary but a huge pain. Once I wrap up the project code, I'll try to document this better and if I can sort it out, submit a documentation PR to explain this better.

[thestumbler]

Why do I care about this? I'm not an everyday GDB user, so having a GUI-based debugger is very helpful. For my younger colleagues, it's almost a showstopper not to have one. IMHO, even a seasoned CLI debugger veteran can benefit from a GUI because of the comprehensive visual picture it gives you while solving a problem.

One of my goals is to introduce a non-Keil workflow to my clients, and any candidate must have a suitably featured GUI-based IDE.

A lot of people are already familiar with Visual Studio, so making the leap to VSCode isn't a big step.

A pleasant side benefit for an old gray-haired CLI-loving engineer with decades of hard-to-overcome VI keys muscle memory is that an extension can bring the VIM experience to VScode.

For me, realistically I'm mostly going to use this for the debugger. Mostly I'll stick with the CLI for the basic editing, building and uploading operations. But getting VSCode integration as a necessary part of my MODM experiment, and I'm glad I (finally) succeeded.