EEM0 collides with recent Nucleo-144 boards

[airwoodix]

On recent Nucleo-144 boards, the STLINK programmer is not detachable anymore and thus overlaps with EEM0.

With standard-height pin-headers, the port is not usable anymore:

Using higher pin-headers is possible, but quickly shifts the board out of the front-panel cut-out.

Would a long version (same as Kasli2/Kasli-SoC) of the board be feasible, to get the full-size Nucleo-144 board not collide with the EEM0 port?

Potentially in combination with #15, would that allow for an extra EEM port on this board?

[gkasprow]

sure, we can do it in DIOT/EEM form factor.

[airwoodix]

Sounds great, thanks for the feedback!

Concerning DI/OT: how many ports could fit on this board? 4 DI/OT + 4 EEM sounds like a lot, doesn't it? Since EEM is still more common at the moment, our near term preference would be on more EEMs, but it would of course be nice to have the same level of connectivity with DI/OT.

Are there plans to work on a new Humpback revision in the short/mid-term? I see that there are also a couple of issues with the BOM. It would be nice to consider #15 as well, if that's realistic. Please let us know if we can help.

Thanks!

[gkasprow]

DIOT and EEMs use same FPGA lines.
What is the exact use case for this board?

[airwoodix]

humpback-dds is a typical use case, potentially combined with other DIO cards. Maybe it could also be used instead of an Arduino for GPS locking of Wenzel_ref?

I was wondering whether 4 DI/OT and 4 EEM connectors would fit on the board, together with the larger footprint for the Nucleo board.

Are there known use-cases for the other supported µC modules (OrangePi, BBB, etc.)? Given the synergy with e.g. Stabilizer and Thermostat, we could envisage a Humpback with a hard-wired STM32H7(53?). But it's more complexity.

[gkasprow]

So it works as a crate controller?

[airwoodix]

Yes.

[gkasprow]

So there is no reason to make it DIOT compatible. We already have DIOT controller with STM32 and ECP5.

[airwoodix]

Do you mean STM_Sys_Board? I overlooked that, sorry.

At the moment, the modules we control/want to control are Urukul, DIO_*, maybe Wenzel_ref, which would still require EEM, wouldn't it?

Could one have a variant of STM_Sys_Board with EEM instead of DI/OT instead of a rework of Humpback?