Teensy 3.5/3.6
Teensy 3.5/3.6
that makes the teensy boards comparable to the pyboards I guess. 1Meg Flash 256kB RAM, cortex M4@180Mhz sounds familiar.
https://www.kickstarter.com/projects/pa ... /508891821
it's got heaps of interfaces, even an ethernet stack. Probably will take quite an effort to port the hal.
https://www.kickstarter.com/projects/pa ... /508891821
it's got heaps of interfaces, even an ethernet stack. Probably will take quite an effort to port the hal.
- pythoncoder
- Posts: 5956
- Joined: Fri Jul 18, 2014 8:01 am
- Location: UK
- Contact:
Re: Teensy 3.5/3.6
That was my thought too - I guess there are a numerous differences in the I/O devices. They look interesting pieces of kit, though.marfis wrote:Probably will take quite an effort to port the hal.
Peter Hinch
Index to my micropython libraries.
Index to my micropython libraries.
Re: Teensy 3.5/3.6
I've signed up for the developer pack, which includes a pre-production unit of the Teensy 3.6.
It looks like most of the peripherals between the various devices are all very similar (in terms of register layouts etc).
It's been filtering to the top of my list of TODO things to work on the Teensy port and add more peripheral support (and probably move over to using machine instead of pyb), so I'm planning on working on improving the existing support and adding support for the new boards.
It looks like most of the peripherals between the various devices are all very similar (in terms of register layouts etc).
It's been filtering to the top of my list of TODO things to work on the Teensy port and add more peripheral support (and probably move over to using machine instead of pyb), so I'm planning on working on improving the existing support and adding support for the new boards.
Re: Teensy 3.5/3.6
Hi Dave, I saw your info for compiling MP for Teensy 3.5/3.6 (https://github.com/micropython/micropyt ... .1-3.5-3.6) and appreciate the work you put into this. I did try compiling with a current git copy and ran into issues flashing the image to a Teensy 3.6; the Teensy loader complains that the image is compiled for Teensy 3.1, not 3.5/6 and refuses to load it when I run the command "make BOARD=TEENSY_3.6 deploy":
I've tried re-checking out another copy and performing a make clean, however there isn't any change. Am I missing something or is this currently broken? I'm using Arduino 1.6.13 and Teensyduino 1.32 BTW, here's the teensy loader log output:
Thanks!
Larry
Code: Select all
micropython/teensy$ make BOARD=TEENSY_3.6 deploy
Use make V=1 or set BUILD_VERBOSE in your environment to increase build verbosity.
Using toolchain from PATH
Generating build/frozen.c
GEN build/genhdr/qstr.i.last
GEN build/genhdr/qstr.split
GEN build/genhdr/qstrdefs.collected.h
QSTR not updated
CC build/frozen.c
LINK build/micropython.elf
text data bss dec hex filename
190092 1236 20400 211728 33b10 build/micropython.elf
HEX build/micropython.elf
Preparing post_compile for upload
Opening Teensy Loader...
Teensy Loader error responding to comment (p)
Makefile:182: recipe for target 'post_compile' failed
make: *** [post_compile] Error 1
Code: Select all
04:47:09 AM: Teensy Loader 1.32, begin program
04:47:09 AM: File "micropython.hex". 191328 bytes, 18% used
04:47:09 AM: Listening for remote control on port 3149
04:47:09 AM: initialized, showing main window
04:47:09 AM: remote connection opened
04:47:09 AM: remote connection opened
04:47:09 AM: remote cmd: "comment: Teensyduino 1.32 - LINUX64 (teensy_post_compile)"
04:47:09 AM: remote connection closed
04:47:09 AM: remote connection closed
04:47:10 AM: HID/linux: bus "009", device "001" vid=1D6B, pid=0003, ver=0408
04:47:10 AM: HID/linux: bus "008", device "001" vid=1D6B, pid=0002, ver=0408
04:47:10 AM: HID/linux: bus "007", device "003" vid=2109, pid=0812, ver=0BE1
04:47:10 AM: HID/linux: bus "007", device "002" vid=05E3, pid=0616, ver=9223
04:47:10 AM: HID/linux: bus "007", device "001" vid=1D6B, pid=0003, ver=0408
04:47:10 AM: HID/linux: bus "006", device "027" vid=16C0, pid=0478, ver=0103
04:47:10 AM: Device came online, code_size = 1048576
04:47:10 AM: Board is: Teensy 3.6 (MK66FX1M0), version 1.03
04:47:10 AM: File "micropython.hex". 191328 bytes, 18% used
04:47:10 AM: set background IMG_ONLINE
04:51:56 AM: Program event
04:51:56 AM: File "micropython.hex". 191328 bytes, 18% used
04:51:56 AM: elf size appears to be 262144
04:51:56 AM: elf binary data matches hex file
04:51:56 AM: Code size from .elf file = 262144
04:51:56 AM: Incompatible file, showing warning dialog
Larry
Re: Teensy 3.5/3.6
Hello Larry, I gues you cloned @dhylands branch for teensy, as detailed here: http://forum.micropython.org/viewtopic. ... lit=teensy in hist post from October 20th.
If you did. it should work. The first few lines of the make log shoud look like:
So, TEENSY_3.6 shold be visisble. If not, you do not have the right repository.
If you did. it should work. The first few lines of the make log shoud look like:
Code: Select all
Use make V=1 or set BUILD_VERBOSE in your environment to increase build verbosity.
Using toolchain from PATH
mkdir -p build-TEENSY_3.6/genhdr
Create build-TEENSY_3.6/genhdr/pins.h
Generating build-TEENSY_3.6/frozen.c
Generating build-TEENSY_3.6/genhdr/mpversion.h
......
Re: Teensy 3.5/3.6
Yeah - the teensy stuff hasn't been merged into the main repository yet.
You can use the following git commands to merge it into your existing repository:
at the end of the build you should see: (i.e. look for build-TEENSY_3.6, not just build as the name of the directory).
If you then install teensy_loader_cli, you can use: to flash the image.
There are also precompiled hex files in the teensy/hex-files diorectory along with flashing scripts (which also assume teensy-loader-cli is installed.
There is a link to the teensy_loader_cli repository in the wiki:
https://github.com/micropython/micropyt ... .1-3.5-3.6
I'm just in the process of addressing the VCP_USB issues that @roberthh mentioned, and then I'll be starting on I2C support.
You can use the following git commands to merge it into your existing repository:
Code: Select all
git remote add dhylands https://github.com/dhylands/micropython.git
git fetch dhylands teensy-usb
git checkout teensy-usb
cd teensy
make BOARD=TEENSY_3.6
Code: Select all
LINK build-TEENSY_3.6/micropython.elf
text data bss dec hex filename
251532 1260 21692 274484 43034 build-TEENSY_3.6/micropython.elf
HEX build-TEENSY_3.6/micropython.elf
If you then install teensy_loader_cli, you can use:
Code: Select all
make BOARD=TEENSY_3.6 deploy
There are also precompiled hex files in the teensy/hex-files diorectory along with flashing scripts (which also assume teensy-loader-cli is installed.
There is a link to the teensy_loader_cli repository in the wiki:
https://github.com/micropython/micropyt ... .1-3.5-3.6
I'm just in the process of addressing the VCP_USB issues that @roberthh mentioned, and then I'll be starting on I2C support.
Re: Teensy 3.5/3.6
Wonderful. I've gotta try this .... see if I can find some time. Thanks for the mention to the Teensy CLI I hadn't seen that https://www.pjrc.com/teensy/loader_cli.html
Also BTW a link for Andrew's Usb HOST FS framework that I've got working on a Teensy 3.6 that I believe would be compatible with uP REPL.
https://forum.pjrc.com/threads/28173-Te ... post123532
The difficulty I've with the uPython board framework was doing the debugging of an OTG framework.
Somehow I couldn't figure out to make the REPL only use use a serial connection.
The REPL over USB device (with powering) is so fantastic for debug simplicity, until trying to debug and use the OTG.
So I wonder if there is way of being able to force all REPL/debugging to only use the serial connection, for the purpose of being able to monitor the USB FS OTG decision, and be able to switch to Host.
Also BTW a link for Andrew's Usb HOST FS framework that I've got working on a Teensy 3.6 that I believe would be compatible with uP REPL.
https://forum.pjrc.com/threads/28173-Te ... post123532
The difficulty I've with the uPython board framework was doing the debugging of an OTG framework.
Somehow I couldn't figure out to make the REPL only use use a serial connection.
The REPL over USB device (with powering) is so fantastic for debug simplicity, until trying to debug and use the OTG.
So I wonder if there is way of being able to force all REPL/debugging to only use the serial connection, for the purpose of being able to monitor the USB FS OTG decision, and be able to switch to Host.
Re: Teensy 3.5/3.6
The REPL I/O winds up funneling through the functions in teensy_hal.c
https://github.com/dhylands/micropython ... ensy_hal.c
I haven't yet added compile time options to put the REPL on a UART, but you can do it using the following in boot.py (this I have tested):
Hard coding it would need to do something similar to what's done in stmhal: https://github.com/micropython/micropyt ... #L453-L466
Both methods wind up causing pyb_stdio_uart to be set.
If you comment out all of the code that calls usb_vcp_xxx in teensy_hal.c then you can make the REPL be UART only. You'll lose the ability to use Control-C (even stmhal doesn't do Control-C on the UART).
I also noticed that the Teensy 3.5/3.6 has the ability to connect a debugger (there is a DE line which, if grounded, is supposed to disable the onboard JTAG flasher chip and allow DD/DC to be used for SWDIO/SWCLK), but I haven't tried this myself.
I've found the teensy_loader_cli seems to fail about every other time, so I modified the Makefile (not yet pushed to my tree) to do this:
and that seems to be working. I need to investigate a bit more and report back to Paul.
https://github.com/dhylands/micropython ... ensy_hal.c
I haven't yet added compile time options to put the REPL on a UART, but you can do it using the following in boot.py (this I have tested):
Code: Select all
import machine
import os
repl_uart = machine.UART(1, 115200)
os.dupterm(repl_uart)
Both methods wind up causing pyb_stdio_uart to be set.
If you comment out all of the code that calls usb_vcp_xxx in teensy_hal.c then you can make the REPL be UART only. You'll lose the ability to use Control-C (even stmhal doesn't do Control-C on the UART).
I also noticed that the Teensy 3.5/3.6 has the ability to connect a debugger (there is a DE line which, if grounded, is supposed to disable the onboard JTAG flasher chip and allow DD/DC to be used for SWDIO/SWCLK), but I haven't tried this myself.
I've found the teensy_loader_cli seems to fail about every other time, so I modified the Makefile (not yet pushed to my tree) to do this:
Code: Select all
post_compile: $(BUILD)/micropython.hex
$(ECHO) "Preparing $@ for upload"
$(Q)if ! teensy_loader_cli -v -mmcu=$(MCU) -w -s $<; then \
teensy_loader_cli -v -mmcu=$(MCU) -w -s $<; \
fi
Re: Teensy 3.5/3.6
Any progress on this port? ) I could help to test something)
Re: Teensy 3.5/3.6
The teensy-rtc branch is my latest branch. I updated the README.md file to cover what is and isn't implemented and provide documentation for the functions that are implemented:
https://github.com/dhylands/micropython ... ine-module
Currently, the big things that are missing are I2C and SPI functionality.
https://github.com/dhylands/micropython ... ine-module
Currently, the big things that are missing are I2C and SPI functionality.