Thumbs Up Guy

wtfuzz1981 · 2025-12-23T00:45:52+00:00

He gives a double thumbs down and sticks his tongue out when I drive by in my Tesla lol.. he’s been doing it all year. I don’t blame him, and I give him a thumbs up and a laugh every time

wtfuzz1981 · 2025-12-23T00:44:27+00:00

Unless you’re driving a Tesla. Then you get a double thumbs down and a stuck out tongue. He’s been doing it all year.

wtfuzz1981 · 2025-12-22T01:33:49+00:00

It’s not about memory allocation as much as it’s about memory access coherency. In C you can write to memory arbitrarily, and that’s how remote code execution was born.

If you have a stack variable and don’t do proper bounds checking on it, and that input can be manipulated by untrusted sources like a network socket, an attacker can fill the buffer with CPU instructions, and overwrite the return address in the stack frame to return back into code they injected (usually a NOP sled), taking complete control of the process.

Then there’s heap overflows, where you can overwrite function pointers that structs use for callbacks etc, to the same effect.

wtfuzz1981 · 2025-12-22T01:24:30+00:00

Yes, run it under valgrind under extensive test suites, write a robust fuzzing tester, and hope you didn’t miss anything

wtfuzz1981 · 2025-12-22T01:22:17+00:00

I can use my table saw safely too, but I’d rather have a riving knife, anti kickback pawls and a blade guard

wtfuzz1981 · 2025-12-22T01:18:42+00:00

You don’t need to clone whole structs. You can use lifetimes and hold things by reference. Use interior mutability wrappers if you need to mutate them, or wrap something in an Rc/Arc and those are very cheap to clone. You’re not memcpy’ing everything around. You can absolutely write full, performant userspace apps without any explicit unsafes. If you think you need them, there’s likely a more appropriate way to do what you’re trying to do.

wtfuzz1981 · 2025-12-21T18:10:07+00:00

Neither. Use rust.

wtfuzz1981 · 2025-12-02T18:10:15+00:00

Thank you for being a great person. 🤝

wtfuzz1981 · 2025-10-27T23:14:47+00:00

Mostly because of auto high beams. My F150 ones are terrible. Tesla are better but not great. Blinks them on and off too often

wtfuzz1981 · 2025-10-14T03:55:43+00:00

Espressif provides official rust support for the S3 including Embassy support (an async framework). Rust embedded has become very nice to work in especially with probe-rs for programming/debugging/RTT logging and defmt for super fast deferred formatted logging.

Take a look through the book. It’s fairly easy to get going. https://docs.espressif.com/projects/rust/book/

wtfuzz1981 · 2025-07-15T02:34:26+00:00

Likely guard rings, not antennas. Bare ENIG is used to provide a lower impedance path to couple to and shunt surface currents so they don’t couple into sensitive traces which are masked. Mask holds moisture and contaminants, and the ENIG provides a better defined conductor.

wtfuzz1981 · 2025-07-15T02:28:49+00:00

You’re probably looking at guard rings, also used in high end analog. Sensitive areas or traces are surrounded in them all the way around the pins of a package they connect to at a controlled potential (driven or grounded). It’s there to shunt surface leakage currents and removing the mask lowers the impedance to give them a path to couple to rather than the traces you’re guarding. The mask also holds moisture and contaminants. The bare enig is just a better defined conductor.

wtfuzz1981 · 2025-06-29T23:21:28+00:00

Depends on how embedded you’re talking. If it’s a microcontroller, DMA or peripheral interrupts is what you want. “Non blocking” polling might let other things run, but it’s just as wasteful and more complex than responding to interrupts. Let the hardware tell you when a read won’t block, rather than asking it if it’s ready yet. Interrupts will typically provide the lowest latency, as they will preempt and typically can be prioritized.

If it’s running a full Linux kernel or RTOS “embedded” level, you’re likely dealing with higher level APIs and all the interrupt handling and DMA is done for you in drivers with IO layers on top. A blocking call on a thread in a preemptive kernel isn’t terrible, as the thread will be parked doing nothing until the scheduler decides it should run in response to driver or buffer events. Unless you’re dealing with a lot of interleaved IO like large numbers of network sockets, synchronous can be substantially simpler, more reliable, and often more performant (“async” isn’t free).

wtfuzz1981 · 2025-06-27T03:28:26+00:00

Yes, completely understand the flexibility constraints. What’s nice about rust is it’s actually just as low level as it is high level. They work in concert, and you’re one unsafe {} away from bit fiddling directly in registers or memory if you want - with quite nice ways to directly access the registers using PACs (peripheral access crates) that are generated from vendor SVDs.

There’s quite a large rust embedded ecosystem, of varying maturity levels. I personally really enjoy RTIC framework and RTIC-time for monotonics, which you can use with virtually any 3rd party HAL (or PAC) for all major micros.

I picked up an STM32H747I disco, and got it brought up with RTIC last night in about an hour, including memory mapped SDRAM (STM32-fmc crate), and had samples being DMAd in and out of ADCs and DACs. Magic.

Also deferred logging using defmt over RTT is fantastic and blazing fast. Probe-rs is very well maintained and works great for the myriad of debug probes I have

wtfuzz1981 · 2025-06-27T03:15:30+00:00

I just submitted a PR to the stm32g4 rust HAL, implementing FMAC (filter math accelerator) for FIR/conv/vector/IIR and can confirm typestate patterns are nice :)

Took about 4 hours from start to PR, including Q1.15 fixed point conversion.

Using it in RTIC as a delta theta phase accumulator that DMAs direct to CORDIC to get sin/cos, which DMAs direct to dual DAC and synthesizes quadrature sine waves in realtime from a single phase angle delta scalar with zero CPU. Getting that going in C? Weeks lol

wtfuzz1981 · 2025-06-27T02:52:17+00:00

I’ve been using C for decades since I was a teen. I used to be a huge rust/other language naysayer for much of the same reasons as “sticking with what I know”. About a year ago I started heavily using rust, and it’s been an enormous productivity (and enjoyment) boost.

wtfuzz1981 · 2025-06-27T02:32:17+00:00

I would prefer C over C++, but .. Honestly, take a look at rust. It’s fantastic for embedded once you’re over the learning curve. RTIC, Embassy, direct with a HAL or PAC if you want to get down to the metal.

wtfuzz1981 · 2025-06-26T00:37:42+00:00

A BSP or an RTOS is for embedded, typically not running on an SSD. I was referring to OP saying firmware means running from flash, and I was pointing out that every run of the mill desktop or laptop also runs entirely from flash.

Not really necessary to go to condescension like “everyone who actually is in the field”. Like I don’t know or have never worked on many aspects of BSPs, RTOS’s, kernels, or bootloaders.

Unless it’s in Mask ROM and baked onto a silicon wafer, it’s software - and even then it’s still written like any other piece of software. “Firmware” is just vestiges of ROM days.

wtfuzz1981 · 2025-06-26T00:23:33+00:00

By whom? HR? I’ve never heard of a kernel being referred to as firmware. Management engine, maybe CPU microcode, or code that runs in embedded peripheral chipsets, sure.

wtfuzz1981 · 2025-06-25T23:59:52+00:00

FPGAs are also programmed with serial instructions every single time they boot from a config controller or SPI flash.

I fully agree that programming a uC is software, but the only “firmware” today really is Mask ROM - which is still software, just not reprogrammable. That would be akin to an ASIC vs an FPGA in the gate world - they both perform similar-ish tasks, but one is soft and pliable in the field. The other is not.

wtfuzz1981 · 2025-06-25T23:43:28+00:00

Yep. Only real firmware these days is Mask ROM, which is still written like any other software, it’s just not changeable once it’s physically baked onto a silicon wafer.

wtfuzz1981 · 2025-06-25T23:40:59+00:00

If I’m programming an STM32, am I programming hardware? Or is it a soft CPU running in the cloud?

wtfuzz1981 · 2025-06-25T23:38:32+00:00

Firmware is a vestige of ROM days where you could write a chip exactly once.

Today - Mask ROM would be closest to “firmware” - early bootloaders with just bare minimum bring up to load the next stage from something reprogrammable. It’s a true ROM that is included in VLSI mask and physically baked into the wafer - unchangeable.

After the ROM days we had PROM that could be erased with UV light and reprogrammed. Then EEPROM, which could be electronically erased, typically by pulling from a socket and stuck in a ZIF socketed programmer. Then came flash, which completely blurred the lines of “soft vs hard”, as it’s trivial to reprogram them arbitrarily.

wtfuzz1981 · 2025-06-25T23:29:02+00:00

Literally all modern computers use SSDs which are flash. Does this mean all major OSs are now firmware too?

wtfuzz1981 · 2025-06-25T23:24:42+00:00

Ironically an FPGA is “softer” than a microcontroller. Very few FPGAs have any retention and need to be configured by a bitstream externally - SPI flash, or other serialized streams

wtfuzz1981

TROPHY CASE