Should I keep using Unos or switch to Megas/Dues?

I have a mobile LoRA datalogger project with TFT-LCD display for a GUI when out in the field. Right now I am using Unos because they're cheap and adequate for the slow pace of a datalogger project.

However, I have a few concerns about using Unos despite how cheap, easy and useful they are:

  1. LCD touchscreen GUI and basic sensor/logger libraries are taking up alot of memory ~60%.
  2. Low SRAM means I can't pull up many historical variable values on the LCD.
  3. Have to use SoftwareSerial instead of having a hardware serial for LoRA module.

I am not sure if these are serious problems though, am I overworrying?

  1. I can simplify the GUI and it seems like as long as there's room for the bootloader, I can fill the memory as much as possible.
  2. I exercise discipline by using F() for strings but there's only 1 kB of SRAM, nothing more I can do. But reading lots of historical data is a luxury.
  3. How much does SoftwareSerial matter when it isn't a continuous datastream but rather just a single burst transmission every few seconds?

Is it advisable to change from Unos to Megas or Dues, or does it seem like with sufficient discipline I can keep the scope of the project within the capabilities of the Uno? Would like some advice before spending money.

These devices work with direct connections on the DUE, with no need for level conversion circuits, since the DUE is 3.3V logic;

LoRa devices
TFT displays with touch
SD cards

I have a shield PCB I use for the same purpose;

It largely depends on your actual needs. So far it seems the Uno (better said: the ATmega328p processor) can cope just fine, except for the historical data part.

SoftwareSerial's main shortcomings are bidirectional communication (send and receive at the same time), and high speed communication (it's effectively limited at about 56800 bps). AltSoftSerial can improve a bit on the latter. That said, not so long ago I made myself a Nano with two hardware Serial ports... after replacing the ATmega328P chip with it's direct successor, the ATmega328PB :slight_smile:

The first upgrade I'd suggest you is from an Uno to a Nano. Cheaper than the Uno, but more importantly a much more convenient form factor - you can actually solder things firmly to it, or stick it in a set of headers on a PCB. This is especially important for things you take out in the field, no worries about those fragile connectors falling out or breaking.

The 3.3V levels of the Due are of course a great advantage (which the Mega doesn't offer).

Nano every is well worth a look

xyz_summer:
am I overworrying?

It Seems that you might be. I quite quickly came to the conclusion that Unos aren't up to datalogging and a Mega was the obvious choice. This was more due to running out of memory than running out of pins. You seem to be doing a fine job of proving me wrong - at the moment....

I understand you want local archive, so couldn't that be solved with on-board SD card? You already know about space-hogging libraries but you still have 40% of memory left and it costs nothing to add the required software and test things.

If software serial is OK, there is no need to change it but, if you have on-board SD, you may want the extra speed hardware serial offers if you want to download from it.

I can't see how a Nano fixes any problem you might have, it just moves them. In the unlikely event you need to go in that direction, you should look at the Every, as suggested above - and come forth with the elusive spondooley accordingly.

Nick_Pyner:
It Seems that you might be. I quite quickly came to the conclusion that Unos aren't up to datalogging and a Mega was the obvious choice. This was more due to running out of memory than running out of pins. You seem to be doing a fine job of proving me wrong - at the moment....

When datalogging I'd write the data to permanent storage (such as an SD card) immediately, instead of keeping it in RAM.

wvmarle:
When datalogging I'd write the data to permanent storage (such as an SD card) immediately, instead of keeping it in RAM.

And in circumstances when you are short of memory to run a directly attached SD card, just format the output to Serial Monitor in the format you want to log data and attach an Openlog to the pin the Serial monitor uses for TX. The Openlogs cost around £5.

If you are not using the USB serial interface then you should be able to use the hardware serial port instead of SoftwareSerial, as long as you have a way to disconnect the LoRA module from Rx/Tx while uploading code.

Are you logging locally to an SD card, or remotely over the LoRA?

Nick_Pyner:
It Seems that you might be. I quite quickly came to the conclusion that Unos aren't up to datalogging and a Mega was the obvious choice. This was more due to running out of memory than running out of pins. You seem to be doing a fine job of proving me wrong - at the moment....

I understand you want local archive, so couldn't that be solved with on-board SD card? You already know about space-hogging libraries but you still have 40% of memory left and it costs nothing to add the required software and test things.

If software serial is OK, there is no need to change it but, if you have on-board SD, you may want the extra speed hardware serial offers if you want to download from it.

I can't see how a Nano fixes any problem you might have, it just moves them. In the unlikely event you need to go in that direction, you should look at the Every, as suggested above - and come forth with the elusive spondooley accordingly.

Running out of memory is definitely a problem too. I've had to exercise discipline by F() all strings but at the end of the day it is quite marginal.
For historical values purposes, what I'd like is to plot historical values onto the touchscreen at minimum - this I have done and the Uno is fine for this. But eventually I'd also like to be able to interact with the data i.e. zoom in or zoom out. I haven't gotten anywhere with that. For using the SD card, I am not sure how to go about reading values off the SD card and plotting them on the screen.

david_2018:
If you are not using the USB serial interface then you should be able to use the hardware serial port instead of SoftwareSerial, as long as you have a way to disconnect the LoRA module from Rx/Tx while uploading code.

Are you logging locally to an SD card, or remotely over the LoRA?

How would I go about doing that without having to take apart the module each time? Is it necessary to physically disconnect the module via an enable pin/physically wiring VCC/GND to a switch? Or will it be OK to have a touchscreen button that has Serial.begin(); when pressed and is Serial.end(); when pressed again?
My ambition is to have local logging backup to LoRA. I have had trouble working with SPI SD drives in the past due to using RA8875 screen not working when SD is enabled; I think there's a bug with the RA8875 MISO pin. I heard that with correct CS pin definitions you can get around it but I haven't gotten around to testing it yet (https://forum.arduino.cc/index.php?topic=253169.0).

Thanks for the advice guys.

xyz_summer:
My ambition is to have local logging backup to LoRA.

Works for me on a DUE.
Not sure I undestand why it would be a problem.

srnet:
Works for me on a DUE.
Not sure I undestand why it would be a problem.

So it is worth it to buy a Due? I just want to understand that I can get substantially better capability before spending money, and I like to try and get as much out of the hardware I have as possible.

david_2018:
If you are not using the USB serial interface then you should be able to use the hardware serial port instead of SoftwareSerial, as long as you have a way to disconnect the LoRA module from Rx/Tx while uploading code.

On a Nano or Uno that is a problem as the USB interface chip is physically installed on the board.
On the other hand when using a Pro Mini this is easy to do: add a 1k resistor to the Tx and Rx connections towards the LoRa (or other Serial device). Now when uploading through the FTDI interface these resistors allow the FTDI signals to easily override the LoRa signals.

wvmarle:
when using a Pro Mini this is easy to do: add a 1k resistor to the Tx and Rx connections towards the LoRa (or other Serial device). Now when uploading through the FTDI interface these resistors allow the FTDI signals to easily override the LoRa signals.

Hah! Now that is something I didn't know.........

xyz_summer:
For using the SD card, I am not sure how to go about reading values off the SD card and plotting them on the screen.

I have never done it, I just download the entire file for analysis elsewhere, but it can't possibly be difficult, although it may give you another memory problem.

How would I go about doing that without having to take apart the module each time? Is it necessary to physically disconnect the module via an enable pin/physically wiring VCC/GND to a switch? Or will it be OK to have a touchscreen button that has Serial.begin(); when pressed and is Serial.end(); when pressed again?

You just have to disconnect the power to the serial device while uploading. I don't know how difficult this might be, but the prize in the end is superior serial comms AND the deletion of the software serial library. Generally speaking,

  1. the only reason for having software serial on a Uno is that you have two serial devices in operation, which I now understand this is not the case here. I think I misread your point 3, and I assumed the LCD was on serial, but I now see that it is SPI.

  2. using software serial when hardware serial is only used for uploading and debugging is just a refuge for the lazy and incompetent. That said, you may have good reason for doing so, but I can't see it.

I have had trouble working with SPI SD drives in the past due to using RA8875 screen not working when SD is enabled; I think there's a bug with the RA8875 MISO pin. I heard that with correct CS pin definitions you can get around it but I haven't gotten around to testing it yet

I suggest you do so promptly. There is probably no MISO problem at all.

If pin count is not an issue, what about SAMD21 based boards?

Nick_Pyner:
2. using software serial when hardware serial is only used for uploading and debugging is just a refuge for the lazy and incompetent.

Good luck with that on the Uno or Nano, with the TTL/USB chip hardwired to the hardware Serial interface... The second device's Tx will be fighting the TTL chip's Tx, basically causing a short every time it tries to send a logic zero!
It also means the loss of your primary debugging interface.

xyz_summer:
So it is worth it to buy a Due? I just want to understand that I can get substantially better capability before spending money, and I like to try and get as much out of the hardware I have as possible.

There are issues with some SPI devices, caused by the 5V - 3V3 logic conversion circuitry on them, that creates problems when using some SPI devices.
Not aware of an SPI interoperability issue on the DUE, its 3.3V logic, so no logic level conversion circuitry needed that can mess things up.
You specifically mentioned a LoRa device, TFT display and Datalogger (SD card presumably). All those will connect directly on the DUE; compare with the wiring required to get all those 3.3V logic devices correctly connected to a 5V logic level Arduino. A 5V logic level Arduino is just off the choice list as far as I am concerned,way too many problems with modern devices.

srnet:
There are issues with some SPI devices, caused by the 5V - 3V3 logic conversion circuitry on them, that creates problems when using some SPI devices.
Not aware of an SPI interoperability issue on the DUE, its 3.3V logic, so no logic level conversion circuitry needed that can mess things up.

I expect the exact same issues - for SPI devices that have the logic conversion circuitry on them, for the simple reason that the circuits are in placec. Certain versions of a common SD card reader come to mind, I remember it was not releasing the MISO line. Newer versions don't seem to have that issue.
There may however appear other issues: even if you have the version of that SD card reader that does not cause issues with the SPI, the SD card reader doesn't even work properly when supplied with 3.3V power, as now the built-in regulator gets in the way.

Fortunatly there are break out boards for SD cards that have no regulators or logic conversion stuff on them, ideal for 3.3V logic Arduinos.

wvmarle:
Good luck with that on the Uno or Nano, with the TTL/USB chip hardwired to the hardware Serial interface... The second device's Tx will be fighting the TTL chip's Tx, basically causing a short every time it tries to send a logic zero!

Which is why the design includes a 1k resistor in between. The device you connect only has to pull down 5 mA though if it is a 3.3 V device, it must also pull down 2 mA while its output it HIGH but a Schottky diode or two 1N914s can take care of that. :sunglasses: