Hmmm, i went to the your mbed-src URL and imported the library (had to remove the old library from the program folder first). but the compile failed looking for toolchain.h .... I've never tried this kind of mbed update before to on-line compiler ???? i'm testing with https://developer.mbed.org/users/yoonghm/code/Teensy_MBED_BLINKY/

Other observations on teensy3.1 platform: 1) i think the I2C pins are revsersed in PinNames.h 2) tried a simple PWM test, a pwm.write(0.5); took over 19 ms!! i need to view with logic analyzer 3) SPI speeds are not near SPI CLK rate, presumably FIFO's aren't being used as in teensyduino firmware...

thanks for porting the MBED stuff to teensy3.1, an ambitious undertaking!

Due to how SPI works in mbed, using the FIFOs would only slow it down. The overhead depends on the clock speed you are using. If you are more in a hurry you can use BurstSPI lib, but to be fair, if you are looking at speeds of <5MHz the overhead should be negligible.

Regarding PWM, try adding a wait (or random other statement which takes more than 20ms) in front. Setting up the PWM already changes the period/dutycycle registers. Sadly I have been working on that PWM way too long to get a normal PWM functioning properly, but in the end it did not seem possible to make those buffers do what I want them to do, what for example the KL25 PWM buffers can do. The K20 has a different version of the timer for PWM, it has a legacy mode, and that legacy mode of course does not work the same as the legacy PWM peripheral does. So plan A would have been to follow the route the KSDK (K64F/K22F) boards (and too many others) use: That is everytime you switch to a different pulsewidth/period, reset the complete timer, change the values, start the timer again. I considered this unacceptable.

What it does now is have some kind of synchronization enable. Software sets a flag to sync the values in the registers to the PWM hardware at the right moment (so you don't get glitches), and new reads are only done once the old write has been processed. Since the pwm = 0.5 needs to read the current period, and that has only just been set, it needs to wait 20ms (default period).

So, option A: Don't use the pwm.write, but use the pulsewidth functions. These dont need to read and always happen immediatly. Or use the pwm.write, but do not do multiple write actions in a single period. Yes, I could have added software registers which would also keep track of all the pulsewidths and periods of the different pins. But since I considered it to be a quite unlikely situation after initial setup, I decided not to do this, and in general I considered having good output waveforms to be too important to go the route many other targets use of resetting the PWM all the time.

For the first one: Such things can happen indeed :). Which pins specifically? Is easy enough to fix it.

Finally, your first one: So you got the program you linked, removed mbed lib, and imported mbed-src lib instead? I just tried to check it, and compiles fine for me. From the compile dropdown menu you can also try compile-all, this does a clean compilation from the start.

PinNames.h has the I2c defines the wrong way round to see if you guys were paying attention. Now you spotted it I will change these over :) But will leave it for a week or two to see if anything else crops up before sending a PR. During tests I tended to use the 'D' and port names (PTC1 etc.) so that did not show up. Also difficult to show every pin define on the platform page without it being overly complicated.

One other observation, I see that there is a Teensy3.2 now available, generally identical, however it has a higher power 3.3v regulator. I noticed this version does indeed have the different style white 'prog' button. I don't have one of these but can see no reason why it should not work with Mbed.

Nope, I can't get the Teensy Blinky to compile with the new mbeb.bld. I also tried compile-all. Still get

Error: Cannot open source input file "toolchain.h": No such file or directory in "USBDevice/USBDevice/USBHAL.h", Line: 24, Col: 24

I did a fresh load of the Teensy Blinky from URL above, removed the mbed.bld, and fetched the mbed-src lib ...

Yeah verily, using pwm.pulsewidth_ms(1) runs at a 1.5us rate. (I was using the pwm.write(0.5) because that is what I used in the same test on the LPC1768, where average back-to-back calls took 2.5us). Probably not that meaningful a metric, but it was in an old Arduino speedTest sketch. I would call the delay in pwm.write() "unexpected".

At least on the Teensy 3.1 the SPI FIFO used in the teensduino firmware and the FAT lib allows write's of 1024 bytes to run at near SPI clock speed, e.g 27 mbs with 30MHz SPI CLK (CPU @120MHz). For other anecdotal SPI performance numbers with FIFO or DMA on various MCUs, see

https://github.com/manitou48/DUEZoo/blob/master/SPIperf.txt

What do mean mbed.bld? You should have mbed-src in your working directory, that should show revision 635 (current today) on the right hand side of your screen if you select it. Make sure you import the correct library there are two on that page, its on the right hand side under 'Repository toolbox'.

Try this example :

https://developer.mbed.org/teams/CommunityContributors/code/USBSerial-RTC-HelloWorld/file/7bf81089fce6/main.cpp

I have it running now.

What device do you have connected to SPI? I have tested this on various displays and SD cards, works fine.

Ahhh, I was never good at multiple choice. I was not fetching the one on the right hand side ... TODO.

SPI is working, I was just sayin' it might go faster.

That's the drawback with some of the Mbed API's, unlike Arduino there are many (probably too many) platforms that share much of the code so they are not finely tuned to just one vendors MCU capabilities. But the up side is the flexibility to use the different targets to get a quick result depending on the users requirements. With Arduino your stuck trying to push it to its limits and beyond, Mbed, just pick a faster more flexible chip.

OK, loaded in the mbed-src and blinky compiled. BUT the teeny loader says hex file is unreadable. Sure enough, it is not an ASCII hex file, but rather is a binary file ???????

close but no cigar???

EDIT: re-did compile all, and now getting ascii hex file .... running at 96mhz

As proof of concept, have program to exercise Teensy 3.1's internal ADC channels (temperature sensor and VREF output), see https://developer.mbed.org/users/manitou/code/teensy_adc/

You may need to calculate the temperature coefficients for your Teensy 3.1

VREF output (or there is also a bandgap ADC channel) can be used to monitor the input voltage at Vcc.

Official Mbed libraries now have the updated clock set ups, finally, much faster compiles.

Tom, tried your ADC program, I see we only have ADC0 specified. This was inherited from the FRDM-K20D50M code, that only has ADC0. I think we need to add the ADC1 defines.

Paul, should the DMA TCD be dimensioned at 16 rather than 4?

Which DMA TCD?

i'm looking at TCD[] in targets/cmsis/TARGET_Freescale/TARGET_K20XX/TARGET_TEENSY3_1/MK20DX256.h Though I guess the dimension is somewhat cosmetic as the structure is just an overlay over the IO space.

That is not where I would have gone looking for it :P.

That file is supplied by Freescale. Doesn't mean it is error free, and in principle we can change it also, but it is not something we wrote.

The entire library started as a mirror of the FRDM-K20D50M libraries. Erik and I made changes to the Flash, RAM and clock set up spec's, also added the additional NVIC's and peripheral defines. This was then combined with some conditional code to condense it into a shared K20 folder. Some of the code may remain set to the K20D50M architecture.

@Tom I get the impression you have good knowledge on the Teensy. It's been around on Arduino for some time so please detail if there is anything you spot that we need to change or can improve (bare in mind we did not write the libraries in the first place). This can then be updated. Apart from some Mbed limitations there should be no reason why this would not work much the same as it does on Arduino.

BTW there is no CAN API, I did see this on GitHub:

https://github.com/teachop/FlexCAN_Library

Perhaps this can be modified to work here.

At the moment I'm working on some hardware to send to Mbed in Austin so that the 'Tests' can be done before it can be officially added to the Platform page. I know it sounds ridiculous as this 'Platform' only has the MCU and no other external peripheral devices. However I understand and agree there should be no exception to the Mbed rules, unless you're ST of course. There is no way I want to be associated with any work that has ST's bug reputation on Mbed and more importantly, users to be disappointed.

Another proof-of-concept program for mbed Teensy 3.1, a DMA memcpy(), https://developer.mbed.org/users/manitou/code/teensy_dma_memcpy/

For suitably aligned vectors, the ARMCC memcpy() is quite efficient, presumably unrolled assember.

If one wanted asynchronous operation, an IRQ handler would need to be provided.

Now whats unfair to ST, it isn't like other manufacturers do not have completely bugged implementations which are happily released. Hell there is not even a need for having a product which can be ordered, or having an mbed implementation, to be listed on the platform page.

Of course it is their site, if they only want to list platforms when someone payed for it, thats fine. But then just say so and don't expect the community to do your work when you don't even want to communicate with the community. Also like how they expect that *magic* is going to port their async api to other targets, and where they didn't even bother to discuss anything related to the async API with anyone except the Silicon Labs.

Absolutely Erik, but ST do nothing to correct their bugs, only add more platforms with the same bugs and completely ignore any related questions. But they will only damage their reputation by doing so. Freescale where have they gone? KL43 halve finished over a year ago, nothing.

I do not believe Mbed and the community exists as it was any more for the moment, maybe that will change.

I can't think of an MCU vendor that does not have an ARM core in their line up, So from a commercial point why bother with Mbed anyway.

BTW I'm going to this:

http://www.hitexarmconference.co.uk/?utm_source=Hitex%20UK%20Ltd&utm_medium=email&utm_campaign=6069884_ARM%20conf%202015%20blast%201&utm_content=agenda&dm_i=4PZ,3M3JW,EDCP4O,DA6RM,1#!visiting/cp0e

I will pump Hugo for some answers.

Paul - since the barebones board doesn't use the on board regulator, is the low pass filter used on the teensy between Vout and VDDA really necessary? Do you just use 100 nF decoupling caps for each of the VDD pins?

Couldn't an OpenOCD SWD interface like an STlink be used to program the barebones board?

Here's another Teensy 3.1 DMA example that uses DMA to send sine wave values to DAC timed by PDB.

https://developer.mbed.org/users/manitou/code/teensy_dma_dac/

Paul, I couldn't find DMAMUX def's in MK20DX256.h, e.g., #define DMAMUX_SOURCE_PDB 48

For teensyduino, these are defined in https://github.com/PaulStoffregen/cores/blob/master/teensy3/kinetis.h

(ref manual Table 3-18)

They are manually defined by the guy who wrote the Teensyduino stuff though. Within mbed while you could in principle add them, it falls a bit outside the scope of the main mbed library (since DMA isn't used there, and it isn't defined in the CMSIS files supplied by the vendor).

For mbed this is probably more something for a user library, for example one I made for DMA which supports a few targets: https://developer.mbed.org/users/Sissors/code/SimpleDMA/ (If you want you are more than welcome to make a Teensy addition for it and create a pull request of course).

In general I don't think a generic DMA class for mbed would be a bad idea, but thats something mbed staff would have to add, and I don't see it happening.

Yes pretty much Nick, you can use the internal MCU 3.3v regulator depending on what you want to do. If your looking for very low energy use, an external low IQ LDO regulator is the way to go. I found the MCU regulator is not that efficient in practice so I go the external regulator route. As per the schematic decouple your supply pins as close to the MCU as possible with 100nF capacitors. You should achieve around 6uA in deep sleep including the LDO regulator. That makes this MCU rather good for low energy use but with good performance when you need it.

The KL25 MCU is a good all-rounder for very low energy use (That goes down to 3.5uA in deep sleep), but of course does not that K20 performance. You can very easily use the FRDM board to program your prototype board with this.

Programming... That is one of the problems with all Targets on Mbed, but not unique to Mbed. In general you can use the Platform board to 'jump' your code onto a prototype board, that is what I have been doing in the past. This works well until you want to program a variant of that Target. The interface software will connect to the MCU and interrogate the MCU type number, no match, no programming. The main reason is the interface firmware needs to know the size of the flash area and where to start loading the user code, other things as well. This in itself is no major problem, there is a cmsis-dap and MSD utility on Mbed. The major problem is it is based on using Keil with some middleware. This middleware comes with the 'Pro' version of Keil and the biggest problem is more than £5000 to buy a licence. So the next best overall option was to go down the route of using the Segger Flasher Portable. This is cheaper than the Flasher pro but does what you need to directly program ANY ARM core MCU (That is Cotex M series) without the need of the interface MCU.

The other far cheaper alternative is to get another Teensy3.1, carefully remove the K20DX256 MCU (hot air or IR soldering required) and use fine wires to connect the programing pins to the header pins. That will give you a Teensy3.1 or if you like MK20DX256VLH7 type MCU programmer using the Teensy loader. I did think about that but I drink too much beer that makes my hands shake too much :) However I believe that PJRC are looking to make that very thing if you check their Teensy3.2 forum.

Sounds a bit like the "Sy" board from the "Teen" and "Sy" (split teensy) project.

Team,

I recently decided to switch to mbed, instead of arduino framework. I'm using platformio to maintain my toolchain and use atom and eclipse as my IDE. But, as with any new project, I had to stuck at the simplest "Hello World" issue. So let me explain my issue here. I'm trying to run the example that comes with platformio at path

platformio-develop/examples/mbed/mbed-blink

I've commented out all other platforms in platform.ini file other than this little piece:

# Teensy Platform
[env:teensy31]
platform = teensy
framework = mbed
board = teensy31

I'm able to successfully execute "platformio run target upload" command with the following output

[Mon Nov 16 22:57:09 2015] Processing teensy31 (platform: teensy, board: teensy31, framework: mbed)
---------------------------------------------------------------------------------------------------------------------------------------------------
"~/.platformio/packages/tool-teensy/teensy_loader_cli" -mmcu=mk20dx256 -w -s -v .pioenvs/teensy31/firmware.hex
Teensy Loader, Command Line, Version 2.0
Read ".pioenvs/teensy31/firmware.hex": 9544 bytes, 3.6% usage
Soft reboot is not implemented for OSX
Waiting for Teensy device...
(hint: press the reset button)
Found HalfKay Bootloader
Read ".pioenvs/teensy31/firmware.hex": 9544 bytes, 3.6% usage
Programming..........
Booting
=========================================================== [SUCCESS] Took 3.07 seconds ===========================================================

And here is my classic problem ... Nothing happens on the teensy board. I should get but-in LED blinking, but to my disappointment (or rather frustration) there's no blinky. I'm assuming that I'm missing a little piece somewhere, and if I'm able to get it through, I'll be able to move forward.

And my Teensy is 3.1 running on 96MHz, the default as it shipped, and I did not change the clock. I'm still be able to use this same chip using Arduino and Teensyduino combination. I'm in fact able to execute the avr-based code using platformio config

# Teensy Platform
[env:teensy31]
platform = teensy
framework = arduino
board = teensy31

But I want to move out of avr and into mbed. Anyone has any idea what might be the missing point here. Thanks in advance.

Shine On!

I am not familiar with using Eclipse, how did you set up the Eclipse mbed project? If you try using the mbed online compiler, does it work with that hex file? Also make sure you at least got latest mbed lib version, there has been a bug in the clock settings in earlier versions.

I have a Teensy 3.1 never tested....this is a reason to do it.
Compilation with the online compiler: no problem . It is a blinky program with a faster frequency , compared to the original Teensy blink. (with update mbed lid and USBDevice
Loader : download from the pjrc website: the 64bits linux loader and the udev file
The instructions from the mbed website are pretty clear: success (congratulation for the team ! ) The first time I did not read the instructions and the Teensy did nothing. My teensy blinks now with the new frequency.

Now off-line because I work always offline with the gcc-arm and a editor (Scite) - no Eclipse !
Back to the online compiler to export the project .
I change the frequency, compile and build...a lot of warning for unused parameters.
Back to the Teensy loader and it is blinking at the intended frequency
Everything is ok , the serial output on the terminal too!

Thanks Eric & Robert!

As mentioned, I'm using platformio and they make using eclipse much easier. All you need is a CDT plugin and use platformio init command to start your project. platformio also helps maintain the latest libraries, frameworks and platforms, so I'm on the latest version of all of these.

I'll try to use the online compiler for mbed along with the other steps Robert mentioned, and will let you know if it works. I'm pretty sure that the code/examples in fact work, it's just that I'm not able to make them work for me.

Alright, I figured out the issue. I guess the problem exist with platformio setup. I'm able to compile online and the generated hex file works fine. But when I try to get it done with platformio, the resulting hex file, although compiled without error, does not work on teensy after uploading.

I'll look into it with a little more detail later and try to find what might be the broken issue there. But I wanted to thank you awesome people to help me out. At least I have a starting point to move away from arduino frameworks.

Dear Mercury Waters,

I'm an author of PlatformIO. Don't forget to inform PlatformIO team with the similar issues using https://github.com/platformio/platformio/issues

--

As for the your issue with Blink example. I have Teensy 3.1 and I've just re-tested this example and my Teensy blinks as supposed. See output:

$ platformio run --project-dir examples/mbed/mbed-blink -e teensy31 -t upload
[Wed Nov 18 15:07:43 2015] Processing teensy31 (platform: teensy, board: teensy31, framework: mbed)
----------------------------------------------------------------------------------------------------------------------------------------------------------------
arm-none-eabi-g++ -o .pioenvs/teensy31/src/main.o -c -std=gnu++98 -fno-rtti -fdata-sections -ffunction-sections -Wno-unused-parameter -fno-exceptions -Wextra -fno-delete-null-pointer-checks -fmessage-length=0 -mthumb -Wno-missing-field-initializers -c -fno-builtin -O2 -fomit-frame-pointer -Wall -MMD -mcpu=cortex-m4 -DTARGET_TEENSY3_1 -DTOOLCHAIN_GCC_ARM -DTOOLCHAIN_GCC -DMBED_BUILD_TIMESTAMP=1441271832.77 -DTARGET_K20DX256 -DTARGET_CORTEX_M -DTARGET_Freescale -DTARGET_M4 -D__MBED__=1 -D__CORTEX_M4 -DARM_MATH_CM4 -DTARGET_K20XX -D__MK20DX256__ -DPLATFORMIO=020400 -I.pioenvs/teensy31/FrameworkMbedInc248832578 -I.pioenvs/teensy31/FrameworkMbedInc-213564679 -I.pioenvs/teensy31/FrameworkMbedInc-250686161 -I.pioenvs/teensy31/FrameworkMbedInc-1845648957 -I.pioenvs/teensy31/FrameworkMbedInc-666725808 -I.pioenvs/teensy31/FrameworkMbedInc357213333 -I.pioenvs/teensy31/FrameworkMbedInc1049033388 -I.pioenvs/teensy31/FrameworkMbedInc-194069199 src/main.cpp
arm-none-eabi-ar rcs .pioenvs/teensy31/libFrameworkMbed.a /Users/ikravets/.platformio/packages/framework-mbed/variant/TEENSY3_1/mbed/TARGET_TEENSY3_1/TOOLCHAIN_GCC_ARM/cmsis_nvic.o /Users/ikravets/.platformio/packages/framework-mbed/variant/TEENSY3_1/mbed/TARGET_TEENSY3_1/TOOLCHAIN_GCC_ARM/startup_MK20DX256.o /Users/ikravets/.platformio/packages/framework-mbed/variant/TEENSY3_1/mbed/TARGET_TEENSY3_1/TOOLCHAIN_GCC_ARM/retarget.o /Users/ikravets/.platformio/packages/framework-mbed/variant/TEENSY3_1/mbed/TARGET_TEENSY3_1/TOOLCHAIN_GCC_ARM/board.o /Users/ikravets/.platformio/packages/framework-mbed/variant/TEENSY3_1/mbed/TARGET_TEENSY3_1/TOOLCHAIN_GCC_ARM/system_MK20DX256.o
arm-none-eabi-ranlib .pioenvs/teensy31/libFrameworkMbed.a
arm-none-eabi-g++ -o .pioenvs/teensy31/firmware.elf -Wl,--gc-sections -Wl,--wrap,main -mcpu=cortex-m4 -mthumb --specs=nano.specs -Wl,-T /Users/ikravets/.platformio/packages/framework-mbed/variant/TEENSY3_1/mbed/TARGET_TEENSY3_1/TOOLCHAIN_GCC_ARM/MK20DX256.ld .pioenvs/teensy31/src/main.o -L/Users/ikravets/.platformio/packages/framework-mbed/variant/TEENSY3_1/mbed/TARGET_TEENSY3_1/TOOLCHAIN_GCC_ARM -L.pioenvs/teensy31 -Wl,--start-group -lc -lgcc -lm -lstdc++ -lsupc++ -lnosys -lmbed -lc -lgcc .pioenvs/teensy31/libFrameworkMbed.a -Wl,--end-group
arm-none-eabi-objcopy -O ihex -R .eeprom .pioenvs/teensy31/firmware.elf .pioenvs/teensy31/firmware.hex
"/Users/ikravets/.platformio/packages/tool-teensy/teensy_loader_cli" -mmcu=mk20dx256 -w -s -v .pioenvs/teensy31/firmware.hex
Teensy Loader, Command Line, Version 2.0
Read ".pioenvs/teensy31/firmware.hex": 9544 bytes, 3.6% usage
Soft reboot is not implemented for OSX
Waiting for Teensy device...
(hint: press the reset button)
Found HalfKay Bootloader
Read ".pioenvs/teensy31/firmware.hex": 9544 bytes, 3.6% usage
Programming..........
Booting
================================================================= [SUCCESS] Took 5.79 seconds =================================================================

Please follow these steps:

1. Upgrade PlatformIO to the latest version via `platformio upgrade` command
2. Update all PlatformIO packages via `platformio update` command
3. Download PlatformIO source code with examples via https://github.com/platformio/platformio/archive/develop.zip
4. Go to `platformio/examples/mbed/mbed-blink` and run `platformio run -e teensy31 -t upload`

Thanks a lot that using PlatformIO!

Regards, Ivan Kravets

Hi Ivan,

First of all, thanks for making such an awesome toolchain management system. I'm very sure that there is something wrong on my end. Primarily, because I repeated the steps your mentioned (on a fresh directory) and still don't get my blinky running. The code compiles without any error or warning, but my teensy 3.1 does not work. However, if I put that code on online bed compiler, and then load the hex, I get it running perfectly fine.

On the relevant note, I'm using Mac OS X Yosemite and probably it has to do with this specific platform. In order to narrow down the issue, I'll try to get Mint and Debian Linux installed tonight and setup platformio on those and try to re-produce the issue. To further investigate I'll also try to get it compiled with gcc-arm compiler and see what I get from there. I'll share my findings here.

And I really really appreciate all of you people for taking the time, and helping me out here. If anyone of you happen to be in Silicon Valley, or plan to visit, I owe you a drink or two of Scotch or Bourbon, for that matter.

Shine On!