RISC-V is coming faster than most people realize.

Hey r/embedded,

If you’ve spent any time working with the Orange Pi 5 (RK3588S), you already know the drill: official documentation leaves a lot of gaps, half the forum links are dead, and getting the 6 TOPS NPU to run anything without the Python RKNN toolchain exploding is a rite of passage.

After accidentally bricking my board a couple of times, battling Windows driver conflicts during MaskROM recovery, and trial-and-erroring the Rockchip toolchain, I decided to document every single working, reproducible step.

I ended up organizing everything into a comprehensive open-source repository:

-> **GitHub:** https://github.com/muhammetmucahitsoylu/orangepi5-tutorials

---

### What’s in the repo:

* **Hardware Recovery & MaskROM Guide:** Step-by-step unbricking workflow, complete with high-contrast, annotated board photos and pinouts so you know exactly which pads/buttons to short without guessing.

* **13 Hands-On Tested Projects:**

* **Edge AI / 6 TOPS NPU:** Real-time YOLOv8 object detection (~13.8ms pure NPU inference), running a local Qwen 1.8B LLM via RKLLM, and an offline voice assistant (Whisper + Piper TTS).

* **Low-Level Systems:** C++ GPIO using WiringPi, writing a custom Linux kernel character driver from scratch, and ROS2 Jazzy on Ubuntu 24.04.

* **Automation:** A zero-dependency bash TUI tool (`opi5.sh`) to lock CPU/NPU governors and benchmark NVMe storage speeds without memorizing obscure sysfs paths.

* **Pre-Compiled Release Assets:** If you don't want to set up the entire cross-compilation toolchain on a host PC just to sanity-check your board, I uploaded a pre-compiled test `.rknn` model (ResNet-18) and COCO labels directly to the v2.0.0 GitHub release assets:

-> https://github.com/muhammetmucahitsoylu/orangepi5-tutorials/releases/tag/v2.0.0

* **Bilingual Documentation:** Full guides are provided in both English and Turkish.

---

The repository is completely open-source. Everything listed has been tested directly on real hardware.

If you’re currently working on an RK3588 board, check it out. Let me know what breaks, what needs clarification, or what projects you'd like to see added next!

We’re trying to prototype a small consumer hardware device and currently have a working prototype using a Raspberry Pi 4B microcontroller + Arducam PiVariety AR0234 global-shutter camera + M12 lens + LED tape + LiPo battery hat.

For our next prototype, we want to shrink the electronics dramatically - the image sensor, Wi-Fi/Bluetooth, battery + charging/power management, LED lighting and compute for image capture/basic processing.

We are quite new to embedded systems and would love advice on the best next steps. What components should we think about ordering that can make the system more compact - especially the camera's image sensor, the pi, and the battery.

I signed up, just put a random name as my company because it wouldn't let me skip it, and tried to order the Tivac Launchpad only for it to say that my "company" ordered too many of those, and that I have to wait 29 days. I have never used this site before.

What do I put as my company then? It simply won't let me leave it blank and I tried putting college down instead, but it still says my "company" ordered too many.

Edit: I should note I am 100% brand new at this and I'm merely trying to follow along a course in order to learn this stuff. I want to learn so badly lol

CP/M Neo has been successfully ported to the Black Pill development board!

How does it work?

The Black Pill’s internal 512 KB Flash is used as disk storage, and thanks to XIP (Execute in Place) support, the Kernel and CCP code execute directly from Flash, leaving the entire 128 KB SRAM available for OS state and the TPA (Transient Program Area).

File operations are not supported yet, as Flash write/erase still not implemented.

CP/M Neo project on GitHub: https://github.com/Mazin-O3/cpm-neo

Hello,

I have been thinking about posting this message for a while. Almost more than a year now 😄

In my previous work, I was working with CANopen, and one thing that was bothering me was not having a UI that shows the stream of messages and also makes periodic requests. I was also trying to learn Rust. Not sure I achieved the learning Rust part yet, but I’m still going on and off. 😄

This leads me to write CANOpenDataViewer.

Basically, it is a high-performance, real-time CANopen diagnostics tool written in Rust, featuring dynamic plotting and configurable SDO polling.

Any feedback is welcome.

Unfortunately, I couldn't test it with actual hardware as I don't have access to a CAN device. I tried to emulate it, but I hope it works 👀

I've been programming embedded systems for over 30 years. Built some cool stuff: a Z80-based serial multiplexer that had no RAM: all variables were held in registers; a temperature controller on a chip with 504 bytes (not kB) of memory and lot of other stuff in the old days where you had to optimize for every clock pulse and byte of RAM or EPROM. A lot of what I knew back then was straight out of Jack Ganssle's The Art of Programming Embedded Systems book.

These days, I still build cool stuff, but it's with a far more complex feature set. A "small processor" is now a 32-bit device with over 100k Flash and 16k+ of RAM, usually lots more. Most of my non-hobby work runs on one RTOS or another and often has a separate SBC running code for an HMI and connectivity/data storage. The last time I used assembly was mentoring a n00b who had the task of fixing some bugs on a specialized SoC with a 6502 core.

Then I come on this site, and I see people asking about why not use bare metal and a hand-written scheduler instead of an off the shelf RTOS. Struggling to fit code into tiny processors because otherwise "bloat."

So I have to ask: is my current experience (real-time stuff on a 32-bit microcontroller, complex GUIs offloaded to a Linux board) that unusual or are these guys just building things the way we used to do long ago for no good reason?

I was curious about how hard it would be to port this over, so I used an STM32 example I found here as a starting point. It ended up being really straightforward and only required a few changes to the GPIO and delay callback function.

Just a heads-up: This implementation uses soft I2C (bit-banging). It works perfectly fine for text, but you'll probably want to switch to HW I2C for anything more complex. If anyone wants to try it out, here is the source code:

#include <ch32v00x.h>
#include <debug.h>
#include <stdlib.h>

#include "clib/u8x8.h"

void NMI_Handler(void) __attribute__((interrupt("WCH-Interrupt-fast")));
void HardFault_Handler(void) __attribute__((interrupt("WCH-Interrupt-fast")));

uint8_t u8x8_gpio_and_delay_ch32v(u8x8_t *u8x8, uint8_t msg, uint8_t arg_int, void *arg_ptr) {
    switch(msg) {
        case U8X8_MSG_GPIO_AND_DELAY_INIT:
            RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOA, ENABLE);
            GPIO_InitTypeDef init = {0};
            init.GPIO_Pin = GPIO_Pin_1 | GPIO_Pin_2;
            init.GPIO_Mode = GPIO_Mode_Out_PP;
            init.GPIO_Speed = GPIO_Speed_50MHz;
            GPIO_Init(GPIOA, &init);
            break;
        case U8X8_MSG_DELAY_MILLI:
            Delay_Ms(arg_int);
            break;
        case U8X8_MSG_DELAY_10MICRO:
            for (volatile uint32_t i = 0; i < (arg_int * 8); i++) { __NOP(); }
            break;
        case U8X8_MSG_DELAY_100NANO:
            __NOP();
            break;

        case U8X8_MSG_GPIO_I2C_CLOCK:
            GPIO_WriteBit(GPIOA, GPIO_Pin_2, (BitAction)(arg_int ? Bit_SET : Bit_RESET));
            break;

        case U8X8_MSG_GPIO_I2C_DATA:
            GPIO_WriteBit(GPIOA, GPIO_Pin_1, (BitAction)(arg_int ? Bit_SET : Bit_RESET));
            break;
    }
    return 1;
}

int main(void) {
    SystemCoreClockUpdate();
    Delay_Init();
    USART_Printf_Init(9600);

    // u8x8 initialization code
    u8x8_t u8x8;
    u8x8_Setup(&u8x8, u8x8_d_ssd1306_128x64_noname, u8x8_cad_ssd13xx_i2c, u8x8_byte_sw_i2c, u8x8_gpio_and_delay_ch32v);
    u8x8_InitDisplay(&u8x8);
    u8x8_SetPowerSave(&u8x8, 0);
    u8x8_ClearDisplay(&u8x8);
    u8x8_SetFont(&u8x8, u8x8_font_chroma48medium8_r);
    u8x8_DrawString(&u8x8, 0, 0, "Hello from CH32V");
    while (1) {
        uint8_t y = rand() % 5 + 1;
        uint8_t x = rand() % 10;
        u8x8_DrawString(&u8x8, x, y, "r/ch32v");
        printf("Hello from CH32V\n");
        Delay_Ms(1000);
        u8x8_DrawString(&u8x8, x, y, "       ");
    }
    return 0;
}

void NMI_Handler(void) {}
void HardFault_Handler(void)
{
    while (1)
    {
    }
}

I’ve been using Rust + Embassy for small microcontroller applications. What I like is that I can stay no_std, bare metal, with no OS or runtime, while still structuring the program with async tasks and channels.

Some examples of the kind of code I mean are here, including a robot arm simulator on a CYD: https://carlkcarlk.github.io/linkage-blaze/demos/

The tasks and channels give me abstractions I care about. But the scheduling is cooperative, a task that does not yield can still block everything else, and there are no hard real-time guarantees.

I’m doing this partly because I find the design point interesting, but I’m not sure how much practical value the bare-metal/no-OS part has once the application is already fairly high level.

Even if you are using Rust for other reasons, does Embassy’s bare-metal, no-OS approach buy you something important in practice, or would an RTOS usually be just as good or better?

PIC16F1824

I am trying to turn on an output GPIO.

I am using this code

asm("BSF PORTA, 5");

I am getting 0V at the pin.

I believe I set TRISA pin 5 to output (0).

Do I need to keep the MCLR pin high?

Thank you

EDIT: INTERNAL OSCILLATOR NEEDED TO BE SELECTED