Go Down

Topic: Feasibility of phase 2 (Read 264 times) previous topic - next topic

adamlwvdc36

Nov 11, 2017, 04:44 am Last Edit: Nov 11, 2017, 05:12 am by adamlwvdc36
Ok.  I currently have a mega connected to a relay module (Through NPN transistors), 2 I2C devices (RTC and LCD), a 4x4 keypad (using the keypad library), and am currently using only 1 AI pin.  

The system does the following:
Once a day, polls a server for internet time
Analog reads the AI pin (connected to a pressure transmitter through a 4-20 to 0-5 signal conditioner)
Uses that pressure to run one of 2 well pumps through a lead/lag configuration  (pump a is lead and pun b only comes on if pump a fails to meet a threshold pressure within a certain time window, then once a pumpOff pressure is reached, pumps turn off, and pump b becomes the lead for next cycle)
Once every 10 seconds, send data to a pho script for insertion into a MySQL database on the server (server is "local-in house")

This runs perfectly. Like, months of running with almost no data loss.  I do have a 555 circuit "watchdog" that the arduino pulses to "pet the dog" and this has only reset the system a few times in the few months.

No serial prints at all now since all debugging is done, literally deleted debugging code.


What I want to add for the next phase of development:

A total if 3 hall effect flow meters to measure flow off if each pump and then out to the house.
Add 2 more pressure transmitters to measure tank bladder pressure and "after filter" pressure for differential  pressure between  pre and post filters to alarm when too high to let us know when to change filters
Add EC probe with Atlas Scientific conductivity circuit (communicates through UART) to measure salinity of softener brine tank.

Question:
Can a single mega handle all if this or would it be better to have one mega do what it is now, minus the client print and then a second mega taking care of the flow and additional pressures and EC probe and have them communicate to an uno through serial or I2C to report their data, and the uno does the client print and LCD/RTC interface.  

Current sketch uses 26% of memory.

Shouldn't need to post code since this a general capability question.  I just need to know how hard I can push this thing.

Thanks in advance.

adamlwvdc36

https://youtu.be/9mPM4ENvvhE

Video of me explaining the system for any one interested.

wildbill

The mega has plenty of capacity (pins and additional serial ports) to do what you wish.

adamlwvdc36

Thanks for the response. 

I am aware that there are pins galore on the Mega.  I guess my question would be more along the lines of CAN the mega do 3 interrupts 3 analog inputs, send/get data from a UART device as well as 2 I2C devices... all while still sending data to the client?   

My big unknown here really is the flowmeters.  I'm not sure how hard on the chip it would be to constantly be looking at the hall effect sensors and trying to do all of the other functions at the same time.  I do validate your statement, this is more of a capability question rather than a question of amount of I/O.

Thanks again!

cattledog

Quote
My big unknown here really is the flowmeters.  I'm not sure how hard on the chip it would be to constantly be looking at the hall effect sensors and trying to do all of the other functions at the same time.
You will be able to count pulses from the hall effect sensors with interrupts which run in the background and should not impact other code.

You will read the pulse counts on a millis() timer.  Here's a basic example using two interrupts. As long as you use non blocking code, the Mega should be able to handle it all pretty seamlessly.

Code: [Select]
//pulse counts changed within count_ISR's
volatile unsigned int count1;
volatile unsigned int count2;

//variables for protected copies of counts
unsigned int copyCount1;
unsigned int copyCount2;

void count1_ISR()
{
  count1++;
}

void count2_ISR()
{
  count2++;
}
void setup() {

  Serial.begin(115200);

  /*
  //send test signal to interrupt pins
  analogWrite(5,127);//980 hz timer 0 jumper pin 5 to pin 2
  analogWrite(9,127);//490 hz timer 2 jumper pin 9 to pin 3
  */
  attachInterrupt(0, count1_ISR, RISING); //pin2 (Atmega328)
  attachInterrupt(1, count2_ISR, RISING); //pin3 (Atmega328)
 
}

void loop() {
  static unsigned long lastSecond;
  if (micros() - lastSecond >= 1000000L)
  {
    lastSecond += 1000000;
    getCount();
    Serial.println(copyCount1);
    Serial.println(copyCount2);
    Serial.println();
  }

}
unsigned int getCount()
{
  noInterrupts();
  copyCount1 = count1;
  count1 = 0;
  copyCount2 = count2;
  count2 = 0;
  interrupts();
}

adamlwvdc36

Thanks cattledog.

One last question then.

I was reading about attachInterrupt today.  There is a mention about millis() not working or incrementing while the interrupt is working... which would be all of the time.   As off the millis timer would be on hold while counting pulses... 

Am I not understanding this correctly?

cattledog

Quote
I was reading about attachInterrupt today.  There is a mention about millis() not working or incrementing while the interrupt is working... which would be all of the time.   As off the millis timer would be on hold while counting pulses... 
Am I not understanding this correctly?
Not exactly.

The value of millis() will not advance within the isr (which is why you can't use delay() in an isr) but will update when the program exits from isr.  That's one reason why the interrupt routine should be very brief. Millis() relys on interrupts, to advance, and if one of these occurs during the pulse count isr, it will be placed in a queue and executed by the processor when the pulse count isr is over.

For a great tutorial on interrupts, see
http://gammon.com.au/interrupts

aarg

Are you using the String class? It is known to cause memory corruption and thus crashes. Maybe that is what is triggering your watchdog.
  ... with a transistor and a large sum of money to spend ...
Please don't PM me with technical questions. Post them in the forum.

adamlwvdc36

No.  But, to be honest this is an older board that i have prototyped several projects on.   I have plugged shields in, taken them out, put new ones in, and so on.  I am actually developing a board where the 2560 will be straight on the board and not a shield. I know I have to program through the SPI, and I'm cool with that. But, there is a lot of stuff on the arduino mega that is just not needed. So, I'm taking it away.

CrossRoads

Designing & building electrical circuits for over 25 years.  Screw Shield for Mega/Due/Uno,  Bobuino with ATMega1284P, & other '328P & '1284P creations & offerings at  my website.

adamlwvdc36

Sort of.  I'm just buying the chip and parts to solder onto my own board. Should be a good time.

Go Up