Trying to doing a greenhouse project which I thought would be simple.
- temperature sensor
- humidity sensor
- soil moisture sensor
- data from SD (bitmap images for display)
- TFT (user interface)
- 4 channel relay (devices in greenhouse)
- WiFi (MIT App Inventor on Android)
The system can be controlled via the TFT onsite or via an App on an Android device.
So I started on an UNO with a TFT/SD shield and started laying out my screens. I got about 10 screens with only 3-4 controls on each screen....and with all the libraries I'll need, I ran out of program memory. Variables memory was fine.
Then I decided to jump up to the MEGA, but found that the built-in SD on the TFT was not compatible. So I tried getting a SD shield to work off SPI (51,52,53) and that apparently has to be done with SoftSPI. Which I could not get to work. The SD.begin(53) keeps failing.
Now I'm concerned that maybe it's just too much for an Arduino. I originally wanted to use an UNO Rev 2, but that wasn't compatible with the TFT shield. I haven't even gotten started on the communication or reading the sensors.
So the question is....what would be the best processor/hardware combo to use on this project. The Arduino is starting to look like it's too small for what I intend.
Thanks in advance.
Some SD card modules will not play well with other devices on the SPI bus. The problem is with the way the level shifter on the SD module is wired. The ones that do not work well have the MISO signal running through the level shifter. That causes the MISO signal to not be released so that the other devices can control it. The modules made by Adafruit (and some others) have the MISO signal going from the SD card straight to the MISO, bypassing the level shifter. Look at the schematic for the Adafruit module to see what to look for. DO (data out) is the MISO signal.
No idea why the SD shield won't work with software SPI. Need to see your code. Read the how get the most out of this forum sticky to see how to properly post code. Remove useless white space and format the code with the IDE autoformat tool (crtl-t or Tools, Auto Format) before posting code in code tags.
As there's WiFi involved, the ESP8266 comes to mind immediately - can be in the form of a NodeMCU or WeMOS D1 Mini board. They have limited I/O pins but play very well with MCP23017 or PCF8574 port extenders.
As you are using a TFT screen you will be happy with the additional processing power of the ESP8266 (80 or 160 MHz clock; 32-bit processor - while an Arduino Uno or Mega is 16 MHz and 8 bit).
The ESP has a lot of Flash memory, and can use up to 3 MB of that as internal Flash drive. That may negate the need of an external SD card.
You may consider the ESP32 as well - WiFi, Bluetooth, and lots more processing power and I/O pins than the ESP8266.
So I tried getting a SD shield to work off SPI (51,52,53) and that apparently has to be done with SoftSPI. Which I could not get to work. The SD.begin(53) keeps failing.
That sounds odd, the Mega hardware SPI pins are 50, 51, and 52 (MISO, MOSI, and SCK), with 53 being SS, although you can use another pin for that. Why are you using softSPI on the hardware pins? If you are going to use softSPI, use 12, 11, and 13 (same as on an UNO), and the card reader on the TFT shield should work.
The big problem is shortage of pins and the conflict between the TFT/SD, pins needed for other I/O signals, and memory limitations.
I think what I might do is dedicate one UNO to manage the TFT/SD and use pin1 , pin0 (Rx/Tx) to communicate
with a second Aduino board. Put them in the same enclosure to make a single controller.
The second board will be a UNO Rev 2 which will handle all the sensors, relays and WiFi communication. It of course talks to the other UNO using pin1, pin0 (Rx/Tx).
Seems like a overkill of two boards, but it allows me to keep both sketches within the memory limits. The TFT and SD libraries and sketch will reside on the UNO, keeping all the main program logic to reside on the Rev 2 board.
TFT and SD cards generally use SPI as well, and SPI is designed to be shared. Adding a software SPI library I expect to use more memory than sticking to the hardware SPI, and it definitely adds a LOT more demand on processing resources.
With the amount of memory and I/O pns a Mega offers, it's hard to believe you're running out of either, or that a puny Uno would solve this (just the communication between the two adds quite some extra code complexity).
This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.