Are there any plans for QP Zephyr port? The Zephyr project is getting a lot of steam, with even Nordic adopting it as a primary way to program their MCUs. Having the ESP32 port was certainly a great step to cover a huge number of ESP32s in the wild, so maybe Zephyr port should follow.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Aleksa,
Yes, Zephyr Project seems to be pushed hard by the Linux Foundation and WindRiver. But have you tried to actually use it? I'd be interested in your and other experiences.
The one aspect that I find off-putting is the idiosyncratic build process that the Zephyr project imposes. (Why are they in the business of dictating a building process? Every company I know uses their process anyway...)
The project (by its origin) is apparently intended to run on Linux, so on Windows it requires "chocolaty", "ninja", "west", and some other stuff. At the same time, it's unclear whether an how professional tools, such as IAR or ARM/Keil can be used. The usual problem is, of course, debugging... I'm not sure if I want to rely entirely on OpenOCD...
Anyway, perhaps Zephyr is a fine RTOS underneath -- hard do say without dedicating a build machine just to try... But perhaps I'm exaggerating. Therefore I'm curious what the actual users of the RTOS think. Please share your experiences with Zephyr.
--MMS
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, I personally have mixed feelings about it.
Nordic examples where you launch their slightly updated version of Segger Embedded Studio have been positive. Everything builds right away and generally "time to hello world" has been quite short.
Now I still maybe prefer their Nordic SDK, not to be confused with Nordic Connect SDK with Zephyr. That's probably because I'm not very fond of RTOS and the basic SDK is event-driven so it reminds me of QP which spoiled me to some extent.
That being said the build process does look quite complex on the surface and even after watching a dedicated webinar I was left with many questions because it is a very different way of building your project. Also, their decision to only support new BLE features and boards with Connect SDK is kind of questionable but that's for another topic.
I do believe that having a framework/platform that allows you to go a step above the actual hardware and relatively quickly change MCUs/boards is a step in the right direction.
One thing that is troublesome for me now that I have some experience with QP is working with bare RTOS. After you set up a flow where you generate high-level code with QP and use/generate low-level code with maybe CubeMX you are left with writing only middle "glue" code that immensely accelerates development. That's why I think it's important for QP's future to support as many platforms to help with its adoption.
ESP32 port is certainly amazing to see given that it's probably the most important platform in the hobby/maker community but also a lot of companies use that chips for their custom hardware.
As for debugging, it's quite of a challenge even with SES for Nordic boards as the BLE stack doesn't mix nicely with breakpoints so you are going in the wrong direction where you again rely on basically logging what's happening.
That's where QS/QView steps in with the ability to "see" what's going inside of a project much easier and would tremendously help with development.
To finish my point, Nordic chips are really ubiquitous in the BLE space and I think having the ability to use QP with them would be very beneficial for the whole project.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, it's obviously important to support all these different platforms, but it's also tricky to balance the cost of doing this versus other work. Every additional platform requires maintenance (updates, tooling, testing, etc.), which dramatically slows down the pace of innovation.
Perhaps the best solution would be if such adaptations could be provided by the community. For example, by forking the QP/C and/or QP/C++ projects on GitHub. Then a post about such community project(s) could be made in this forum.
--MMS
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
Are there any plans for QP Zephyr port? The Zephyr project is getting a lot of steam, with even Nordic adopting it as a primary way to program their MCUs. Having the ESP32 port was certainly a great step to cover a huge number of ESP32s in the wild, so maybe Zephyr port should follow.
Hi Aleksa,
Yes, Zephyr Project seems to be pushed hard by the Linux Foundation and WindRiver. But have you tried to actually use it? I'd be interested in your and other experiences.
The one aspect that I find off-putting is the idiosyncratic build process that the Zephyr project imposes. (Why are they in the business of dictating a building process? Every company I know uses their process anyway...)
The project (by its origin) is apparently intended to run on Linux, so on Windows it requires "chocolaty", "ninja", "west", and some other stuff. At the same time, it's unclear whether an how professional tools, such as IAR or ARM/Keil can be used. The usual problem is, of course, debugging... I'm not sure if I want to rely entirely on OpenOCD...
Anyway, perhaps Zephyr is a fine RTOS underneath -- hard do say without dedicating a build machine just to try... But perhaps I'm exaggerating. Therefore I'm curious what the actual users of the RTOS think. Please share your experiences with Zephyr.
--MMS
Well, I personally have mixed feelings about it.
Nordic examples where you launch their slightly updated version of Segger Embedded Studio have been positive. Everything builds right away and generally "time to hello world" has been quite short.
Now I still maybe prefer their Nordic SDK, not to be confused with Nordic Connect SDK with Zephyr. That's probably because I'm not very fond of RTOS and the basic SDK is event-driven so it reminds me of QP which spoiled me to some extent.
That being said the build process does look quite complex on the surface and even after watching a dedicated webinar I was left with many questions because it is a very different way of building your project. Also, their decision to only support new BLE features and boards with Connect SDK is kind of questionable but that's for another topic.
I do believe that having a framework/platform that allows you to go a step above the actual hardware and relatively quickly change MCUs/boards is a step in the right direction.
One thing that is troublesome for me now that I have some experience with QP is working with bare RTOS. After you set up a flow where you generate high-level code with QP and use/generate low-level code with maybe CubeMX you are left with writing only middle "glue" code that immensely accelerates development. That's why I think it's important for QP's future to support as many platforms to help with its adoption.
ESP32 port is certainly amazing to see given that it's probably the most important platform in the hobby/maker community but also a lot of companies use that chips for their custom hardware.
As for debugging, it's quite of a challenge even with SES for Nordic boards as the BLE stack doesn't mix nicely with breakpoints so you are going in the wrong direction where you again rely on basically logging what's happening.
That's where QS/QView steps in with the ability to "see" what's going inside of a project much easier and would tremendously help with development.
To finish my point, Nordic chips are really ubiquitous in the BLE space and I think having the ability to use QP with them would be very beneficial for the whole project.
Hi Aleksa,
Thanks a lot for the update.
Yes, it's obviously important to support all these different platforms, but it's also tricky to balance the cost of doing this versus other work. Every additional platform requires maintenance (updates, tooling, testing, etc.), which dramatically slows down the pace of innovation.
Perhaps the best solution would be if such adaptations could be provided by the community. For example, by forking the QP/C and/or QP/C++ projects on GitHub. Then a post about such community project(s) could be made in this forum.
--MMS