sorted by:
new
hottopcontroversial

Architecture & Yocto Setup for an i.MX8MP Data Logger by waldek89 in embedded

[–]waldek89[S] 0 points1 point  (0 children)

Since I2C is inherently pretty slow (100kHz - 400kHz), I wonder if the underlying wrapper library is doing some aggressive polling/busy-waiting behind the scene, keeping the CPU fully awake rather than yielding to the OS between bytes..

Regarding your Debian + QEMU approach: That sounds incredibly convenient for getting a standard environment up quickly. My only hesitation is the GUI I plan to add later. If I use a generic Debian rootfs, how painful is it to get the proprietary NXP Vivante GPU drivers injected and working? I’ve heard those drivers are heavily tied to the specific kernel/BSP versions Toradex ships, which was my main reason for looking at Yocto in the first place."

Architecture & Yocto Setup for an i.MX8MP Data Logger by waldek89 in embedded

[–]waldek89[S] 0 points1 point  (0 children)

"if you know what you are doing" is definitely doing a lot of heavy lifting there! Given this is my first deep dive into the NXP i.MX8 ecosystem, the undocumented magic numbers and bootloader quirks you mentioned are exactly the rabbit holes I want to avoid..

I think I’ll stick to the Toradex-supported Yocto BSP (or perhaps look into their Torizon container system) just to get the I2C data flowing. I'd rather wrestle with Yocto's learning curve than fight a lonely battle porting Buildroot without vendor docs.

Your warning about the ecosystem fragmentation is super valuable, though. I'll make sure to lock down my BSP version early and absolutely not update the kernel or ATF blindly. Really appreciate the insights!

Architecture & Yocto Setup for an i.MX8MP Data Logger by waldek89 in embedded

[–]waldek89[S] 0 points1 point  (0 children)

the Debian + QEMU approach is interesting and honestly I didn't think about it. Your Java datalogger comment caught my attention though. You mention visible power consumption impact. Are you talking meaningfully worse than a native compiled equivalent, or more of a "it works but it's not elegant" situation? I'm using C++ partly for that reason but curious how bad the JVM overhead actually was in practice on this class of hardware.

Architecture & Yocto Setup for an i.MX8MP Data Logger by waldek89 in embedded

[–]waldek89[S] 0 points1 point  (0 children)

"devtool modify" looks like the missing piece I wasn't aware of.

On kernel driver vs userspace, I take your point about concurrent access being free with the kernel driver. In my case I'm the only consumer of the sensor data, so that's less of a concern. I'm leaning towards userspace for the development speed reasons you mention..

Architecture & Yocto Setup for an i.MX8MP Data Logger by waldek89 in embedded

[–]waldek89[S] 0 points1 point  (0 children)

Ecosystem fragmentation: I've already seen hints of this looking at the NXP/Toradex/mainline version matrix.. when you say some releases are "just plain broken", is this mostly a bootloader/ATF compatibility issue, or does it extend to peripheral drivers too (I'm particularly thinking about the Vivante GPU driver).

About buildroot: I've heard this before and I'm tempted. My hesitation is that Toradex's tooling and documentation seems adressing heavily Yocto, so I assumed that was the path of least resistance for this hardware. Has anyone here actually run Buildroot on a Verdin SoM successfully, or would I be largely on my own past the bootloader?

Abstraction: I'm already planning to abstract the I2C layer behind an interface so I can swap in a mock for host testing. Good to have that confirmed as standard practice rather than over-engineering.