maximusdrex

3 ay öncediscuss

Yeah, I read that note and stopped looking further. I was hoping that maybe the hardware-specific code was in a different project and just wanted to be nice in case. I just don’t get the point of making AI slop out of something like a toy RTOS, which is inherently a learning project more than anything else. There’s nothing even fun about doing it if you won’t even try to get it to run on an STM32 or something.

maximusdrex

3 ay öncediscuss

Looks like a fun project, but I’m curious what you actually tested on. There’s real numbers for estimated context switch timing, and you mentioned implementing context switching, but I can’t find any actual implementations of the context switching routine in your code. You don’t need to do this yourself, but it’s weird to talk about it if you haven’t.

maximusdrex

3 ay öncediscuss

> It is precisely to avoid running Linux and the "wealth of drivers".

Why not? I understand not wanting to deal with unnecessary complexity as a hobbyist, but you'll find yourself creating far more complexity trying to implement all of this yourself (and vendors certainly don't want to support you in this). Secondly, I think the number of customers for chip vendors who are uncomfortable with setting up an embedded Linux environment, but perfectly confident in routing DDR and PCIe signals is approximately 0.

> What I am trying to point out is that there is a huge market gap.

> i.MX8 is not realtime and the support for running bare metal code is very much non existent.

This isn't quite true and is what I'm trying to get at. Most of these embedded SoCs contain a Cortex-M and a Cortex-A (not all but there are quite a lot). High performance DRAM, external PCIe devices, and large internal caches are fantastic for compute performance but most of the things you want to do with a PCIe device (networking, asynchronous compute) don't require cycle-accurate determinism. Generally there isn't much you need to do with such stringent timing requirements, so you can offload that work to secondary Cortex-M33 core with a shared memory interface to the main core and get the best of both worlds.

I see so many systems trying to take advantage of the impressive compute power of modern MCUs (which is really cool!) but often end up just re-inventing the cooperative multitasking OS, but worse.

maximusdrex

3 ay öncediscuss

ST seems to consistently put out faster chips [1]. I think the better question is why bother though? The real reason to use a Cortex-M is determinism in hard real-time systems. I'm sure DDR3 and PCIe would be cool in an MCU and people would certainly make some interesting things with it, but at that point you either aren't making a hard real-time system and would benefit greatly from an MPU, allowing you to run Linux and benefit from the wealth of drivers available for these interfaces, or your real-time deadlines are so tight an FPGA would be a better choice. The real advantage of the Cortex-Ms is that they can be manufactured on ancient process nodes for next to nothing. The moment you don't care about that, why not upgrade to an i.MX8?

[1] https://www.st.com/content/st_com/en/campaigns/stm32v8-high-...

maximusdrex

4 ay öncediscuss

Calling this "hardware-based security" is somewhere between disingenuous and dangerously naive. Hardware-based security normally implies hardware with a dedicated secure element with cryptographic identities which are impossible to spoof. Security based on USB serial numbers can be defeated by any adversarial device claiming to use the same serial device as a device you have registered. There's no secure signatures or anything backing a USB serial number.

This is so, so much worse than that though, because the code doesn't even do what the AI-hallucinated documentation describes, because as far as I can tell the actual "serial number" is returned by the following line: Ok(Some(format!("{:?}", device.product_id()))) So the "serial number" is actually the USB product id, which generally corresponds to the "model", not even unique per-device. So you didn't even test this with multiple identical flash drives.

comments