Just recently, Bouffalo Lab introduced BL602 which is a RISC-V WiFi-BLE chip with ESP8266 price. I guess Espressif had other plans for the competition!
I2S is also handy for bit-banging protocols without using CPU time—it's popular to use it on the ESP* chips to drive WS2812B and similar strips without hassle.
I use the RMT (Remote Control) devices of the ESP32 from FreeRTOS for this. They were intended for generating on-off-keying of carrier modulated wave forms to blink an IR LED for a remote control.
If you leave off the carrier modulation you end up just specifying a list of on and off times and get absolutely rock solid waveforms in hardware.
There's a bunch of them, I forget, maybe 8? So you can drive a bunch of chains at once.
You can also use these for rock solid reading of input signals too. Say you have a weather station that sends some god awful protocol up a wire at you… you just collect a list of the high and low times and get notified when it stops wiggling the signal. Then you sort out the data from the transmission. The timing might be way off because it's cold and the sender's electronics are really cheap, but you can analyze the signal and see what they meant.
That’s handy sounding. There’s some use cases I was thinking about needing to read in high speed IO lines, above 1Mhz. SPI has odd timing requirements. Can you point to example code for this technique, or is it just a matter of using(abusing) the i2s library? And the horrible wire protocol is all too common.
I hadn't looked at the RMT peripheral before... Based on what you describe and from a quick skim of the documentation this also seems perfect for a simple logic analyzer!
There’s lots of “competitors” to esp32, pretty much none of them except STM have the software for developers, which makes their offerings close to useless.
The only way to gain critical mass is relentless deep commitment to developer tools/libraries and documentation.
In many cases these competitors actually try to hide their documentation and keep secret how their chips work.
I’d be interested to hear if there’s other chip vendors with software/documentation as impressive as Espressif but I haven’t heard any, except as I said STM.
> gain critical mass is relentless deep commitment to developer tools/libraries and documentation
Which seems (IMHO) why the likes of Texas Instruments has failed. They've made a few attempts at jumping on the IoT bandwagon over the last decade and should have been in a perfect position to capitalize on the huge uptake but it just didn't fit their profit margin goals I'm guessing.
RISC-V so far is a turndown for a design, speaking honestly.
ARM have by faaaaar the best tooling in the industry, which are more open, than not, and the baseline is made on GNU toolchain, only with more fancy debug tools being paid/locked down.
RISC-V did not yet benefit from its openness for as long as tooling go.
However, RISC-V would still be infinitely better than Cadence, and them wanting $100k for a basic (and terrible) debugger with coresight-like functionality.
It just means it isn't made for hobbyists... Hardware companies don't care about the lack of good software - they just pay some embedded code monkey a lowish salary to 'just make it work'.
It's a pretty uncharitable description, but yeah. There are only two types of companies that do this though: companies where they're working at such a scale that spending a few extra months to years of developer time doesn't make a dent compared to the BOM savings. You're more likely to get vendor support by name recognition at these kinds of companies, so it's not as bad as the hobbyist experience. The second kind is where either the project or the company can't afford the capital outlay for better documented chips (or support packages). Stay the heck away from these if you value your sanity or know your own worth.
Sadly no - apart from a very tiny number of silicon valley companies, everyone else in embedded tech seems to pay the people who write verilog and assembly the same as the people who make the schematics and the mechanical designs. That's sometimes only 40% of what people who write python and nodejs get in the same city...
I think that's partly due to market forces and the value produced per developer. A few Webdev's can write software that enables an entire web company in a few months. Due to the poor state of embedded development ecosystem the same is not true in hardware, compounded by the time/effort required to workaround bugs in the hardware plus working in error prone C. Then embedded developers/companies don't share workarounds via open source, so every team must spend time working around already solved issues. Personally, I'm using the ESP32 largely because of the open-source SDK, that didn't require an NDA or some crappy IDE, then I ported Nim to it. But normally it might take 2-3x more embedded devs to create products with comparable profits to similar devs in pure software
If you're doing automation of some kind in the bay, embedded has roughly comparable payscales to other dev jobs. Beyond that, no. You'll generally be paid slightly less than webdevs (but still far more than most engineers make).
I have been involved in embedded systems for more than 25 years now, and I barely do "pure" embedded development these days. That is projects that comprise only designing a specific PCB hardware, or writing the firmware drivers and top level application for them.
Except for a couple of years I have resided mostly outside of California, but when doing consulting I have mostly engaged with companies in the Bay area.
In the past when I did pure embedded development I had to fight tooth and claw to get rates close to $100/hour, while at the same time iOS app developers or webdevs were starting at $120-$140/hour easily, even after the mobile app craze. Despite taking into consideration that I am both a hardware and a software engineer, and rates outside of California were much lower ($45-$70/hour at the time). Which was one of the reasons I pushed hard to find my clients in the Bay area instead.
These days since I have more experience and business contacts I have diversified into more complex projects that have embedded components and pay me better since they belong to regulated industries. Even now I work with full-stack software programmers in AWS/GCP cloud apps, React/Vue frameworks, modern databases and connected middleware that make around $200/hour. For comparison, in the last years I have been involved in the development of a medical device where I did the hardware design (MCU/FPGA, signal acquisition), HDL/firmware programming (Verilog, RTOS, Linux, BLE), technical host tools (C++, Python, Qt) and was paid $180/hour, and lately a mobile robot project where I did the hardware architecture, integration and system control loops (MCUs), and prototyped the high level software application (RT-Linux, ROS, Nvidia Jetson) for $150/hour. An acquaintance in the valley that was working for a similar project but entirely in the ML/CV stack was billing $270/hour. That may be a bit extreme example since ML is hot today, but nevertheless.
Is this the same in Europe or outside of Bay area? It really isn't fair since you are doing the actual full-stack (from F_freaking_PGA to C++/Vue on host) but the ML type is invoking an amalgamation of libraries to do something with 90% confidence level.
Basically, if there more customers but smaller orders, the wasteful overhead of customers reverse engineering the produce will grow. But then there's more incentive for HW companies to overtake the competition by offering better docs.
This. If it doesn’t work with the Arduino IDE/platformio, I would rather not use it. What these manufacturers should do is invest in integrating with these SDKs instead of creating their own. And they should document everything to the level that IPFS is documented (just an example of excellent documentation that comes to mind). Do those two things and you got a winner even if the device itself isn’t technically the superior choice.
Because, to be frank, Arduino is a bit of a toy platform.
It is really good for beginners and for hobbyists to make embedded devices available to a wider audience, but nobody in their right mind would build an actual product on top of Arduino.
People trying to build "real" products on top of Arduino usually do so in spite of, not thanks to, the platform.
Once you start trying to build a polished experience, not a quick hack, you quickly run into limitations that are solvable by dropping to lower levels. I ran into this when I tried to make an ESP8266 temperature sensor - the Arduino stuff didn't have working power management, so it would heat up skewing the measurements, nor anything like threading or coroutines for network handlers, so a single stuck network request would block all others. Ironically, the Arduino port included a coroutines implementation under the hood, but used it in a silly way with a single coroutine. I rebuilt the thing on top of the ESP SDK, stole the thread switching code from Arduino, and used it to build a nice low power version that could handle up to 4 requests at once.
I don't think I've ever seen a well engineered product built on Arduino that wasn't trivial. They might've hacked on it until the user experience is good, but then you peek under the hood and it's clear the engineering isn't good. And that ends up creeping into the user experience in the end, or worse. (OnlyKey comes to mind, which is built on Arduino and also its authors clearly do not have the competence to be writing security/crypto code, but they seem unwilling to accept any criticism).
I know of a good production line that has seen improvements in efficiency and safety due to automation with Arduino. I’m sure there are better ways but in terms of bang for buck, it’s hard to see how a non-programmer could have done better.
On things I've personally worked on, I tend to just use the basic libraries supplied by the vendor, or even just implement everything myself from reading data sheets. This is obviously realistic mainly for very small and simple systems, which is what I've usually worked with.
Almost every consumer 3D printer out there runs on top of Arduino. Sure that’s a small market compared to all electronics. But it’s still a big market in absolute terms.
This was true three years ago. Plenty of 3D printers are now using ARM. The Monoprice MP Mini Delta has been out about two years now with a price of $175 US. Marlin 2.0 has support for ARM, I think it would be accurate to say "Almost every consumer 3D printer out there runs on top of Marlin", although there are a few alternatives like Smoothie.
That is going to put a dent in ARMs revenue. Even if that particular chip isn't a big seller, it means ST now has a drop-in replacement for ARM in their other SoCs. Soon people will realize that ISA is often irrelevant, but the peripherals, libraries, and tools are.
That's one opinion. Another ARM engineer who contributed one heck of a lot more to ARM's success (designed ARM7TDMI, Thumb, Thumb2) says RISC-V is great. See at 51 minutes in this https://www.youtube.com/watch?v=_6sh097Dk5k
Agreed having recently bought an esp32 s2 board it does not yet have platform io support so I put the board aside and figure I’ll come back to it in 6 months and see if that is updated.
To my understanding, PlatformIO is (merely) a set of scripts to handle multiple toolchains and HALs in a consistent way. In esp32-s2 case, it means integrating ESP-IDF only. What stops you from directly invoking cmake using the ESP-IDF?
Just time. I only just started learning how to use Arduino this past summer and discovered I could platformio with a Makefile this fall - it’s been pretty cool so far. I will probably spend sometime later learning Esp-idf next
Meanwhile, the US government is worried about our dependence on Chinese tech, and security implications. What if these convenient and cheap little WiFi modules become ubiquitous and start DOS'ing the entire spectrum?
This is really nice, riscv plus Wifi and BT will be a dream for hackers provided the chip and firmware is well documented. The datasheet is also in the comments (https://mega.nz/file/nk41mSAL#R_d0njlKRb-aIoGuX6JXUB5eeflAdy... )(chinese pdf) : 160MHz 400k sram apparently single core.
Interrupts and exceptions can happen at any point in a program's execution on a microcontroller, and they are free to modify memory and peripheral registers.
>Load <register>
>Modify register in memory
>>Interrupt happens and changes <register>
>Write incorrect value back to <register>.
These sorts of bugs can be pernicious to debug, and they are easy for novice developers to create.
You can disable interrupts when modifying locking primitives, and save/restore the CPU context when interrupts are entered/exited. You can also minimize the amount of changes that any interrupt handler can make within the interrupt context.
It's not really that bad, and plenty of microcontrollers lack atomic operations.
If you disable the interrupts, does that mean any incoming events get ignored, or simply queued for later? If the former, that sounds like you risk missing something important.
Sure, although I think "missing" has negative connotations that don't actually apply to this. When unmasked, your interrupt handler usually just runs until there is no more work to do, which is (again, usually) discoverable. Your device driver is still awoken promptly if the interrupt arrived during a critical section.
The critical section is typically very small, usually just modifying a single variable. Interrupts can't happen faster than the CPU frequency anyway, so you won't miss much.
Only communicate in one direction. I write, you read. I can also provide a large coherent set of data so long as you dont read it until I mark it as ready. There are many other ways too.
Obviously interrupt code can't clobber registers like that, any shared register the ISR needs to share with ordinary code must be saved/restored on entry/exit somehow.
You disable interrupts for the three instructions it takes to emulate the atomic instruction. Which is barely slower than the atomic instruction would be anyway, because both have to read and write RAM, which is the slow part whether it's one micro-sequenced instruction or several standard ones.
You implement higher-level abstractions like mutexes. On a single core device this could be as simple as masking interrupts. You can use the mutexes to avoid the described race.
Rust is much easier to use on RISC-V [1] than on ESP32 [2]. I'm looking forward to making some small projects with this chip, assuming the software is usable.
Eicks! 10GB of disk space and 6GB+ RAM for the compiler? That’s seems crazy. No compiling that on most RPi’s. Maybe the cranelift project will help over time.
Specifically a compiler fork that needs to be locally compiled, AFAICT. It's doable on most developer's machines nowadays, but not all. Many laptops still only have 4GB of RAM.
It seems it only supports CDC and some JTAG mode. For keyboards and such, the USB stack should support HID which doesn't seem to be the case here. In other words, they've implemented a USB 1.1 FS stack just so far to make intermediary USB2UART chips like FTDI and CP2102 redundant.
I doubt they implemented CDC in hardware.
If they have a low-level USB peripheral, all the high-level protocols you want can be implemented in software.
This is pretty awesome, ESP32s were great little Arduino nodes with wifi. Having an open architecture should open up more software. They previously had their own cpu arch
How can they possibly sell these chips at these prices? This is impossibly cheap. You can’t even accuse them of trying to flood and control the market because they already own the market!
I think you might of gotten that impression after years of being raped by TI/STM levels of margin. TI even tried to sell their microcontroller with wifi at ~$20-30 price point.
Sounds like the Bouffalo BL602 and BL604 that were recently revealed. Competition in this sector is very interesting, I hope the Espressif chip will be as open or even more open than the Bouffalo chip.
I’d love to see a similar hobby-oriented chip that supported Thread as well. It’s a low power IPv6 networking stack that’s designed for connected home automation.
I manage to get around 80uA in deep sleep, when it’s on it’s around 100mA because of WiFi and peripherals. You can use an Otii to track consumption too but that hardware is expensive, there are cheaper ones like uCurrent etc.
Issue is BLE, power consumption on BLE is still not BLE level power (eg. Nordic chips). It’s still at mA levels.
Mind pointing me in the right direction? The ones I have are more like 10-20mA (maybe that's a side-effect of having USB on board? I'm not really an expert, I just want my battery powered stuff to last months instead of days)
With a BME 680, 2 seconds of measuring every 5 minute and esp-now protocol for sending, I estimate a 200+ day battery life. Esp-now protocol sends the message in a fracture of the time than wifi. Also you can tune the cpu & flash frequency depending on our workload. I have to wait 2s for the measurements to complete, so I lower the frequency to use less energy.
Just curious, have you been running it long enough to extrapolate that? I have some TTGO boards and they're a mixed bag. On one of the eink ones (which you'd think is the perfect scenario for deep sleep), they used a lipo chip that shuts everything off if the power draw is too low, so if you try to deep sleep the device never wakes back up
No, I did not, but I made tests with a configuration that was using more power.
I measured total runtime per wakup, and number of wakeups until the battery was depleted. I used this data to estimate the runtime if I take a measurment only every 5 minutes. This does not fully take in account the deepsleep current & battery self discharge. But wake up from deepsleep is definitly working.
From 3.7V to 2.7V I coud activate 37'000 times with a total runtime of about 8h.
You also have the battery voltage on IO35 with a 2x100kOhm Voltage divider.
The setup is not perfect, but good enough so far, and practical.
If I start over, i would look into
* taking a processor with lower speed und power.
* taking CR 123 or a battery optimized for very low self discharge current.
* Use a wireless protocol with very low overhead. I use ESP-Now now, WLAN would cut battery life in half.
That one has extra circuitry to shut the esp down completely and wake it on either an external trigger or RTC based alarm. It claims 1.5uA sleep current.
Thanks, these are some neat boards! A bit higher cost than the Aliexpress ESP32s I'm used to, but maybe that's the price you have to pay for better design and components. It's neat that the TinyPICO lets you turn off the power LED without having to cut traces on the PCB.
I was wondering with these RISC-V processors is a minimum set of features required for Go code to work with them? Is there an easy way to determine if a RISC-V processor will run Go code?
[1] https://news.ycombinator.com/item?id=24877335
[2] https://news.ycombinator.com/item?id=24916086
Skimming over C3 datasheet, it seems it doesn't have DAC but has one I2S. BL602 has DAC but no I2S!