I'm liking the looks of this from a quick skimming. From what I can tell, the Teensy 3.1 is cheaper than an Arduino Uno, 32-bit and has more RAM in a smaller space?

Also, is this one of the other microcontrollers micropython is to be ported to? Either I missed it or Damien hasn't stated this yet.

I think Damien made a mention somewhere that it might be possible to port MicroPython to Teensy. I happen to have a couple, so I figured I'd give it a try.

My brother Jon is making a small little robot http://blog.huv.com/2013/12/uc-microcrawler.html which will use a Teensy and I know he'd like to use MicroPython to control it. I'm working on a larger robot using a Minds-I chassis, and would like to use a Teensy or MicroPython board for the low level stuff and a BeagleBoardBlack for the high level stuff.

For me, doing to the port forces me to learn stuff about the internals of MicroPython.

The Teensy 3.1 has 256K flash and 64K RAM and runs at 96MHz.

I like your thinking. Combining the host/microcontroller seems to be where everybody is heading nowadays. I'm looking forward to the Arduino TRE, which is basically a Beagleboard bolted to an Arduino. Cool stuff.

I think I'll be getting a Teensy after this. I can help out MicroPython as well as have a better options for porting libembroidery to Arduino too. My time is split between the projects but I will be definitely be following your progress on this. I've been trying to get up to speed with the internals too, but have mostly done non-programming related contributions so far.

Files string0.c, gchelper.c, printf.c, malloc0.c, etc. are almost verbatim copies of files in stm/. Why do you do it like that? Please see immediate criticism in #83 (comment) and discussions on how to organize ports to different boards in #83, #19.

Yep - I agree that the way things are currently is not optimal. I think it makes sense to factor this stuff. I'm even willing to help out.

The Teensy isn't an STM device (it's a Freescale device), so it doesn't belong in the stm folder. It is a Coretex M4, but it doesn't seem to have an FPU. So there will be many similarities with the stm device, but also some differences.

I expect many of the peripherals will be similar.

We need to decide what code should be made common, and what APIs it should use for interfacing to things (like systicks). I think that many other commands like gpio and LEDs etc can be genericized a bit and have the python interface bits be common as well.

But since the structure doesn't currently exist, I followed the pattern which does exist. I'm happy to update and adapt as well, but I also don't want to do this all as one big commit. I'd rather get the basics in and then start to factor things.

Other things which come to mind which need to be considered are things like pin naming. In the python gpio bindings, for example, on the MicroPython board, it uses the string "A3" to refer to pin 3 on port A. The teensy has an Arduino influence, so the pins are numbered 0 through 34 and are mapped internally to ports and pins.

I'd like to hear Damien's thoughts on all of this. I'm definitely willing to work on refactoring. although I don't yet have an actual MicroPython board for testing. I'm willing to acquire an STM discovery board just to help facilitate that (Wow - I didn't realize how inexpensive they are - only $15 from DigiKey). I also didn't fully appreciate the similarity to the processor in the MicroPython board.

Nice work. Teensy 3.1 was on my TODO list (but down the bottom).

Agree we need to sort out duplication of files and how ports will be arranged. There are going to be boards that are very similar (pyboard and STM32F4discovery), boards that are different but have similar CPU (pyboard and Teensy) and boards that are totally different.

I'll merge this request in, because I think it'll provide a good test-bed for the framework for supporting different boards, and seeing what needs to be factorised.

@dhylands: Thanks for positive response, finding people who'd be interested in refactoring is the best outcome of these discussions. But even now it would be possible to reuse files from stm port without duplicating them: #83 (comment) (but sure, better solution is factor them out from STM port, but as you say, it requires some planning and steps).

@dpgeorge added more comments on pin naming to #86, I'll follow up there too.