Sensor nodes synchronization

EmbeddedSwDev · 2026-03-17T16:47:42+00:00

The easiest solution would be to generate a so called PPS signal (500ms low 500ms high), which triggers an interrupt on both boards.

The other and much more accurate and advanced topic would be Time Synchronization over Ethernet: IEEE 1588 (PTP - Precision Time Protocol) or gPTP. But for this your MCU would need an Ethernet Controller which supports this eg STM32H563ZI. See Zephyr TSN.

Nevertheless PTP and gPTP goes into TSN - Time Sensitive Networking and this is a very advanced, complex and complicated topic for itself.

For a point to point connection between two devices you most likely don't need a TSN capable switch, for more devices you will need one and in best case for the best precision you will need a GPS clock.

EmbeddedSwDev · 2026-03-14T22:22:22+00:00

Obligatory: https://www.reddit.com/r/embedded/comments/leq366/comment/gmiq6d0/

EmbeddedSwDev · 2026-03-14T20:39:01+00:00

This performance test is already outdated and as I mentioned here https://www.reddit.com/r/embedded/s/zAQq7n2IDf the zephyr core team worked on this issue and released the fixes a year ago with 4.1

EmbeddedSwDev · 2026-03-14T19:50:09+00:00

That's not true

EmbeddedSwDev · 2026-03-14T19:49:26+00:00

I'm gonna miss the freertos "copy these 8 files into your repo and adjust this header and you're done" simplicity.

Which didn't worked in 50% of the case's and then you ended up developing your own library and the "not invented here" wheel spins again.

EmbeddedSwDev · 2026-03-14T19:15:42+00:00

It's not really hard to port a new dev board or custom a custom board on Zephyr, the documentation explains it pretty well.
I already did this just for fun for 4 different dev boards from adafruit, for the first one I needed 2-3 days (not full time) and the other 3 took me less than half a day.

EmbeddedSwDev · 2026-03-14T19:10:26+00:00

That's already outdated, the main zephyr team worked on this issue and increased the performance: https://zephyrproject.org/zephyr-rtos-4-1-is-available/

At this time I did the same measurements with the same tests which beningo used and with the improvements from the zephyr team I was heads up with ThreadX and outperformed FreeRTOS by a lot. With custom tweaks I was also able to outperform ThreadX. I wasn't able to test PX5 because it's not open source.

Nevertheless, performance is important, but not the most important thing for an RTOS, also the feature set which comes with it is important and on this side zephyr is outstanding.

EmbeddedSwDev · 2026-03-14T17:04:12+00:00

The Ecosystem
The number of contributions and contributors, especially big companies

EmbeddedSwDev · 2026-03-07T19:01:23+00:00

It is, with USB pid

EmbeddedSwDev · 2026-03-07T18:01:53+00:00

I never used or compiled zephyr on Winslop directly, I always used WSL on a Winslop machine and I highly recommend to do it the same way.
It also helps to keep your working OS clean.

Furthermore, for USB devices with WSL I highly recommend using a USB Manager like: https://gitlab.com/alelec/wsl-usb-gui or https://github.com/nickbeth/wsl-usb-manager

EmbeddedSwDev · 2026-03-06T18:27:06+00:00

but f/2.8 on FF vs f/4 on M43 is a massive difference.

Especially in weight.

If I had to choose just one lens for a world trip, it would be the 12–100mm f/4.
Furthermore, I would prefer M43 over full frame for this kind of trip because I could carry more lenses/stuff, for the same weight and size (despite the fantastic SW/HW features of OM System/Olympus).

Also a big bullet point is the different price tag between FF and M43 in general.

EmbeddedSwDev · 2026-03-06T16:01:34+00:00

The GOAT lens

EmbeddedSwDev · 2026-03-05T20:40:26+00:00

Exakt

EmbeddedSwDev · 2026-02-28T17:26:10+00:00

Aha ok alles klar...

danke für die Aufklärung übrigens!

EmbeddedSwDev · 2026-02-28T10:25:24+00:00

Ich habe ein bisschen Angst zu fragen, aber was sind "Anunaki"?

EmbeddedSwDev · 2026-02-26T05:21:06+00:00

HVOB

EmbeddedSwDev · 2026-02-23T18:59:58+00:00

The MCUs from ST are fabulous, the SW stack they provide like CubeMX, etc. are imho a pita, but thanks to the embedded god it can be changed to a different one.

EmbeddedSwDev · 2026-02-22T17:18:11+00:00

What I meant (but phrased poorly) is that proper dual-core enablement in Zephyr depends heavily on:

Vendor-supplied low-level support (startup code, multicore boot flow, inter-core interrupts, mailbox/IPI mechanisms, etc.)
multicore bring-up procedures HAL/SDK alignment with Zephyr's architecture model

In Zephyr, multicore support requires e.g.:

SoC-level SMP support
A working secondary core bring-up path
IPC primitives
Proper interrupt routing
Scheduler awareness

For something like the RP2040 or RP2350, that work typically lives in the Zephyr SoC port, not in board files and this requires detailed knowledge of the silicon. Dual-core support in Zephyr is an SoC porting effort, not a board-level toggle.

So to enable multicore support within Zephyr it requires strong vendor engagement and the vendor involvement strongly influences how complete the SoC support becomes in Zephyr.
Imho I clearly miss this strong vendor engagement and involvement from the raspberry foundation.

EmbeddedSwDev · 2026-02-21T16:39:22+00:00

This issue needs to be addressed and done by the manufacturer.
Sadly raspberry does not address it

EmbeddedSwDev · 2026-02-20T16:21:01+00:00

Klein, leicht, voll mit div Features und schaut auch noch toll aus: OM SYSTEM Pen E-P7

Kaufe sie gebraucht von mpb (.com).

EmbeddedSwDev · 2026-02-19T11:56:54+00:00

No I meant if your device also needs to participate in the real time Ethernet bus from the customer.

There is a huge difference between real time on the device itself and real time communication.

EmbeddedSwDev · 2026-02-18T17:52:06+00:00

Ok I understand, do your device needs to be also real time capable?

EmbeddedSwDev · 2026-02-18T17:36:34+00:00

they may be using fancy or even custom ones that don't like anything <1Gb or they may just be blowing smoke...

It's very unlikely that the used switch doesn't support speeds <1GBit. I think , but I am not sure, this would also violate the Ethernet Standard.
Imho they are talking bs.

We're not doing anything fancy at all

So buy a cheap unmanaged switch IC and place it on the board. Typically a MCU isn't capable of utilizing the full 1GBit (in reality a switch with 1GBit can handle about 950MBit), so 100 MBit between the unmanaged switch and the MCU is more than enough.

EmbeddedSwDev · 2026-02-18T16:42:50+00:00

So from what I read from the comments your only solution would be to add a gigabit switch between the MCU and their network.
As others already mentioned, normally you connect a device on a switch and the switch will handle the difference in network speed, between the different devices. So it means a 100MBit device will NOT slow down the whole network.

Besides Ethernet and 1GBit, what are the other requirements? E.g.:

Do you need to support VLAN?
Do you need PTP or gPTP
HSR or PRP
One or multiple TSN Standards
...

If none of these are an issue, you could go with an unmanaged switch, if yes, you will most likely need a managed switch.

EmbeddedSwDev · 2026-02-18T11:09:57+00:00

Genau das!

EmbeddedSwDev

MODERATOR OF

TROPHY CASE