There are two ways in which you can set the device configurator for each project:
1.Remove the BSP_DESIGN_MODUS component from the application definition build system example: add the following to Makefile under Advanced Configuration section:
. This will enable you to use custom design.modus in your project.
2.Create a target folder for each board that your example supports.
3. In each target folder, copy the design.modus from the BSP for that target. Then customize design.modus as required for the application.
You can refer to the USB Audio Recorder project for example. You would notice that the code example contains COMPONENT_CUSTOM_DESIGN_MODUS folder for each of the supported target. The target folder in turn contains the design.modus file for that particular kit.
Open the Library Manager, under the BSP Tab, uncheck the shared box corresponding to the BSP you are using:
This will add the target folder for the KIT (which contains the design.modus for the kit) under the libs folder of the project.
Since libs folder is a part of the generated source this might prove to be a limitation in case you want to share your project with others.
1 of 1 people found this helpful
That's good information for me.
I checked the second method and found that there are some points to note, so I will report it.
If you do this after configuring the Device Configurator (shared), the configuration will start from the beginning (not inherit the shared one). In other words, you must first decide whether or not to share the Device Configurator.
However, if you want the previously created settings to reflect the Device Configurator settings, you can solve it by copying the design.modus file.
If you launch Device Configurator after performing the second method, it will launch with the contents of the shared design.modus (it will not start with the settings under the project). it needs to restart your MTB.
To MTB developers,
I have created and programmed some projects on MTB 2.2. Sharing the Device Configurator is very inconvenient. This sharing doesn't make sense for programmers, as they change the peripheral settings from project to project. I hope the default for this part to be per project.
I'm sorry that I am NOT a "MTB developer", as it is too difficult for me to use comfortably.
I'm slowly learning it, but I don't know if I can use it as naturally as PSoC Creator while my lips are still red.
Needless to say, if someone provides me the "schematic" editor like PSoC Creator for MTB, I will be a good boy ;-P
(May be I should ask it for the Xmas present)
Having written that at least having a private copy of PDL for each workspace(s) is an improvement over having only 1 for all the workspaces/projects.
I burnt myself many times when I was trying FM0+ with PDL2.x. Every time I configured a new pins to my project I was destroying my previous project(s).
Reading the situation (or symptom?), I would think that we should share a same hardware setup within a workspace.
This way sharing the same configuration between projects will not harm.
Meantime, we can have different hardware setups in each workspaces.
So IMHO, understanding or assigning reasonable roles to "workspace" and "project" sounds important to live happily with eclipse type tools.
Thank you for your valuable opinion.
Including this case, MTB can be said to be a better tool than PSoC Creator only when the functions of PSoC Creator (circuit input and function generation of components used by users) are added. I hope that MTB will support these functions as soon as possible in order to take advantage of the goodness of PSoC microprocessors.