Yeah.. which micro?

[Siwastaja]

AVR was promising, it's a pity they did their job for less than a decade, and basically had only two generations; the early devices (AT90S) in late 1990's were not that great but the sane CPU design and availability of GCC was the trick. Then, a few years later, they introduced another generation of devices (with Tiny/Mega naming scheme) with significant improvements in peripherals, but that's all, then they stopped all work and just sold the chips as they clearly kept selling. Finally, coming into 2010's, competition from much cheaper, much more capable ARM devices was overwhelming.

Meanwhile, PIC has always had larger lineup of devices with larger variety of peripherals. And peripherals are always the key in microcontroller market, not the CPU core! But because AVR originally succeeded thanks to their CPU core, they clearly forgot to keep the peripherals up to the competition. Slowly all projects drifted to devices which have better timers, better analog, modern communication interfaces. And AVR32 was "too different". 8-bit AVR core was actually quite powerful, the problem is always with peripherals. AVR peripherals are not bad, just the selection is very limited. By choosing different AVR chips, you can control whether you get 1, 2 or maybe 3 USARTs, but that's it.

[hans]

I think AVR benefited immensely from tools. The core was sane enough for a GCC port, which caught on because it supported decent C/C++ standards (see Arduino). The core was also quite capable. Then there were tools like avrdude which made programming chips super easy. I remember integrating an ATTINY85 into an industrial computer terminal (as an afterthought - we picked a SBC which didn't had a beeper). The chip was programmed with the onboard serial port using a small avrdude script, which was also used to send commands to the chip..

However, pricing for AVRs has stayed obscene. I remember 10 years ago looking at ATMEGA2560 and PIC32MX440/STM32F103. The choice was very clear which one to pick (32-bit). Who is going to pay 10+ euro for a 8K RAM MCU, even in 2010?
I also think there was the XMEGA series, which seemed like an interesting chip, however it had the new awkward PDI programming interface. I think avrdude supported it, but it required original AVR tools like the AVRdragon, instead of the very popular DIY or "entry-level" programmers.

I do wonder - since the ESP32 C3 has built in UART and is USB compatible AFAIK, why do they need to include a Silicon Labs USB to UART chip on the dev board?

Maybe to also cover bugs or other possible issues ?
It sounds like 'USB' a dedicated block, I wonder what BAUD rates it supports or does it skip a 'baud' idea if the connections are fully internal ?
I'd expect some firmware needed for this to function ?  Does the ROM have enough ?

3.4.9 USB Serial/JTAG Controller
ESP32-C3 integrates a USB Serial/JTAG controller. This controller has the following features:
• USB 2.0 full speed compliant, capable of up to 12 Mbit/s transfer speed (Note that this controller does not
support the faster 480 Mbit/s high-speed transfer mode)
• CDC-ACM virtual serial port and JTAG adapter functionality
• programming embedded/external flash
• CPU debugging with compact JTAG instructions
• a full-speed USB PHY integrated in the chip

There is notion of baudrate at USB CDC level. USB bits are transferred at 12Mbit/s, 480MBit/s, etc. (depending on USB spec/standard). Serial baudrate is for when the bits are put again on an UART/RS232 line and need to be transmitted at the correct speed.
Ofcourse the software will have a throughput limitation. But even for mid-end PIC24 microcontrollers it is able to transfer hundreds of kB/s, with a max of usually around 900-1000kB/s on USB2.0 12Mbits.

I imagine they need the Silabs serial converter because the bootloader is only capable of serial communications. It is possible to write a bootloader with over USB (e.g. Mbed had the USB drive firmware update figured out 10 years ago)... or STM32 has a DFU tool.. don't know why this is not a thing on ESP32s..

Onece you know 1 µC pretty well and understand the principles, it is usually not that complicated to learn to use a different one.  It is still convenient to still limit to a few types, not to have too many IDEs on the computer.

ARM finally ended this era. Not only the same tools (such as compilers) work for all ARM controllers, there is a certain "culture" in how the peripherals are organized. Even the CPU cores and tools standardized, this is already quite an improvement even when the peripherals are different.

Sadly, many people opt to continue the mess of "one tool for each manufacturer", or even worse, "one tool for each manufacturer per each 3-4 years" for no reason other than wrong impressions, bad documentation or lack of good tutorials.

Standarisation of your tools is key indeed. IMHO Eclipse (on which many of the ARM IDEs are based) or Visual Studio code are good choices nowadays with support for many languages so they also work far beyond the embedded microcontroller world (think VHDL, Verilog, Python, C / C++, Java, Lua, etc).

VCode is indeed a nice text editor for many languages. I write some quick python or small C programs in it, or browse through 3rd party code.
A "dumb" text editor is really old fashioned. I remember writing thousands of lines of code in Notepad for PHP websites 20 years ago, and I don't want to ever endure that much pain again. Even for those days it was not the best way to do it (but well.. what do you know when you're 10).

I nowaday use CLion. Sure you need to bare CMake, but once setup I can easily switch compilers (x86, ESP32, ARM, AVR, GCC PICs), run my unit tests with coverage, project-wide code refactoring tools, etc. If I need to do serious Python work (e.g. when I use nmigen) I use Pycharm.
Ofcourse CLion is not free, and I'm lucky to still have access to an academic license, but I would seriously consider buying a personal license (I also pay 10eur/month for Spotify, and that doesn't compile my projects)

[Kleinstein]

The AVRs were nice with GCC support and an early adaption of flash memory. I have not seen that much advance going from AT90S to the mega and tiny series. They got faster and a more sensible pinout, but the periphery was essentially the same, with some confusion due to name changes. On the periphery side I only remember USART instead of the old UART.

There was / is also the Xmega series with still essentially the same CPU but more capable periphery (12 bit ADC, DAC, event system, USB), though they started with a lot of erratas around the ADC. Before the AVRs had nice/ short erratas.
The newer AVRs like the xx09 or AVRxxDA... are no longer called xmega but are essentially from that family.

[Siwastaja]

The AVRs were nice with GCC support and an early adaption of flash memory. I have not seen that much advance going from AT90S to the mega and tiny series. They got faster and a more sensible pinout, but the periphery was essentially the same, with some confusion due to name changes. On the periphery side I only remember USART instead of the old UART.

There were small but significant changes like adding differential ADC inputs with 20x gain on some parts (Tiny25/45/85 for example)...

Things like that. Yeah, I don't mean massive advantages, but something that could be expected from the second "generation" and a few years of work. If they had this going for another 2 generations during the next decade, AVR could still be quite popular regardless of having just an 8-bit core. 16-bit memory bus is one of the advantages as well that made this architecture relevant and easy to program, despite 8-bit data path. And at 20MHz, single cycle ALU instructions and a lot of registers, 32-bit math really wasn't a problem, even if implementing quite fast PID loops (it was only lack of proper timers which prevented 3-phase motor control!)

At the same time, you can get a $3 ARM to do the job on peripherals alone, spending just a few% of the enormous flash and RAM, and nearly sleeping that powerful CPU; or running code that could run on the AVR as well.

Also even though psychological, I was sick of having to buy some $50-$100 dongle for each microcontroller family just to program it. Availability of Chinese clones for $5 helped but it's still a psychological barrier. I saw the availability of out-of-the-box standard logic level UART programming on STM32 a huge advantage, even if many do not use it at all. I certainly did and still do. Atmel ruined their microcontroller families by coming up with many different programming standards, all requiring a specific programmer. They should have just kept their classic ISP and add an option for UART, you can always buy an RS232-USB cable and add a level converter, or buy a $1 Chinese USB-UART logic level dongle.

[westfw]

AVR was promising, it's a pity they did their job for less than a decade, and basically had only two generations; the early devices (AT90S)... Then, a few years later, they introduced another generation of devices (with Tiny/Mega naming scheme) with significant improvements in peripherals, but that's all...

There were a USB series, and there was the XMega series.   The latter was promising, but they really bungled the release (or something) and they never really caught on.  (The new mega0, avr-dX, and xTiny chips are pretty nice too.)
However, they have the same problem as most 8 and 16bit microprocessors - expanding memory beyond 64k (bytes of RAM or words of code) is ugly, pretty much breaks the compiler models ("trampolines"?!  Even the development of better peripherals ended up pushing most of them outside of the "special" address space that the instruction set was designed to use :-(
I imagine their internal scandals didn't help, either.

[ssashton]

since the ESP32 C3 has built in UART and is USB compatible AFAIK, why do they need to include a Silicon Labs USB to UART chip on the dev board?

Probably for Arduino compatibility?  The Serial port can be coerced into supporting "automatic reset and upload", while USB ports tend to be more problematic in that regard.  I believe that the board uses the ROM bootloaders, and the USB bootloader might be "tricky" to run, cross platform.

(I'm not sure I'd have picked a ESP32-C3.  The RISC-V version is relatively new, and there isn't a lot of community experience, AFAIK.  OTOH, it's less obscure to actually use, than the Tensilica core.  Good Luck.)

There is also the ESP32 S2 with an LX7 processor. Both are recently supported in Arduino. I'll see if I can get one of those to play with too.

I have seen an ESP32 board without the USB chip. I wonder if they had to pre-load it with something or it just works?

[ssashton]

Looks like I might not get the ESP32 module from Mouser.

The item(s) on your orders are controlled for export and re-export, and/or transfer (within the US) by the US Government.

I filled this in once saying 'Hobby use' but they rejected it asking for more detailed information. See if this satisfies them.

[DrG]

As a result of this thread (and maybe because I am sick of selecting holiday gifts for others), I ordered this, from Espressif and through Amazon and it is scheduled to arrive in a few days...

https://www.amazon.com/Espressif-ESP32-C3-DevKitM-1-Development-Board/dp/B08W2J9B8J

[harerod]

ssashton, I admire your patience and your attention to detail. 
That being said, I wonder why the U.S. Government is controlling the flow of Chinese hardware. I never heard of any restrictions here in the EU. However, due to the quantities required, my clients never bought those from an American distributor. I have been developing BLE and WiFi for quite some time. Starting out with TI products, which required an expensive per seat license for the IAR IDE (after a limited test phase).
TI BLE lost any of our future projects, the moment ESP8266 and then ESP32 came along. Free, unlimited development tools. And to my huge surprise, the ESP32 has such a benign EMC behaviour that my first design passed medical 60601-1-2 and ETSI with flying colors.

For not-so-much-radiating chips I prefer STM32, AVR and PIC - whichever is currently in stock and fits the requirements.

[SiliconWizard]

AVR was promising, it's a pity they did their job for less than a decade, and basically had only two generations; the early devices (AT90S) in late 1990's were not that great but the sane CPU design and availability of GCC was the trick. Then, a few years later, they introduced another generation of devices (with Tiny/Mega naming scheme) with significant improvements in peripherals, but that's all, then they stopped all work and just sold the chips as they clearly kept selling. Finally, coming into 2010's, competition from much cheaper, much more capable ARM devices was overwhelming.

Meanwhile, PIC has always had larger lineup of devices with larger variety of peripherals. And peripherals are always the key in microcontroller market, not the CPU core! But because AVR originally succeeded thanks to their CPU core, they clearly forgot to keep the peripherals up to the competition. Slowly all projects drifted to devices which have better timers, better analog, modern communication interfaces. And AVR32 was "too different". 8-bit AVR core was actually quite powerful, the problem is always with peripherals. AVR peripherals are not bad, just the selection is very limited. By choosing different AVR chips, you can control whether you get 1, 2 or maybe 3 USARTs, but that's it.

Agree with that. The fact AVR got so popular is even a bit unexpected IMO. Sure it was nicer to deal with than the PIC of the time, especially for programming them in C. But history is interesting: AFAIR, AVR was actually a student's work, and the end-result was not that different from what the two students designed. I wonder if that was not part of what made those chips popular in universities, which in turn pushed a lot of new students to use them in their future jobs.

[Kleinstein]

I don't think the universities cared so much about the history of the CPU - not sure if the students also designed the periphery.

The AVRs in the early days had a few advantages: 
- the support by GCC and thus a free C-compiler
- simple, logical ASM code, so a good platform to learn ASM
   some of the early, small chips like AT90S1200 had too little RAM to really use C.
- relatively cheap ISP porgramming and the option to build an even cheaper DIY one for the first tests
- flash memory, while PICs were still often OTP
- relatively little erratas

I don't know when the feature was available in the early versions of AVR studio, but the simulator part is a great feature for beginners, e.g. learning ASM.

[james_s]

GCC support was(is) a huge benefit, it's entirely feasible to do cross platform development entirely with an open source toolchain. You don't need a big bloated IDE if you don't want one, you don't need to spend money on crappy proprietary tools, the chips hit a nice sweet spot of simplicity vs capability and overall they just work.

I don't see a lot of value in the higher end AVRs like the xMega series. They are expensive, my friend who used one in something said they had some annoying quirks, and once you get to where you need a part in that class it's hard to come up with a good reason to not just go with ARM. Where the AVR shines I think is for simple projects where a basic 8 bit microcontroller is all you need. It would be silly to use an ARM as a glorified 555 timer or LED blinker, a Tiny13 or something similar is a good fit though. There are loads of embedded projects that are small and simple, not everything needs a graphical TFT and a zillion IO pins.

[tszaboo]

However, pricing for AVRs has stayed obscene. I remember 10 years ago looking at ATMEGA2560 and PIC32MX440/STM32F103. The choice was very clear which one to pick (32-bit). Who is going to pay 10+ euro for a 8K RAM MCU, even in 2010?

Yeah, it is clear that pricing is more important for these parts than the peripheral set or the core. The AVRs had quite limited peripherals, but they beat the ARM7TDMI chips, so everyone was using them. Nowadays there are many projects done for the ESP32. The toolchain is bad, the ADC almost doesn't work, doesn't have built is USB or flash on older chips, few pins, not a lot of versions. S TI simplelink, or an NXP micro with wifi is objectively better chips. But the price is killer enough to get new projects.

As a result of this thread (and maybe because I am sick of selecting holiday gifts for others), I ordered this, from Espressif and through Amazon and it is scheduled to arrive in a few days...

https://www.amazon.com/Espressif-ESP32-C3-DevKitM-1-Development-Board/dp/B08W2J9B8J

I got myself an S3 engineering sample. USB-OTG, wifi, BLE, so everything one would need.
Hopefully they update micropython to support it.

[james_s]

As a result of this thread (and maybe because I am sick of selecting holiday gifts for others), I ordered this, from Espressif and through Amazon and it is scheduled to arrive in a few days...

We stopped exchanging gifts a few years ago when most of my family reached the point where we had almost everything we could want and were out of space so anything new required getting rid of something we had and everything we still wanted was too specific or too expensive to ask for as a gift. Now we typically exchange a few small gifts, consumable stuff like snacks and treats, and then just buy ourselves something that we actually want, it's a lot less hassle and nobody has to find a way to tactfully return or exchange things or find a use for something they never really wanted.

[ssashton]

Mouser shipped my devkit! I guess that was the extra detail they needed.

Nowadays there are many projects done for the ESP32. The toolchain is bad, the ADC almost doesn't work

Curious for more detail about these two remarks?

[hans]

The ADC is "unusable" because it requires a 2 point calibration (y=a*x+b) for it to be barely usable, but even then there are clear offset, gain and non linearity errors. You could improve this with more calibration constants, but that is a PITA to characterize manually for each chip/board that is produced.

Personally I'm neutral on the toolchain. ESP-IDF does look like it's the only way people are using the ESP32 hardware (I've barely seen anyone writing code that talks with registers directly), but it does seem to work reasonably well in my limited experience. However, at times it can be a bit unclear what the capabilities/limitations of the hardware are.
I only touched ESP32  through Arduino runtime, because I allowed myself a holiday project that I wanted to "just work". The compiler is based on GCC which is good. But the [Arduino] libraries I had used, still had very obvious bugs in them (such as hinting which WiFi channel a station was on wouldn't get used, resulting in 3s+ instead of <300ms connection times).

Another complaint I may have is that the ESP-IDF contains proprietary build tools to create and flash images using the integrated serial bootloader. Although this worked I had to downgrade some of my pip packages I haven't tried to use the chips with JTAG yet. It's supported by openocd, so most JTAG cables should work I suppose.

[Kleinstein]

I don't see a lot of value in the higher end AVRs like the xMega series. They are expensive, my friend who used one in something said they had some annoying quirks, and once you get to where you need a part in that class it's hard to come up with a good reason to not just go with ARM.

The Xmega chips are not that expensive. By now they are the cheaper ones if you want more than some 8 KB of memory. It is more that the old ones are expensive for more momory.
The Xmega series also has more capable periphery: Event system, fractional divider for Baud rate, 12 Bit ADC (also faster) - though with some bugs in the early ones, DAC (sometimes) and a few more features, Clock PLL, DMA,... .  The main downside is that one needs another programmer.
AFAIK they still used the same IDE (AVR Studio), so the software side is/was easy.

[tszaboo]

Mouser shipped my devkit! I guess that was the extra detail they needed.

Nowadays there are many projects done for the ESP32. The toolchain is bad, the ADC almost doesn't work

Curious for more detail about these two remarks?

It has a range of what, 1.2V peak to peak? No reference voltage is available on any pins, and it has a large offset, and it is silicon lottery what you get.
https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/peripherals/adc.html

Its not even suitable for a simple "measure battery voltage" kind of tasks without calibration.

The toolchain is just meh. I do hardware and couldn't care less about learning yet another toolchain with the usual "spend 3 days just to make your project compile and upload" bullshit. I just tried to flash my ESP32-S3 with micropython, and the bootloader just tells me that "Error 0xFFFF". No results online how to fix it. 

[james_s]

I wonder how they screwed up a simple ADC so badly? It's not exactly a new and exotic feature in the world of microcontrollers.

[Psi]

There were small but significant changes like adding differential ADC inputs with 20x gain on some parts

Some even had x200 gain. I always wanted to try x200 for something, but never did.

[Kleinstein]

I wonder how they screwed up a simple ADC so badly? It's not exactly a new and exotic feature in the world of microcontrollers.

The ADC part has / had problem in severa occasions. So the ADC is not such an easy part. The processes are mainly made for digital operation and analog parts can be a bit tricky and not all is caught by similations. Unless totally broken they may not want to do a new expensive set of masks. There are usually some software work-arounds or still acceptable performance reductions (e.g. full performance not for all inputs, extra dummy conversions needed, more delays needed, limited reference range).
Some limitations in the fine print / erratas effecting the ADC of µCs are common. A look at the erratas is generally a good idea - not all features promissed in the DS may actually work and for some reasons they tend to keep those down sides in a separate file instead of changing the DS. Some limitations can be quite serious, like the interrrupt priorities not working correct with the early (not sure they fixed it) PIC18.

[ssashton]

It has a range of what, 1.2V peak to peak? No reference voltage is available on any pins, and it has a large offset, and it is silicon lottery what you get.
https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/peripherals/adc.html

Its not even suitable for a simple "measure battery voltage" kind of tasks without calibration.

That's useful to know!  So am I right presuming the ADC is not actually delivering 12-bits of analog resolution?

[hans]

I wonder how they screwed up a simple ADC so badly? It's not exactly a new and exotic feature in the world of microcontrollers.

The cynic in me would say it's far easier to "implement" digital design using copy-paste development than it is to fine tune an analog part. Especially in CMOS it's quite an art, since absolute tolerances of +/-20% not uncommon. Relative tolerances could be far better, but is still a silicon "lottery" in terms of matching quality that varies with random direction vectors, not to mention considering the PVT corners.
It's like digital is more like building a city. Some parts of it will be badly implemented, but as long as you can reach any place you want it will remain to function.
Analog is like building a skyscraper (or any high rise building). If you mess up the foundations, it will likely not perform well and collapse.

Anyhow, it's still remarkable it go to that state. We are used to rail-to-rail quite-linear ADCs with "no missing codes" for years, even in MCUs... Not to mention that some competitors are able to make multi-MSPS >12-bit ADCs in modern processes.

[SiliconWizard]

I wonder how they screwed up a simple ADC so badly? It's not exactly a new and exotic feature in the world of microcontrollers.

And it's not that simple either.
Many major vendors use ADC IPs they either carefully crafted over the years, or just buy existing IPs. Here they probably wanted to cut costs and had no prior experience with designing ADCs.

[Siwastaja]

Good ADCs are difficult to design, really, but they are trivial to buy as an outsourced IP; this is easier than ever, and not even that expensive.

But ultimate penny-pinching is the likely reason for failure.