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.

Around the time of the Pure Digital acquisition, Cisco was making a push into the home. They started buying up consumer brands like Flip and Linksys. I can't speak to why--perhaps their enterprise growth had slowed due to the recession? Anyways, they floundered with the consumer brands for a while before killing them (Flip) or selling them off (Linksys). People hypothesize that the rise of smartphones killed off Flip, but I really believe it was the Cisco acquisition that killed it. I think Flip could have otherwise survived for a few more years out of a tail of slow adopters before pivoting to a GoPro-type market.

I worked on the Flip Mino, but as a consultant, not a Pure Digital employee. I followed them fairly closely, but didn't have much inside information, so the above is just my own hypothesis. Though OP's article seems to have come to the same conclusion.

And before the camcorder, they did a single-use still camera too. Here's an old press release about it: https://cvshealth.com/newsroom/press-releases/cvs-launches-w...

My theory: Hardware and hardware tooling has tangible capital costs. Most people are acutely aware of what they've spent on hardware, so discarding it can be quite painful. Estimating is hard and many devs are terrible at accounting for their time. A rewrite is often underestimated (people always seem to forget about testing--they especially seem to forget how much time they spent manually testing to get to a working state) so the costs of writing software aren't as visible. In my experience, good, seasoned devs feel just as bad about discarding software as they do hardware.

Edit because I posted while running out the door and probably could have explained better: Elsewhere in this thread, dmckeon linked to Spolsky's article on why rewrites are bad. This does a better job than I did of explaining the hidden costs of a software rewrite. In my experience, these costs are rarely tallied up and written down such that they're as visible as, for example, the $50K one spent on creating an injection molding tool, or the millions spent in NRE and component purchases to get an assembly line running. Or even the few thousands spent on a prototype PCBA. In hardware, these capital cost numbers are always in your face. So, even though hardware devs are as bad as software devs in estimating time and accounting for testing, the capital costs provide a built-in, visible incentive to avoid unnecessarily discarding work.

There was an app called Minecraft Reality back in 2012 that would seem to prove otherwise: https://mojang.com/2012/11/announcing-minecraft-reality-for-...

It placed a Minecraft creation into your environment in realtime. Though it seemed mostly like a tech demo without much of a point, it was pretty impressive when I played with it.

I think they're suggesting a subconscious perception of the subtle differences in sizes that result from building with round numbers in metric vs imperial (e.g. 1 meter is different than 3 feet). This is interesting, but seems less likely than the more dramatic differences in architectural styles, materials, regulations, and zoning.

As an ex-owner of an outsourcing company, I've been on the other side of this. Without any disrespect intended in asking this, is it possible you've been without a project for so long because you don't have the most flexible skillset?

I can say that, in my company, when business was slower, we would often see the same few people constantly without work because they were either too inexperienced, too limited in their capabilities, or too inflexible in what they were willing to do.

We worked hard to try to give them opportunities--having them shadow more senior engineers on projects (the extra project help also gave our clients more bang for their buck and made us look even better as a group), getting them training, having them work on internal projects, etc. Not all companies will or can go this extra mile to find opportunities for you, but might be receptive if you structure and propose something that uses your down time to your mutual benefit.

If they're not receptive, or if you can't structure something like this in your environment, then you might consider moving on.

Edit: Actually, as others are mentioning, it was also way easier to staff people who were actively involved in the sales phase of a program. Volunteering to do research, prototypes, etc. was a great way for motivated people to help out during this phase. Since they were effectively already working on the program by the time it started, they were usually the ones who would wind up staffed on the program.

Interesting. I hadn't heard the "green thread" term before. Does anyone happen to know how this compares to Windows' "fiber" mechanism? I can't recall whether fibers actually run in user land.

Yeah, that seemed really incongruous. It left me wondering if I was missing some industry-specific context.

Yeah! I recently built a website that heavily uses Illustrator assets exported as svg. I was happy to have read that explanation before pulling my hair out over weird artifacts.

That probe is pretty small, but keep in mind that many of these need to be tucked into existing circuit breaker panels while maintaining certain clearances for regulatory reasons. They also need to be easy to install for safety and product adoption reasons.

I think we are saying similar things though. I worked on this project with Verdigris (though I was not personally responsible for the design of these probes) and, to your original point, the challenge is fitting these at a reasonable cost while achieving the desired accuracy. I guess I'm so used to low manufacturing costs being a given that I tend to focus more on the other aspects of the problem.

It's cost, size, and regulatory. Existing current probes that are magnetically coupled and thus don't require an electrical connection to the mains (which would be a safety/regulatory nightmare) are big: http://www.tek.com/current-probe

I just got a giant warning popup from Parallels (virtualization software) on MacOS that I need to update Parallels before upgrading any Windows guest OSs to Windows 10 Creator's Update. The update claims to fix an issue where Windows won't boot after updating. So, maybe one would want to block the update for reasons such as this? Not sure...it was easy enough for me to stop and update Parallels first, but maybe others have reasons for not doing so.

Cool. Presumably they're already doing this, but I'd really recommend observation to understand the environment in which the product will be used and then following up with user tests as they prototype. There can be some surprising or unintuitive ergonomic concerns around heavy machinery. For example, factory equipment with automated movement often requires two-handed operation. Even if it could be operated with one hand, many machines will have two buttons--one on either side of the machine--which must be pressed simultaneously. This ensures the operator's hands are out of harm's way during the automated movement. If the operator takes a hand off of a button to perform a hand-based gesture, the machine comes to a halt. Also, operators tend to develop a flow as they perform repetitive operations. If a tool breaks that flow, it will likely be rejected or abused.

It sounds like your acquaintances are targeting service technicians, not necessarily factory workers, so the above examples might not apply, but I'd imagine their targeted industry has its own ergonomic concerns.

Sorry to ramble at you. Just excited because it sounds cool.

Jawbone Bluetooth headsets actually contact your jaw to use the conducted vibrations to cancel background noise, similar to your idea. Disclosure: I worked on their first generation Bluetooth headset. I'm not certain the current generations still work this way.