(Question) zephyr support for teensy.3.x ?

BeinerF

Member
Hi,

I did a little bit of reading regarding the very fast evolving mini-RTOS ZEPHYR( https://www.zephyrproject.org/ ) - project.

I was just wondering if already somebody is making an attempt to get teensy 3-x support sorted.

Or am I missing anything that would make this impossible ?

Cheers
 
Apparently, they don’t offer Teensy support yet
This is why I was asking this, at least I think, reasonable question, if somebody here made an attempt to get support. (I don't expect anybody to do it.)


But if you really need to use their RTOS..
I don't have an urgent need at all. I am just curious, as zephyr seems to gain traction.

However, my main question is, if there is anything that speaks against it from a technical point of view.
 
I'm curious to hear from anyone who's actually used Zephyr for real projects. Likewise for Cayenne.

These folks know how to make a slick sales pitch. But do they really deliver a useful system? Do things boring bread-and-butter features like Serial, SPI, I2C work reliably? Do they perform well when combined with other stuff? Do LED libraries work? Can you drive WS2812 LEDs without blocking other stuff? Is the USB well supported, and does it perform well when you use the other stuff?
 
This makes for an interesting read (however from a year ago 2017/01/22): THIS

It looks Zephyr still has a long way to go, but the direction *could* be promising (considering all the marketing removed). Right now it is more like an incomplete FreeRTOS copy with some drivers.
 
A small update on this.
I have been working on a project using Zephyr on the FRDM-K64F development board. The project will entail multiple UARTs, SPI for an 802.14.5 radio, I2C for FRAM, RTC, ATEC608A Crypto chip, and an AT24MAC602.

I chose Zephyr (after trying at least 5 other platforms), because it came with a full IPV4/IPV6 network stack (client/server, DHCP, SNTP, PING, IPVv6 autoconfig), supported OpenThread (which is what I am going to do with the radio), and contains built in USB modules (including CDC-ECM which I want).

I have done enough experimenting to know that all of those things are going to work under Zephyr. So I believe I have committed. Zephyr certainly takes some time to understand, and can be a configuration nightmare until you are comfortable with it.
My same application can be compiled to run on the FRDM-K64, FRDM-K41Z, NRF52840, and now:
Teensy 3.5 and Teensy 3.6.

Zephyr uses the concept of 'Boards' that define the MCU, the connected pins, and what device drivers are required. For the MK6x series, it uses the HAL from the MCUXpresso SDK (it looks like v1, but could be v2)..in any event, you really don't need to worry about that. Just that I haven't found a module on the MK6x that zephyr doesn't support.

I decided to move away from the FRDM-K64F, because of it's limiting ability to connect I/O, with only an Arduino style connector with fixed pin placements.
Moving to Teensy was a no brainer, completely configurable but lacking the I/O to attach to. So I designed a 'carrier' board that would allow me to add all of the additional hardware I wanted/needed. I am calling it 'Teensy Explorer'.

The board includes a slot to plug in the Teensy, 4 Mikro-Bus 'Click' sockets (hundreds of devices), a socket for the upcoming ETH PHY board, optional power inputs and regulation, outputs for all 5 UARTs. You can 'stuff' the board with whatever features you need, with the bare minimum being the sockets for the Teensy, and a couple of sockets for click boards.

I should have the new board back from OshPark tomorrow (I already know of a couple of bugs), and I will post updates...

...but Zephyr 2.2 is running on both Teensy 3.5/3.6 models. Screenshot_3.png
 
thx for the update @marketideas . that is awesome. if you have a minute , it would be amazing if you could write down a couple of bullet points, how you proceeded and succeeded. would be much appreciated. Cheers
 
I started a basic approach to add TEENSY4.x board support to zephyr project. Code can be found here:
https://github.com/bdkrae/zephyr/tree/teensy4-branch/boards/arm/teensy4

For the moment it has the drawback of needing a supplement to the nxp_hal to work:
https://github.com/bdkrae/hal_nxp/tree/teensy4-branch

Board version 4.0 is in early testing but expected to work, e.g. with the blinky sample. I also managed to catch the console output via USB, example code will follow.
Board version 4.1 is not tested as I am waiting for my 4.1 hardware.

Contributors would be welcome as there is some way to go before placing a pull request. E.g. check...
- Ethernet
- USB OTG
- SD card
- SPI/CAN/PWM/...
- optional Flash/RAM on the 4.1

As @marketideas stated its a mess to get started with zephyr. But at least it seems to provide good performance and small footprint. Worth to have a look at it...
 
Last edited:
@ufechner relating your issue at zephyr project I would not be very confident that someone at the zephyr´s team will do the work for us. But I did some steps regarding my approach stated above and planning to place a pull request somewhere at end of next week.

nxp_hal issue
solved, see here. That means you can just take the teensy4-folder from my zephyr-clone, place it at the correct place in your local zephyr installation and you should be ready to go.

Ethernet
In progress, my hardware to check is on the way.

SD card
Working with some drawbacks due to missing card voltage switch ability and detection switch, details will follow.

SPI/CAN/PWM
As teensy provides no board specific hardware related to this peripherals I think we can skip testing this.

optional Flash/RAM on 4.1
I am not planning to test this before stating the pull request. Maybe someone is interested to do so.

USB OTG /USB host
OTG is working already, host is open. Does zephyr actually provide support for usb host functions?

GPIO issue
Controlling internal pullups/pulldowns for gpios seems not to work currently. As a workaround external resistors must be used.

As promised I started an example application located here. Readme will follow. Maybe someone can check it an give some feedback.
 
Last edited:
@bdkrae I copied your reply to the github issue. I think github is indeed a better place to discuss the progress. Even if nobody of the Zephr developers helps directly, they still might give hints how to achieve a good quality.
 
Back
Top