snops

Interesting, GCC has '-fstack-usage' to output the stack usage of each function into .su files, I didn't realise LLVM was lacking this feature.

There is a tool in rust[1] I just found that makes LLVM emit this information for rust code, but it stores it within[2] the .stack_sizes section in the emitted .elf instead. Possibly a similar trick could be added to Zig

[1] https://github.com/japaric/stack-sizes [2] https://llvm.org/docs/CodeGenerator.html#emitting-function-s...

I don't know Rust very well, but it strikes me as quite, complex, with a lot of language-level features. I think a lot of that complexity isn't needed in embedded, e.g. the borrow checker and "fearless concurrency" makes less sense for single-threaded applications, which is by far the majority of embedded development.

The original post lists rust as having a lot of "hidden magic", which zig explicitly states it does not have. I am unsure how much Rust actually has of this tbh.

Also, are you sure Rust has "a C compiler built in?[1]" If I look at the official guide, it recommends compiling your C code to a static library[2], though there are crates to add this to the build process. Rust requires bindings to be generated too, which can be automated [3], but in Zig it just requires including the header file[4] and optionally converting the error codes into proper errors, no extra packages.

Finally, I don't rule out Rust as an option, especially due to its much higher popularity, mindshare and hence ecosystem. But I think a comparison is interesting when discussing other languages for embedded development.

[1] https://ziglang.org/#Zig-is-also-a-C-compiler [2] https://rust-embedded.github.io/book/interoperability/c-with... [3] https://rust-embedded.github.io/book/interoperability/c-with... [4] https://ziglang.org/#Integration-with-C-libraries-without-FF...

I'd be interested to see the comparison against zig[1], which I am eying up as a quite interesting language for embedded development. I think the comparable features would be:

- No automatic magic, anything that looks like a function or memory allocation is, anything that doesn't, isnt.

- Good compile time code generation capabilities including reflection, much nicer than C macros.

- Runtime safety features, such as bounds checking, but not as intrusive as Rust's borrow checker (which makes less sense for single threaded embedded applications). These can be turned off in release builds.

- Very good C interop for use with manufacturer HAL libraries etc, includes a C compiler.

- Better error handling than C, without needing full exceptions, instead the "try" and "defer" macros nicely replace C's "goto" for error handling[2].

- No garbage collection

- Embedded is a first class target, unlike Go/TinyGo

- Working async support on all platforms.

- Sadly not as popular as others, one full time developer currently I think.

[1] https://ziglang.org/ [2] https://eli.thegreenplace.net/2009/04/27/using-goto-for-erro...

I believe the trial it refers to is a civil class action case relating to the UK Post Office "Horizon" IT system, which falsely accused hundreds of postmasters (managers of local post offices) of theft. This case was settled this month, ruling against the post office to the tune of £57.75m [1].

The very lengthy judgement[2], does have an appendix going into technical detail, and page 17 onwards contains an interesting and long discussion of "the meaning of 'robustness' ".

[1] https://www.theregister.co.uk/2019/12/12/post_office_horizon... [2] https://www.judiciary.uk/wp-content/uploads/2019/12/bates-v-...

The licensing is a bit poor. While openthread is open source, and the spec is public: > "Membership in Thread Group is necessary to implement, practice, and ship Thread technology and Thread Group specifications."[1]. This seems to be a similar limitation to what prevents Zigbee from being in the Linux kernel, as commented elsewhere[2] in this thread.

In contrast, the Bluetooth SIG only requires a fee to be paid when you actually ship, as a once off not a yearly fee. The cost is roughly similar.

[1] https://www.threadgroup.org/ThreadSpec [2] https://news.ycombinator.com/item?id=21825822

Algorithms doesn't seem to be the right term, this seems to be more tooling, like this wrapper for Tensorflow and YOLO training that runs a variety of monitoring tools for you:

https://github.com/BMW-InnovationLab/BMW-YOLOv3-Training-Aut...

The author linked the development board, either $4,495 or $5,995, but he did say he got it second hand I think:

https://www.intel.com/content/www/us/en/programmable/product...

The release notes: https://docs.julialang.org/en/v1/NEWS/

That channel owner, Ben Katz did the mechanical hardware, motor control PCB + firmware for the MIT Mini Cheetah as part of his PhD, here is his blog post on it[1], which links to a full technical report. The latest firmware is here [2]

[1] http://build-its-inprogress.blogspot.com/2019/03/hello-there...

[2] https://os.mbed.com/users/benkatz/code/Hobbyking_Cheetah_Com...

Interesting how you say short lived, I had a look and it's on founders edition NVidia RTX2000 series cards, though not mandatory [1] and Valve recently cancelled support for it on the Index headset. [2]

Do you think it will be cancelled on the next series of cards?

The need for yet another specialised variant of USB-C cables does look a downside for me, vs DisplayPort getting fast enough to need only two lanes for VR, so standard cables can be used.

[1] https://uploadvr.com/nvidia-rtx-super-virtuallink/ [2] https://www.roadtovr.com/valve-index-virtuallink-adapter-can...

Quite suprising Motorola couldn't push the navigation bar down slightly, that wastes a lot of space at the bottom. I know the article says android needs a rectangular navigation bar, but a lot of phones with rounded corners on the display just crop the navigation bar (e.g. Oneplus).

Would this have been possible with that much larger bottom curve, or are there parts of the Android UI that would be cut off? The little hint that comes up to switch to portrait/landscape mode comes to mind.

They don't say who makes the SOC, just "1.2 GHz Quad-Core ARM Cortex-A53 CPU", which is a lot higher spec than the GR8[1] used in the prototype. This has implications for mainline kernel support etc.

[1] http://linux-sunxi.org/GR8

A well documented project, and its admirable getting actual open source hardware certification, but I think the design isn't really suitable.

All those separate switching regulators look a nightmare for electromagnetic interference to me, the inductors are unshielded and there is no solid ground plane on the PCB. I would be surprised if USB HS (480mbps) works reliably with this layout. Also, there is no consideration given for ESD protection.

A better design would be to have a single more modern high current regulator/module (the LM2596 [1] used dates from 1999) and use protected high side load switches to supply the ports. These kind of high current supplies are a bit tricky (external MOSFETs etc), so a module might be a good shout, example [2], which might even end up cheaper than having 4 discrete regulators and passives.

Protected load switches detect overcurrent and turn off the output, sometimes with auto-retry. Its getting harder to find them in packages with legs, but the AP22815[3] looks suitable in a TSOT package that shouldn't be any harder to solder than the USB hub IC.

Protected load switches could also allow removal of the microcontroller, as they have a simple high/low enable pin and fault LED, that could connect to a simple slide switch and red/green LED per channel. They also offer nice features like discharging the output capacitors, and reverse current flow protection.

As for the suitability/usefulness of a 3A USB hub, if you try and pull 3A through a USB connector, it will get quite warm, especially if you have a micro USB connector on the other end.

[1] http://www.ti.com/lit/ds/symlink/lm2596.pdf [2] https://www.digikey.co.uk/product-detail/en/bel-power-soluti... [3] https://www.digikey.co.uk/product-detail/en/diodes-incorpora...

The Dotnet Micro Framework appears to be no longer developed by microsoft, with the official repository being archived [1]. However the Nanoframework[2] fork appears to be alive. Does anyone know which one this project is using? It's unclear from both the OP and the Kickstarter link as well.

[1] https://github.com/NETMF/netmf-interpreter [2] https://nanoframework.net/

The linked paper shows the "classical system" is the Summit supercomputer[1], using 128 petabytes of disk. Still, its remarkable that the choice of a different simulation algorithm by IBM that trades memory for CPU usage cuts the time from 10,000 years to only 2.5 days.

[1] https://www.olcf.ornl.gov/olcf-resources/compute-systems/sum...

An interesting non-free alternative is the SEGGER Runtime Library [1] which works with GCC, but with smaller code size than newlib-nano and significantly faster floating point emulation [2] for processors like the Cortex M3 or RISCV wih no FPU. It would be interesting to see if newlib-nano or picolibc could use these tricks.

[1] https://www.segger.com/products/development-tools/runtime-li... [2] https://blog.segger.com/floating-point-face-off/

Speech enhancement (denoising/dereverb) and seperation is absolutely a hot research topic, as it's needed for fields like voice assistants as well. Unsurprisingly, the state of the art is variety of deep neural networks, here's a good overview of recent developments [1]. Of course, many of these are far from real time, but earlier techniques are used in some digital hearing aids iirc. Apple have also released [2] some details of the system the Homepod uses, along with audio samples.

A quite interesting further development of these is this paper [3] which uses brain activity to determine which particular speaker the listener is trying to hear, and then optimises that.

[1] https://arxiv.org/abs/1708.07524 [2] https://machinelearning.apple.com/2018/12/03/optimizing-siri... [3] https://advances.sciencemag.org/content/5/5/eaav6134

For anything powered by a Switch Mode Power Supply/SMPS (TVs, computers etc) then not much effect, as power is rectified immediately and then converted back several 10s of KHz, and so many SMPS devices will actually run from DC.

Heating elements (kettles etc), also don't care, and a lot of motors used in household items are universal motors[1], which will end up running at the same speed even as the frequency drops. Old alarm clocks do use the mains supply as a time reference though, so they will end up having the wrong time, as happened recently in the European grid [2].

For a transformer, efficiency decreases rapidly[3] with falling frequency. For household usage, transformers running directly on mains frequency are only used for linear power supplies (as opposed to the SMPS supply used earlier) which found in things like audiophile level power amplifiers (adds a nice bit of weight), so your Class-A amplifier may get even hotter.

The power grid uses transformers of course, to step down the several kV supply to the 240V used in the UK, and its possible that a big enough frequency shift could cause overheating of these from the decreased efficiency. I would be very surprised if they would not turn off if they got too hot though, it seems like a sensible thing to design in.

In short, not much for small changes, but the frequency is falling as there is more consumption than supply, so the supply gets turned off to decrease demand.

[1] https://en.wikipedia.org/wiki/Universal_motor [2] https://www.irishtimes.com/news/world/europe/clocks-in-25-co... [3] https://electronics.stackexchange.com/questions/23999/effect...

Quite dangerous to leave this without an enclosure, since the power supply is on the same PCB, several of the components and solder points carry mains voltage.

I'm surprised an outlet as high profile as Make don't at least recommend one, or have any of the usual warnings about high voltage.

On a side note, it's no mean feat integrating large through hole components and tiny SMD parts onto the one PCB, normally power supplies are wave soldered while SMD parts need reflow instead, and hence TVs and the like use seperate PCBs. Pin-in-paste[1] is possible, but only with some parts, so maybe they used automated selective soldering[2] instead?

[1] https://www.7pcb.com/blog/the-application-of-the-pin-in-past...

[2] https://www.nordson.com/en/divisions/select/soldering-proces...

Yes, but using the DMA engine in the NVMe drive to write directly into GPU RAM, rather than go through system RAM first. This was not previously possible, as DMA is almost always to/from main RAM.

From the article [emphasis added]:

> If a DMA engine in an NVMe drive or elsewhere near storage can be used to move data instead of the GPU’s DMA engine, then there’s no interference in the path between the CPU and GPU. Our use of DMA engines on local NVMe drives vs. the GPU’s DMA engines increased I/O bandwidth to 13.3 GB/s, which yielded around a 10% performance improvement relative to the CPU to GPU memory transfer rate of 12.0 GB/s shown in Table 1 below.

They don't seem to have revealed many more technical details about how they did it, just a lot of benchmarks. I presume this only works where there is a shared PCI-E switch in between the GPU and NVMe drive, and so traffic can be routed past the CPU?

With Azure Functions, the runtime[1] is open source, and the development tooling for VSCode makes it easy to run them locally [2], starting up in a few seconds. You pass in your database keys etc as environmental variables, and it integrates nicely with the IoT Hub tooling so you can debug the whole device sends message -> function gets hit flow in one window.

However, I have had this break in places before, and not really been able to figure out why from what is going on under the hood, needing to restart various parts to get it working. Checking the contents of the database is annoyingly manual, requiring a seperate GUI only tool[3] and hitting the refresh button a lot, a "watch" window would be much nicer. Profiling once deployed is also difficult, I ended up having to inject timestamps at various different places to try and measure end to end latency.

If Dark can give better tooling for debugging once deployed, it would be a definite advantage.

[1] https://github.com/Azure/azure-functions-host [2] https://docs.microsoft.com/en-us/azure/azure-functions/funct... [3] https://azure.microsoft.com/en-in/pricing/details/data-explo...

To find out the surprising fact that Azure IoT makes no promises about maximum latency at all, not even a "soft" guarantee without SLA penalties.

This is the introduction page, follow the links at the bottom for more, there is a lot of interesting detail including things like writing a kernel driver to interface with the HDMI receiver.

They already do this with ITER[1] for the "bioshield" to protect humans from radiation, the facility is semi underground as well.

However by the sounds of it, a reasonable fraction of the output power is in the form of neutrons. If you had no lithium blanket and just concrete, the energy of the neutrons would go into heating the concrete, where it would either be wasted, or require the concrete to be actively cooled which would be difficult as concrete is not a great conductor.

[1] https://f4e.europa.eu/mediacorner/newsview.aspx?content=941

I would be interested to see some more complex examples for this than the ones provided[1], specifically around interrupts and DMA, both are somewhat "concurrent" resources that in C need to be managed manually, with careful use of the volatile keyword and similar.

For instance, UART transmit looks to be implemented using blocking IO[2]. I don't know Go very well, but it would be interesting if this could be implemented as a buffered channel [3], which would provide a nice abstraction for the hardware FIFO buffer used by the UART, and allow the CPU to be doing other things. The same could also be used for the I2S support I think, which will often be used to send much more data (streaming audio) than the UART.

On closer inspection, looking at the issue tracker, it appears this is already in planning, which is great [4].

[1] https://github.com/tinygo-org/tinygo/tree/master/src/example... [2] https://github.com/tinygo-org/tinygo/blob/515daa7d3c9af18c78... [3] https://gobyexample.com/channel-buffering [4] https://github.com/tinygo-org/tinygo/issues/9#issuecomment-5...

Powering some 12V motors for a robot from a 48V tether supply.

Quite easy to get into hundreds of watts with relatively small brushless motors, the type that would normally be used in hobby RC, powered from LiPos. The Vicor parts have a good amount of protection circuitry as well, useful when shorted wires can start glowing very quickly, and RC lipo packs have no protection at all.

Having needed something like this recently, I would recommend utilising 48V-12V convertors designed for servers. Telecoms equipment has long been 48V (actually -48V) but some datacenters are moving that way too for internal distribution.

There are some automotive designs for 48-12V conversation, but these are not really available as modules as automotive is large volume and high integration. Using discrete components gets expensive fast at these power levels, a Renesas 2KW reference design I saw needed a 4 layer, 6oz PCB which would have cost ~$500 to prototype in China.

The Vicor BCM series can do 48V->12V 150A out in a very nice self contained module, with excellent EMI shielding, and takes cables directly, although definitely needs a heatsink! http://www.vicorpower.com/products?productType=cfg&productKe...

Ah thanks, that explains why I couldn't find the programmers manual for it directly

It would be interesting to know what the ARM SecurCore SC300 processor[1] does, if that is constant time multiply or if they just expect you will use the hardware crypto accelerators that are commonly integrated with it, e.g. in the ST33 [2].

[1] https://developer.arm.com/ip-products/processors/securcore/s... [2] https://www.st.com/en/secure-mcus/st33-arm-sc300.html

The spec does try and make it simple to build compliant devices for basic features. It's only if you want higher power or bandwidth than the existing USB 2.0 that you need any kind of digital logic.

For instance, a USB-C analog headphone adaptor is just some resistors and the connectors themselves, and a USB A-C cable just requires a single extra resistor so the USB C device knows there is a USB A plug on the other end and not to draw too much current. Unfortunately, dodgy manufacturers got even that wrong, see https://www.extremetech.com/computing/217556-google-engineer...

Cisco are not using dedicated hardware logic like Allegro DVT I think. For phones etc, dedicated hardware will be very useful, but it takes time to get into products, which is why a real time CPU encoder is very interesting.

Looking at the video (https://vimeo.com/344366650) of the Cisco talk, at 20m18s they say a "real time low latency HD software encoder" [emphasis added], which confirms it.