I like the single C file, but Docker if you want all the examples approach, that's really convenient for embedded.
Test coverage looks good as well, be interesting to see the metrics.
This would be quite cool for adding scripting to medical devices, avoiding the need to revalidate the "core" each time you change a feature.
An interesting comparison would be against an embedded WASM bytecode interpreter like https://github.com/bytecodealliance/wasm-micro-runtime, which is still much larger at 56.3K on a Cortex M4F.
Maybe WASM is just a more complicated instruction set than the smallest RISCV profile?
Wasm-mvp is very simple, especially if you drop the floating point instructions. But WAMR supports a lot of extensions - https://github.com/bytecodealliance/wasm-micro-runtime?tab=r.... There is a garbage collector, jit, WASI, threads, debugger support etc.
It would be operating off rectified DC (like an induction hob) or using a SMPS operating at ultrasonic frequencies to deliver a lower DC voltage, you wouldn't get the 50Hz buzz even if there was a transformer.
The best part I find about ChargerLab teardowns is identifying all the passive and discrete components.
Western distributors tend to only stock western/japanese brands of these, but they can make up a sizable fraction of the BOM (especially electrolytic capacitors) so knowing who the big players are comfortable with using is very handy. LCSC stock a lot, but its nice to know which suppliers have been proven in use.
> but its nice to know which suppliers have been proven in use.
Watch out. Some of the suppliers you’ve never heard of are capable of delivering good parts to companies like Apple but still have ultra cheap parts available retail.
It can, it just needs the two resistors, which is the cheapest possible thing the standards committee could have asked manufacturers to do.
USB-C gets complicated at the high end, but for basic functionality I think the standards committee did a very good job at making the cheapest way to do it the correct way, e.g. a USB-C to 3.5mm audio adaptor can be entirely passive, it just needs the right resistor in it.
Then a lot of phones don't support it, so it took me three attempts to find a usb-c to 3.5mm adapter that didn't have it's own DAC that would work with my phone's FM radio lol
>e.g. a USB-C to 3.5mm audio adaptor can be entirely passive, it just needs the right resistor in it.
How does that work? is each USB-C host port, or downstream USB-C hub port required to contain a stereo DAC? Does the standard impose performance requirements like dynamic range, noise, minimum sample rate,...? Does it also mandate the jack can be used for mic / line-in? Does it similarily stipulate inclusion of an ADC in each port?
It doesn't mandate any of that, it's an optional feature.
The data pins are repurposed for analog audio, so it won't work with hubs. You'd of course need a DAC for output and an ADC for mic input, but the point is to replace a headset jack, so you'd have those already.
I think the most recent surge is due to LLMs, the only way to (easily) apply them is to have some form of code like textual representation of your problem domain so "circuits as code" is the obvious way to wedge them into electronic engineering.
Kicad also makes it easier to make such startups as it has an open file format with several different free viewer tools and lots of content (schematics/footprints). If that ecosystem didn't exist I don't think you would see as many of these startups around, but with that you can launch one of these tools within a initial VC funding
The article links to a Linux implementation that does it with off the shelf WiFi hardware. You do need specific features in the hardware/firmware, but there are consumer devices that have that e.g. Atheros AR9280.
It currently drops connections to an AP, but the authors of the implementation seem to believe this could be fixed:
> OWL does not allow a concurrent connection to an AP. This means, that when started, the Wi-Fi interface exclusively uses AWDL. To work around this, OWL could create a new monitor interface (instead of making the Wi-Fi interface one) and adjust its channel sequence to include the channel of the AP network.
The cable is cooled by a mix of water and glycol, which runs through the cable and also cools the connector pins. Tesla use this in their supercharger cables, as without it the cable would be too heavy.
This is really well documented with lovely schematics, and the link in the github to the proper "korg style" toggle switches [1] on AliExpress is worth the read.
The code [2] is very nice as well, showing how clean a bare metal Pi Pico project can be.
I like the single C file, but Docker if you want all the examples approach, that's really convenient for embedded.
Test coverage looks good as well, be interesting to see the metrics.
This would be quite cool for adding scripting to medical devices, avoiding the need to revalidate the "core" each time you change a feature.
An interesting comparison would be against an embedded WASM bytecode interpreter like https://github.com/bytecodealliance/wasm-micro-runtime, which is still much larger at 56.3K on a Cortex M4F. Maybe WASM is just a more complicated instruction set than the smallest RISCV profile?
reply