HN user
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.
https://www.virginatlantic.com/en-US/help/articles/powerbank...
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.
Really neat clean code!
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.
https://github.com/seemoo-lab/owl
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.
https://www.cpcworldwide.com/Liquid-Cooling/Electric-Vehicle...
Marimo does this for python, by tracking dependencies.
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.
[1] https://www.aliexpress.com/item/32958319752.html
[2] https://github.com/shmoergh/hog/blob/main/boards/midi2cv/src...
Smallest Swissbit do is 512MB, but that's as it's SLC flash so far lower capacity. https://www.swissbit.com/en/products/product-finder/products...
Looking at pricing, 1GB is only about 25% more in unit quantity.
https://www.mouser.co.uk/ProductDetail/Swissbit/SFSD1024N1AS...
MLC/TLC flash will be 2GB and up, and most consumer cards you can buy.
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.
https://docs.micropython.org/en/latest/reference/constrained...
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.
If its "just storage", how is it any better for this application than a zip file?
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
Its (presumed) competitor, MIPI-CSI is not open source either.
SLVS-EC looks easier to interface with an FPGA at least, presumably the voltage levels are closer to standard, unlike MIPI D-PHY's exotic dual level switching that either requires an external IC, a passive resistor network of borderline compliance, or an FPGA (e.g. Lattice CrossLink) with the correct special inputs.
For production,its best to specify the important properties as you say, then let the contract manufacturer figure it out, rather than spend ages finding the cheapest 100nF 10V X5R 0402 cap. If it really matters, then add a "no subsititutions" column in your BOM.
For smaller prototype runs, PCB+Assembly suppliers like Eurocircuits have "generic parts" already in stock for common passive values, which they will give you for free.
Its only really if you are in a big rush or very budget constrained (e.g. a hobbyist or startup) that you would assemble yourself and hence buy all the parts.
If you do though, then Altium can happily manage multiple alternative options for the same "part" using ActiveBOM, including a search tool and distributor stock levels. I think the cheaper CircuitStudio option might have this too.
There is hardware available with the same microcontroller (ESP32) in a thick watch style case, but I don't know if anyone has ported meshtastic to it yet. On the face of it, power usage looks a bit higher due to the LCD display rather than OLED.
Very interesting how they made this work on iOS, given so many failed (before the Apple/Google protocol was released). A lot of the design documentation references the UK market, I wonder if VMWare were asked/volunteered to help with the NHSX app that tried to ignore the Apple/Google "blessed" approach.
Provides a number of approaches to workaround the ‘iOS detection in the background’ bug in iOS to a point where detection and continuity is superior to existing protocols
The technical details on the protocol (seperate from the "payload" which is contact tracing specific data) are here[1], and the iOS library here[2]. I would be interested if anyone else has verified these claims.
[1] https://vmware.github.io/herald/specs/protocol [2] https://github.com/vmware/herald-for-ios
The DDC interface, which is an I2C bus that allows for bidirectional communications to read EDID data, so you know what you are plugging into. Hot plug detection via the HPD line, so you can tell if you are plugged in or not. Embedded 5V power, very useful for conversion dongles, ethernet, probably more things I forget. HDMI has a lot of pins, which makes DIY cables difficult, however they are useful.
See also Heatshrink[1] based on LZSS
[1]https://spin.atomicobject.com/2013/03/14/heatshrink-embedded...
The command line interface eCos has to call any C function sounds interesting, I wonder if there is a standalone library to do this on other platforms.
To further boost performance, it might be worth skipping past interrupts and going straight for DMA, as the CPU probably doesn't need to be doing anything. I imagine figuring out how that works on an undocumented chip would be quite tricky though.
SVD is this machinine readable description, and is available for most ARM micros, as it is needed for the peripheral register view in debuggers.
svd2rust [1] is an project that generates a (very low level) Rust API for a specific micro from this file.
Generally the file generated from this is known as the header files (as it is just C headers to access the registers directly) and the HAL is an abstraction layer on top, and is actually written manually by the microcontroller designer as it contains higher level functions (e.g. a function to calculate the clock settings to get a specific UART baudrate).
The STDLib is often supplied by the compiler vendor instead, or is an open source project like picolibc [2]
If anyone wishes to read it or similar European standards, each nation is required to sell it at a price proportional to the average wage, and hence the Estonian standards body is selling it[1] for €14, instead of the £204 the British standards institute wants.
You can use Protothreads[1] for this which work on anything that runs C, as they are just using setjmp/longjmp.
I would recommend FreeRTOS instead, as it has proper prempetive scheduling, context switching and wide debugger support. It's actually only 4 files[2] so not very heavyweight in either memory or stuff to learn, and has decent abstractions for cross thread communication (queues etc). Then you can write continuous code and use preemption, rather than have to code everything as a state machine and co-operatively schedule, which is painful sometimes.
[1] http://dunkels.com/adam/pt/
[2] https://www.freertos.org/Creating-a-new-FreeRTOS-project.htm...