[WIP] make all teensy devices variants #753
Open
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
🚨 Work in progress, BUT LOOKING FOR FEEDBACK!
I recently created a custom imxrt1062 pcb with teensy bootloader + sdram, and in the process of trying to get it working I ended up making lots of changes to the teensy4 cores. While I was able to get everything that I needed working, it was a pretty painful process, and I lost a lot of momentum on the software side. I'm not looking forward to revisiting the pain when the next beta comes out, so I pre-emptively jumped down the rabbit hole of exploring how teensy cores could be updated to make it trivial to get a custom variant working.
The steps I'd like to see are:
#define
s using data from the reference manual.teensy4_custom_variant.h
To get this working seamlessly, the existing teensy4 "variants" should also have all the same information defined in a single header file per variant. The files included in
./teensy4/variants/
were generated using a script, and require a few tweaks before they could be used:master
has what I assume are some hacks to make it simple for people to useanalogRead()
onA0
by providingpin0
. my script didn't include this behavior as I believe it's confusing.The safety of such a change should certainly be in question, but diffing post-preprocessed sources from
master
and this branch makes it pretty easy to see what has changed.I'm going to halt this effort here until I can get some feedback, and/or confirmation that something like this has the possibility to be merged. There is still a reasonable amount of work to complete this, and while I'd be happy to push this across the line and get it merged, I would rather not spend time on this if it doesn't have a chance.
Additional Reading