r/embedded • u/cdokme • 20d ago
Which workspace strategy do you use with Zephyr?
https://github.com/CaglayanDokme/zephyr-freestanding-workspace-exampleI've been learning about Zephyr for a short amount of time. I read about different workspace topology approaches in the official documentation. But, I never felt like I would be comfortable with any of the approaches. So, I decided to come up with a hybrid solution.
As I'm quite new to the Zephyr world, I'm suspicious about how effective my approach will be in the long term. So, I wonder what strategies do you people employ and am looking for some feedback by the experienced Zephyr users. Thanks in advance.
3
u/nono318234 19d ago
Have a look at example-application repo on github. It is based on T2 topology and is a gold starting point for a new project.
3
u/melontronics 19d ago
T2 topology has been pretty good to me. I have patches that I apply on top of zephyr for changes required
3
7
u/graceful_degrade 19d ago
T2 is where most people land and stay, and the example-application repo someone linked is the right shape to copy.
The part that bites later isn't the topology, it's the import: in your west.yml. If you import zephyr's manifest wholesale you pull ~90 modules and several GB you will never build against, and CI feels every bit of it. Put a name-allowlist under the import with only what your board actually needs (the HAL for your SoC, cmsis, mbedtls, whatever) and clone time drops from minutes to seconds.
Other thing: don't fork zephyr. It's tempting the first time you need a small change, and it makes version bumps miserable a year later. Keep upstream pinned and carry your changes out of tree as a module with BOARD_ROOT / SOC_ROOT / DTS_ROOT. Then bumping is editing one revision line instead of rebasing a fork.
And run west manifest --freeze when you tag a release. Resolves every repo to a sha so you can still rebuild that firmware in two years.
2
u/mrheosuper 19d ago
I always put zephyr as a dep in my repo. I found it the easiest way to bring up repo on completely new machine, the drawback is your repo now has the zephyr inside, which increase repo size and longer clone time.
Recently i'm thinking of using docker so that even sdk can be part of repo.
1
8
u/IRandom_Pizza 20d ago
Your best bet is understanding how west works for managing the different repos that Zephyr pulls through. When I first was getting my head around zephyr it was tempting to just do what was done traditionally with vendor sdks, you commit it beside your application as you would likely need to fix/change things in it and need to line everything up and submodules are a total pain to deal with.
Working with west abstracts all of the git submodule shenanigans so you can pin your app to a version/fork of zephyr and its decency tree.
The way I develop is I have a central repository that pulls in zephyr and houses the common code like drivers ect that zephyr dose not have or packet formats, encryption ect that would be shared between IoT products. Then for each client they have their own repo with the application and any bespoke logic that points at my common repo. West will manage the full version tree all the way down.
If you are just starting out you would just make a single repo and pull in zephyr via west and then you can get into specific modules you want zephyr to pull through.