I am building better dev tools for firmware and PCB developers.
For example, we have GitHub Action workflows that allow you to push builds to the connected EmbedHub project. Your EmbedHub project has fine grained release management - so for example only the git tagged releases will be shared with the customer, but the testing/QA team will get access to builds from regular commits on branches as well.
I am also building a physical device (called HAL) similar to the now discontinued EtcherPro[1] - which will connect to your EmbedHub account and have access to your releases. This will let you offload tasks like long term testing, mass flashing and provisioning of devices, and more.
Love seeing alternative approaches to browsing!
If the aim is to avoid Google's dominance in the browser world, also check the efforts by https://ladybird.org/
The author is quite active on X/Twitter and posts regular updates.
Yeah I'm watching that project, it's great. Once it will be mature I will evaluate it against CEF (Chromium Embedded Framework).
I plan to add an optional support of embedding CEF so that you can use it for specific tabs or websites directly from FixBrowser instead of having to switch to another browser.
In the future there could be a similar support of embedding Ladybird engine.
It's an early prototype - so there's still plenty of work left on the optimization front. This particular thing you mentioned is because of misconfigured UI generation tool which creates 2 separate screens when it doesn't need to.
Syncs with their phone app, to keep a track of bills and expenses. Based on the Espressif ESP32. Quite handy for small shop owners who can't have a full-blown computer+screen cash register.
Disclaimer: I am working as a freelancer for their next version of hardware that will be based on Linux.
I think moving to a full blown operating system is moving in the wrong direction. I think moving in the other direction towards a strictly hardware double entry book keeping system would be progress.
I think any operating system over complicates and encumbers the idea with un-needed dependices.
> I think any operating system over complicates and encumbers the idea with un-needed dependices.
The prime problem is latency, which becomes both noticeably larger and unpredictable. Both those aspects cause huge loss of ergonomics. It's quite easy to tell whether a piece of hardware is doing things directly in firmware, or if it's running a full OS with a software stack - the latter has neither instant nor predictable feedback.
A good example would be phones, for anyone who remembers the transition from feature phones to iOS and Android smartphones. That transition is where we lost predictable input latency, and thus ability to develop muscle memory and operate device without looking at it. E.g. texting people while keeping the phone in your pocket was a typical thing teenagers did, that became impossible with modern smartphones.
It's gotten worse since the introduction of smartphones. Instead of a button being hit changing into a pressed state instantly, they added animation that looks nice, but they end up making UI feels laggy and unresponsive.
Forget texting from pocket. Consider why we can't really operate any of the common touchscreen devices, like phones, tablets and computers, without looking at them. It's because of unpredictable input latency, unpredictable UI timings, and unpredictable UI behavior all across the stack - from the apps with bullshit flashy UX, down to the OS which is not a real-time OS, and will introduce arbitrary latencies for arbitrary reasons.
The touchscreens and their driving hardware is itself fine. It's the introduction of a proper, non-real-time OS, that's the "original sin" here. Everything else is just decades of practice of writing for such OSes, with the fundamental unstated assumption that interactivity means user is looking at the display while operating the device. This assumption bleeds all the way to the very core of *nixes and Windows.
Lots of embedded work won't tolerate an OS, sometimes not even an RTOS, which I think was GPs point - nothing specific about Linux.
Or to put it another way, the only reason you would want to move to an OS is to add complexity to what the device is doing. GP is arguing that's a bad trade off.
My thinking from a digital system point of view is that double entry book keeping is the beautiful concept. This concept can easily be expressed using computers but it loses its beauty at each abstraction layer.
The beauty is lost because the user is using a device for double entry book keeping but many other back ground tasks could fail that are not directly related to the task of book keeping.
The user is now faced with needing to understand their goal book keeping plus anything that makes the book keeping device function.
I think a digital aesthetic can be found by creating simple digital devices that are highly specialized but would need something similar to phone to add all the fantastic features that a network device provides.
Imagine how great cars would be with physical buttons but an optional screen to mirror one's phone like device.
Finally I'm actively working on this idea with an 8 unit mixed use building.
I'm trying to make it as sophisticated as possible with very simple circuits that don't relay on the internet to function.
The idea is that the industry is overly focused on the internet and completely ignoring all the very simple things that can be done digital devices. I think by establishing a digital aesthetic we can start to say something simple that requires the internet or an operating system is ugly.
I don't live in India (nor run a shop!) but I imagine for businesses that take both cash & PhonePe it could be a useful feature to collate the two, if there's some kind of API for that? i.e. so you'd have all sales in one place, regardless of payment method, and the daily/weekly/etc. total would cover everything.
Just a thought. I like the design! Keeping it simple & familiar, calculator works (or almost, just missing feature), no need to reinvent that part. :)
Is the calculator being manufactured fully in India or shipped from China? Curious.
Love the WiFi connected ability. Does the user have any choice on what api they want to export to? Or it has to be a specific app?
Even in the US, 90+% of gifts bought for Christmas are made in China. Almost anything containing electronics, plastics and some kind of plush fabric / faux leather seems to be made in China.
Components are from China - everything is assembled in India (Bengaluru). It's probably impossible to manufacture with locally sourced components in India in 2023(especially displays, processors, memories).
Would you say a shopkeeper could pick these up for themself or their salespeople and immediately continue with the same workflow, if they had been using a popular plain calculator up until then?
And it could provide additional layers of local and remote data handling from an easy to administer server app on the owner's phone without the need to concern the end users of the calculators with software whatsoever?
Seems to me one thing the calculator in hand can do is traditional real-time negotiating and discounting. Where something like the distraction of software could be a disadvantge compared to what came before.
The current version looks like a great solution, because it's so basic.
You risk adding too many features (and cost) in the next version.
A cell modem is going to require certification and of course a separate sim-card/data plan. Do they need USB unless they have a computer already? And speakers? Is this to play the radio while tending shop? I'm sure even the most illiterate can still read numbers, so TTS would be just a gimmick IMHO.
I'll take the downvote as a measure of the number of HN contributors that still don't know the (important) difference. At least four people have hopefully learned from that comment. A strong signal to continue pointing it out.
That will give you an idea about the bare minimum circuit one needs to build a functioning board (crystal, power regulator, boot select buttons, and so on)
The 8266 was based off an xtensa core instead of an Arm core which is the norm in the industry. Espressif created a replacement for this wildly popular chip with the C3 and based it off RISC-V to keep up with the times and the community. No more toolchain complaints from the community, plus they get to use open standards like RISC instead of xtensa from Tensilica. The never-ARM approach from Espressif has worked out well for them over multiple other alternatives that they chose over the years.
If someone writes a book on the downfall of Arm in a few years, this is going to be a very interesting chapter IMO.
disclaimer - worked at Espressif for a bit (2017-2019)
You know that ARM is used in a number of microcontrollers? There are over a 100 of them in every modern car, also in Chinese ones. So there are a billion a year alone in that area. Then all the peripherals which use either 8051 or ARM based microcontrollers, like simple things like the keyboard controller.
While I think Risc-V has its benefits. I don't know how it compares today to the scalability of the Cortex-M series starting with the M0 and then following the Cortex-A series. But I see that it is still a long way to go par.
Something can have massive market penetration and still be doomed. Nobody talks about the biggest fax machine manufacturer, after all.
Mind you, whether that applies to ARM is a bigger question, it's like asking whether sand is going obsolete. I have my doubts unless something radical happens in the RISC-V space commercially; I don't think Espressif going all-in would do it on its own.
- As one of the replies said, I was talking mostly about the IoT space, but I think it's true for the non-IoT laptop/server space as well.
- Sure - looking at what Apple's silicon team is doing with ARM would make you think that ARM has nothing to worry about for a while. However, notice that Apple is the only one who is getting a lot done with ARM at the high end. Qualcomm, etc. aren't getting the same amount of performance. I believe that's because of the non-ARM stuff that Apple puts in their silicon efforts. Imagine in a few years, when the small companies designing and licensing RISC-V cores are not that small anymore - folks like Amazon (uses ARM cores in their servers) and Apple might have a serious alternative.
- I think open source models win in the long run, similar to Windows vs Linux, or closed version control software vs Git. The tooling around open source grows over a few years and then suddenly it feels like it's miles better than the closed options. I think similar stuff will happen with silicon.
- ARM themselves worry about this btw - not that long ago they created a website smearing RISC-V which was mostly full of FUD. Their employees revolted and made them get rid of that site: https://www.theregister.com/2018/07/10/arm_riscv_website/
ARM should be worried. In anticipation of their new IPO, they changed their licensing model to be based on the value of the final device, not the chip itself. Manufacturers are profoundly unhappy with that, and hey, there happens to be ann alternative to invest in now.
Talk to someone who works at a RISC-V startup. There’s a lot of energy there. It’s going to take a while, but startups are working on every class of chip.
ARM changed the fee structure because growth has been flat, and this is a way to get money short term, not grow the addressable market. It will settle into Intel-like stagnation as a disruptor takes its markets. What's ARM's moat?
I believe OP is speaking specifically to the IoT space, which is still a bit of a stretch - but slightly more accurate than the massive ARM dominance we're seeing elsewhere.
RISC-V is a much better ISA for IoT since it's so much better aligned. You just need to use the parts that you want instead of having to put in the whole package. Plus, it's free!
ST, Atmel and Microchip maintain massive product catalogues so users can choose between 4MHz, 10MHz, 16MHz and 20MHz for their 8-bit, 8-pin microcontroller, and choose whether they want 1750 bytes of program memory or 3500 - but for the same price customers can get a 160 MHz, 32-bit microcontroller with built in wifi?
Why would expressif pay the engineering costs and supply chain complexity costs to make worse products, when their flagship product is already a great price?
It's not about the number of ARM cores shipping today, but tomorrow. If RISC-V tools are about as good as ARM and the cores are cheaper it will become the preferred instruction set somewhere in the future.
Seems in this age of open source tools the instruction set is mostly commodity anyway.
Espressif is taking quite a radical approach as compared to other semiconductor companies. They provide everything from a Cloud SaaS for their chips, to open source phone apps that connect over BLE/WiFi to their chips, reference hardware designs, integrations with voice assistants, and more. Typically, semiconductor companies have shied away from providing anything comprehensive because they don't want to upset their distributors and partners who provide the missing services - but not Espressif.
I think if the US-China chip war hadn't been going on, and customers wouldn't have been paranoid of using a Chinese chip (and being in a tough spot like Huawei customers), Espressif chipsets would be waaaaay more popular.
Disclaimer/source - worked at Espressif for a bit (2017-2019)
> Espressif chipsets would be waaaaay more popular
Oh, don't worry, they're getting a ton of attention from the "pros" these days. In hardware no one likes to be the guinea pig if they don't have to be. But these days Espressif is not seen as an exotic choice, and their low cost, excellent feature set, and good supporting material are big draws.
Honestly it feels like they're truly just eating this market, but it's just happening (what looks like) slowly.
My job uses the ESP32-S3 (the 2MB PSRAM version, for some extra memory headroom) professionally (and with Nim for the firmware, which is fun). Super neat little SoC!
Interesting you use Nim, would you have some resources/pointers for using Nim on embedded devices.
Do you use a native compiler or cross-compile it for this (RISC-V) chip ?
So the S3 is actually a Xtensa LX7 processor rather than a RISC-V one, but the process is the same: “--compileOnly” to output C sources from Nim, and point CMake to that nimcache output folder.
With #line macros injected into the compiled C output source files, JTAG debugging and other tools just work, which is quite nice.
That said, if I was on the C3 or any of the RISC-V chips I’d look at using the C toolchain directly: you can easily have “nim c main.nim” call out to a specific C compiler with your specific build and linker flags!
The one annoyance in all of the embedded toolkits when trying to use non-C/C++ languages is always CMake; companies build component systems and such on top of it which a naive C compiler usage can’t really leverage, which means you end up rebuilding the whole build toolchain again.
Easier to just stick within CMake and use Nim’s C output instead, at least for now (until I get some time to write a nimscript parser for a subset of ESP-IDF’s CMake file format…)
I also use Nim quite a bit on linux/windows for machine-learning purposes.
But even on these systems, It is generally a pain to try to trick Nim into using a compiler not directly supported, as some original hard-coded flags would be incompatible with the one i am trying to use,for example NVCC .
Follow up question, Do you generally use Nim on ESP like chips which run some form of a RTOS, or also on bare-metal micro-controllers ?
Yeah, we deliberately have a fork of Nim that is purely for adding workarounds when we hit small internal things like that — though most of our changes are upstreamed proper now which is nice!
To answer your follow up question; both - we’re in the process of bringing up firmware for the STM32G0 and L4 microcontrollers, and CubeMX is such a pain to try and bind as-is, we started to play with svd2nim and see if we can’t bring up peripherals that way instead. That’s a less well tread path of course, but it’s promising so far. Only downside is that’s more like Rust’s approach of rebuilding the world, but oh well
Run-time configurable box that acts as a IoT gateway to various sensors/protocols/etc, pulling data from a heap of different possible devices and kicking it to our web platform. Used to track all sorts of stuff across a few industries
I forget we actually have a website, probably easier to share that and answer specific technical questions instead! https://www.venturi.io/
> Honestly it feels like they're truly just eating this market, but it's just happening (what looks like) slowly.
I have an friend who works at ARM, he said there's a mix of people who don't understand what's happening and people who are freaking out but have no power to respond.
I have no idea what market share changes have been but speculation based on what I've heard is that EspressIf is large enough that ARM has awareness of their presence but doesn't comprehend their threat. It sounds like it's going to play out like typical market disruptor where the titans will respond too slow and too late to stop them.
The thing is, it's all about that radio. No one cares what the core is. ESP32 is ample evidence of that: neither their Xtensa nor their RISC-V cores are as good as an ARM Cortex-M, in terms of design quality, implementation quality, documentation, ecosystem, or general familiarity. And it just doesn't matter. No one even cares about the Xtensa versus RISC-V products. The toolchain, documentation, major features, and raw horsepower available are all that's important.
Which is a long way to say that ARM has no moat here.
From what I recall, the ESP8266 was originally just a module designated to provide WiFi capabilities to other circuits, but over time, hobbyists discovered that it had much more potential. Its incredibly low cost sparked its popularity. Espressif did an excellent job of designing the ESP32 to accommodate the demands of the emerging audience. But I could be mistaken; I might be missing a part of the story.
> The ongoing US-China chip war has created a situation where users hesitate to use Chinese chips, wary of ending up like Huawei's customers. Without this scenario, Espressif chipsets might have enjoyed much greater popularity.
These chips are intricate enough to potentially contain backdoors. While it is something I never thought about with respect to Espressif, it does seem plausible that they could be a target.
What really sparked my interest was having WiFi in a chip that only cost maybe 2 usd at the time. Plus, you could find great usb dev boards for less than 5 usd.
If I had this stuff as a teenager, I would've lost my mind...
Yeah, important to remember that the old Wifi module for the Arduino was like 20-30 bucks and was basically just an AT modem that still needed a host Arduino. Barely anybody ever used them that I saw. The original ESP-01 for a couple bucks was a very exciting product for hobbyists just as a serial-to-wifi adapter even with minimal English documentation, and then it went bonkers when they released Arduino support and a package with enough IO to do useful things. Espressif has also been pretty nice to the hobbyist community in general once they realized what they had done.
The first time I saw a 8266 I thought "why am I struggling with Arduino or Raspi if this thing is all I need to make a sensor + wifi mesh". Also being powered through the USB is a plus, lots of unused USB ports around in 24/7 machines.
Agreed. Hobbyist (and retired professional here) who fools around with IoT stuff at home. I've done lots of things with Raspberry Pi Zeroes that can be done with an ESP8266/ESP32 and with the benefit of on board analog inputs. Some of the devices I've used (like the Bosch BME280) seem to work better on the ESP and I suspect that's because the serial communication does not suffer from the risk of missed data due to managing the protocol in user space. The ESP is easier to program for real time either using FreeRTOS or just bare metal. Espressif's SDKs are a bit cumbersome to install but the VS Code extension helps to manage a lot of that. And it all works well on Linux.
> These chips are intricate enough to potentially contain backdoors. While it is something I never thought about with respect to Espressif, it does seem plausible that they could be a target.
As the old saying goes, "the S in IoT stands for security" - I choose to trust Google/Amazon and their peers to have an Internet-connected device, but everything else (95% the IoT devices I have) gets sectioned off to a dedicated VLAN & WLAN with no Internet access (and no access to the rest of my network).
This keeps me safe, and keeps the devices safe from each other (micro-segmentation in the access level). No need to trust what has minimal interfaces, and then I don't worry as much if I don't roll software updates every week...
> These chips are intricate enough to potentially contain backdoors. While it is something I never thought about with respect to Espressif, it does seem plausible that they could be a target.
They could indeed be, as already are all PC's, phones, TVs and any smart connected household appliance, no matter if they're built in China. I would never ever consider building a IoT home system wthout putting it behind a dedicated and firewalled hardware subnet that protects from the outside and from the inside. Ok, the firewall hardware itself could contain tampered chips with firmware instructing them to encapsulate and redirect certain traffic outside of the rules without reporting it, but that's another story; when in doubt, I prefer to consider every piece of hardware that is closed and connected as potential spyware.
They already are very popular. They're embedded in devices from smart home gadgets to washing machines and smart appliances.
The great thing I find about them is, that they are "hackable". Don't want to depend on some weird company and their cloud, especially with long-lasting appliances (which outlast the company cloud or even the whole company)? Just buy something with esp8266/esp32 inside, and there's a high chance, that there is some opensource firmware (tasmota, esphome,....) available.
(disclaimer: some times the "hacking" part involves soldering irons, wires, usb->serial adapters and knowledge of electronics safety, especially with mains powered devices)
It's also great to see how with a little technical know-how, you can avoid paying 100s of dollars for some IoT tech that is reliant on more people buying overpriced hardware for it to work in the future, and instead - go for DIY or cheap hardware (e.g.: SonOff) which gets a huge audience due to their low prices, which guarantees someone like me will spend the time to get it properly supported soon enough...
All of a sudden, the premium product becomes the inferior product, because it will have a smaller market share, and therefore, fewer hackers :-)
A lot of grey-beard type embedded programmers, who programmed in assembly through the 80s and 90s, really got attached to their architecture of choice, whether that is AVR or MSP430 or 8051. That crew tends to be very conservative with tech choices, for both good and bad reasons.
Some then learned to tolerate ARM Cortex M.
But Espressif, this weird new and unknown Chinese manufacturer, came out with their own arch and instruction set that no one else uses (xtensa). A lot of old timers were wary.
Their price to feature ratio is unbeatable though. That go them in the maker/hobby community fast, and lately I've heard of more and more companies using esp32 for actual professional products.
Xtensa is licensed from Tensilica which is both an American company, but also used extensively in non-consumer facing industrial systems. It's not that nobody uses it, it's that you're likely not even close to the target market they're made for. Espressif is a fabless semiconductor company, they don't actually make their chips, they license a bunch of parts, design some developer boards, and write software around it. They're much closer to a software company than a hardware company.
Athereos wireless cards (ath10k) have also used Xtensa.
And the audio DSP in newer intel chipsets (e.g. Apollo Lake) is also Xtensa-based, but unfortunately quite locked down (signed firmware only). See https://thesofproject.github.io/latest/platforms/index.html
Also ISTR that older Radeon graphics cards used Xtensa (e.g. in the Unified Video Decoder).
There was a period centered around the late '90s where new architectures were a dime a dozen, as access to fabs opened up, and small companies with an idea hoped to become the next Intel.
Anyway, ESP32-C3 is RISC-V, and I suspect they won't do any more new Xtensa cores.
I can't agree with this enough. Willow[0] (disclaimer - I'm the creator) just wouldn't be possible without the robust Espressif ecosystem, libraries, code samples, docs, etc. Let alone all on a finished product (ESP BOX, $50) available worldwide through their distribution channels! We have a lot of background and experience in this and related fields but the fact remains we went from concept to initial release in less than six weeks (with two part time devs - if you include me, which you shouldn't haha).
Wouldn't the newer RISCV based ESP32 models eventually add to the commercial popularity? Maybe some commercial users stayed away from the Xtensa powered ones, especially if they would have needed to do lower level work?
ESP32s aren't really ‘lower level’ in the sense that anyone is likely to write assembly code for them (compared to, say, 8051 or PIC), other than maybe some driver author at Espressif. The big win from using RISC-V, other than name recognition, is mainstream compiler support (which is nothing to sneeze at, especially when it's largely funded by someone else).
When I worked on Matter¹, the Xtensa and RISC-V versions were basically fungible from the software point of view. (And really, so were other vendors' various ARMs.) We did find that Bloaty McBloatface² didn't support Xtensa, so I had to write an alternative.
I am building better dev tools for firmware and PCB developers.
For example, we have GitHub Action workflows that allow you to push builds to the connected EmbedHub project. Your EmbedHub project has fine grained release management - so for example only the git tagged releases will be shared with the customer, but the testing/QA team will get access to builds from regular commits on branches as well.
I am also building a physical device (called HAL) similar to the now discontinued EtcherPro[1] - which will connect to your EmbedHub account and have access to your releases. This will let you offload tasks like long term testing, mass flashing and provisioning of devices, and more.
[1] - https://www.balena.io/etcher-pro