[HN Gopher] Arduino Joins Zephyr Project
___________________________________________________________________
Arduino Joins Zephyr Project
Author : manchoz
Score : 28 points
Date : 2023-06-22 13:01 UTC (10 hours ago)
(HTM) web link (zephyrproject.org)
(TXT) w3m dump (zephyrproject.org)
| idank wrote:
| is Zephyr a good option in a project that aims to expose a UART
| device through BLE using an nrf52x chip? At a glance it seems
| pretty low level, capable and possibly overkill. If not, what's
| more suitable?
|
| Hopefully that makes sense, I'm new to all of this.
| bathMarm0t wrote:
| Just recalling what I did a couple years ago.
|
| Bluetooth is an absolute nightmare if you don't understand the
| majority of what's going on (which in and of itself takes... a
| lot of time). There's a bunch of logic going on and most of it
| is handled in callbacks that you will never see, except the
| dreaded timeout/failure to handle print at the end of the main
| loop. Zephyr will ease a lot of those painpoints, with the
| understanding that you're ignoring a lot of the machinery
| humming under your feet.
|
| Things that stood out to me:
|
| 0. If this is your first embedded project / you're actually new
| to all of this, get ready to take a beating. "Abandon all hope,
| ble who enter here."
|
| 1. Do yourself a huge favor and get two* dev kits. Nordic
| provides walkthroughs on getting setup with two flavors of code
| (zephyr, or low-level drivers). Each has a tutorial for uart
| forwarding/handling. Expanding on that tutorial will take a lot
| of futzing around, or actually learning what the machinery is
| doing under the hood. Learning the stack did not come naturally
| / I found it very difficult. Why two? Two lets the bluetooth
| abstraction handle itself / you don't have to deal with it
| right away when you're getting started.
|
| https://www.nordicsemi.com/Products/Development-hardware/nRF...
|
| 2. If / when you want to attach your bluetooth device to
| something more useful (e.g. a computer or mobile device), do
| yourself a second huge favor and develop using linux + a
| laptop. I tried to do development on windows + WSL and there
| were many, many hangups with the hardware handoffs from PyBlues
| to the local bluetooth drivers. Maybe it's gotten better, but I
| doubt it. My other alternatives were driving direct from
| Windows bluetooth libraries (behemoths that would take time to
| setup / understand), or develop for mobile (which also will
| take time to setup / understand). Neither was an enjoyable
| experience.
|
| so in summary:
|
| Is Zephyr overkill? - Absolutely. But the path is well trodden.
| EmbeddedHash wrote:
| Not sure if I understand, but you currently have a device that
| has UART enabled, and you are trying to communicate with it via
| BLE? Thus, you want to add a BLE chip, i.e. the nrf52, and then
| relay the commands from BLE -> UART for the second chip?
|
| Regardless, Zephyr is an RTOS which provides OS functionality
| like scheduling, interrupt handling, semaphores, etc.
|
| It is most likely overkill for what you are attempting to do.
| You should instead look at the vendor provided SDK for the
| nrf52 chip and program it bare metal. The SDK is most likely
| just libraries/drivers and does not come with an RTOS.
| idank wrote:
| Yes exactly. This device is a mini exercise bicycle, it has
| half a dozen buttons and LEDs with a UART enabled chip that
| orchestrates everything. I'd like to make it controllable via
| Bluetooth (e.g. on/off, set speed) and have it send stats
| like current speed, etc.
|
| Would something like circuitpython not be easier to work
| with?
| bfrog wrote:
| It makes sense if you consider the devices being made now are
| faster and more complex than ever.
|
| Multi core SoCs with different archs and memory protection
| schemes all sharing a bus. This complexity can be wrangled with
| device tree and Zephyr readily and has good company with other
| large silicon vendors being contributors.
|
| I for one am looking forward to seeing more contributions and
| companies joining.
| crote wrote:
| It's a bit of a tradeoff, really.
|
| The upside is that you no longer have to essentially write an
| entire OS if you just want to make a light blink, making it way
| easier to get started with a complicated project. The downside
| is that all those layers of abstraction make it really hard to
| figure out what is _actually_ going on, and they can quickly
| get in the way when you are trying to do something which isn 't
| a 1:1 match to the high-level model used.
| lionkor wrote:
| I've had the pleasure of using Zephyr OS on an embedded bluetooth
| project with a few others. We were using NRF52x chips, with a dev
| board, and Zephyr was one of the least painful parts of the whole
| thing. Can absolutely recommend Zephyr in general.
| kenmacd wrote:
| Zephyr has a lot of good points, but I really wish it didn't
| use Kconfig. Getting a working config seems to be mostly a
| matter of copying an already working example. It might be okay
| for hardware side of things, but it's a really bad at
| software/feature dependency.
|
| Set
| https://docs.zephyrproject.org/latest/build/kconfig/tips.htm...
| and the issue: https://github.com/zephyrproject-
| rtos/zephyr/issues/52575. And don't even get me started on
| trying anything to group options together.
| elevation wrote:
| Could Zephyr's difficulties be resolved if Kconfig supported
| an additional operator besides 'select' and 'depends on'? Or
| perhaps with an overlay capability like bitbake has?
|
| Since Kconfig is used to configure the kernel, why aren't the
| kernel devs experiencing similar issues with their
| configurations?
| genmud wrote:
| Zephyr is such a great project, I really have enjoyed working
| with it and the Nordic (NRF5x) is awesome. I think over the next
| 3-5 years it is really going to get more and more adoption
| compared to alternatives like freertos or vxworks.
___________________________________________________________________
(page generated 2023-06-22 23:02 UTC)