So the "first" port (the outdated one) was trying to get teensy stuff running, so I wound up using lots of the arduino shim code.lbattraw wrote:@dhylands - re: recent code changes
Yep, I have pushed several times recently, which might be part of the problem Things are changing rapidly as I keep finding new things I'm doing wrong, and there's always something new to fix...
I've been looking at your HAL code for Teensy as I realized I didn't have a way to output strings via the USB VCP, and am wondering some more about where to split up such code and the existing Teensy Arduino libraries (Which I wanted to reference instead of duplicating sections). Ideally I'd like to build on all that existing, tested code to avoid reinventing things (Or copying things that might later be changed in the original code base), with just some glue code to make it work with MicroPython. It might also make it a little less difficult for future ports since if they can use the Arduino API they may be able reuse glue code as well. That's the idea anyway. Any thoughts on this, creating/copying code vs. using Arduino interfaces?
-Larry
In the more recent port, I'm trying to use as little of the arduino shims as possible and coding directly to the registers. The timer.c file is an example of this. The Pin code is actually common enough that I was able to use the stmhal version.
The arduino shims are fundamentally too limiting, in that you only get as much functionality as they expose, and it adds an extra layer of redirection (i.e. arduino pin numbers don't necessarily map nicely to CPU pins, etc). It also reduces the code size quite a bit.
I expect that I'll keep the USB serial stuff, but for UART, I would probably just code directly to the registers, since the UART is pretty straight forward as far as peripherals are concerned.
So I would probably take stmhal's uart.c, keep all, or most of the functions, and rewrite the contents of each function.