Programming in multiple languages

I'm exploring using the Arduino Nano rp2040 Connect (ANC) as the MCU for my current prototyping stage. Can various device programs / programming be in different languages (say one in C, another in an Arduino sketch, another in MicroPython) and all be utilised on the MCU.

I expect that multiple functions in different languages would be written to call each other or utilise API's, but I'm not a programmer, so technically challenged in this realm. Example - setpoint control function is written in C, takes a DS1820 one wire temperature input using say CircuitPython, with the C program output to operate an on-board relay, and Wifi relies on the Arduino WifiNINA library (uBlox) which communicates via MQTT to a server. The arrangement might also involve I2C on-board comms. It appears that PlatformIO in conjuction with VS Code could address things, but I'm not sure.

You are mixing compiled programs with INTERPRETED programs. Look up the difference.

different languages can be used if compiled in a common format and the .o files linked together. however, many languages are not compiled (e.g. python, java, ...) and cannot be used to other languages

the primary advantage of using different languages is to use libraries compiled in one while the application in another

Mixing Arduino Language/C++ and C is simple to do. In fact, you are actually using C code libraries in your Arduino sketches already.

Maybe I'm just old and dimwitted and the sharper folks welcome the chance to run their noggin through its paces, but I find too much hopping back and forth between Python and C-ish languages is really not pleasant. I do plenty of it, but I don't actively seek out the experience. I'm perfectly happy with Arduino/C++ alone for my embedded systems projects.

An Arduino only runs one program at a time.

You can mix C and C++ in a single program, but using microPython or CircuitPython requires that the "main" program be the python interpreter.
(OTOH, you can implement python functions in C (maybe C++ too?) But that's an "advanced" topic, and it's not really the same as having separate C and Python programs.

You could look at the Portenta H7
It is a dual core machine where the two cores communicate over a remote procedure call mechanism. In this special case, it is possible to mix language types.

And there is some form of MicroPython support for Portenta H7:

I don't know whether there is CircuitPython support yet.

There are always raspberry pi and similar SBCs.
They’ll run multiple programs in multiple languages just fine.

Interesting conversation. But, the folly of the idea was expressed by the OP right in the first post:

So, if you don't know how to program in one language you might as well not know how to program in several languages?

Though I'm not a programmer, I will (based on my own research and the valuable views of others such as those on this forum) get some sense of what is impossible, possible but difficult, or readily accomplished with the requisite knowledge. I'll be contracting others to develop a revised prototype - schematic design, fabricate & assemble PCB's, and subsequently program them. In different sectors, I have frequently had to guide designers through unfamiliar territory - an underpinning of innovation. I've researched and selected key components, directed developers to incorporate into POC's and sucessfully demonstrated the desired functionality.

As the Nano rp2040 / ANC is quite new and unfamiliar to many, I'm getting a lot of pushback from developers who are entrenched in STM32's, ESP32's, etc. I feel the rp2040 has some pretty hefty potential in the IOT space and what's bundled in the ANC a is very robust starting point.

There's numerous stigma's associated with Arduino, particularly that one is locked into a home hobbyist IDE and its percieved limitations. This is clearly not the case, but I'm having to walk folks through the Arduino ecosystem, with by extension quite a broad collection of resources such as Python, MicroPython, CircuitPython, etc. Nevermind the extensively documented universe of rp2040 / Pico C & C++. There's quite a bit of lattitude here, just have to dig around a bit.

To the extent possible and practical, I would like to take advantage of existing libraries and programming, as it should reduce programming time & costs, bugs, and leverage a very active and responsive community. I would welcome any deeper perspectives you might have, and your patience with my limited technical knowledge. Thanks.

I've explored the land of RPI's and though there's plenty of flexibility, it's a lot more capability, power consumption, etc. than I want. My applications are in the low power, low bandwith, very compact IOT world. Thanks.

The Portenta is a lot more than I need, and I intend to incorporate ANC's onto prototype PCB's which have addtional components. I'm keen on working with MCU's based on the RP2040 chip, it looks to have some real potential down the line.

CircuitPython is already functional in the ANC. See:

This was yet another appealing aspect of the ANC. Thanks.

Most Arduino like devices are single core and single thread. There are exceptions, ESP32s and the RP240 for example. Also there are some multi-tasking libraries.

But, there's no O/S on any of these things, so running code in multiple languages is a non-starter. You'll have one executable only.

I'm not sure how to parse that regarding ESP32. But, in fact, it runs the FreeRTOS OS.

not sure the arduino libraries are industrial grade. my only experience with commercial libraries was unpleasant

certainly nothing wrong with using a commercial processor such as the one on an arduino or raspberry pi. i don't believe they were designed for the hobbyist product, they were used for hobbyist product

what type of application are you developing?

The principal purpose of the prototypes will be to do bench and field testing to demonstrate unique functionalities which in many cases, were prevoiusly done in POC / breadboarding. As quickly and inexpensively as possible.

Applications are for residential, commercial equipment and systems. Heating, cooling, setpoint control, etc. Similarities to a communicating thermostat, but not all the bells and whistles.

Moving from prototype to production design, I don't expect any bit of that phase will happen in the Arduino ecosystem. In the long run, strong pull to C & C++, heck that's where Spacex got its legs. OOP will likely be important, encapsulated / modular approach. That's further down the line and I suspect at odds with Arduino's one trick pony.

Because the RP2040 embraces mainstream languages, if properly written and tested - code for that chip should be industrial strength. That would be the goal.

Would love to hear more about your unpleasant experience...

Unfortunately, The library is for the avr architecture and the RP2040 is Arm M0+

Missing your point. ESP32 runs FreeRTOS natively. And, it's neither AVR nor ARM.

In regards to the ESP32 you're correct. But as noted, my focus is on RP2040 based MCU's. Had the ESP32 in a previous proto - its a great workhorse.

what do you mean by "one trick pony"?

quality depends more on process than language.

was working with a C4 network processor (had never heard of a network processor) which had ~80 processors: tx/rx bit/byte and host processors/chan supporting 16 channels. we spent months debugging panics from their code. got it to work reliably then found out they changed the architecture to avoid the problems we fixed. worked with one other EE. one of the best experiences during my career.