Zephyr (?)

Status
Not open for further replies.

markonian

Well-known member
Thanks to Four Short Links, I found out about the Zephyr Project.

I'm passing on this information because it could be of interest to some Teensy 3 (and above?) users. I have no connection to Zephyr. I would not have posted this information if Zephyr were not backed by the Linux Foundation.

Since Zephyr doesn't support Teensy 3.x (yet), this is just F.Y.I. and something to possibly keep an eye on.
 
Thanks to Four Short Links, I found out about the Zephyr Project.

I'm passing on this information because it could be of interest to some Teensy 3 (and above?) users. I have no connection to Zephyr. I would not have posted this information if Zephyr were not backed by the Linux Foundation.

Since Zephyr doesn't support Teensy 3.x (yet), this is just F.Y.I. and something to possibly keep an eye on.

Looks interesting....but also a little risky...on the right projects it might be a nice plan.

I'm pessimistic.

My java-based blu ray player takes 30 seconds to load a disc or eject. This is (in my opinion) a by product of adding a complex OS to what should be nothing more than an embedded device.

Conversely my old dvd player from 2003 does the same thing in a second or two. Both do the same job. (insert disc, show menu, play movie). I don't use any extra features of blu ray so i just suffer at the sluggish hands of java and its bloatware.

Is a lightweight embedded platform really the right target for an OS kernel? maybe in some cases.....

my gut feeling is OS kernels (no matter how lightweight) really don't belong in a land of such limited resource.

I also remember trying to run DOS games from windows 3.1.....
 
The question....

I also remember trying to run DOS games from windows 3.1.....
Dat timer interrupt....
rage-face.jpg

For the sake of this discussion: here are my applications...
  • STM32F4: A high-bandwidth, latency-sensitive, open-source motion-capture glove.
  • Teensy3.1: An audio device with shallower demands of the HARDWARE specificity, but very STRICT demands on the interoperability of various special-purpose libraries (Paul's Audio, a few AdaFruit drivers, SdFAT, and Teensyduino itself).
  • Teensy3.1 / RasPi-Linux / Fubarino Mini: A general-purpose gesture controller that may or may not need threads, depending on platform. Low bandwidth.

...and numerous other things I haven't published (bluetooth beacons, geiger counters, power-suppies, etc).

...on the right projects it might be a nice plan. I'm pessimistic.
Before I bore you with a case-study, know that I share your pessimism. If all you need to do is turn off a light switch given the value from a CdS cell, anything resembling an OS is taking the NASA Route. If we're going to go so far as introducing threads, I would be even more pessimistic. With no MMU and the very serious concurrency considerations thereby introduced, I would argue very strongly against threads for any application that didn't need sub-millisecond response times in the midst of heavy CPU usage. Most of the threaded code I've seen in embedded land is only present as a means of avoiding writing a proper hardware-specific ISR. Essentially: polling done dishonestly.

In such tight spaces, we can ill-afford to leverage the immutable-types and recursion that the "big-platform" functional guys seem to have recetly discovered, nor the garbage-collection and soft-types that they take for granted. And the complexity of good concurrency-control is not worth an afternoon's laziness about writing a platform-specific ISR.

..my gut feeling is OS kernels (no matter how lightweight) really don't belong in a land of such limited resource.
But for those times when they DO, I have to confess... I'm *really* tired of writing the same sort-of code over-and-over again. For anything more complex than a simple sketch or one-off project, a good programmer will find himself implementing a work-queue (or something that is in-substance equivalent).

Moreover, if I want to port the Audio library to PIC32, I don't want to also be required to port DMA drivers for the SPI subsystem if all I care about is a variable filter. So as someone who (I think?) shares your anathema for unnecessary complexity, I submit: This discussion might be best-viewed as a serparation of functional responsibilities in code, and (by extension) between personages and institutions.

It would be nice to be able to better-levarage not only other-people's code, but also my own under different circumstances. And also to limit the burden for those of us that (say) maintain a sensor driver in places where there is no common API or access paradigm. Or who find themselves on the unfavorable-side of the design choices made by another (differently-constrained and/or less-competent) engineer.

I wrote ManuvrOS to solve these problems. The same ones that Zephyr is also trying to solve, with the exception that my stuff doesn't imply a threading model. In this regard, it bears more structural resemblance to Contiki.

This started because I wanted to use the same i2c code on a Teensy as well as a linux environment. And that meant wrapping it. And that meant using the same API to deal with (no-threads + ISR), as well as (under some sort of a threading model [on linux, where no hardware ISR is accessible]). If threading is desired, ManuvrOS uses FreeRTOS in small-spaces, and pthreads on linux.

ManuvrOS is a work of evolution. And it shows. I've been slowely re-working pieces of it for the sake of portability. But I have to ask an honest question of myself: Is it worth it to burn so much time doing the same things as everyone else (porting the INA219 driver to their particular situation), or would it be better to translate the things I've done that are uniquely-useful into a form that others can use in a wider range of projects (and vice-versa)?

While I contemplate that, I created an account at the Linux Foundation.

Having just taken the position as the principle firmware engineer at a large telecom (which is genuinely embracing open-source), I think it also worth saying that I have no ego about my code. IDGAF if the winning design is my own. But the thing that I *really* don't want is to see the IoT realm being dominated by closed/crap/incompatible corporate offerings because -despite its inherrent-bias towards meritocracy, its diversity-of-thought, and its FAR superior manpower- the open-source world is too balkanized to keep pace.

Zephyr already has support for a closely-related microcontroller. Most of the porting effort would be in the libraries, and not in the hardware-layer. The release-candidate for Digitabulum needs support for the STM32F746, and I'm sick of fighting FreeRTOS support on PIC32 (not my primary platform). From where I sit, Zephry appears to me to be an excellent pattern to start conforming to, as those of us who are serious and make a living off this stuff have long-since grown out of the intolerably-interwoven and brain-damaged build system of Arduino, as well as it's limiting API.

I will be watching this thread closely for the next several weeks to see what others think. The discussion held here might determine how you turn on your light bulbs in a few years, as these are the choices before us today.
 
setting up a development environment for Zephry, based on the instructions (no Windows version), is more of a career than an easy to use tool!
Then to target an ARM MCU and do debug, more tall walls.
 
I'm amused by "level 60 mage". ;)
Thanks for Teensy3, Paul. You've leveled many other mages. :-D

setting up a development environment for Zephry, based on the instructions (no Windows version), is more of a career than an easy to use tool!
I wouldn't argue with that. You're probably right. But I don't use Windows, nor do I care about supporting it. You are in open-source land, my friend. :)

FWIW, I want to start using PlatformIO. And it appears that they might care about Windows enough to do something about it. That is where I will start concentrating my efforts. Zephyr or not.
http://platformio.org/

If you like, I will help you learn enough linux (in a separate thread) to make better use of your time in that world.
I can't really help too much with OSX, but at least it is built on a *nix foundation with all of the concomitant knowledge and best-practices that are concentrated there.

Then to target an ARM MCU and do debug, more tall walls.
Now this I can help with.
What are your targets?

I've written lots of bare-metal support for ARM-based micros. My immediate targets would be...
* STM32F407/417
* STM32F746/756
* mk20dx256/128 (Teensy3.x)
* RasPi (all models)

Less XP in this skill-tree. But enough to make progress and inflict only *some* collateral damage. :)
* PIC32MX2xx/3xx
* PIC32MZ

Much of this support already exists in PlatformIO. But I'm unsure as to the extent.

I have a sprint to finish at work this coming week. But the week after that, I will be digging in hard.
 
I know Linux very well. And worked with System V way back, and Sun OS for years, and so on. And DEC's flavors. And VMS, and on and on.
Windows -well, my day job (embedded firmware developer), I choose to use Windows because of the great IDEs for C/C++.
have Mint installed on a disk in this PC, but I rarely use it.
Just preference! I need to spend as little time struggling with tools as possible - just use 'em. Tool struggle-time is essentially unbillable.
Last 1+ years, my work is mostly for STM32F415 and others in that family. Customer likes ST as do I, and the current project has two MCUs on the flex PCB (1mm thick), working with die, not packaged ICs.
Plus Python with Qt Designer for the host side of the system - so that the code AND the GUI move between Windows x, Linux and Mac OS with ease.
I play with RPis (have an RPi Zero), mostly Python too, for rapid apps for hobby stuff. Not doing products.
So, we all do our thing for our own reasons :eek:
 
Last edited:
...the current project has two MCUs on the flex PCB...

Those are fairly large microcontrollers...
Might I know your opinions on any of the following things, as a data-point?
  • FreeRTOS (or any other RTOS's you've crossed paths with)
  • Threading or not
  • Cross-usage of code/libraries between projects, especially between microcontrolers
  • PlatformIO
?

FWIW, I don't use IDE's because I don't like fighting my tools either. I use text-editors. The biggest value I see in PlatformIO pertains to the library manager. The fact that it has an Atom plugin essentially turns my text-editor into an IDE of-sorts. But I'm not inclined to see that as valuable for its own sake.
 
Last edited:
Those are fairly large microcontrollers...
Might I know your opinions on any of the following things, as a data-point?
  • FreeRTOS (or any other RTOS's you've crossed paths with)
  • Threading or not
  • Cross-usage of code/libraries between projects, especially between microcontrolers
  • PlatformIO
?

FWIW, I don't use IDE's because I don't like fighting my tools either. I use text-editors. The biggest value I see in PlatformIO pertains to the library manager. The fact that it has an Atom plugin essentially turns my text-editor into an IDE of-sorts. But I'm not inclined to see that as valuable for its own sake.

Opinion. Oh no, Mr. Bill.
FreeRTOS - I've used it quite a bit. Mostly configured for non-preemptive scheduling to simplify.
Threading and tasking (same). For me, I normally use multiple state machines instead of threads/tasking. Simpler. more predictive. Rare is the need for preemption.

I used makefiles for decades but switched to IDEs about 10 years ago. Used Eclipse for most of a year and grew to dislike it. I now use IAR for professional ARM work and for hobby/Teensy it's Visual Micro pluginj for free Visual Studio ... but I use windows because these good IDEs are windows only due to market share and demand. Other tools I use are N/A here on this forum for the Freescale aligned teensy.

Cross usage of libraries... yes, some that are not hardware specific, like FATFS and the like. Freescale and ST have great librarfies that build for all their chips nicely. Esp. ST. But these don't work across CPU types. Arduino and Paul's early work in AvR emulation at the register level via C++ overloading is the only such work I"ve seen.

To much to delve into here. Esp., since this forum is Teensy specific.


j
 
Last edited:
Talk of non-Teensy products and other software systems is perfectly fine, in threads like this which are clearly about those system.

As a general guideline, you should refrain from non-Teensy talk in thread where someone is seeking help with a specific issue or way to do something on Teensy. Of course there are some rare cases where mentioning an alternate approach is a great contribution. But more often than not, bringing up specific technical details for ST or other chips in conversation specifically about how to solve those problems on Freescale's chip or Teensy, and especially without clearly mentioning those details aren't related, well, that just isn't helpful.

So please use good judgment in all cases, and understand that non-Teensy details in the context of a conversation focused on helping someone solve a problem specific to Teensy or Freescale/NXP Kinetis can be not only unhelpful, but sometimes cases me extra work if it starts to lead someone down a fruitless path.

Robin and I have a forum philosophy that can be summed up as "almost anything is better than censorship", so we pretty much never delete stuff. Expect spam. Spam is definitely bad!
 
Status
Not open for further replies.
Back
Top