One thing that wasn't mentioned is that its important to measure the plywood you're using. 18mm ply can vary from 17 to 19mm so when you're making tight finger joints its important to know the thickness of the sheets that the parts will be made from.
Once it comes to actual cutting, the tool (in my case, a water jet) will often have an auto-nester to lay out the parts, but being able to prototype the part nesting in CAD means its faster to optimise the design to fit the sheets you've got.
My tenure at Amazon was during the meeting link era, rather than putting everyone in a room - I agree, way better. Get your secondary oncall to give updates to the room, while you dig in and figure out what is actually happening in relative peace
If you _must_ use I2C, then look at SMBUS if its an option for the parts. I2C's biggest failing is that there is no protocol level timeout, so one stuck device can block your entire bus unless you have a reset line for all the peripherals on it.
https://www.analog.com/en/resources/design-notes/guide-to-co...
I had a good one with a thesis student I supervised. The security micro she chose was designed to sit between SPI Flash and the main SoC, so a big feature was hardware accelerated SPI slave support. Guess what feature didn't work on the dev board...
I guess it depends on what they're trying to say (which isn't clear). When you get an AWS machine with 36 vCPUs, if you pick Intel, you get 36 threads, if you pick a Graviton2, you get 36 Cores.
Mine is framed in 70x35mm pine, and built from formwork plywood (formply), which is 17mm thick. The holds attach with 3/8th inch bolts that go into t-nuts in the back. I still need to give the formply a bit of a sand and put a non-slip coating on it, as the holds can rotate if I've not recently tightened them.
I built a climbing wall at home for myself and the kids, since the bouldering gyms have closed. Its not as good as a gym, but hopefully I'll keep my some of my grip strength!
Polling GPIOs is bad, because you miss events. Looking through the source code, the author has functions to get the state of GPIO pins, which send a command over the USB serial port, then read the output. This is fine for things that don't change very often, but if you've got a keypad, or something that may have a relatively short pulse width, you really want a notification that something has happened (GPIO 4 just transitioned from 0-1). The simple way of doing that for this project would be for the hardware to send a message when that happens - its easy to set up interrupts on the MCU, and then send a message back down the serial channel saying what happened. Latency won't be great, but you shouldn't miss things. The Serial interface (over USB) isn't too bad, but will add latency over a raw USB interface.
The LLVM backend that has been written generates code that directly runs on the Videocore GPU, which also handles the early boot process. Your link is concerned with code that runs on the ARM core, and interfaces with the GPU via the existing code running on the GPU
As the poster below said, GbE is mandated by a lot of data centres. 2 ports is also pretty useful too - you can aggregate them if you're concerned about reliability, you can use the console server to segment out a management network etc.