Many airlines are going much further than this, for instance Virgin Atlantic ban you from either charging or charging from any power bank, and you can't keep them in the overhead locker, you must keep them next to you in case it starts burning spontaneously!
They have a "fire containment bag" they can chuck it in should you notice it getting hot or smoking.
TFA does directly mention the NPU "Arm-China Zhouyi: 30 TOPS (Dedicated)"
"you cannot simply use standard versions of PyTorch or TensorFlow out of the box. You must use the NeuralONE AI SDK."
Neon is a SIMD instruction set for the CPU, not a separate accelerator. It doesn't need an SDK to use, it's supported by compiler intrinsics and assembly language in any modern ARM compiler.
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?
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.
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.
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.
Brushless drone motors suffer from too high a kV (~operating RPM), needing a lot of gear reduction for this kind of application, but I take your point about volume.
Gimbal motors (also in drones) are closer to what is needed, and often come with encoders and centre pass through holes for cables.
Some manufacturers now make larger versions [1] with gearing and a built in motor controller, originally more for robot dogs than robot arms so backlash etc is worse, but the low gear ratio lends itself to cobot type.
For more conventional robot arms (high precision and stiffness) the harmonic drive gearbox patents have expired so there are some [2] of those coming out of china. This offers a really high reduction and very low backlash.
Reducing the RAM requirement to 8GB to fit this on my Macbook Air M2 (with room left for other running apps), I get the same figure (66 GB/s) regardless of the number of threads.
If I actually set it to the size of physical memory performance is _much_ lower, as OSX tries to compress the RAM it is using.
You can "freeze" micropython modules and have them saved in flash with Micropython, where flash only stores the precompiled bytecode.
If your module contains stored data in the form of an immutable object, like a string or bytes(), it will be read straight out of flash without copying to RAM first.
This needs you to run some code on a desktop computer to perform the freezing though.
Some other existing options in this space (not all web based) are
- https://pymeasure.readthedocs.io/en/latest/ python Framework for running science experiments, getting hardware to go through a set of steps and plot the output. Includes a GUI.
- https://plotjuggler.io/ for really fast live time series plotting in C++/OpenGL, very fast and quick to chuck data at (just wrap it in JSON and throw over UDP) but lacks any form of input. Ideal for systems running at kHz etc, I've used it to tune motion control systems.
- https://foxglove.dev/ aimed solidly at robotics (think self driving vehicles) renders time series plots, 3D renders and point clouds, log statements etc, and supports inputs too. All written in HTML and you can write extensions for it. Unlike others, it can support a much larger data file on a server and live stream the bit you are currently viewing to your browser. Not as fast for smaller things though.
This sales pitch ignores cloudflare workers, which sound pretty similar to me, with both webassembly and key-value storage.
The distinguishing part of the articles option seems to be that webassembly functions are uploaded in an OCI container, which I don't think anyone else supports, and I don't think was designed with this use case in mind?
Texas Instruments has also done interesting work in this area with "Compute Through Power Loss" where they use the non volatile FRAM in some MSP430s as working memory [1]
I don't think it needs the kind of compiler tricks this article describes though, instead it's just different hardware. I would be quite interested in seeing a benchmark of the technique in this paper (fast computation in SRAM and cleverly timed checkpoints to Flash) vs just running the stack in FRAM to start with, especially on this MSP430 that has both all 3 memory typed and can work as an RFID tag [2]
There is the mikrobus, grove, and qwiic connectors, all of which will be GPIO, I2C and likely (for Mikrobus) SPI as well.
The reason the SoC says "up to 170" as they are multiplexed with the ethernet, display and camera interfaces, so since this board has all 3 there are likely not many GPIO actually left to pin out
They have a "fire containment bag" they can chuck it in should you notice it getting hot or smoking.
https://www.virginatlantic.com/en-US/help/articles/powerbank...