Hi there! I am designing a controller for a water pump, and I have some questions. I have the following peripherals:
CONTROLLERS: 2 Arduino nanos
INPUTS:
- Water level sensor (2 analog)
- Flowmeter (1 interrupt, 1 digital)
- Encoder (2 interrupt, 1 digital)
- 2 switches (2 digital)
- RealTime Clock (I2C)
OUTPUTS:
- LED display (I2C)
- Pump Relay (1 digital)
I/O:
- Micro SD card reader (I2C)
- Intercom between 2 nanos
The actual functionality (already working on a single board) is the following:
- I read water level sensor signals, pass it through noise reduction functions and according to it, I enable/disable the pump relay
- The noise reduction parameters are saved on EEPROM, and I use UART serial through USB to smartphone to edit them (just at the beginning)
- I also use UART to log debugging info (can be enabled at the beginning).
- One switch is to overwrite water level algorithm, manually forcing on/off pump with the other one.
The improvements I want to make are the following:
5. Collect water consumption through flowmeter and save it to SD card, logged as csv if possible for fast import to excel energy consumption modellization.
6. Substitute need for smartphone and cable connection by installation of LED screen, which would have the following capabilities:
- Show status and debug info if enabled
- Navigate through config menu to change noise reduction parameters.
- View already collected data, as a daily summary
- Handled by an encoder with click
As the LED library is very heavy on storage and SRAM (even the LED ascii minimal one), and I need to handle 3 interrupts (only 2 available on each board), I must use 2 nanos (cannot expand to mega, no available physical space in enclosed box), then I have the following questions:
a) In order to communicate between nanos (send flowmeter data to SD and LED, send new parameters changed, etc), which is the best protocol? Only need to transfer bits, bytes and integers.
- UART: I think it is simple to program, but I don't know if data will be corrupted, and I would have to implement another switch for sketch burning, or desolder intercom between nanos. Pro: it has buffer, so I don't have to be listening coordinately.
- I2C: Is it easy to implement, sharing bus with 3 other slaves? Would one nano be master over the other (the one having the RTC)? Both nanos will be handling many other peripherals, will the slave one be continously listening or is there any buffer enabled? When master enables data sending, does the slave stop working until it receives and saves data?
- Any other handy protocol with buffer, needing small or no library?
b) Which would be the ideal layout of the peripherals? How would you distribute them between both nanos, in order to:
- Reduce data transfer (therefore latency, data loss, listening wait times, etc)
- Distribute equally source demand, in order not to saturate any of the SRAM and storage availables.
- Taking into account the small space available, each controller with its plugged peripherals have to be allocated in a single 400 pin breadboard.
- Encoder and LED should be together, opposed to flowmeter due to interrupts saturation
- Water level sensor, mode switches and relay enabler should be toghether to simplify control algorithm
Thank you so much for your advice!
Mario
I guess the first question is "Do you really need 2 Nanos?" Life will be much easier if you don't need the complexity of communication. What about using a Mega if you need extra I/O pins?
You have not said how much data you need to transfer - how many bytes per second?
If the data rate is modest you could use SoftwareSerial on both Nanos to create an extra Serial port and leave pins 0 and 1 free for programming and debugging. If you want to use serial comms have a look at the examples in Serial Input Basics. The technique in the 3rd example will be most reliable. You could include a checksum in the data to verify that it is not corrupted during transmission. Serial has the advantage that it works over a longer range than I2C or SPI.
If this was my project and I knew I needed serial comms I would choose Arduinos with a spare HardwareSerial port - such as a Mega or Micro.
I am surprised that your water level sensor has as analog output. I envisage a simple ON/OFF switch operated by a float.
...R
Thank you Robin for your answer
I need stackable boards, as my space is limited, therefore I cannot allocate a Mega board (I wish I could, i could have many more interrupts, serials and SRAM...). Then, the cheapest solution i found was 2 nanos (UNOs are virtually the same, with similar capabilities, so there is no advantage). Forgot ProMicro option...
Then, I only want to refresh screen status once every second or so, and log to SD card every 5 min.
If I interact with the encoder, then data should transfer a bit faster (max 10Hz), but never at runtime speed as your fantastic tutorial Serial Input Basics - updated - Introductory Tutorials - Arduino Forum does: very slow rate, and not continuous (also for energy saving, as what I monitor is not connected to the grid but to finite batteries and solar panels.
Your approach with SoftwareSerial seems a good idea, my only concerns are:
- Is the library too heavy (storage and SRAM) to burn it along SD, RTC and display ones?
- Does SoftwareSerial implement also a buffer? My controller algorithm may take a while (~10ms) to get back to loop, and I don't want data to be lost if transmitted while the receiver is busy... I need something in which:
a) sender waits until receiver listens (if any interrupt is enabled meanwhile, no problem, then it returns to sending state), OR
b) receiver that buffers incoming data until read (as in hardware serial)
Your surprise is reasonable, they are floating switches, but as the wire may be too long, the digital could read ON as LOW if it gets under threshold, thus one of the parameters in EEPROM is a configurable analog threshold...
mmusicoc:
Your approach with SoftwareSerial seems a good idea, my only concerns are:
- Is the library too heavy (storage and SRAM) to burn it along SD, RTC and display ones?
- Does SoftwareSerial implement also a buffer? My controller algorithm may take a while (~10ms) to get back to loop, and I don't want data to be lost if transmitted while the receiver is busy... I need something in which:
a) sender waits until receiver listens (if any interrupt is enabled meanwhile, no problem, then it returns to sending state), OR
b) receiver that buffers incoming data until read (as in hardware serial)
Strictly speaking my code is not a library - the idea is that you just incorporate the functions into your own program. I don't think it will be a noticeable burden.
AFAIK SoftwareSerial has a buffer. You might also like to look at NeoSoftSerial
...R
AFAIK SoftwareSerial has a buffer. You might also like to look at NeoSoftSerial
Then, I will use NeoSoftSerial!. It seems pretty handy and lightweight, and I'll look in detail your code in case I find something to reuse. I will include you in the referrals of the Project, of course
Thank you for your advice!