jerryr

Please create or point me to your product review site!

There are a lot of things I don't miss! x86 segmented architecture, for example. Even modern embedded programming on an ARM Cortex-M feels luxurious compared to not that long ago.

If you enjoyed this article, you might also enjoy The Man Who Mistook His Wife for a Hat and Other Clinical Tales by Oliver Sacks. It’s a book of essays about brain function and disorders, but each begins with an individual who exhibits particularly unusual symptoms. They don’t have tidy resolutions like this article, but the book is well-written and engaging—-as are the rest of Dr. Sack’s writings.

Not that they can’t also be contributing to Bazel, but I believe that Chrome uses GN.

It was also for a low-cost audio application, but it wasn't a toy. This was back in 2001 or so. The MCUs in this article all only have ~1KB ROM, which wouldn't have been enough for our audio samples. We needed >256KB. The "4-bitness" was just incidentally what Winbond offered with a large ROM at the time. However, the SunPlus that we later used in the toy also offered a large ROM with an 8-bit CPU for a similar cost. So, while I can't authoritatively say that 4-bit is dead, it does seem like there are a lot of alternatives in similar price ranges now.

That sounds very similar to my experience with toy development. For a toy that played a bunch of pre-recorded sounds, we used a 4-bit Winbond MCU (their MCU division is now Nuvoton) that had a tiny bit of RAM and a ton of mask ROM. Firmware development was done in assembly and targeted a huge (physically large) emulator for test/debug. When we were satisfied with the firmware, we'd send it off to our CM, who would then order the parts with our FW in ROM. They'd get back bare die parts, which were wire bonded to the PCB and then epoxied over (that miserable "glop top" packaging, which is the bane of many teardowns). Development was a bit painful, but high volume production was extremely cheap.

Edit: Oops. I conflated projects. The toy project actually used a SunPlus MCU, not a Winbond MCU. It was an 8-bit RISC CPU running at 5MHz with 128 bytes RAM and 256KB mask ROM. The ROM held both the program and audio samples. I don't recall what encoding was used for the audio.

I also really like his garlic video: https://jp.foundation/video/garlic-puree

This is a friend’s project. It’s a public domain, header-only vsnprintf that supports floats. It has zero dependencies, zero libc calls, no allocations, < 100B stack, < 5K on a Cortex-M with optimizations on. It’s meant for small systems where you need a full-featured printf without a huge footprint.

Ah, you're correct. I did think it was odd that they were able to make the debugger do anything in RDP2, but I misread it. That attack was indeed performed in RDP1.

The tl;dr is that researchers found 3 weaknesses in an STM32's flash protection scheme. For those not familiar, these chips offer three protection levels:

RDP 0 - unlocked, all flash/ram is accessible via the debug interface

RDP 1 - flash locked, you can connect a debugger and read out RAM/peripherals, but not flash. This is intended to prevent you from dumping the flash firmware image, but allow you to perform some diagnostics via the debugger.

RDP 2 - everything's locked down. The debugger cannot access RAM, Flash, or other peripherals.

The 3 exploits are roughly:

* In RDP 1, you can't read flash directly, but you can read anything that the firmware puts in RAM. The researchers were able to extract an entire flash firmware image by watching the results of a CRC self-check that the firmware performs upon boot. By resetting the microcontroller and very precisely controlling the amount of time it's allowed to run before halting it and dumping RAM, the researchers were able to back out the firmware image by observing the CRC progression in RAM.

* The researchers noted that the bit patterns used to represent the different RDP levels in flash were sub-optimal in that only a single bit needs to be flipped to downgrade from RDP 2 to RDP 1. By deencapsulating an RDP 2 microcontroller and exposing it to UV using a carefully-constructed mask, they were able to perform such a downgrade.

* The researchers crafted their own SWD debugger interface that performed less initialization than ST's stock debugger and thus didn't immediately lock down a microcontroller in RDP 1 mode when the debugger was attached. With this modified debugger, they discovered that they could issue a flash read that would lock down the micro as expected, but would also occasionally result in the protected flash data actually appearing in the read buffer (likely due to some internal race condition bug in the microcontroller's hardware). Thus it's possible to automate a brute force extraction of the entire flash in RDP 1 mode.

Edit: Changed RDP 2 to RDP 1 in description of 3rd exploit.

Perhaps it wasn’t the intent, but I find it inspiration not to dwell on my past decisions but to move on and make new ones.

Hi HN! You found my site again. Here's the previous discussion from almost exactly year ago (warning, this links to the profane version): https://news.ycombinator.com/item?id=13437182

I just tried disassembling the hex file. Unfortunately, the code protect bits are set (location 0x300008 is 0x00). This means that the ROM from 0x000800 to 0x007FFF will read as zero. And indeed, that entire space is filled with zero. So, I think we're missing much of the actual firmware.

Edit: And the reset vector begins with a branch to location 0x001ACA, which is all zeroes, so I'm pretty sure most of the firmware was not read out due to the code protection.

Wouldn't that argument be easily settled by discussing the implementation of a hash table?

I think people in this thread are getting a little hung up on the fact that there might not be a clear-cut or widely-accepted definition of "REST". And, sure, if you're only passing people who happen to mention the exact keywords you have in mind, then I'd say your interviewing methodology is flawed.

But I don't think that's what you're doing. I think you're hoping to spark a conversation about what REST is and you've given us a few keywords here as examples of what you might expect to come up in this conversation. And this seems perfectly reasonable to me. I would expect that an engineer with relevant experience and an inkling of insightfulness and professional curiosity would be able to hold such a conversation.

I'm an embedded hardware/software developer with only a lightweight exposure to web programming, and I feel that I could answer that question adequately.

I'd be curious to hear the types of responses you're actually getting. I've had to do a lot of interviewing in my career and I've encountered "simple" questions that throw nervous candidates off of their game simply because of a misunderstanding. Sometimes the simplest questions can be the worst because the candidates expect something harder and overthink it. So, you might play with the phrasing a bit, or have different ways of asking it in case they seem to freeze up. For example, "could you name and describe some of the defining properties of a REST API?" or "could you tell me what makes a REST API different from a [SOAP, etc.--pick your favorite alternative] API?"

That said, I would expect a reasonably bright, experienced candidate to understand what you're asking fairly quickly. If you have to re-phrase it 3 times and they're still stuck, they're probably not a good fit.