Is there a documented/preferred way to take a project made in Modus 3.0 and "export" it so developers can build it with just arm-gcc, i.e. not require the user to have the full Modus toolchain installed!?
Related question. Let's say you want to keep the board-specific configuration in modus, but re-export the BSP in case you change some pin-config or add/remove a peripheral. What is the best workflow to only update those files!? (rather than re-generating everything making git tracking / history a bit challenging)
I am not sure this addresses your 1st question, but in general, you need Make to build a ModusToolbox application. You can "export" that application to various supported IDEs. Take a look at chapter 7 here: https://www.infineon.com/dgdl/Infineon-ModusToolbox_3.0_Tools_Package_User_Guide-GettingStarted-v13_...
For the BSP question, you can use the BSP Assistant to export a BSP as a ZIP file to store that configuration somewhere as a backup. Then, because the BSP is now owned by the application in 3.0, you can make direct changes to the BSP/application using configurators and the Library Manager without the need for a custom BSP. There is no re-generating of BSPs in 3.0, because they are no longer git repos.
If you later want your original BSP configuration back, extract the backed-up ZIP file to the "bsps" folder in your application with some name. Then, add that BSP using the Library Manager and make it the active BSP.
I would like to store the bsp as part of the project repository, mainly so that you can build without having the modus toolkit installed on the host machine
i.e. this, where most is temp-files but perhaps there is a pattern of what files are actually the ones I want to freeze as part of the "bsp freeze". guessing bsp/target_board_rev-1.2/GeneratedSource/*.h/.c !?
this data usually only changes on a new board-revision, so it doesn't feel necessary to re-generate the full tree on each developers computer. Or are there any reasons not to do it once and just commit to the repo?
It would be great if you can help guide me to what build scripts I need to tweak to skip the modus bin tools from running if they don't exist and/or if the files are already present. I'd rather have a special target to rebuild a specific board in the bsp/* folder
The image you showed above from the user guide is the default behavior for ModusToolbox 3.0. The bsp is stored in the application/project folder along with other project-specific files and subfolders.
As I mentioned before, you need at least Make in order to build a ModusToolbox application, but there might be other dependencies as well. I honestly do not know the minimum set of the tools in the package installer you would need to build an application, but you definitely need Make.
I also must not understand what you mean by "freeze" here. When you create an application, you choose the initial BSP and example template application. All of these files are stored in the "main" project folder -- let's say in this case "hello-world." Everything in that project folder, including the BSP, is potentially something you might edit directly or indirectly, so you might want to include all of it in source control.
The .gitignore file and .cyignore file show common files that you probably want to exclude from source control, because they are either stored on a server somewhere, or they can be regenerated with a build. Everything else should be included. Is that what you mean by freeze?
For example, if you make changes to the Device Configurator, your changes are saved in design.modus, as well as files in the GeneratedSource subfolder. You should keep those files in source control. On the other hand, you can probably exclude the TOOLCHAIN_IAR folder if you don't plan to use it.
My advice is to keep the ~/ModusToolbox/ installation folder intact on at least one computer. You can then try to remove various bits of it, but I don't recommend it. The tools package is meant to be a complete thing. You may not need the Bluetooth Configurator or the USB Configurator, but if you start messing around with make, modus-shell, python, fw-loader, and other tools, you will probably run into various unknown errors.
By "freeze" I mean store ALL dependencies in the working repository. Most modus example projects seem to prefer to exclude generated files like bsp and hals, but I will just allow those in the .gitignore and add them to my local repo.
Q: is there a list of what is "real" files vs. just temporary in the built and auto-generated hierarchy!?
Second is to remove the magic of the inherited make scripts from modus. Once you settle on your HALs, libraries and BSP, I really need the project to be able to compile on a machine that doesn't have the ModusToolbox/* files installed. Can I find documentation on how I best migrate the "magic files" from there to my working repo?
An alternative that would also be great would be a 'modus-tools' git repo that just includes the scripts and make files needed, but not the full eclipse suite. That way that could live as a submodule to any psoc6 related project.
Hi again, we have a slight problem with terminology, so I am going to try and be clear. Forgive me if the following is over-simplified. The link I sent you before to the user guide has a description of all the files and folders in section 2.4. There is also a build system chapter (ch. 4) that goes into more detail about the build process and various make targets and variables.
BSP - The board support package includes all the files for the kit/hardware on which you program your application/project. The BSP lives in and is owned by the application/project. This stuff generally cannot be regenerated, so you need to add it to source control. There is a .cyignore file in the BSP, but in only excludes the docs folder.
Application/Project - This contains the source code and configuration files that make your thing unique, such as main.c and Makefile files, as well as bsps, deps, and libs folders. In many cases, we use application and project interchangeably, but in the case of multi-core applications, we have to be more specific about what a project is.
In general, most files/folders in an application/project cannot be regenerated, because you edit it directly or indirectly. The .gitignore file gives an example of what you can exclude.
Dependencies - These are libraries/middleware like HAL, PDL, CAPSENSE, etc. and they are Git repos. These can be local in the application or shared in a separate folder called mtb_shared, where they can be shared by many different applications/projects in the same workspace. For example:
Either way to decide to have these files and folders stored either local or shared, these files and folders CAN be regenerated using the Library Manager or "make getlibs" so you can exclude them from source control.
Hopefully, this answers your 1st question.
As to the 2nd question, I'll have to get back to you. I am 100% sure you can delete the ide_3.0 folder in the installation directory without consequence. You can also delete the docs_3.0 folder. What I don't know is what is safe to delete in the tools_3.0 folder. I'll check with a couple of people a lot smarter than me to see what is possible -- if anything.
ok so read through the guide <Infineon-ModusToolbox_3.0_Tools_Package_User_Guide-GettingStarted-v13_00-EN.pdf> and understand a bit more now, so I guess best approach is to simply freeze the dependencies by make getlibs / bsp-assistant / library-manager and allow the sources to be checked in to the project git-repo.
benefit is that we can now build on a machine without modus installed, and also get an insurance that 5 years from now, the deps are still there and can still be built.
so some related questions
- if I need to update the bsp or bump a revision of some cypress peripheral library, what is the easiest way? preferably without modifying the files that don't need to be updated
- wouldn't it be nice with a 'make freeze' to help with item 1. preferably together with a
'make printfreeze' (like printlibs), so that its clear what needs to be allowed in .gitignore
- lets say we make use of 'make vscode', if you at a later stage modify the modus project, re-running make vscode seems to overwrite everything, is there a flow to only re-export what is needed from a project-structural standpoint?
1. For the BSP, there is no version. It is owned by the application, and by extension you. For Libraries, the easiest way, IMO, is using the Library Manager to select the specific version of a specific library you want to update.
2. I don't quite get this. If you want to freeze a particular library, use a specific Version like 2.2.0 release, as opposed to Latest 2.X release. As for .gitignore, this just tells git not to include various files and folders to be checked into source control. For example, let's say in 5 years you need to update something in your application, but you did not keep the mtb_shared directory. If you specified in the mtb-hal-cat1.mtb that it should be Latest 2.X release instead of 2.2.0 release, it is possible that when you run make getlibs, you could get version 2.3.5 or 2.4.7 if they exist at that time.
3. You only need to run make vscode once, and there should be no reason to run it again. Just like using Eclipse, you can update your application using VS Code and keep there forever. So, I am not sure of the scenario where you would re-run the make command for vscode.
1. but how can I tell the library manager that the files are actually static and part of my local project folder? i.e. make printlibs looks at the project, not the flattened files, or am I missing out on some config here?
2. to simplify, how can I freeze all dependencies of a project to the local folder? i.e. stop the project from auto-generating the deps each time I build!?
3. I still need to keep the modus project so that I can update the BSP's each time a new board-revision is made, or to make tweaks to peripheral settings and such. Once I do that, the vscode is outdated and needs to be re-generated so it's not a one-way command. I'd like to see this as something you can run as an iterative process, i.e. without re-writing the full vscode project, just add the resources that got changed.
1. In that case, you would choose Type = Local Git Repo, and then the library would be stored in the "libs" subfolder in your project.
2. If you just build a project that has already been built, nothing is regenerated. If you change source code in some way, then a bunch of files may have to be regenerated/compiled.
3. This does not make sense to me at all. You have application/project code (main.c) and configuration code (bsp/TARGET_APP.../). If you change your BSP to something else, the application/project Makefile should point to the new/correct TARGET. The bsp.mk file in that BSP points to the correct DEVICE(s). The config files in that BSP should have the updated code based on changes you made to pins, clocks, CAPSENSE, or whatever. You can run the various tools and make updates using the Library Manager. Nothing should be out of date in your application/project unless you are not using the correct tools to make updates.
1 & 2. great! thanks
3. Ok, true, agree with you there. Its important to keep all board specifics in the BSP and not explicitly configure a gpio pull-up and such from application code (as it might be different on another board), but here is where I'm a bit lost...
Lets say I tweak the speed of a peripheral straight in the .h/.c file, or add a different padconfig to a gpio, if I now open 'design.modus' it will of course have another opinion about the bsp and overwrite changes made to files in Generated Source. I guess there is no way in between here!? i.e. either you point and click in the gui and don't touch the generated source.. or you write your own peripheral wrappers and control it all as a runtime configuration.
For 3, When you make tweaks like that, you are modifying the BSP for the application/project, and that application/project alone. One of the main things we changed from ModusToolbox version 2.x to 3.x is that the BSP is no longer a Git repo, so all changes you make are specific to the application in which it lives.
You can export that BSP and use it in another application, and it will then be specific to that other application. Changes you make in one have no affect on the other. Does that make sense?
Do this experiment:
1. Open Project Creator in stand-alone mode, select your BSP, make sure TARGET IDE is VS Code, and create Hello_World.
2. When that is done, open VS Code and then open the new workspace file you just created. Build the project.
3. Open BSP Assistant and if needed select the current BSP you just created. Change the device for the BSP. Click Apply. When that finishes, if there are any errors, open the Device Configurator and make appropriate changes. Save and close Device Configurator. Close BSP Assistant.
4. Build in VS Code again.
Did you get any errors building? If so, what are they?
good idea! I will do some experiments and commit for diffing in between each step. will report back
ps. noted when building it says 'compiling ext file cyhal_psoc6_** for each family and csp, bga package option. I only have one exact part-no that I wanna use so have no need for all of those, can I remove those deps?
ps2. same goes with the toolch outputs, only want arm_gcc, not iar, arm, etc. where do I omit those?
Update: So, I built my application with VS Code instead of Eclipse. I see the same build messages as you reported. I didn't realize this before, but these are the same messages that are shown in Eclipse, but they are shortened in VS Code. These are your "dependencies" as you called them being compiled into your overall application. As I mentioned previously, you can exclude all the libraries from source control. They need to be regenerated at a later date if you want to make changes to your application. But once your application has been built, you don't need them.
cyhal_psoc6 doesn't look right to me. Current ModusToolbox applications use mtb-hal-cat1 for PSoC 6 devices. Can you tell me what BSP and code example you are working with as a starting point?
Here is a snippet of my build output for CY8CKIT-06234/Hello_World:
Auto-discovery in progress...
= Building application =
Generating compilation database file...
Compilation database file generation complete
Building 195 file(s)
Compiling bsps/TARGET_APP_CY8CKIT-062S4/COMPONENT_CM4/TOOLCHAIN_GCC_ARM/startup_psoc6_04_cm4.S ...
Compiling bsps/TARGET_APP_CY8CKIT-062S4/COMPONENT_CM4/system_psoc6_cm4.c ...
Compiling bsps/TARGET_APP_CY8CKIT-062S4/config/GeneratedSource/cycfg.c ...
Compiling main.c -DCOMPONENT_APP_CY8CKIT_062S4 ...
As for other toolchains, they are baked in as part of project creation. I think you can just delete them after they are created, but I am not sure if there is a way prevent them from being created in the first place.