Forum Rule: Always post complete source code & details to reproduce any issue!
Teensy 3.5 / 3.6 Ethernet / mbed
Will there mbed support for the new teensy boards, like for 3.1 / 3.2 ? I like the mbed platform more then the arduino platform,
because of RTOS and Ethernet functionality and its object orientated libraries. The Freescale K66 is supported. I use PlatformIO .
When you make Ethernet support for the Arduino Platform can you make a PlaceIn Library, so that we can use the same code like with the
library for the Wiznet Ethernershields. Also Multicast support is very important for me to code lighting protocols like sACN.
I think the Teensy 3.5 / 3.6 will get the grandmaster for the arduino community.
Thanks for your great work and greetings form germany
+1. This 3.6 should be a nice mbed development board.
+1 I'm also interested in some sort of RTOS w/ threading and using platformIO
I wonder if it's hard because the HalfKay protocol isn't the normal mbed protocol? I have no idea. If that's the case though, it seems better to simply say, nope, sorry not going to support it.
However I do see Teensy 3.1 supported in mbed, so it makes me curious and wonder what the details are.
Alternative mbed enabled boards: (not to be mean... simply copying notes in case someone feels an urgent need to get an mbed enabled board.. then just go buy one rather than making noises)
https://developer.mbed.org/platforms/ST-Nucleo-F746ZG/ STM32F746ZGT6 216MHz
https://developer.mbed.org/platforms/ST-Nucleo-F429ZI/ STM32F429ZIT6 180MHz
https://developer.mbed.org/platforms/ST-Nucleo-L476RG/ STM32L476RGT6 80MHz
Last edited by awef; 03-15-2017 at 03:26 PM.
The Teensy 3.5 (based on the Kinetis K64), uses the same microcontroller as the NXP/Freescale FRDM-K64F dev board which is supported by MBED directly.
An early prototype of a product that my group is working on tried MBED as one of several RTOS solutions, so I know that MBED supports the FRDM board out of the box. I would guess that you would be able to use it with the Teensy 3.5 with minimal modification: The FRDM has an SDcard slot, an accelerometer, and some other peripherals that the Teensy 3.5 does not have, so it may be necessary to disable peripheral devices to get MBED going on a Teensy.
The Teensy 3.6 may be supported, though I have not checked in the last year or so.
We settled on using uTasker as an RTOS though it presents its own set of challenges, and costs (a small amount of) money to use in a product.
Ah that's pretty interesting. I was looking at the same to use the FRDM board settings for the Teensy 3.5.
I was under the impression that mbed had a file system (like teensy 35), some CMSIS DAP debugger thing (breakpoint/code upload facility) and that HalfKay would not support that.
Is my impression wrong? Clearly I don't know the details and am just getting to know this part of the ecosystem.
Is HalfKay just a way of delivering the mbed interface that mbed needs?
(As for the board differences/accessories, no biggie, that I can probably figure out)
The FRDM board has a structure similar to Teensy: The processor that we all use, write programs for and has the peripherals (accel, etc.), is the K64. Both Teensy and thhe FRDM have an additional processor to support downloading those programs and to support the "unbrickability" that is the hallmark of Paul's Teensy.
The support processor in the Teensy (MKL-02), when triggered by the program button, uses the SWD (serial wire debug) facility in the main processor to load a bootloader into the main processor's RAM. That bootloader then takes control of the main processor to allow it to accept flash images from the host.
The FRDM board's support processor remains connected to its USB port at all times, and provides CMSIS-DAP, and a virtual serial port, and a virtual USB storage partition. The host computer can load a new flash image into the K64 by opening and writing a file with the ".bin" extension to the virtual filesystem provided by the support processor. The act of writing data to that "file" causes the support processor to use the SWD facility in the K64 to program its flash.
Te FRDM connects a UART on the support processor to a UART on the K64, and when the host interacts with the abstract communication model "serial" port provided by the support processor, it tunnels the bytes to and from the main processor.
Finally, the support processor supports CMSIS-DAP debug protocol for the classical debugging that are often required to get past knotty problems in the application.
We have been developing a pretty serious distributed industrial data acquisition/control system using FRDM boards for prototyping, and it's been reliable, powerful and convenient. I use Teensys as ultra-programmable signal generators, and general support.
... If only the Teensy 3.5/3.6 and Ethernet were available when were starting development...
Aha! Okay this totally makes sense (only had to read it a few times).
Originally Posted by LenSamuelson
So this bootloader I suppose accepts data in the HalfKay format? https://www.pjrc.com/teensy/halfkay_protocol.html
Surely not every mbed board has a different upload protocol right? That would sound crazy. Surely there's some standard mbed upload protocol? ... That mbed upload protocol... is not HalfKay? I think at this point, it would be "almost crazy" to bother trying to wedge a Teensy into the mbed framework.
What I find so interesting is that the Teensy 3.1 is supported by mbed, yet I don't see any custom HalfKay upload code in mbed-os. Is there some other magic that I missed while browsing the mbed-os code?
There are multiple variations on three common themes, so it's a bit confusing at the beginning.
1) PJRC: Support processor sets up a RAM-executing bootloader to accept images over USB using HalfKay;
2) FRDM (and some others): Support processor always available, accepts images either using USB storage file-writing or CMSIS-DAP;
3) Classical debugger providers (Keil, PEMicro, etc) where a debug dongle uses JTAG or SWD to program flash.
First answer: Yes, Paul's bootloader accepts data using the HalfKay protocol. Supporting that, Paul wrote and maintains the graphical Teensy loader, and there is an additional CLI loader that he wrote and is maintained by the forum community. Both forms of Teensy loader accept images in "hex format", then use Paul's HalfKay protocol to transfer the data to the RAM-based bootloader to program the main processor's flash. This structure applies to every Teensy 3.x.
Next answer: Most people don't think of the world has having "mbed boards", but rather boards/processors that are supported by the MBED programming/RTOS environment. The reason that's important is that there are many ways to load images into boards. The Teensy loader that Paul wrote for the Teensy 3.x is one supporting program that allows images to be programmed into Teensys no matter how they were compiled. (I have implemented Teensy images using MBED, uTasker and TeensyDuino, compiled with a variety of toolkits but always loaded into Teensy boards using the Teensy loader.)
Third answer: You haven't missed any magic other than the amazing creativity manufacturers have in defining how images get programmed into their boards. :-)
Some boards supported by MBED are programmed using the method described for the FRDM boards, where a support processor acts like a USB storage partition, and the protocol for for loading images into those boards is the "copy imagexx.bin to frdmdrive:" trick described above.
Other boards are programmed using debug dongles connected to the board's debug headers. (PEMicro, Keil, others using protocols like JTAG, SWD, and even CMSIS-DAP, etc.)
Oooooh.... I get it.
Although clearly I should have been able to get it without your explicit description, it certainly helped. Thanks!
So basically, somehow make a hex file and stick it in via [Your Choice]
Okay I get it. So bascically, someone needs to spend a bunch of time setting up header/support files in mbed before it can target the Teensy 3.5 for example.
That someone is not me today. Maybe me another day.
I gotta say though, uploading via Halfkay USB is a complete joy compared to uploading via 115k serial. Maybe if I can figure out how to get some RTOS into the Arduino environment then I'll be set? Or maybe if I can otherwise find another way to make gcc-arm punch out a binary, then I might be in business.
I'll check out that uTasker thing as well.
Got a bunch of stuff I need to learn.
I just spent a few hours trying to upgrade the mbed profile for the another board... it's... really... making me wonder if it's worth the time.
I think I'm beginning to see the picture. No wonder not many boards bother to build a profile. And all the glue code makes for enough brittleness that maintenance becomes a giant chore (especially if there's yet another MCU based API/SDK to keep mbed in sync with)
Many of these environments (MBED, uTasker, MQX, etc.) depend on the developer spending a fair amount of time to learn their inner workings, which I'm guessing is what informs your last comment. It is rare for an environment to be so complete that one can get some basic work going without getting a Master's Degree in the pecularities of the environment. Until recently, industrial strength applications in the embedded world needed to extract the maximum possible performance from barely adequately resourced hardware. The result is lots of heavy lifting to get the job done, and the effort needed to "hook into" the development package did not dominate the overall project effort.
Microcontrollers based on modern processor cores like the ARM Cortex M and modern compilers have become powerful enough that it's possible to build somewhat "generic" development environments that allow developers to to interesting work without needing to get so deeply into the system.
Paul's work and the work of the Arduino folks is a good example of the rare development environment that is complete enough and whose behavior is predictable enough that people who are not genius level experts can have success with prototype applications reasonably quickly, then allow the projects to really take off with some experience. Note that even in this case the libraries are pretty well tuned for Paul's boards, and there was a fair amount of work involved in updating the infrastructure for the Teensy 3.5 and Teensy 3.6.
At my day job, the project we are implementing is an example of extracting the very last bit of performance out of the hardware in a demanding and harsh environment, so we've been able to justify getting into one such system. It still had its challenges. When I do small projects at home, I stick with the PJRC environment with just enough customization to work the way I do (normal editor, makefiles instead of the default IDE; that's not too hard for me, since I've been developing with makefiles for about 30 years...). Unless you have some particularly heavy duty requirements, it probably makes sense to stay with what works well, and the Teensy environment works well.
Thanks for all that insight. All too true!
I was able to pull the `cores` repo @ https://github.com/PaulStoffregen/cores and use the Makefile to pump out a hex file. I think simply being out of the Arduino IDE is enough to keep me happy. Everything else seems like "normal C programming" from here.
Would definitely be cool to get more integration with the Kinetis SDK so we can dig in deeper. I'm sure it's just a matter of banging on options until the compiler is happy.