Which Way Forwards ? - Micro

Hi,

Have a working project that runs fine on an Arduino Nano , but the code takes up 98% of its memory so little space for any code improvement.

Its a basic controller for various sensors outputing to a touch tft screen and relays etc. so not doing any high speed complex computing.

One of the future thoughts is towards something with a more program memory plus Ethernet and/or Wifi and Bluetooth abilities but unsure of the best route ??

The Mega was the obvious choice for more memory and I/Os plus the Ethernet shield or ESP8266 etc.

Now the new Arduino Nano33 IOT would seem a good choice and it uses an ESP32 for output, but expensive-ish and no clones around yet.

Using an ESP32 module on its own with the Arduino IDE does seem ok, but are there any major downsides to porting my simplish code over to it, and are they as reliable as the Arduino as seem to remember reading about problems with it crashing for no good reason ?

Did think about recoding the program onto the Raspi which seems to be ideal for wifi etc and have recently been trying it with the young ones b 3+, and as they showed me ! doing SSH and VNC was so simple, but venture outside those pre programmed modules etc and you are faced with ( and expected to know all about ?!) such a mass of Linux code that boggles the mind !

Thanks

There is a lot to what you are asking and I will not even attempt to provide a comprehensive answer. I do think that a lot of folks get to that upgrade point. Here are some thoughts that I have concerning some of the aspects of the issues that you bring up.

The Nano (original) is really one heck of a nice board. Basically an UNO in a smaller footprint. Clearly it has limitations but I have always felt that they can do a great deal.

For upgrading, when you need more speed and memory, I would suggest a Teensy LC.
Compare the specs with Nano and the Teensy LC comes up on top in almost every category - and it is relatively low-priced. still some specs could be important to you - the Nano IO pins source/sink 40 mA - on the LC you don't see that but some pins will do 20 mA. Depends whether you need that particular characteristic.

Code-wise, I think you have an excellent chance of transporting the code with a minimum of issues.

Considering the WiFi / BT issues....

I have experience with the MKR WiFi 1010 and the NANO 33 IOT (there are a bunch of 'new' nanos). The 33 IOT (the low priced one) is basically a stripped down 1010. Ceramic resonator and no crystal, that kind of thing. They are both pretty powerful. Both have the u-blox NINA-W102 ESP32 chip. Both are 3.3V devices.

Compare them to the ESP32 boards and there are a lot of them and they are cheaper - example. Also 3.3V

Wp100 said:

are they as reliable as the Arduino

Click to expand...

As reliable as the Arduino what??

I think that enough time has passed where they are reliable but there are peculiarities and finicky aspects - most of which has been known enough to be written about.

As long as you can transport to 3.3 from 5v easily enough, both should be considered. So, comparing in a general sense the two categories (Arduino ublox) vs generic ESP32 boards, you are going to need to consider the software to use WiFi and BL. Each uses different libraries and, unless you want to write your own, that is what you will need to deal with.

I should add that both classes of boards use the Arduino IDE, but you could use the Espressif SDK.

For Wifi, I think both libraries will get you where you want to go in a fairly straightforward manner - as long as you want to do what I would call "regular" stuff (which is all I have done with either).

If you have never programmed BT on anything, it is not simple at first - I'm not talking about SPP stuff [or AT commands} but "real" BT peripheral and central role devices.
Having used both the NANO and ESP32 for BT, within my experience, I would say that the BLE library for the NANO is actually easier to use. The ESP32 BT is probably more powerful. That is more of an intuition on my part, than factual comparison.

Here is an example. I used a DOIT ESP32 Devkit board to read BLE beacons. I had to wade through the library source code (Most of it is, as I recall, Neal Kolbans work - at least the foundations). I also did some similar things with a **broken link removed** and also had to wade through the source code to figure things out.

The ESP BLE has active github environment and you start following the issues and fixes and so on and so forth.

The MKR WiFi 1010 (or NANO) BLE libraries do not support beacons at this point (at least as far as I can tell). They also have a github development environment and it is quite good (I have corresponded with the 'head' author who is a very sharp guy). They are after a much sleeker design and they have had a few versions and I think it is a good library. No beacon capability as far as I can tell.

So, if I wanted to program a BLE peripheral device that would monitor some straightforward machine characteristics and I wanted to access an app on my phone to get the status of the machine, all three would do the job.

Same as an analogous situation with WiFi monitoring.

One plus with the ESP32 variants is that there has now been a great deal written about them and so lots of examples. A smaller disadvantage is that there are so many different boards - so a few [peculiarities]

That's my casual 2 cents - hope it helps.

Hi DrG,

Many thanks for the taking the time to send such a detailed answer.

My project is nothing special code wise , though I have converted to Nano to run on 3v3 to be voltage compatible with the tft screen to save using voltage converters etc. and the various sensors are fine on either voltage.

As you say it does seem to be a choice between the Nano33 or the ESP32, so will have read up more on both !

Re the point about Reliable, have Nano clones running 24/7 for several years without a glitch, as did my old Pic chips for over ten years, so assume these newer chips are just as good ..

Wp100 said:

Re the point about Reliable, have Nano clones running 24/7 for several years without a glitch, as did my old Pic chips for over ten years, so assume these newer chips are just as good ..

Click to expand...

Nice!

I have absolutely no information about "endurance" for those other boards - no idea why they might be different, I just have no idea at all in that regard.

DrG said:

Nice!

I have absolutely no information about "endurance" for those other boards - no idea why they might be different, I just have no idea at all in that regard.

Click to expand...

Well if I survive another ten years will let you know ...

One possible plus for the ESP32 board (38 pin version) is that it has ten more GPIOs than the Nano / Nano33 boards.

Possibly you could advise here, as unable to find anything on the web , so far, to confirm that with the Arduino IDE / C++ you can use all 32 GPIOs* of the ESP32 ?
* 28 GPIO + 4 GPI

Thanks

Wp100 said:

Possibly you could advise here, as unable to find anything on the web , so far, to confirm that with the Arduino IDE / C++ you can use all 32 GPIOs* of the ESP32 ?
* 28 GPIO + 4 GPI

Click to expand...

I don't believe you can, see here for example - and how many are available depends on the board. There is a lot about this online and others here may know more details.

This is a good getting started tutorial. I have that board and I like it. I did need to add a capacitor to get a more stable reset when programming (read that recommendation somewhere and took it and it worked - maybe it has been fixed).

Going to have to do a lot of reading , though think I have already bookmarked those links as they looked quiet good.

Also found this Ytube series which is the same code and tft as my existing Arduino and seems it runs fine on his ESP32, just got to add the touch control.



So thanks once again for your help in getting over that initial newbie hurdle.

On the question of the ESP reliability, I built an internet connected clock using a Wemos mini board and a 32x8 LED display. It fetches the time (NTP) every 6 hours and has been running reliably for ~2 years. It's weird how quickly you don't trust normal clocks.

Mike.

Code it in assembly. Problem solved.