- Notifications
You must be signed in to change notification settings - Fork1k
feat: target board generation [PROPOSAL]#4999
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
base:dev
Are you sure you want to change the base?
Uh oh!
There was an error while loading.Please reload this page.
Conversation
mikesmitty commentedAug 16, 2025 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
As an example, here is the file generated for a |
aykevl commentedAug 17, 2025
Oh this is an interesting approach! |
aykevl commentedAug 17, 2025
I have been thinking about another approach, that is not necessarily competing with this PR but related. It's to provide some configurations (such as clock frequency / crystal selection / USB VID+PID / other configs) through flags set in the JSON file. One issue I have is that I make custom hardware and I run it at a low frequency to reduce current consumption. Right now I basically just reconfigure the clock, but it would be more convenient if I can just set a flag on the command line. Something like: {// ..."configs": {"main-clock": ["LSI-131kHz","LSI-262kHz","LSI-524kHz","HSI-16MHz","HSI-32MHz",...], }}And then the clock can be set either in a JSON file or via a command line flag ( This could then be used in the runtime like so (switch should get optimized at compile time): switchtinygo.getConfig("main-clock") {case"LSI-131kHz":// configure with main clock set to 131kHz// etc} Something similar could be used for USB VID/PID pairs. Anyway, this is somewhat off-topic but perhaps another way some configuration could be done. It wouldn't work for pin constants, obviously. |
mikesmitty commentedAug 17, 2025
Yep, I made sure a file with the target name is added to the hash key to make sure it would split the caches out and avoid inter-mixing. I really like those ideas you mentioned. I'll do some thinking about how they could be integrated |
Uh oh!
There was an error while loading.Please reload this page.
At the networking SIG meeting the other day we got a little off topic, but one of the things that came up was reducing initial user friction and the relative difficulty of adding support for a new board. One idea that was mentioned was the fact that the
-targetflag can be used to specify an external json file and at least in my mind is the obvious choice for board-definitions. Its purpose is already to store board-specific information and passing in external json target files would make custom board definitions very easily accessible (a very popular request, of course:#3288,#3152,#2607,#2239)I took a look over the various board definitions and the vast majority of the code boils down to just a few things:
All that can be reduced to a template generated from a JSON target file very easily so I put this together and converted a handful of targets as a demo.
The way this works is to take in the board section added to a target definition that contains the pin aliases, usb variables, etc. and templates out a file that is added to the cached TINYGOROOT for that target. I chose to put it into the cache because I wanted to avoid requiring that the TINYGOROOT be writable, but that can be changed pretty easily.
As a handy side-effect, this also makes auto-generating board definitions for already-supported MCUs fairly simple and would further reduce new-user friction if they find that their favorite board is already supported.