OK - I'd like to start looking a bit more seriously at code sharing between boards and ports. Some related threads are in #11 #19 #83

I'd like to propose that we create something like

micropython
|-- common
    |-- cortex-m4
        |-- put common m4 files, like gchelper.s here
    |-- bindings
        |-- put common python bindings here
    |-- hal
        |-- hal_gpio.h
        |-- other hal header files which describes the HAL API
    |-- malloc0.c
    |-- string0.c
    |-- other shared files that are more or less independent.
    |-- other directories which might contain other common processor family files.

The share python bindings would be abstract and would refer to HAL_xxx for doing things.

So for gpio, for example, we could have a HAL_gpio_init() function and HAL_GPIO_SET(pin,val) HAL_GPIO_GET(pin), HAL_GPIO_SET_DIR(pin, mode) (or maybe HAL_GPIO_SET_MODE(pin, mode)).

common/hal/hal_gpio.h would describe the API and would #include "hal_gpio_impl.h"
stm/hal_gpio_impl.h would implement stm-specific macros
stm/hal_gpio.c would implement stm-specific functions (optional)

Each board or board family would implement the appropriate hal functions and macros.

Or maybe we should just use CMSIS, which cover the M3/M4. I also think that FreeRTOS uses CMSIS for the cortex ports (I'm not suggesting that we necessarily want to use FreeRTOS, but some people might, and I wouldn't complain :).

We need to decide how to map pins. I think having some type of external board identifier (i.e. X1, Y1, or for the teensy just an integer number) can map to the internal designator (PORTA pin 13). I think that @Neon22 had some ideas on this front.

We should be able to share the same python bindings for almost all of the functionality (UARTs, LCD, LEDs, GPIOs, Servo, timers, ADC, etc) as long as they aren't too processor specific.

Some things probably need to be split up into 2 layers. For example, the common 4x20, 2x16, etc character based LCDs all use the same commands, but they can be connected directly via GPIO pins, or they be sitting on a gpio expander. I'm aware of at least a couple common GPIO expander variations, like the PCF8574 or the MCP23008, and even there, the mappings from the i2c expander pins to the LCD pins often differ slightly.
So you wind up with one layer which is for talking to the LCD, and a second layer for delivering the LCD commands to the actual LCD device (over gpio, i2c expander A, i2x expander B, etc).

I happen to have: http://www.adafruit.com/products/292 and http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=370802573051&ssPageName=ADME:L:OU:CA:3160 but there are many other variations.