Open gitcnd opened 1 month ago
It might be worth adding and enforcing a rule about what the .md file is supposed to be called (and documenting that).
The following boards exist, but do not have .md files for them:-
The following .md files do not have any corresponding circuitpython/ports/*/board/ folders for them:-
Possibly a different system for board variants makes more sense, than duplicating an entire board .md file when nothing else (not even the firmware) is different?
This section:-
board_id This should be the name of the board for example "feather_m4_express".
probably needs expanding to explain what "board_id" means, and the purpose of this - as best I can tell, this is the name of the folder that the board firmware definition files live in ? and I think it's probably used as a name inside some website build process the generates the firmware binaries, so this line tells the website which firmware goes with the board, right?
Good ideas. Thanks for the suggestions. :) A lot of the enforcements were added after I had written the guide and you're right that it needs some updating.
I'm struggling with my PR https://github.com/adafruit/circuitpython-org/pull/1408
This guide is outdated: https://learn.adafruit.com/how-to-add-a-new-board-to-the-circuitpython-org-website/adding-to-downloads
It needs to explain how to properly fork the website, including the automatic checking stuff. ( This doesn't work
pre-commit install
Because.pre-commit-config.yaml
is missing... )It needs to update the features - some I can think of include:-
It probably doesn't make sense to limit the features and block boards from adding new ones they support - this makes it frustrating for developers and users alike, when new things they're trying to do don't have the correct supporting documentation.
Here's the list of existing features in all boards:
cat _boards/* | perl -ne 'print if($f && /^ \- /) ; $f=0 unless(/^\s/); $f=1 if(/^features:/); ' | sort | uniq