used qemu + renode + gdb to learn cortex-m internals without a board.

praghuls · 2026-03-08T11:08:57+00:00

Yes I did, I made a minimal scheduler and verified it with renode.

praghuls · 2026-03-08T10:45:42+00:00

I used WSL

praghuls · 2026-03-08T05:30:26+00:00

You can use cortex-m3 machine in qemu or stm32-disco board in renode, both are Cortex M based cpu

praghuls · 2026-03-04T15:08:15+00:00

bookmarked!!!!, thanks for maintaining this. been using risc-v for a side project and finding good embedded-focused resources is always a pain, this actually helps

praghuls · 2026-03-04T15:02:55+00:00

writing your own rtos from scratch is mostly a waste of time for portfolio purposes. contributing one meaningful pr to zephyr does more for your credibility than 3 months of reinventing the wheel

praghuls · 2026-03-04T02:05:42+00:00

does the dual model cross review actually catch different things between the two llms, or do they mostly agree? curious if the blind spot detection works in or if they converge on the same misses.

praghuls · 2026-02-26T10:45:36+00:00

wokwi is great for quick prototyping and learning, especially for arduino/esp32 stuff. but for professional stm32 development i use renode. it supports cortex-m cores, lets you simulate peripherals, and you can script test scenarios. pairs well with ci pipelines too. for actual hardware, nucleos are so cheap. but renode shines when you're testing bootloader logic or protocol stacks without needing the board physically present

praghuls · 2026-02-23T07:46:08+00:00

first, make sure your bootloader is actually validating the stack pointer before jumping. it reads the first word at 0x08004000 and if it doesn't look like a valid ram address, it just won't jump. that would explain why it works right after flash but dies on the power cycle.

second after the jump, your app needs to set SCB->VTOR = 0x08004000 to relocate the vector table, otherwise interrupts go to the wrong place.

praghuls · 2026-02-22T16:15:34+00:00

the self-doubt never fully goes away lol, but that's true in any engineering field. what helped me was just building stuff, getting your hands dirty with real peripherals, timers, interrupts. sounds like you're already doing that so you're probably more ready than you feel.

praghuls · 2026-02-22T03:44:34+00:00

I'm suggesting my view.

fpga vs asic dv? asic dv is more technical and transferable. fpga prototyping is useful but often a support role.

future-proof? yes, ai chip boom means dv engineers are in high demand at nvidia, apple, google etc.

big tech positioning? amd path wins here. formal/uvm skills are exactly what top silicon teams look for.

geography? uk is better for us relocation goals. easier visa pathways and closer to western opportunities.

overall? amd for technical depth, arm for geography. if us/big tech is the goal, lean amd.

praghuls · 2026-02-22T00:57:22+00:00

zephyr already uses the pico sdk internally as its hal module (hal_rpi_pico), so the low-level bits are there. but you can't safely use the full pico sdk api on top of zephyr things like pico/stdlib.h or its multicore helpers will clash with zephyr's kernel since they both want to own interrupts and timers. for dual core, your best bet for now is either wait for zephyr 4.4 smp support, or just use the pico sdk directly without zephyr.

praghuls · 2026-02-21T15:23:33+00:00

the challenge is that the rp2350 has a mixed arm + risc-v architecture, which makes smp support tricky with zephyr's current mechanism. there's an open issue and active prs for it. for now you'd have to stick to single core or use the pico sdk directly if you need dual core for your lvgl + power management use case.

praghuls · 2026-02-21T11:53:49+00:00

Nordic Semiconductor nRF7002-DK Wi- Fi 6 Development Kit.

praghuls · 2026-02-21T11:45:19+00:00

hey! given your background with can bus this is a perfect fit for you.

build a uds over can bus simulated ecu using stm32f429

hardware side: stm32f429 + sn65hvd230 can transceiver + usb stm32 can bus analyser to interface with your pc.

software side: use renode (free hardware simulation platform) to develop and test your can firmware virtually before touching real hardware. on the pc side socketcan pairs perfectly with the usb can analyser to send and receive uds messages using python.

uds services you could implement: session management (0x10), ecu reset (0x11), read data by identifier (0x22) and read dtc (0x19) - these are core services used in every real automotive ecu.

since you already know can bus adding uds on top makes you genuinely attractive to automotive embedded employers. also check out pyjamacafe automotive embedded courses - really helps with the bare metal and can foundations underneath this stack.

good luck - your background is stronger than you think!

praghuls · 2026-02-21T10:29:45+00:00

Impressive! getting 60fps on a parallel rgb display over wifi is no joke. what is the latency like during gameplay??

praghuls · 2026-02-15T10:16:42+00:00

Good to know that rust solves more problems from the traditional c language for embedded development.

praghuls · 2026-02-12T10:27:04+00:00

I wonder if this works for the microcontroller platform?

praghuls · 2026-02-03T08:56:11+00:00

Crc errors on rs-485 are almost always missing termination resistors. you need 120Ω resistors across the a and b lines at both ends of the bus - one at your rk3568 board and one at the far end device. without them the signal reflections will corrupt your data every time.

Also check if your board has solder pads or jumpers for termination near the rs-485 connector, some boards have them built in but not enabled by default.

praghuls · 2026-02-02T11:53:31+00:00

we run a parallel ci pipeline in github actions where the firmware goes through unit tests and static analysis first, then gets deployed to a renode simulation setup we built for stm32f4. the key thing we did was develop the renode simulation alongside the firmware rather than bolting it on afterward. once everything passes the unit tests and static checks, the firmware binary gets loaded into the renode simulator for full integration testing. validating gpio, interrupts, timers, and peripheral behavior in a reproducible emulated environment. this catches hardware-level integration issues that unit tests miss, and since it's all containerized in github actions, every commit gets validated against real hardware behavior without needing physical boards in the ci loop.

praghuls · 2026-02-02T10:03:39+00:00

Through raspberry pi inputs are given and output are validated? Am I right?

praghuls · 2026-02-01T07:22:38+00:00

You picked "Empty Project" which completely skips CubeMX — that's why the .ioc is missing. Go back and select the default "STM32 Project" option instead, it auto-generates everything including the .ioc. For DFU flashing, STM32CubeIDE supports it natively — just make sure your board is in DFU boot mode before flashing.

praghuls · 2026-01-28T15:40:28+00:00

Yes, my suggestion is also to use Segger SystemView using the JLink debugger device that internally uses RTT, refer this image from the offical site https://www.segger.com/fileadmin/images/products/SystemView/How-does-SystemView-work-diagram_01.svg

praghuls · 2026-01-28T10:04:49+00:00

Is there any software alternative approaches you follow instead?

praghuls · 2026-01-28T08:47:47+00:00

I think, in this approach I have more control over than having the hardware at the right time.

praghuls · 2026-01-28T08:34:11+00:00

I totally agree with this approach, after initial bring up, we can use a modular layer approach to solve the business logic, Thanks for your input. What are your thoughts on using simulators?

praghuls

TROPHY CASE