Login
You're viewing the y.diskcat.com public feed.
  • Nov 10, 2026, 9:21 PM

    Having learned the hard way from several microcontroller projects, if you're going to talk to a microcontroller, packetize your communication protocol. Give yourself a message type field, flags, message id, and packet length, and then read whatever out of that.

    then, when you are struggling to debug something, you can easily extend your protocol with in-band debug messages that can be discriminated from normal control traffic.

    the overhead is really minimal.

    #embedded

    💬 3🔄 0⭐ 0

Replies

  • Nov 10, 2026, 9:24 PM

    also, abstract your communication transport. in C++ this is easy to do as an abstract base class, in Rust you would define a trait interface.

    The bulk of your code should not know it is talking over USB.

    Now if you ever want to talk to your microcontroller over TCP/IP you can implement a new transport and not have to rewrite absolutely everything.

    💬 1🔄 0⭐ 0
  • Nov 10, 2026, 9:27 PM

    these posts are directed at me, four years ago.

    In my defense, splitting my debug messages out onto the serial UART made sense for #ArduinoX86 when I started that project because the Arduino MEGA I was using had no USB-CDC channel, it was all UART; so a second UART was a logical extension.

    But now having a 115kbaud serial UART hanging off an Arduino Giga with a 480Mbps USB-CDC channel is a bit stupid.

    💬 3🔄 0⭐ 0
  • Nov 10, 2026, 9:30 PM

    This also means if I ever want to host #ArduinoX86's on the internet, I don't have to worry about providing a ton of USB ports; they can all just hang out on a special firewalled SSID, and sit on a shelf in my closet out of the way

    💬 1🔄 0⭐ 0
  • Nov 10, 2026, 9:34 PM

    I had both the 286 and 386 boards plugged in today to debug the protocol changes, and I got an especially stupid idea

    I added support in the GUI to connect to two CPUs at the same time.

    And then we can wire IO ports together, via mail slot ports. Two pairs of IO addresses indicate data and data-ready in both directions - like a virtual serial link.

    So now the 386 can talk to the 286 and vice versa. What is the point of that? I don't know.

    💬 2🔄 0⭐ 0
  • Nov 10, 2026, 9:36 PM

    The multi-cpu support itself is useful since I want to implement support for a 'consensus' mode where I can execute the same code on say, two different steppings of 8088, and see how they may differ.

    💬 1🔄 0⭐ 0
  • Nov 10, 2026, 9:36 PM

    Differences in registers, flags, or cycle execution can be highlighted.

    💬 1🔄 0⭐ 0
  • Nov 10, 2026, 10:01 PM

    it still blows my mind that a i soldered a 138-pin 386EX to a PCB I slapped together in KiCad without any sort of engineering degree and it actually functions

    💬 2🔄 0⭐ 0
  • Nov 10, 2026, 10:03 PM

    actually I wonder if @MuseumJoe would be interested in carrying #ArduinoX86 boards.

    The 8088/8086 board is completely passive and the software GUI is becoming quite mature. It has huge potential for use by educational institutions

    💬 3🔄 0⭐ 0
  • Nov 10, 2026, 10:14 PM

    The best thing about ditching the serial UART though - I get two 5v tolerant GPIO pins back.

    This lets me hook up the PEREQ and /PEACK pins that implement the CPU<->FPU handshake. Capturing those pins in future FPU instruction tests isn't strictly necessary for emulation, but they will make the tests that much useful as an oracle of hardware behavior

    💬 0🔄 0⭐ 0
  • 💬 0🔄 0⭐ 0
  • Nov 10, 2026, 11:27 PM

    @gloriouscow I mean, certainly. I can make them available for less than folks can get them in small batches on their own.

    Not sure what the demand is, but I'm always amenable to a conversation.

    💬 0🔄 0⭐ 0
  • Nov 11, 2026, 7:17 AM

    @gloriouscow I know enough people with an engineering degree who completely unable to design a PCB.
    You can get very far without an engineering degree by just following best practices. The engineering degree however might help you understand where they come from.

    💬 0🔄 0⭐ 0
  • Nov 10, 2026, 10:32 PM

    @gloriouscow I’m sure Intel had a point when they glued two completely different CPU cores with different instruction set capabilities into a single socket *stares in Alder Lake*

    💬 1🔄 0⭐ 0
  • 💬 0🔄 0⭐ 0
  • Nov 10, 2026, 9:35 PM

    @gloriouscow Though if you do only have a UART handy, the popular UART<->USB dongles have reliably supported 1Mbps and 3Mbps operation for about a decade now, so there's definitely no need to limit yourself to 115kbps like it was the early 90s.

    💬 0🔄 0⭐ 0
  • 💬 0🔄 0⭐ 0
  • 💬 0🔄 0⭐ 0
  • Nov 10, 2026, 9:52 PM

    @lena good point. i do have a version field in the connect message - is there a good rationale to put it in every packet?

    💬 1🔄 0⭐ 0
  • Nov 10, 2026, 9:54 PM

    @gloriouscow if you later realize that your message format is total crap and want to change some fields, it means that you'll know immediately when something isn't compatible instead of getting silent problems because of fields getting misinterpreted or something

    💬 0🔄 0⭐ 0
  • Nov 10, 2026, 9:55 PM

    @lena ah yeah that's a good point, you can have version-specific packets.

    i sort of do that in the payload, i have multiple register-set payload versions

    it's good advice though

    💬 0🔄 0⭐ 0
  • 💬 1🔄 0⭐ 0
  • Nov 10, 2026, 9:56 PM

    @thias

    i realize that this is obvious to most people with embedded experience and i'm not inventing anything new, i'm just helping out other dumbasses like me who buy an arduino and start plugging things in not comprehending how much they will hate themselves later

    💬 1🔄 0⭐ 0
  • Nov 11, 2026, 6:25 AM

    @gloriouscow oh, it was not meant as a criticism, we all live and learn.
    IFF is not an embedded format per se, it is a container from the 16 bit era, it was mostly used on the Amiga. Very simple to implement.

    💬 0🔄 0⭐ 0