Just thought I'd share my current project: Taking an old ISA sound card I got off eBay and wiring it up to an Arduino to control its OPL3 synth from a MIDI keyboard. I have it mostly working now.

No intention to play audio samples, so I've not bothered with any of the DMA stuff - just MIDI (MPU-401 UART) and OPL3.

It has involved learning the pinout of the ISA bus connectors, figuring out which ones are actually used for this card, ignoring the standards a little (hello, amplifier chip that is wired up to the +12V line but which still happily works at +5V...)

Most of the wires going to it are for each bit of the 16-bit address and 8-bit data. Using a couple of shift registers for the address, and a universal shift register for the data. Wrote some fairly primitive ISA bus read/write code, but it was really slow. Eventually found out about SPI and re-wrote the code to use that and it became very fast. Had trouble with some timings, fixed those.

The card is an ISA Plug and Play card, meaning before I could use it I had to tell it what resources to use. Linux driver code and some reverse-engineering of the official Windows/DOS drivers got me past this stage.

Wired up IRQ 5 to an Arduino interrupt to deal with incoming MIDI data, with a routine that buffers it. Ran into trouble with the interrupt happening during I/O and needing to do some I/O inside the handler and had to set a flag to decide whether to disable/re-enable interrupts during I/O.

It looks like total chaos, but the various wires going across the breadboard are mainly to make it easier to deal with the 16-bit address and 8-bit data lines. The LEDs were initially used to check what addresses/data were being sent, but now only one of them is connected and indicates when the interrupt handler is executing.

There's still a lot to do after that though - MIDI and OPL3 are two completely different things so I had to write some code to manage the different "channels" of the OPL3 chip. I have it playing multiple notes at the same time but need to make it able to control the various settings over MIDI. Eventually I might add some physical controls to it and get a PCB made.

The fun part is, I only vaguely know what I'm doing with the electronics side of this. I didn't know what a "shift register" was before this project, nor anything about the workings of the ISA bus. I knew a bit about MIDI (both the protocol and generally how the MPU-401 UART works) along with the operation of a sound card from a driver/software perspective, but everything else is pretty new to me.

As a useful little extra, I made some "fake" components that I can build the software against on a PC, to run some tests before uploading it to the Arduino (mostly just prints out the addresses it is going to try and write to).

Personal project: I design and build single-board computers with old processors like Z80, 6502 etc when I'm not being too lazy. A few run CP/M. One that's been more interesting in terms of digging deeper has been an 80C188, for which I've written a BIOS (despite the chip's built-in peripherals and interrupts being at non-standard addresses) mostly in C, which it can use to boot DOS from an image file on an SD card (bit-banged off the UART chip with FatFs). (Yes it's slow, but so is a 5.25" floppy.)

Work: My first project at my current job. Not particularly exciting compared to some stuff on here, but it got me into making useful contributions to the open-source CRM we used at the time. Was building a basic extension to deal with duplicated organisation names. So learned CiviCRM fairly deeply, a bit of Drupal, a bit of PHP. It's a shame we don't use that system any more, the community was cool.

Got an assignment in school to make an easy project in c for embedded real time processors with a free complexity level (it was really early in the course and many had never been programming before).

Since I've been working a few years in development I decided to create an own transmitter and receiver for an own protocol between processors (we had just spent a week to understand how to use existing protocols, but I made my own).

The protocol used only 1 line to communicate with half-duplex and we're self adjusting the syncing frequency during the transmission. I managed to transmit data up to 1 kbps after tweaking it a bit (the only holdback was the processors clock frequency).

Then I got the feedback from our teacher, which basically said:
"Your protocol looks like any other protocol out there. Have you considered using an UART?"

Like yeah, I see the car you built there looks like any other car out there, have you considered using a Volvo instead?

When you are retard and cross TX/RX lines, desperate measures will have to follow, like terminating hardware UART on start-up so that you can bit-bang over crossed TX/RX yourself...

Is there any good linux application to send FUCKING RAW data to a serial port?

Port in question: /dev/ttyACM0
Baud (nice if configurable): 9600

I want to send specific binary data. I want to send 0b00110011 or something like that to it, not some character or a hex value.

I've gotta create a bidirectional communication protocol to link 2-3 RPis over GPIO. I have between 4-5 pins for TX and 45 for RX, so each directional bus is that wide.
Even better, I have to assume 4 bit bus length unless told otherwise, since 4 to 6 pins on the GPIO are usually used for serial/UART, COM and/or 1-pin communications (for use to get a console, not to throw data down.)

The best part?

Needs to be a Python library.

i wanna die

Started a journey of serial exploitations and trying to read stuff with UART/debug pins. Holy fuck where are the UART pins!!

So I ran into a perplexing "issue" today at work and I'm hoping some of you here have had experience with this. I got a story-time from my coworker about the early days of my company's product that I work on and heard about why I was running into so much code that appeared to be written hastily (cause it was). Turns out during the hardware bring-up phase, they were moving so fast they had to turn on all sorts of low level drivers and get them working in the system within a matter of days, just to keep up with the hardware team. Now keep in mind, these aren't "trivial" peripherals like a UART. Apparently the Ethernet driver had a grand total of a week to go from nothing to something communicating. Now, I'm a completely self-taught embedded systems focused software engineer and got to where I am simply cause I freaking love embedded systems. It's the best. BUT, the path I took involved focusing on quality over quantity, simply because I learned very quickly that if I did not take the time to think about what I was doing, I would screw myself over. My entire motto in life is something to the effect of "If I'm going to do it, I'm going to do it to the best of my abilities." As such, I tend to be one of the more forward thinking engineers on my team despite relative to my very small amount of professional experience (essentially I screwed myself over on my projects waaaay too often in the past years and learned from it). But what I learned today slightly terrifies me and took me aback. I know full well that there is going to come a point in my career where I do not have the time to produce quality code and really think about what I am designing....and yet it STILL has to work. I'm even in the aerospace field where safety is critical! I had not even considered that to be a possibility. Ideally I would like to prepare now so that I can be effective when that time does come...Have any of you been on the other side of this? What was it like? How can I grow now to be better prepared and provide value to my company when those situations come about? I know this is going to be extremely uncomfortable for me, but c'est la vie.

TLDR: I'm personally driven to produce quality code, but heard a horror story today about having to produce tons of safety-critical code in a short time without time for design. Ensue existential crisis. Help! Suggestions for growth?!

Edit: Just so I'm clear, the code base is good. We do extensive testing (for lots of reasons), but it just wasn't up to my "personal standards".

Just turned myself inside out why parsing data from serial didn't work. A full day, and 20 minutes before going home I realize the uart interrupt function was too slow. I just didn't get all chars...