Pages: [1] 2   Go Down
Author Topic: Arduino Longterm  (Read 3491 times)
0 Members and 1 Guest are viewing this topic.
0
Offline Offline
Full Member
***
Karma: 0
Posts: 235
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

I am building an Arduino product. Its kinda like a scheduler thing with LCD, relays and all.  I was wondering before I launch it as product what are the additions  or precautions I must take for a long time use. I mean like would I require a watchdog timer? Or will there be any long running time problems associated with it(I am using LCDs) or something similar to those which I should keep in mind while designing a complete package.

I am hoping some of the experienced users who have made products with this can help me out. smiley
Logged

UK
Offline Offline
Shannon Member
****
Karma: 223
Posts: 12577
-
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

I suppose that depends what you mean by 'long term use'. If you mean it can be treated like an appliance and assumed to work for years, then I guess you will need to make sure any electrical inputs and outputs are buffered effectively, make sure your sketch doesn't use any dynamic memory allocation and ensure you have edalt with the issue of counter overflow and number overflow in general throughout. Also make sure it is possible to do a hard reset somehow - perhaps via a pushbutton behind a small hole.
Logged

I only provide help via the forum - please do not contact me for private consultancy.

0
Offline Offline
Full Member
***
Karma: 0
Posts: 235
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

@peterH
Thanx for the info  smiley

Quote
If you mean it can be treated like an appliance and assumed to work for years

Yes this is what I have in my mind.

U mean dynamic memory allocation as in variables used in programs?? I use very few.
 
Quote
counter overflow and number overflow

How do I solve this? Maybe a software reset every 2 days or something?

And I do provide a hard reset button. Is watchdog timers necessary?
Logged

Anchorage, AK
Offline Offline
Edison Member
*
Karma: 42
Posts: 1176
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Dynamic allocation like malloc() and such, where there's a fair chance you didn't free the memory properly, and eventually run out.

Overflows, like millis() -- the runtime counter that resets every ... what was it, 49 days?  What happens if you check the time between two events and it's a huge negative number, for example...  You solve this by watching anything that continuously increments, and handling the case where it rolls from max to 0.  Or negative-max.

As for providing a means to reset, a push-button, barrel jack DC adapter that can be yanked... just some way.  Any way will suit just fine.

Most(?) of the AVR chips have a watchdog timer you can enable.  You tell it to reset the chip after so much time of no communication, then you make sure you reset the timer in your code within that window of time.  When it stops being reset by your code, the watchdog assumes it crashed and resets the CPU.  There's a tutorial from the playground:

http://tushev.org/articles/electronics/48-arduino-and-watchdog-timer
Logged

UK
Offline Offline
Shannon Member
****
Karma: 223
Posts: 12577
-
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset


Overflows, like millis() -- the runtime counter that resets every ... what was it, 49 days?  What happens if you check the time between two events and it's a huge negative number, for example...  You solve this by watching anything that continuously increments, and handling the case where it rolls from max to 0.  Or negative-max.


I disagree. You solve this by designing your code so that counters either don't overflow, or so that the logic is not affected by an overflow. There is a classic example of this in the code usually used to implement the 'blink without delay' example. This version handles overflow correctly:

Code:
unsigned long lastMillis;
...
if((millis() - lastMillis) > interval)
{
    lastMillis += interval;
    ...

This version doesn't:
Code:
if(millis() > nextMillis)
{
    nextMillis += interval;

Although you should provide some way to reset the device, you should design it so that this is never expected to be needed.
« Last Edit: April 04, 2012, 12:39:42 pm by PeterH » Logged

I only provide help via the forum - please do not contact me for private consultancy.

Offline Offline
Edison Member
*
Karma: 8
Posts: 1341
If you're not living on the Edge, you're taking up too much space!
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Good point Peter!  The solution is simple as you illustrated.  Most people will not see the difference in your 2 examples.
Logged

If you fall... I'll be there for you!
-Floor

Skype Brighteyes3333
(262) 696-9619

Offline Offline
Edison Member
*
Karma: 32
Posts: 1288
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

If there are no bugs in your software (or hardware), you should be fine.

I built an alarm system for my 1994 van when it was less than a year old.   (Of course with a different microcontroller.)      It's been running 24/7 for over 15 years!   It's powered-up, turned-on, and running full-time, even when it's not armed.... Only the inputs & "state" changes when you turn it "on" or "off".  There is no "reset", except for when the car-battery dies & gets replaced every 4 or 5 years...
« Last Edit: April 04, 2012, 01:02:20 pm by DVDdoug » Logged

Anchorage, AK
Offline Offline
Edison Member
*
Karma: 42
Posts: 1176
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
I disagree. You solve this by designing your code so that counters either don't overflow, or so that the logic is not affected by an overflow.

I think my meaning was misunderstood.  millis() will overflow.  There's nothing you can do about that, thus proper design handles this accordingly.  Your example, for example, is predicated on the understanding that the integer value (returned by millis()) will eventually increment beyond its limits, and handles that.

One of the other fellows here is building an assembly line counter.  Eventually, that could very well overflow the count variable.  How would you prevent that from ever happening?  Use a larger integer?  Well, eventually, a 2048-byte integer could overflow (in theory -- buuuut probably not in practice), and that's every byte of SRAM on a 328, so it can't be made bigger.  (Not even that big, of course, but you get the point.)  The "best" way to handle that depends entirely on the circumstance.

My point was only to illustrate that such things happen, and if you don't anticipate it, you'll end up with things you didn't expect -- such as a large negative number (assuming you use signed integers) when you only ever expected to see a small, positive, difference.  I never intended to provide a workaround, as there are many valid approaches, and an engineer will ultimately have to find the one best suited to their own application.  :-)
Logged

nr Bundaberg, Australia
Offline Offline
Tesla Member
***
Karma: 126
Posts: 8474
Scattered showers my arse -- Noah, 2348BC.
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

All the above is known as "defensive coding". At every point in your program you look at the assumptions being made and ask yourself "But what happens if...?".

Depending on the application you can spend a lot of time doing this, placing guard bands around arrays, monitors to keep an eye on the stack etc etc. If you get really serious you probably have to look at the MTBF of all the hardware components smiley

It is essentially the difference between some code knocked up for fun in the home and a professional product.

______
Rob
Logged

Rob Gray aka the GRAYnomad www.robgray.com

Offline Offline
Edison Member
*
Karma: 5
Posts: 1730
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Or sometimes the difference between a quality device that no one ever complains about and a cheap piece that is only bought once before people realize its crap
Logged

0
Offline Offline
Full Member
***
Karma: 0
Posts: 235
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Oyii Lots of activity since I last logged in... smiley-grin Thanks for all the replies..  smiley

@SirNickity
I am not using any dynamic initialization so thats out of the window... smiley
I know millis will overflow in around 50days or so. So will it be a good idea to reset (I mean software reset) every 4-5 days and restart the sketch?

@DVDdoug
Quote
If there are no bugs in your software (or hardware), you should be fine.


I was thinking on same lines... smiley-grin Thanx for letting me know that its possible smiley-grin

@winner10920
Quote
Or sometimes the difference between a quality device that no one ever complains about and a cheap piece that is only bought once before people realize its crap

I would like to be in first category... smiley-wink

Let me thank everyone once again for your responses... smiley Is there anything else I could have missed?? If so please do tell... smiley
Logged

Offline Offline
Edison Member
*
Karma: 5
Posts: 1730
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Are you using a rtc for timekeeping or the arduino's millis()? The millis isn't that accurate over large amount of time, a software reset isn't needed if your code can handle the millis rollover
Logged

Anchorage, AK
Offline Offline
Edison Member
*
Karma: 42
Posts: 1176
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Yeah, what he said.  :-)

milis() is useful as a quick "how long has it been since I've done some maintenance task" thing.  Or for debouncing, or backlight timeouts, or what-have-you.

As winner said, and like we were discussing above, if the code you write to calculate differences between samples taken from millis() expects and properly handles the rollover case, then there's no need to worry about it.  The overflow is completely harmless.  All it means is that you can't blindly assume the value will always be higher than the last time you checked it.  At some point it goes back to zero and starts counting up again.

Along the lines of the defensive coding thing, you should probably ALWAYS expect counters of any kind will eventually overflow.
Logged

Delray Beach, FL USA
Offline Offline
Full Member
***
Karma: 0
Posts: 113
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

All it means is that you can't blindly assume the value will always be higher than the last time you checked it.

Or to get really picky, you can't blindly assume the computed time even if you handle rollover correctly was less than 49 days :-).
Logged


Ontario
Offline Offline
Jr. Member
**
Karma: 0
Posts: 61
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

It was mentioned that an RTC can help address the time accuracy.  How does an RTC work?  Does it track the actual time (so you'd have to set it some how...), or is it also just milliseconds, but can count more accurately, and we'd do to the match to calculate the proper time?
Logged

Peter

Arduino and electronics newbie... but enjoying what I'm learning

Pages: [1] 2   Go Up
Jump to: