What killed WSL for me was the incredibly janky way I had to share USB peripherals. usb-ipd works 80% of the time, all the time.
HN user
kenz0r
I've found the OnShape flow pretty good for this, using the Laser Joint and Auto Layout scripts he referenced - thread here: https://forum.onshape.com/discussion/14166/designing-laser-c...
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...
If you enjoyed the story, you might like Pantheon - https://en.wikipedia.org/wiki/Pantheon_(TV_series) which is based on a few short stories of a similar vein from Ken Liu
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.
Just to correct you on firearms. Police officers in Australia are generally issues firearms (semi-automatic pistols).
Yes, you can :) https://www.uncarvedblock.com.au/build-climbing-wall-at-home... gives you a bit of a guide, and if you search climbing walls on youtube, plenty of people have been building them.
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!
Petitboot does do x86 - we're using it on an AMD x86-64 network appliance.
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.
Serial interface, and GPIO reads are polled. Its a good first or second year uni project, but its not a product.
True, but from my recollection, most hardcards were running MFM or RLL disk controllers, rather than IDE.
As expected, the stuff that you really want to be able to replace (Screen, SoC, and RAM) are the ones you can't.
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
Shift 2 to get double quotes, and you'll need to assign line numbers
Try the example
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.
You're probably looking around the $2 - $2.5K mark for a professional equivalent, but they're a fair bit more robust inside.
Eg. https://www.opengearstore.com/ProductDetails.asp?ProductCode... - PCIe UARTs rather than USB, 2 GbE ports, a bunch more software smarts, and support.
MP3 support requires a decoder card according to the page; I remember running into the same issues on my 486.
MIPS (Cavium and Broadcom) and PowerPC (Freescale QorIQ) are big players in the Networking market currently, but the next generation of processors from those companies mentioned above will be ARMv8
It thins the oil, so there are less frictional losses, at least until the bearing surfaces get damaged.
Should be pretty quick! we build appliances with the Armada 370 CPUs (Single core Cortex A8, but same Ethernet and bus IP), and they can route/NAT at 800-1000 megabits between 2 interfaces (at 1500 byte packets)
That still ties it to a physical VM host doesn't it - what happens if you want to host the VM in a cluster and have it migrate?
One of the more compelling use-cases for USB over IP is connecting proprietary licensing dongles to virtual machines.
MASQ refers to IP Masquerading or Network Address Translation (NAT)
You can, or you can use the gpio_keys driver to nicely handle it in kernel space and give you key presses via the event subsystem. One small device tree snippet, and you're sorted. There is even a gpio_keys_polled variant if you can't get interrupts from your GPIO controller.
Selenium is great for this. For this particular case, it won't access an element unless its visible, so you can validate that the scroll happens on button press. Easy to make a quick smoke test that can run in a few browsers
I don't think that is exactly true. DRAM from SDRAM up has had a number of mode registers to control the ram. More info here: http://en.wikipedia.org/wiki/Synchronous_dynamic_random-acce...