Support projects generated with CMake, at least when debugging.

[s13n]

The requirement to generate the project with the GNU MCU Eclipse plug-ins in order to assign a device is too limiting. There are various good reasons why one may want to use a different way of generating the project files, of which CMake is a very prominent one. When debugging such projects, it would be desirable to have at least the peripheral view available.

It would be useful to set the device in the debug configuration rather than the project settings, since debug configurations are not overwritten when the project is regenerated. I would propose to have an option in the debug configuration dialog, that allows me to specify the device there, instead of inheriting the information from the project. It would be acceptable to enter the path to the device file that shall be used, although a nicer way of selecting the device would be preferable.

[ilg-ul]

I'm already in the design phase with another mechanism to create projects (https://xpack.github.io), and the plan is to use the the information in the project, if available, else resort to information stored in the debug configuration, ultimately to a single path to the SVD file.

just that it'll take some time...

[ilg-ul]

btw, GNU MCU Eclipse is all about managed build projects, for keeping the Eclipse indexer in sync with the actual compile options.

how do you achieve this when using CMake?

[s13n]

I don't understand the full details of this process, but the most important part of it is the preprocessor definitions. They are being autodiscovered by eclipse by calling the compiler with a special set of switches. The result is fed into the indexer, which seems to work reasonably well, and captures both the macros predefined by the toolset, and those supplied on the command line by the build tool.

The CMake eclipse generator can't yet generate projects with multiple configurations. You effectively have to generate multiple different out-of-source builds for what you would normally use different configurations (Debug or Release...). I consider this a major drawback of the current CMake eclipse generator. The generator for Microsoft Visual Studio does not have that limitation.

I still experiment with CMake and the various ways how you can set up projects, targets, etc. to see what the consequences are for the resulting eclipse project. The fact, however, that you configure a project programmatically through the CMakeLists.txt files as opposed to clicking your way through complicated properties dialogs is a big adavntage IMHO.

Furthermore, the combination of eclipse and ninja is very effective in figuring out exactly what files need to be rebuilt. The eclipse makefile generator ends up recompiling the entire project much too often for my taste. If you have a larger project with a lot of C++, a full rebuild takes considerable time.

You can also generate for ninja alone, which makes for a very effective build server. That's much more elegant than having to install eclipse just to use it from the command line.

[chrta]

btw, GNU MCU Eclipse is all about managed build projects, for keeping the Eclipse indexer in sync with the actual compile options. how do you achieve this when using CMake?

Eclipse CDT parses the compiler calls and discovers the options from there. cmake already configures the indexer so that this works out of the box.

[ilg-ul]

I would propose to have an option in the debug configuration dialog,

done, please check the latest version, 4.3.1.

you can associate any SVD file to a debug configuration.

I did not test this for a project-less configuration, so any feedback will be appreciated.

[chrta]

FYI: With the current CDT 9.4.0. there is an issue with cmake generated projects, this is fixed in CDT 9.4.1: https://bugs.eclipse.org/bugs/show_bug.cgi?id=529121

-> The release "GNU MCU Eclipse plug-ins v4.3.1-201801092051" does not work (calling make does not work) for projects generated from cmake.

[s13n]

I had to wait for CDT 9.4.2 to be able to build again with the new MCU plugin, but now I can report that the SVD tab and the register display is working as expected. Thanks for this work!

There's a related question (not sure if it warrants a separate issue): I notice that the NVIC, and a couple of other CPU-related register sets, are missing from the register display. They are not part of the SVD file, but since the SVD file lists the CPU type used, it would be possible, I reckon, to include the CPU-specific registers in the peripheral list as if they were peripherals.

Is this something that can be added easily, or do you have a different idea how to support this?

[s13n]

To correct my last message:

Actually, since the NVIC and other CPU-specific peripherals are attached to the CPU, it might be better to list them in the Registers view instead of the Peripherals view. Currently, there's only the "General Registers" entry in the Registers view for ARM Cortex M CPUs. I would find it best to have more entries for the CPU-specific periperals like the NVIC there.

The advantage would be apparent in multi-CPU chips, where each CPU has its own NVIC, and can't see the NVICs of the other CPUs. See the LPC43xx series for an example.

I have no idea if and how the Registers view can be extended, however.

[ilg-ul]

the names of the registers in the General Registers is not under Eclipse control, the list is passed via an XML by GDB.

[s13n]

Hmm, so what would you propose? The CPU peripherals are definitely interesting enough to warrant having them shown in a more user-friendly way than with the memory browser. Would this have to be requested from the gdb folks?

[ilg-ul]

I doubt this will change any time soon. GDB itself has a limited knowledge on the device, it gets the actual definitions from the GDB server, J-Link/OpenOCD/QEMU in our case. I doubt you'll be able to convince all those who maintain them to change the list of General Registers.

Please mind the name: 'General Registers'. By definition this does not include device peripherals.

[s13n]

I wasn't trying to propose to include the CPU peripherals with the General Registers themselves.

Note that within the Registers view, the "General Registers" are just one (currently the only) group, which needs to be opened by clicking on the > symbol at the left margin. What I would like to propose is to add the CPU peripherals as further groups (one per peripheral) in the Register view, but outside the General Registers Group.

I assumed that something like this is what the eclipse developers wanted to enable, otherwise there would be no reason to have this grouping mechanism in the first place.

Whether this makes it easier in practice, is something I do not know.

[ilg-ul]

add the CPU peripherals as further groups

aha. I did not check the sources, but as far as I know the group name "General Registers" and the list of register names come from the GDB, which get them from the GDB server.

GDB knows the notion of register groups, but the MI protocol used to talk to the GDB server does not.

in theory it might be possible to reimplement completely the Registers tab, and include some of the peripherals, but that would not be easy.

[s13n]

There shouldn't be a need for expanding the MI protocol for this, as the registers have memory addresses. I was basically hoping that a plugin would be able to add groups to the Registers tab dynamically, with no need to reimplement it, and somehow implement their behavior outside. But that's probably me being naive, as I'm completely unfamiliar with the eclipse code (I have no experience in Java coding, either).

Of course, if GDB and MI supported groups properly, it would be possible to have integer and floating point registers in different groups, but that would be icing on the cake.

Anyway, you get the idea. If the Registers tab is too difficult, adding the CPU peripherals to the Periperals tab would also be an option, but the problem here is that depending on the type of CPU core being debugged, it would need to change. Hence the LPC43xx example, which has CPUs of different type, and hence different CPU peripherals. The "normal" peripherals are the same across all CPUs.

[ilg-ul]

adding the CPU peripherals to the Periperals tab would also be an option

yes, that would be the natural option. unfortunately ARM and the MCU vendors did not agree on the details. the content of the Peripherals tab comes from the MCU vendor SVD files. ARM specs were not clear enough, some vendors add system registers to the SVD file, others do not.

I asked ARM to provide a 'common' SVD file with the system registers, but did not get very far.

[s13n]

If you had such a common SVD file, how would you use it? It is not too hard to make an SVD file for the cores that ARM offers. Their number is much smaller than the number of MCUs made with them.

[ilg-ul]

probably I would patch the plug-in to allow a second SVD, and manually add the path to this SVD.

recently I added a new tab to the debug configuration, probably there we can add a new selection for the second SVD.

[s13n]

I use that new tab already. Adding a second SVD there would be simple, I'm sure. A slightly more comfortable solution would be to select the second SVD automatically depending on the CPU information contained in the first.

But maybe it is best to first provide something simple, and polish it later.

[s13n]

By the way, in case you didn't notice: There are SVD files for the ARM cores in ARM's CMSIS distribution (i.e. the ARM CMSIS pack). They are a bit rudimentary; the NVIC is missing for some reason. It seems ARM and their customers can't agree on what belongs where.

[ilg-ul]

It seems ARM and their customers can't agree on what belongs where.

exactly!

on the other hand it should be noted that NVIC has not really a common definition, it is implementation specific (the number of bits in the priority, the number of interrupts, etc).

[s13n]

You're right. The chip's SVD contains information that specifies the missing information for the CPU peripherals that should be in the CPU's SVD. So in a way they ought to work together. But it needs some intelligence in the tools; merely merging the SVD files for CPU and chip won't be sufficient.

This SVD stuff looks to me more and more like a good idea that wasn't thought through properly.

I'm also trying the header file generators that generate C headers from the SVD file. The headers generated by the Keil tool are appalling. I guess I will end up doing my own generator...

[ilg-ul]

header file generators that generate C headers from the SVD file

for inspiration you can take a look at https://github.com/xpack/xsvd-js.

[s13n]

Cool. Hadn't seen XSVD before, I just tried my luck with it, and have difficulties. See my bug report over there.

[ilg-ul]

the link was provided for inspiration, in case you want to write your own generator; the main trick is to use templates.