What µC patform f. new Metrology project

[r6502]

Hello All,

I need an actual micro controller for a new meteorology project. It's a a few years ago, that I developed applications on Atmel micro controllers but there are new chips present with interesting features, but it's hard for me to decide what to use. My question is now, what platform should I use?

In our company, we are currently using PIC32, STM32  and now also the RP2040 platform.

I have the following requirements:
- tool chain for development must run on my mac, no windows PC is present
- display for the project will be a multi line LCD character display e. g. 4x40
- data  rate for output of analogue data will be max. 100 samples/sec  for 4 channels with 24 bits each at the same time
- data input rate will be the same
-> total data rate will be in the range of 2400 bytes / sec
- max. local storage, needed on the device lets say ten times the acquired data, so about 24k
- ability to connect to local network, Ethernet preferred, GPIB also possible, to be able to grab the data with a PC
- settings will be done with a rotary encoder and some btn's, or remote

I think, all device platforms  will be able to handle my requirements - what would you prefer to use?

Guido

[brucehoult]

If WIFI is ok instead of Ethernet then the ESP32 series is pretty nice and east to use, especially the more recent RISC-V based ones.  Also the WCH range, with variously have ethernet and/or USB.

USB serial (shows up as COM4 or whatever on your PC) is also very viable for much higher data rates than you're talking about here. You can also use RNDIS to get TCP/IP communications with the µC via USB e.g. ssh, run a web server on the µC, raw sockets .. whatever you want ...

Do you want chips or boards?

[r6502]

Hi brucehoult,

Thanks for answering.

ESP32 is no choice for me, as it seems that it supports only WiFi, that I do not want for several reasons. I'd like to have a physical connection to a network. With the ESP32 I would have to use  something like W5500 or ENC28J60 or similar Like when I will use the RP2040. ESP32 are nice chips but not for my application ...

Guido



.

[dobsonr741]

Two software platform recommendations:
1. RP2040 pi pico labtool, provides USB TMC class access: https://github.com/jancumps/pico_scpi_usbtmc_labtool

2. Circle on Raspberry Pi baremetal. Simple to implement raw SCPI socket connections over network of your choosing, WiFi or Ethernet. Older Pis are good too:
https://github.com/rsta2/circle

The build tools are platform agnostic, I run them on Mac using docker to avoid installing to much stuff.

[rteodor]

Hi brucehoult,

Thanks for answering.

ESP32 is no choice for me, as it seems that it supports only WiFi, that I do not want for several reasons. I'd like to have a physical connection to a network. With the ESP32 I would have to use  something like W5500 or ENC28J60 or similar Like when I will use the RP2040. ESP32 are nice chips but not for my application ...

Guido

There are ESP32's with integrated RMII. For example there are these Olimex boards EVB32-EVB, ESP32-GATEWAY and ESP32-POE.
W5500-EVB-PICO has the Ethernet onboard for not much extra cost.

[tellurium]

In our company, we are currently using PIC32, STM32  and now also the RP2040 platform.

It makes sense to use something your team is already familiar with.
PIC32 & STM32 are too broad to tell exactly, but mentioned RP2040 is IMO adequate for the job.
Also it is (and it was) remarkably available during the chip shortage, and it is quite inexpensive, so looks like a sound choice.

If you plan to bake your own PCB, then RP2040 + W5500 seems reasonable,
otherwise consider W5500-EVB-PICO (already mentioned before)

[selcuk]

ESP32-D0WD-V3 chip has a RMII interface. You can use it with RMII chips. There are drivers for RTL8201, IP101, LAN87XX, DP83848 and KSZ80XX in ESP-IDF SDK. You can easily use ethernet and wifi together with the included TCP-IP stack. I recommend to use RTL8201 since it has an industrial grade version (if required) and a spread spectrum clock.

There is no flash memory inside the MCU. So you can use a 4 - 16MB SPI flash and store both the application and the data on it.

There is a rotary encoder example project in the SDK.

[nctnico]

I second the suggestion to use the W5500 (or the newer version which supports IPv6) for networking. It saves a lot of trouble trying to deal with an internal network stack.

Then again, if GPIB is an option, then why not use USB-CDC to mimic a serial port on a computer? Nowadays this works out of the box on all devices (including mobile phone). That way you'll be talking through a UART at both sides. Using ethernet also comes with needing to obtain a MAC address (Microchip has eeproms with an integrated, unique MAC address though) and setting IP parameters to set a fixed address or support DHCP.

[hans]

It depends on what kind of network stack.

IPv4+UDP? Relatively easy
IPv6+TCP? Ugh

FWIW the requirement of the project are very modest.. no big graphic LCDs or fast ADCs sampling in the dozens of ksamples/sec. If you like to stick to what you know, then any PIC32 or STM32 with the required peripheral set could do. E.g. I found programming with a PIC32MX775 to be quite enjoyable as everything was still simple&managable by a single developer. Even the ethernet peripheral driver took only a few hours to code up.
The trouble was for me IDE.. if you guys plan to stick with Mac's, then AFAIK there is still no Apple silicon IDE/compiler build available. I'm unsure how well it works under Rosetta.

In contrast, modern STM32 parts have reference manual of 3000+ pages and that still is not exhaustive documentation. Or many other parts these days. Practically, you could pick any chip and combine it with a W5500. In that regard, pick something that you know and gets the job done.

The ESP32 is a neat part, but mostly for WiFi and arguably its cost. Similar to RP2040, but it lacks WiFi.
Both chips require external memory, so practically no code protection. The ESP32 supports some built-in crypto stuff, but AFAIK it's succesfully attacked, and the RP2040 doesn't include any protection features (education product) hence probably why it was still available during supply shortages. I'm not sure if these features are any interest to you in the metrology sector.

[dobsonr741]

Similar to RP2040, but it lacks WiFi.

Depends if you consider the bare RP2040 or the Pi Pico W as the choice. https://projects.raspberrypi.org/en/projects/get-started-pico-w/2

OP might want to clarify if this a hobby project making one, or a commercial scale one.

Mac Silicon works great with Visual Studio Code and the aarch64 version of the ARM gnu toolchain. And faaaast

[nimish]

It depends on what kind of network stack.

IPv4+UDP? Relatively easy
IPv6+TCP? Ugh

Everyone uses lwip or an rtos. That said udp and ipv6 are pretty easy but don't reinvent the wheel.

[artag]

Another way to get wired ethernet is to use a micro with host-mode USB (eg RP2040) and plug a USB-ethernet module into it. That also gives you a hardware option for wireless, if you want it.

I don't know if lwip has drivers for common USB-ethernet interfaces. I would think not, but it seems like a worthwhile addition.
 

[fchk]

- tool chain for development must run on my mac, no windows PC is present

Intel Mac or Apple Silicon? MPLABX does not support Apple Silicon yet, so PIC32 is out then.

ESP32: Wired Ethernet is only available on the first Generation ESP32S, not on S2 or S3. I wouldn't start new projects with ESP32S(1).

I'd choose some more recent STM32 variant like STM32G4 or STM32L5. Stay away from the old F1 series.

[Doctorandus_P]

Your requirements are quite modest. Almost any uC can do the job.

And that makes it mostly a personal preference, or dependent on other factors.
Are you interested in learning something new, or do you want to get the job done quickly and stay with an uC you're comfortable with?
Do you want a bunch of IC's (Ethernet, ADC, frontend, RAM, Power supply) or do you want to integrate it as much as possible in a single IC?

Maybe you have (vague) plans for another project that does require more complexity from the uC side. You could use this project to get familar with the uC & architecture of that "more demanding" project.

[dobsonr741]

Even if OP is for a commercial product, I would not rule out the RPi CM4 in metrology projects. A nice example how it delivers: https://www.eevblog.com/forum/projects/eez-h25005-a-possible-successor-of-eez-h24005-programmable-power-supply/msg5190906/#msg5190906

[linux-works]

esp8266 or esp32

wifi IS the way to go.   firmware over-the-air updates, easy network access.

I'm a believer in REST interfaces. 

I developed an iot api system for the esp that I've been using for several years.  its a work-horse.  but  you have to get over yourself and be ok with wifi.

it has so many benefits (being a networked system).  just getting a good NTP is one reason enough, really.  all my values are correctly timestamped by my stratum1 gps ntp server.  that wifi network is my test network and it gets its own ntp server, dhcp server, ntp server, etc.

I do suggest you consider it.  networked is the best way to distrubute and abstract servics.

[linux-works]

oh, and if you hate wifi, at least use bluetooth to connect things instead of cabling everything together.

if you have a uart, you can send to an hc05 BT module and bind that to another one on your pc.  there you have a nailed connection that is secure, stable and wireless (with no wifi concerns)

[dobsonr741]

IMO SCPI is the way to go, over serial, USB TMC, WiFi or wired Ethernet. Lot of open source available and well demonstrated in projects how to use. Can also be used from Pro tools, like lab view.

[SiliconWizard]

Yeah, really depends on what the goal is. If this is a specific development for a tool that is not really supposed to be distributed or reused, you can go for a simple ad-hoc protocol and leave it at that, otherwise going for standard SCPI is a good idea indeed. Just saying that you don't need to overengineer it if it's not needed.

[tellurium]

Interesting.
I've never heard of SCPI before.
Does it overlap somehow with modbus, or am I talking nonsense here?

[dobsonr741]

No overlap with Modbus. SCPI is the standard for programmable instruments, like benchtop multimeters, power supplies and oscilloscopes. Uses a text based protocol easy to understand. There’s a chance you alraedy have a programmable instrument with SCPI already.

[Doctorandus_P]

I've never heard of SCPI before.

Look up. Is there a rock above your head?   

https://en.wikipedia.org/wiki/Standard_Commands_for_Programmable_Instruments