Running Arduino Micro 24/7

Hi,
Could you please tell me if its recommended/safe to run an Arduino micro 24/7 in a home environment?
So far I have 1 setup but would like to use 5 of them to control roller blinds in my house, my setup works as follows:

  • Arduino Micro (input power 12v from switching adapter vin/gnd)
  • Qik 2s9v1 to control 2 motors when activated(1 motor is on each blind), it also uses the same 12v power from the power supply
  • 2 reflectance sensors (only active when the motor moves to auto stop the blind)
  • 1 Infrared receiver

When not in use, the void loop performs some logic checks and is listening for an infrared signal (using IRremote libary)
Also, would it be better to use less voltage for the input or is this not important?
Thanks in advance for your help!
Paul

I have a number running 24/7. They work perfectly, month after month.

Also, would it be better to use less voltage for the input or is this not important?

You may find the voltage regulator getting hot with 12V input. You may want to scale that back to closer to the minimum recommended amount (7V).

phthomps:
Could you please tell me if its recommended/safe to run an Arduino micro 24/7 in a home environment?
So far I have 1 setup but would like to use 5 of them to control roller blinds in my house, my setup works as follows:

Yes, it's OK to run them 24/7. Avoid using dynamic memory allocation in general and the String class in particular, otherwise memory fragmentation may cause available RAM to be exhausted after a while. Also you'll probably want to use the watchdog timer to reset the mcu if the system locks up for any reason

phthomps:
Also, would it be better to use less voltage for the input or is this not important?

That depends on what you have connected to the +5V and +3.3V pins. If you have nothing connected to them, or just low-current devices, then 12V input is fine. If you draw more than about 50mA from them, then the regulator will get hot and a lower input voltage would be preferable.

Hi,
Thanks to all of you for your help! the comments are really useful and should help save me some headaches :slight_smile:

Regarding the input power of 12v, the only reason I'm using 12v is so that I can use the same supply for both the motor power and the Arduino). The motor can operate with less than 12v but it will go a bit slower (not really a problem).
Do you know if theres an easy way to take 2 different voltages from 1 power supply? or would using a different supply with 9v be any better instead?

Regarding the connections, there are 2 devices consuming power from the 5v output of the Arduino whilst the system is in wait mode:

  1. The Qik 2s9v1 motor controller requires logic power, it uses max of ~15ma when operating and can accept a voltage of 2.7 - 5.5v.
  2. The IR receiver (TSOP38238), I can't fully understand the data sheet for this but it looks like it uses ~3ma and can accept a voltage of 2.5 V to 5.5 V.

There are also 2 reflectance sensors (QTR-1A) connected to the 5v but they are not called by the program until the motor is moving. Each one uses 20-25 mA so I hope that this is not also consumed in standby mode.

I am also really interested to read the comment about monitoring the watchdog timer to reset the mcu if the system locks up, could you please give an example of how to do this in code?

Thanks again!
Paul

Do you know if theres an easy way to take 2 different voltages from 1 power supply?

Add a voltage regulator to reduce the supply to the arduino - you can stick a heat sink on it too.

Thanks,
Please excuse my questions but i'm new to the Arduino world and this is my first project.

For the Watchdog timer I found some example code and added it in my loop as below - so far it seems to be working so thanks for the idea!

#include <avr/wdt.h>
wdt_enable(WDTO_8S); // have the wdt reset the chip if 8s passes without a reset (in the setup)
wdt_reset(); // reset the wdt (in the void loop)

Can you also please give me some tips on how to check if i'm using dynamic memory allocation. There are no string variables but apart from that my C knowledge is very rusty.
Most of the variables I use are defined at the top of the script as ints, there are also a few arrays without explicitly choosing a size, e.g.

int sensor_pin[]={0,1};
int sensor_output[] = {0,0};

and functions look like this:

int read_sens(int pin_no)
{

The last question I had was regarding the 'void loop()', in old school programming language we used to always make sure that there was a delay() in the script to avoid saturating the CPU, is this important with the Arduino?

Thanks in advance for your help,
Paul

If you don't use malloc, new, or the String class, you probably are not using dynamic memory (unless one of the libraries you include, does).

There is no need for delay. The processor is running full-speed anyway, inside delay it is just running full-speed checking if time has elapsed.

Regarding delay, you are probably thinking of a multi-programming operating system, like Apple or Windows. In those cases, doing a delay let other programs run. That doesn't apply here.

Great! That has answered a lot of questions for me and put my mind at rest so thanks!

On another note, today I had some other serious issues with my Arduino micro board so I was hoping that you might have some idea.
After putting in the Watchdog timer reset, it pretty much appeared to kill the board.
I could no longer upload any program (not even the BareMinimum), the upload just got stuck for about a minute before timing out.
Both reset and powering off/on didn't fix it, rebooting PC etc..
I did a bit more digging and eventually found 1 fix which got it going again:

  • Hold the reset button. Start uploading. Release the reset button.
    Noting else worked!
    I tried to reproduce the WDT issue again and the same thing happened, exactly as before
    When testing this script on my Arduino Uno it worked without problem.
    Do you know if this is some nasty bug on the Arduino micro only since it works on the UNO? or could my script be wrong?
    I have put the script below, any ideas would be very helpful.
    Thanks again,
    Paul

#include <avr/wdt.h>
void setup() {
wdt_enable(WDTO_8S); // have the wdt reset the chip if 8s passes without a reset
}
void loop() {
wdt_reset(); // reset the wdt
}

It's a well-known problem with some versions of the bootloader on the Arduino Mega.

Installing a corrected bootloader will fix it.

Your technique (of holding down reset) stops the sketch from loading after a power-off, so the problem WDT is not activated.

Well he stated using an arduino micro board, which like the leonardo board uses a 32U4 chip, so I don't think his problem is based on the old 'doesn't handle WDT interrupts correctly' problem. I would think all the 32U4 based arduino products handle WDT correctly? And I would not think there are upgraded bootloaders avalible for this chip series anyway?

This sounds more like a problem the very first UNO boards had that if loaded with a sketch that started sending serial data immediatly effected the 8U2 USB serial chip from responding to the bootloader correctly, or something like that? It was fixed with a firmware upgrade to the 8U2, but I recall a work around was holding in the reset button, plug the board in and only release the reset when the upload started?

Lefty

retrolefty:
I would think all the 32U4 based arduino products handle WDT correctly?

Well the empirical evidence appears to be against that hope.

If anyone wants to try and knows how to reburn the bootloader in case the test results come out positive (or is that negative, I always seem to get that wrong :wink: ), below is a sketch that will 'brick' any bootloader that doesn't disable the WDT upon entry to the bootloader. Bricked both my mega1280 boards until I upgraded them to a optiboot.

// Test sketch to see if WDT interrupts are handled properly by the bootloader

/*
 Warning Warning Warning this is a semi-destructive test in that
 if your bootloader does not reset WDT interrupts upon starting 
 it will be forced into a tight loop of bootloader starts/WDT resets
 chip/bootloader starts again/lather rinse repeat. One can only
 recover to normal operation by reburning the bootloader with
 a ICSP programmer. If this sketch runs properly on a chip with a WDT aware bootloader,
 you will see continous serial output on the serial monitor.

Note that current arduino mega boards will fail this test and brick

*/

// Code from arduino forum poster (sorry name not remembered) 1/11/13

#include <avr/wdt.h>

void setup(){
  Serial.begin(57600);
  delay(100);
  Serial.println("Hello world");
  wdt_enable(WDTO_15MS);
}

void loop(){
  Serial.println("I am going to not get stuck..");
  for(int x=0; x<100; x++) {
    wdt_reset();
    x++;
    delay(10);
  }
  wdt_reset();
  Serial.println("I am going to get stuck now..");
  for(int x=0; 1; x++) {
    delay(10);
  }
}

Well I just happened to have an Arduino Micro to hand (recently received) so I tried your torture test.

It worked (the WDT did its stuff) and afterwards I could upload a new sketch.

Although ... this is strange. After powering it off and on again, even with the ASCII table sketch loaded (and nothing to do with watchdogs) the sketch didn't run. I could upload it again, and it would run, but it wouldn't run the existing one from power-off.

Yes, it seems really flaky.

I can upload new sketches, and after opening the serial monitor it runs them ... the first time.

I don't know about the rest of the folk on this board, but to me, the fact that we are still having problems with the dog gone bootloader after knowing for years that the problem exists is really, really annoying. Put the fix in the darn production line so we can forget it ever existed.

For the OP, there is a workaround that I developed while I was waiting (and whining) for a fix to the 2560 bootloader. You turn the bootloader into a timer and slap in some code to take care of the board locking up on something. It's not the absolute perfect solution since it isn't totally hardware, but it worked for months and months without a hitch in several arduinos of mine. I use it pretty regularly when I need a watchdog that can run a longer period than the provided one. This one can run a long time if needed (sky may be the limit).

Details are at: Desert Home: The 2560 Board is Not So Stupid Anymore

It's not just one bootloader, that's the problem. And there would be a lot of boards out there with older bootloaders.

Very true Nick, but crap, this has been going on for years, add this item to the test suite for every bootloader and get rid of the problem. Testing for this is so easy and simple that it can't even come close to comparing with the other problems normally tested for.

As for the boards already out there, the users can fix them if they have a good bootloader to put on them. Heck, you've come up with a method that works pretty well, all that's needed is a good bootloader somewhere it can be downloaded easily. There just isn't any excuse for something like this coming off the production line for any of the arduino boards anymore. Three years ago, maybe, but not now.

The problems I'm observing with my Arduino Micro, however, are not to do with the watchdog.

I'm a little surprised it's working so strangely, the only excuse I can give is that it is new and they are ironing out bugs.

That was released on Thursday, November 8th, 2012. So it's pretty new.

Yes, your problem may well be a brand new bug. New bugs are expected and have to be tolerated, I totally understand that. My tirade was only directed at the watchdog timer problem that has plagued us for years on various boards through many production runs and major modifications.