PlatformIO can not add custom processor

I have been trying to get PlatformIO working with a cortex-M4 (ATSAM4E). What I am finding is that PlatformIO is very limited in the ability to add support for random processors. Specifically it appears there has been many pull requests to add CMSIS support to the atmelsam processors but none have been approved. What this indicates is that PlatformIO is limited by the github approvers…

I am wondering if there would not be a better way for example, is there not a way where the per project configuration can be stored with the project. Much closer to the npm model in node.js, maybe using the xpacks project.

That is if I want to use a processor that is not supported by platformIO I am pretty much out of luck… This is a major flaw in the architecture of the system. It should be such that I can include links to my compiler build tools, SVD, packs and such in the platform.ini and not have to do pull request into platformIO main repo to make this happen. Also I should not have to clone platformIO and add in my processors to do this. PlatformIO should be independent from the processor, much like npm libraries with node are.

Sure platformIO looks neat but it is zoombie project because it has such a bottleneck in adding new processor support.

1 Like

One does not have to do all that. We’ve demonstrated that at Bare metal on arduino due / atmelsam. Custom board definition + a tiny bit of builder script in a baremetal project get CMSIS up and running just fine.

Show me an example of how you would setup a custom processor. For example if Microchip/STM/NXP comes out with a new processor today, how do I setup platformio to build code for that processor? How do I make PlatformIO install the correct compiler and build tools (even if just a makefile) and gets the debugger working. That is a bare-metal setup example like:

platform = Cortex-M4
framework = …
board = …

An example is maybe in PlatformIO to have generic processor support like Cortex-M4, etc. Then you know to install the arm gcc compiler and build tools. Then for peripheral support in debugger create a .platformio directory and have the SVD there for peripheral mapping. Here even supporting makefiles would be good enough.

If I have to go modify PlatformIO’s python code to do this then platformio is bandwidth limited based on the maintainers doing pull requests. That is you can never grow the project faster than the maintainers can pull in changes.

As far as framework=… this does not appear to not be documented anywhere I have found.

Note everything should be in the project directory. I do not want to have to modify anything in my %APPDATA%/.platformio directory because then if another developer picks up project they have to do the same mods. Hence any and all customization must exists in the project.

Also there needs to be an option to specify the version of build tools. For example once a version of compiler is qualified for use on a project we do not change the compiler version without a complete product regression test. Each project might use a different version of compiler and build tools. So for the current project we need to specify which compiler will be installed an used. Here again you see this with node/npm packages.

Thinking about this more it appears that PlatformIO is designed to be an improvement on Arduino, but maybe was not designed with the thought of doing mission critical embedded development.

Mission critical embedded you control everything that goes into your project. This includes the compiler version, tool versions, etc. At a basic level, if in 5 years you can not build your project and create the same binary exact hex file for the processor you have failed.

This might seem strange, but the reality is for mission critical projects testing takes as much time, often more time than development. So you want to minimize the changes at the assembly code level. As a simplification, if you change one function and can verify nothing else changed, you can then bound your regression tests which need to be ran with some level of confidence that you did not break anything else. If everything in the hex file changed, then you have to do a complete regression test which can take weeks or months to complete. This is a simplification to explain the concept.

What this means is you can not have a “framework” behind the curtains that can change. The framework is part of project and usually checked into version control with project. If it is not checked in with project then you need to be sure you are controlling the revision of the framework such that you can create that binary exact hex file at any point in the future. For example if you buy a new computer (or your hard drive crashes), you can reinstall and still build that same binary exact hex file.

Note I have seen this to extremes, where virtual images of operating systems with tools have been checked into version control. For example one project used a compiler that only ran on windows 95. So they had virtual machine running windows 95 they used for bug fixes to the project. Most projects are not that extreme as that if you control versions of tools and libraries you can control the hex output.

This is what npm does for javascript. For those who do not know about npm, it is a node package manager for doing javascript project development. What happens is that for a project you have package.json file which has two sections one is project dependencies and the other is devDependencies. These dependencies contain a list of libraries or tools (for dev) and the revision that is accepted (‘^’ means at least that revision or newer), see below. This allows you to control the tools, frameworks, libraries, dependencies, etc that you use for your project. Hence in 5 years if you install the same dependencies and versions, then build project you should get the same output. xpm and xpacks is a project that is trying to do this for embedded development, The xPack Project Manager | The xPack Build Framework.

So until PlatformIO can make it where you can guarantee that in N years from now I can load a project and build it to get the same binary exact hex file output, then PlatformIO is more of a toy like Arduino. That is it good for hobby projects but nothing I could personally recommend for mission critical embedded projects.

Example for npm package.json dependencies:
“dependencies”: {
“axios”: “^0.21.1”,
“bootstrap”: “^4.6.0”,
“bootswatch”: “^4.6.0”,
“font-awesome”: “^4.7.0”,
“formiojs”: “^4.12.7”,
“history”: “^5.0.0”,
“lodash”: “^4.17.21”,
“moment”: “^2.29.1”,
“node-sass”: “^5.0.0”,
“react”: “^17.0.2”,
“react-dom”: “^17.0.2”,
“react-formio”: “^4.3.0”,
“react-router”: “^5.2.0”,
“react-router-dom”: “^5.2.0”
“devDependencies”: {
@testing-library/jest-dom”: “^5.11.4”,
@testing-library/react”: “^11.1.0”,
@testing-library/user-event”: “^12.1.10”,
@types/jest”: “^26.0.15”,
@types/lodash”: “^4.14.170”,
@types/node”: “^12.0.0”,
@types/react”: “^17.0.8”,
@types/react-dom”: “^17.0.0”,
@types/react-router”: “^5.1.13”,
@types/react-router-dom”: “^5.1.7”,
“react-scripts”: “4.0.3”,
“typescript”: “^4.1.2”

1 Like