EEVblog Electronics Community Forum
Electronics => Microcontrollers => Topic started by: ssashton on December 05, 2021, 07:13:18 pm
-
I'm in the process of designing and coding my first product that uses a micro. It's not large scale, just a cottage business.
I am prototyping with an Arduino Uno, it's that simple, just drive an OLED and send I2C commands to a dedicated DSP that does the heavy lifting. I've started to run out of SRAM but PROGMEM seems to take care of that.
So, before I get to board layout I wondered what might be a good MC choice in this time where parts are like gold dust? Is the ATMEL328 a good choice?
I'm tempted to make the MC on a daughter board so I can change it easily. Is this a good idea or is there a range of MC that are pin compatible anyway?
-
You're already familiar with the M328 and it does the job, so it is reasonable to use that if you can get it. There is a whole family of AVRs with the same pinout but the M328 is the top of that range IIRC so there is nowhere else to go with that. The world seems to be going toward ARM but I've found those to be a LOT more complicated to work with so I've stuck with 8 bit AVRs for most of my projects. Putting the uC on a daughter board sounds like a kludge, I would not bother with doing that, you can always spin a new board sometime down the road if the part you're using gets discontinued but I don't see the M328 vanishing any time soon.
-
I agree with james_s here.
If the ATMEGA328 does the job for you there is hardly any reason to use another uC, especially if you expect to sell low to medium quantities. If you sell multiple hundreds of PCB's then the price of the uC becomes a significant factor.
Adding a daughterboard for the uC is silly. It would mean extra costs for that PCB and a more complicated assembly. Unless PCB area is really important, it makes sense to reserve some room on your PCB around possibly difficult parts, so you can localize modifications if you have to respin the PCB because of parts shortage.
-
Use what you are comfotable with.
If you do find out that the 328 isnt cutting it, then finding another processor that is highly arduino compatible might be the best way forward.
So either you could go for a bigger arudino board, maybe something based on a Mega like the arduino nano every (48K flash 6k ram).
Or an newer arduino board that has an ARM processor, but still has the full support of the arduino ecosystem, eg something like the nano 33.
-
First check the suppliers and the availability, then decide your options :-DD
With the fab crysis, you'll definitely want a company that runs its own, Microchip should be a good option (Although I'm not up to date onthis), hopefully you'll be able to source any pic/atmega mcus easily.
-
NXP's LPC ARM Cortex controllers are worth looking at. Simple and reliable devices. Not the cheapest out there but the very few bugs and easy to use peripherals pay back in time saved. IMHO these are a good step up when coming from 8 bit microcontrollers.
-
I'm in the process of designing and coding my first product that uses a micro. It's not large scale, just a cottage business.
I am prototyping with an Arduino Uno, it's that simple, just drive an OLED and send I2C commands to a dedicated DSP that does the heavy lifting. I've started to run out of SRAM but PROGMEM seems to take care of that.
So, before I get to board layout I wondered what might be a good MC choice in this time where parts are like gold dust? Is the ATMEL328 a good choice?
I'm tempted to make the MC on a daughter board so I can change it easily. Is this a good idea or is there a range of MC that are pin compatible anyway?
What size is the OLED ?
You could work backwards, from the RAM which seems to limit you, and choose.
8-bit MCU have simpler manuals, but generally have less RAM than 32b MCUs
The AVR DA/DB series are newer, have 4K RAM, and are easy to get right now because wider usage is not yet out there :)
-
If the 328 works, but you are using less than all the flash, consider the lesser ones in the series to save a little money - ATMega8, 48, 88 and 168, the 48/88/168 all have broadly the same capabilities as the 328 just less memory, the 8 has a compatible pinout but lacks some features I can't remember off the top of my head.
-
Is the ATMEL328 a good choice?
I would say that the 328P is getting a bit "long in the tooth." A little while ago, there was a NRND on the ATmega328p product page, and now I can't find a product page (alas, it is tempting to blame these on Microchip's crappy web page maintenance!)
If you can use SMT, I'd consider at least an ATmega328PB. Despite extra features, this has been cheaper than a 328P for a while now.
If you must have DIP, there are the new AVR128DA28 chips, which are currently IN-STOCK at microchip direct. These have LOTS more memory than a 328, and are likewise cheaper. But you lose a pin or two, and the HF crystal oscillator. Or maybe an AVR128DB chip.
-
First check the suppliers and the availability, then decide your options :-DD
With the fab crysis, you'll definitely want a company that runs its own, Microchip should be a good option (Although I'm not up to date onthis), hopefully you'll be able to source any pic/atmega mcus easily.
Microchip outsources most of its production these days. The best they can make themselves is 130nm from a 17 year old fab.
source: https://en.wikipedia.org/wiki/List_of_semiconductor_fabrication_plants
-
Maybe for newer devices, but I highly doubt they do that for older tech. Having multi-million $ fabs stopped will make them lose a lot of money, specially nowadays.
ATmega328 dates back to 2002! So do a lot of other mcus.
This can be easily seen: Devices that have been +6 years on production are easily sourced, while newer designs (ex. PIC18-Q10 family) are gone and estimated for DEC-2022!
I might be wrong, but that's what it seems to me, so I would stick to older tech.
Even stm32 isn't that edge cutting: they started to use 40nm in their H7 series in 2016.
A lot of their product line still use 90nm, which is a 2003 technology. In 2005 we already had 65nm.
Most mcus don't need such ridiculous high density fab process, their transistor count is low compared to modern computing.
So relying on older fabs process keeps costs down, I guess. These plants already payed themselves years ago.
I keep thinking that this semiconductor crysis is partually faked to riuse the prices.
Yeah, TSMC might be completely overloaded with all phone/cpu/gpu new tech stuff, but c'mon, the're hundreds of fabs using older tech.
Not everything is GDDR5, Nvidia/AMD and 3D-NAND.
-
Thanks for the replies! I thought ATMEL328 was bottom of the range I didn't know ATMEL8, 48, 88 and 168 existed.
Interesting though, I just looked at the JLC PCB stock and they have STM32 F6 for $1.05 each 6.6k in stock. While the humble ATMEL328 is $6.04 each and only 3.3k stock. Even the ATMEGTA32 is cheaper at $4.10 each.
Suppose I should use the STM32 even if it's way more than I need, haha. I heard lots of stories about them being unavailable for less than $100 each!
-
Wow prices are WAY up on the atmega series, the last time I bought a M328 I think it was under $2. They are an old part, but the fact that the standard Arduino is based on one I think has contributed to them being produced in huge numbers for a long time. Also they're nice parts, powerful enough for a lot of applications and easy to work with.
-
Right now you have to use what is available, and only current availability matters.
Heck, I would force a project into the old and crappy atmega328p if that is what I could get.
If you already have your project up and running on mega328p and you can buy the chip, don't wait any longer, order the parts immediately for the whole production batch. As large batch as you can justify.
Because tomorrow, atmega328p might not be available.
And no one can predict what parts come and what disappear overnight.
-
Right now you have to use what is available, and only current availability matters.
Heck, I would force a project into the old and crappy atmega328p if that is what I could get.
I probably would not. But that would very much depend on requirements to begin with...
And no one can predict what parts come and what disappear overnight.
That's for sure.
Just from a quick look on Mouser a few minutes ago, it appears the cheapest and in stock MCUs at the moment, at least on Mouser, are the PIC32MM. I would probably take that if I had no choice.
On Digikey, the listing is quite different.
-
I am prototyping with an Arduino Uno, it's that simple, just drive an OLED and send I2C commands to a dedicated DSP that does the heavy lifting. I've started to run out of SRAM but PROGMEM seems to take care of that.
Some of my designs are Uno based, in fact so much so I used to buy Uno boards from China and use hot air to move the parts across to my design... the processor, crystal, usb i/f, etc. It's not a bad approach if you are hand assembling a few. Using Arduino Uno as a base design has lots of advantages, e.g. reliable boot loader, easy development system etc.
If you are thinking of moving then you should use the device features to guide your choice, do you need LCD control, in-built USB, WiFi, etc etc. Recently I've been using ATSAM but that is because they fit my requirements.
Have fun!
-
You could take a chance on the LGT8F328P - a clone of the 328 with a few extras added.
Arduino-like modules are available on aliexpress. To get the bare chip search for it on alibaba.com.
A random review:
https://sites.google.com/site/ericmklaus/projects-1/lgt8f328p-arduino-clone
-
I've not used an ST32 or really anything other than the Uno. Is there a reason I should not use the STM32F6 for my project? I've seen people compile from Arduino IDE using a library for the STM32 F10 and then program from an FTDI dongle. Can I do the same for F6?
-
Could you tell us what an STM32 "F6" or "F10" is? Because those references are not right.
-
.
-
I've tried to get into ARM a few times, but I found them to be so incredibly complex and the software required so bloated and crappy that I've gone back to 8 bit AVR every time. AVR Studio 4 is SO much lighter and more responsive than all of that Eclipse based crap. I'm not a professional developer, life is too short to spend hours just getting an LED to blink when I can do it in 2 minutes with an AVR.
-
I've tried to get into ARM a few times, but I found them to be so incredibly complex and the software required so bloated and crappy that I've gone back to 8 bit AVR every time.
It looks that way and I admit you easily get lost here, but this doesn't need to be that way. I write software on ARM processors exactly like I did on AVR. I refused to do anything else; I also refused to go back. It paid off. The amount of code required is approximately 1.5-2x, and there is no bloat. It's not that bad. The key is not to change your workflow in any way. Open up the manual, look up the peripheral registers, write code. Done. Get LED blinking on AVR: set direction register to output. Blink the LED by writing to output register. Get LED blinking on STM32: Enable clock to GPIO port. Set MODE register to output. Blink the LED by writing to output register.
Sure, it's more complex. But not by orders of magnitude. Maybe by 2x. And when you get to devices like STM32H7, it's like 5-10x, but you don't need to start there. I like some things better. For example, I like changing clock source in software even if it results in 2-3 lines of more code, instead of having to understand a special concept called "fuses", how to program them, and how they end up apparently "bricking" the device.
-
Most AVR peripherals are pretty much the same across different ATMega chips.
The registers can differ a bit sometimes, however it usually doesn't take much time to move to a new ATMega. Or to get your code running on a different ATMega to what it was written for.
So maybe just decide how much FLASH / EEPROM / SRAM is plenty for all the stuff you want to do and pick a ATMega that meets those needs.
Biggest ATMega mcu I've used myself is ATMega640 (64K / 4K / 8K).
The problem with the bigger ATMega's is that they cost quite a bit verses ARM mcus which are much more powerful
eg, ATMega640 is like $10 and $10 would get you a crazy fast STM32 MCU.
It really depends what matters to you. If you're just messing around with it then a more expensive AVR mcu might be good, you already know the hardware peripherals and dont need to learn ARM.
Just be aware there are some newer ATMega/ATTiny chips that microchip have released that are NOT the same as the old ones.
eg, ATMega809. They have a different looking datasheet, you program them differently (UPDI), and the peripheral registers are quite different.
-
The older AVRs are relatively similar in the periphery - just not all in all chips, but a similar ADC and sinilar USARTs and so on.
There now newer ones related to the old Xmega series - again a group of rather similar chips, but quites different in the periphery. For higher power / larger memory the newer series AVRs are relatively cheap, especially the AVR128DA... series (around $2-$3 depending on the case).
Currently STM32xx have awful awailabilty. So there is a chance that you can't get the chip you planed for. So one may have to buy the chip before actual doing the design.
-
As you made your prototype with Arduino UNO, I think Atmega328P (https://www.theengineeringprojects.com/2017/08/introduction-to-atmega328.html) will be a good choice.
-
Wow, I would never've imagined the world would run out of atmega328s.
I think the same thing happened like with many other components. The chinese bought the entire stock and are hoarding them, with scalping the prices.
When I look at octopart, I see many on stock at not authorized distributors.
-
I can see it happening like this:
Designer can't buy the STM32 they originally used.
Pick another STM32.
Can't get any STM32.
Panic.
Try other ARM vendors.
Not much better.
"Hey, there was this popular Arduino thing, I tried it a decade ago, wasn't it ATMega328P? While underperforming and lacking peripherals, it was quite simple to use and it worked. I'm sure I can make it work. Is it still available?"
Hit order button in panic.
-
So, before I get to board layout I wondered what might be a good MC choice in this time where parts are like gold dust? Is the ATMEL328 a good choice?
I left the AVR family a decade ago. Too expensive for the features available. The 328 is a typical hobbyist choice because of Arduino. For a business I'd think different.
- 5V is athing of the past. Most current devices use 3.3V today. Using lower voltages decrases power, and this relation goes with a power of 2. Imported if you plan for mobile devices.
- Use SMD parts whereever possible. The cost of manufacturing per part is much higher for through-hole parts (*5...*10)
- The CPU core is not that important any more. In a business settimng noone will code in assembly any more since it is too expensive. Unless you have 6 figure quantities.
- The available peripherals are important. Many PICs for example have numerical controlled oscillators or configurable logic blocks etc. If your application can benefit from special hardware blocks, choose your MCU accordingly.
I'm tempted to make the MC on a daughter board so I can change it easily. Is this a good idea or is there a range of MC that are pin compatible anyway?
Too expensive. Connectors cost money, PCBs const money, assembly cost money, and the reliability decreases. If necessary, just do a new board design.
For small projects I often use PICs. Microchip has own fabs for them, so the long-term avialability usually is not a problem. AVRs are manufactured elsewhere as Atmel sold their fabs long ago. The newer PICs have better peripherials then the classic AVRs, and they usually run at full speed even at lower voltages.
-
The biggest issue in those large, expensive AVRs is that while they grow in number of IOs and available flash and RAM, the peripherals remain the same, quite stone-age actually.
There was one special AVR which included CAN peripheral and some special AVRs with motor controller timers, but these were all "special snowflake" parts, even more expensive, and pretty old otherwise.
In the meantime, even the crappiest, lowest cost ARM MCUs come with 3-phase motor control timers, USB, often CAN, even ethernet on "mid class" devices, still cheaper than some ATMega640 (which I did use in a few projects. A nice chip when you just need a lot of simple IO.)
I didn't go into ARM for CPU processing power or memory. That was secondary, a side effect, or "nice to have". Better peripherals is the real reason. It's also the reason not to go back to the AVR devices except for the simplest projects. Sadly, nothing prevented Atmel from implementing more and better peripherals, but they trusted their successful product lineup from early 2000's so much they didn't want to change it at all. PIC had more variety in peripherals all the time.
-
still cheaper than some ATMega640 (which I did use in a few projects. A nice chip when you just need a lot of simple IO.)
Or if you need 4 hardware UARTS :)
That why i used it.
-
The old AVRs got expensive with large memory. The newer ones (Xmega related like DA, DB series or the xx09 ones) have also more capable periphery and are cheap also with 64 K or 128 K.
They however need a new programmer.
If it is for 4 UARTS, the new AVRxxDA48 comes with 5 and the 64 pin version with 6.
-
I'll use JLC PCB to assemble my boards and the model number they have most stock and lowest price is STM32G030F6P6TR and the datasheet shows some variations based on memory. However I realise now this is called the STM32 G0 series:
(https://i.ibb.co/fN8TcHF/Untitled-1.png) (https://ibb.co/8xzQh9s)
(https://i.ibb.co/KX4VMK0/Untitled-2.png) (https://imgbb.com/)
There are also Arduino compatible STM32 boards based on what I thought was STM32 F10, but it is actually STM32 F1 series:
https://www.instructables.com/Getting-Started-With-Stm32-Using-Arduino-IDE/ (https://www.instructables.com/Getting-Started-With-Stm32-Using-Arduino-IDE/)
A lot of you are talking about knowing the peripheral registers, but having only worked with Arduino IDE I don't think I've dealt with this. I guess that is all part of the Arduino library. So I think I need to take a step back and ask; even if I used the ATMEL 328 which the Uno is based on, what would I need to do to use the bare chip in my project? Can I not simply connect an FT232 to the RX / TX pins and program it via Arduino IDE? I do kind of remeber hearing something about AVR chips not having the embedded bootloader installed?
P.S. I don't need clever peripherals, I've already got this working on the Arduino Uno and I programmed it in Arduino IDE (C++). All the MCU does is take input from a rotary encoder, display some text on OLED (128x64, but I might go bigger) and spit out I2C writes directly to specific registers on the DSP chip. Although I would be nice to add an SD card, USB file transfer or other way for the user to drop a text file with custom filter coefficients on the MCU that can then be written to the DSP.
In reality though, I'm not paying bloody $6 for a bare ATMEL328 when an STM32 is $1. So I better start learning how to move this project over to the STM32 G0. ESP32-C3 is another sensibly priced and stocked option.
-
Oh, if you have zero experience working with microcontrollers and only have worked with Arduino Uno and Arduino libraries, I very strongly suggest you get Arduino Uno or compatible boards and work with these. Even from iffy sources. Trying to start learning microcontrollers now, from scratch, would be very time-consuming and would kill your actual project.
Sure, I have worked that way in the past, promise something in 3 months then start learning how the heck I do that. And then it takes 6-9 months and the customer is not happy. In the end, it always worked out but it's a stressful situation.
Really, unless you are really experienced, the best advice is to keep using what you are comfortable with. Unless you know that Arduino libraries are available on some other MCU, and you know they work exactly (or very close to) the same, assuming this and just buying something is a huge risk. You'll learn, sure, but you'll fail to deliver the project as well.
When you are more experienced and worked with many different microcontroller families, you get better at finding the relevant things in the documentation and have seen many of the traps, so it's much faster to develop even on an unknown microcontroller. And if you have worked on 8-bit PIC or AVR before the Arduino era, that's a really good start to build on, but if you have only worked with Arduino libraries and your projects have been simple enough so that you didn't need anything else, then you have quite some road ahead. You may be able to cope with libraries of whatever MCU vendor (such as STM32 HAL) but the problem is, they are all different, they are not similar to Arduino libraries at all, and look much more complex and bloaty, compared to the simple Arduino interfaces.
Arduino sure does good job getting people motivated, but it's really like those training wheels. The next step is to remove the training wheels and keep going (this includes falling sometimes), not buying a Harley Davidson motorcycle.
-
The step from the Arduino libraries to the STM HAL libraries may not be so bad. It is some change, but at least one would not complain about the limitation of the HAL libaries. HAL produes quite some overhead ( in my case (depends on the periphery used, more in debug mode) some 14 kBytes - which is a bit much to use a 16 kByte µC) for the start, but it is not so bad with a larger µC. The Arduino libs also add some overhead and some init code is needed anyway.
The STM32 are at least a µC worth looking at them and maybe have a look at the HAL documentation. Everybody learns different and maybe you like (or hate it) that style. I personally do not like HAL very much, but I came from the AVRs programming very close to the HW, paritally in ASM and some hate towards bloated documatation. It only got better with the PDF search function.
-
Whatever you do, sticking to a good old part forever just because it's your comfort zone eventually leads to panic once the part is not available anymore. It's a very non-resilient approach. So exploring new MCUs and new things in general is a GOOD thing. The later you do it, the more painful it will be.
-
Really, unless you are really experienced, the best advice is to keep using what you are comfortable with.
But if you do that, how do you become really experienced?
-
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. Besides learning about the µCs one may also need new hardware for programming / debugging with a new µC type.
Some µCs are also relatively similar, like the STM8 and STM32 series. Different CPU, but similar periphery. When programming in C the CPU part does not really matter - there can be speed differences, but most programms don't need the full speed anyway. Switching to a new µC family is mainly learning about the IDE and periphery, not much about the CPU. Chances are one would anyway look up the periphery details when programming the parts close to the HW - so the quality of documentation can be a big point.
-
Whatever you do, sticking to a good old part forever just because it's your comfort zone eventually leads to panic once the part is not available anymore. It's a very non-resilient approach. So exploring new MCUs and new things in general is a GOOD thing. The later you do it, the more painful it will be.
I don't think the entire 8 bit AVR series is going to vanish overnight, even if they go out of production I'll still be able to find enough of them for my personal projects. If I really have to move up to ARM some day I will, but I have no compelling reason to do so at the current time.
-
Really, unless you are really experienced, the best advice is to keep using what you are comfortable with.
But if you do that, how do you become really experienced?
Yeah, excellent question, my comment assumed project is already in a crisis due to lack of parts, and job needs to be done. In bigger picture, you should really find projects where you get some leeway for experimenting and widening your skills. Best projects are such where the whole team learns. But sometimes you just need the Job Done ASAP. If all projects you do are that way, you never learn much. You just learn to do the same projects tiny bit quicker every time.
-
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.
-
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).
-
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).
Text editor. It's lightweight, fast, and universal, and will stay universal for the rest of my days.
-
It seems that Arduino IDE have support for a number of ESP32 types, so I think that sounds nice. In addition I've read that ESP32 have a pre-loaded bootloader that allows programming of the chip directly over UART or USB. The WROOM modules with antenna, crystal, and ROM is also attractive.
https://randomnerdtutorials.com/installing-the-esp32-board-in-arduino-ide-windows-instructions/
I ordered a ESP32 C3 dev kit so I'll see how I get on with that.
I do not have a deadline and I am the whole team. So that's an advantage in some ways, but obviously I'm also very inexperienced.
-
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).
Text editor. It's lightweight, fast, and universal, and will stay universal for the rest of my days.
But no syntax highlighting, realtime error indicators, function outline, call hierarchy, etc, etc. No thanks!
-
But no syntax highlighting, realtime error indicators, function outline, call hierarchy, etc, etc. No thanks!
I use Notepad++ on my Windows machine, Pluma on my Linux machines and Atom on Mac, all three of these have most of these features.
I've had to use Eclipse on a number of occasions and it is a steaming turd. It's practically the poster child for software bloat.
-
Alright, well I got Arduino IDE to install support for numerous ESP32 modules! It returns no errors when compiling for the RISC-V ESP32 C3 dev board (except when I tried to manually include avr/pgmspace.h). Now I just need to wait for the dev board to arrive.
(https://docs.espressif.com/projects/esp-idf/en/latest/esp32c3/_images/esp32-c3-devkitm-1-v1-isometric.png)
https://docs.espressif.com/projects/esp-idf/en/latest/esp32c3/hw-reference/esp32c3/user-guide-devkitm-1.html
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?
-
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.)
-
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
-
Just from a quick look on Mouser a few minutes ago, it appears the cheapest and in stock MCUs at the moment, at least on Mouser, are the PIC32MM. I would probably take that if I had no choice.
At least that's MIPS, not the awful PIC 8 bit ISA(s).
I assume the peripherals are similar. A lot of people seem to say "sure the PIC instruction set is rubbish, but they have better peripherals than Atmel" (back when they weren't the same company anyway).
-
I don't really blame the PIC for its faults, it was one of the first products of its kind on the market. I certainly think the AVR was a large step up though, more than 20 years ago when I first started out with microcontrollers I tried PIC and AVR and it didn't take me long to settle on AVR.
-
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.
-
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)
-
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.
-
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.
-
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.
-
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?
(https://i.ibb.co/k44df4x/Ha13d91855dd44082aff4d498cb8051b18-1.jpg) (https://ibb.co/k44df4x)
-
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.
(https://i.ibb.co/rGNcNgs/Untitled-1.png)
-
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 (https://www.amazon.com/Espressif-ESP32-C3-DevKitM-1-Development-Board/dp/B08W2J9B8J)
-
ssashton, I admire your patience and your attention to detail. :-DD
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.
-
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. ;)
-
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.
-
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.
-
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 (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.
-
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.
-
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?
-
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.
-
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.
-
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
(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.
-
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.
-
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.
-
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.
-
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
(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? ;)
-
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.
-
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.
-
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.
-
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 (https://www.amazon.com/Espressif-ESP32-C3-DevKitM-1-Development-Board/dp/B08W2J9B8J)
Pretty quick delivery. Hey does this count as an 'unboxing'? ;)
(https://www.eevblog.com/forum/microcontrollers/yeah-which-micro/?action=dlattach;attach=1346522;image)
-
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.
Typical microcontrollers run at ~80MHz, these ESP32s at 400. I guess they are using different process nodes, and they might have different analog characteristics. It could be as simple as too much ESR on an analog switch or leakage current too high on the SAR capacitors. You probably know this though.
-
As a (big) step up from ATMEGA328 boards, I went with Teensy boards which are 32-bit ARM based (48 MHz Cortex-M0+ to 600 MHz Cortex-M7). See https://www.pjrc.com/teensy/ (https://www.pjrc.com/teensy/). They have a Teensyduino add-on for the Arduino IDE which makes migration a no brainer. And more libraries to take advantage of modern peripherals.
-
You can use an arduino Pro Mini directly solded on your board. Cheap, tiny and accompanied by oscillator, voltage regulator, capacitors, reset button, power led.
https://www.aliexpress.com/item/32672852945.html (https://www.aliexpress.com/item/32672852945.html)
-
As a (big) step up from ATMEGA328 boards, I went with Teensy boards which are 32-bit ARM based (48 MHz Cortex-M0+ to 600 MHz Cortex-M7). See https://www.pjrc.com/teensy/ (https://www.pjrc.com/teensy/). They have a Teensyduino add-on for the Arduino IDE which makes migration a no brainer. And more libraries to take advantage of modern peripherals.
Only Teensy 3.0 and later are ARM. They started as AVR for the first few generations.
They are nice boards. They have a really slick Out-of-the-Box-Experience these days. Zero to blinky in a couple of minutes.
-
Damn, I hate black PCBs....
Never understood that, they look cheap and dirty.
-
I quite like them, I've used black PCBs in a few projects where the PCB was going to be visible and I think black looks quite nice. In this case though who cares? It's a development board, I struggle to think of a way the PCB color would be relevant at all.
-
It's a development board, I struggle to think of a way the PCB color would be relevant at all.
For some types of "development", it's nice to be able to see the tracks clearly, so you can trace signals and check against the way the circuit is supposed to be.I personally would avoid black, white, and other "opaque" soldermasks on boards where the board itself is being "developed." (but I don't dislike them on "done" boards, unless I'm needing to reverse-engineer something.)
-
Yeah, black is the worst in development boards because actual development often involves doing quick everyday reverse-engineering tasks (just quickly see where the traces go, that's quicker than trying to look if the manuals explain this), or even small modifications to the board.