Hello again! After some time lurking in the shadows (not really lurking, I just didn’t have enough time) I decided to re-start again some projects, like the BXDrone, whose new code is available on GitHub, but it’s still on a raw state.
However this post will talk about the BusTracker project. I have already shown how it works (refer to previous link), and even though the code has changed, the basics are the same. The major changes that I have introduced are:
- Change Ethernet with WiFi. “Hey dude, that’s not a major change! Just change a couple of code lines but the rest is the same”. Kind of. I decided to use the Adafruit CC3000 WiFi board, which works perfectly in Arduino and Adafruit provides with very good examples of how to use it.
- Change Intel Galileo with Arduino. If you remember, I was using an Intel Galileo instead of an Arduino for this project, and there are several conflicts with the Adafruit CC3000 library and the Intel Galileo, so I had to use an Arduino. “Ok, still it’s good. What’s the problem on that?”. Memory, my friend. Memory is everything, and while Intel Galileo has 256MB of memory, Arduino Uno is playing in the Major leagues with 2kB RAM. That’s OK for most of the applications that Arduino has. Even we can scratch off some free memory storing fixed strings and variables in Flash memory. However, the Saskatoon transit website we are trying to download has 22,000 characters (1 char = 1 byte) in its source code, this is 10 times larger than Arduino’s RAM memory. Before you know it, your program is in a coma.
- Download website in chunks of X bytes. In my code, I set this X to 50 bytes. My code reads 50 bytes of the source code we are downloading, extract whatever information is useful (bus line, waiting time, etc.), throw it away and read the following 50 bytes.
Even with these fixes, Arduino get stuck sometimes. It can be 1 minute after the program has started, it can be after several hours… who knows? It’s really annoying that each time this happens, we have to push the reset button. That’s the reason behind the new feature: Watchdog timer.
“What’s a watch-what?”. Do you see what I said before about hitting the reset button whenever the program gets stuck? That’s what a watchdog does, without you having to take care of it. It’s a module in the microcontroller that sets a countdown at the beginning. Before the countdown goes off, you tell the watchdog “Hey! The code is still working!” and the watchdog resets the countdown to the original value. If, for any reason, you don’t notify the watchdog that everything is OK (for example, when your code gets stuck), when the countdown goes off, it’ll reset the Arduino, and this process will start all over again.
It’s pretty useful for situations like these. “Hey dude! Still you’re not preventing that the Arduino gets stuck!”, yes I know, but I get the program to give me continuously the waiting time for the buses, which is what I want, even though it gets stuck
For Arduino, the code is really simple:
#include <avr/wdt.h>
/* Auxiliar variable */
int k = 0;
void setup(){
// Use the Serial comm to know when it resets
Serial.begin(9600);
// Initialize watchdog (countdown = 8 seconds)
wdt_enable(WDTO_8S);
}
void loop(){
// Print a number and add 1 afterwards
Serial.println(k++);
// Feed watchdog (uncomment this line to keep the watchdog from resetting
// wdt_reset();
// Insert 1 second delay
delay(1000);
}
The code above sets up the watchdog but doesn’t feed it (note the commented line on the loop() function). In this case, the watchdog should reset the Arduino after 8 seconds (i.e. when the countdown ends). You can check that if you open the Serial port and see that after printing “8” or “9”, it goes back to print “0”, “1”, etc. That means that the Arduino has been reset.
There are some other ways of resetting the Arduino (the one that I like the less is connecting a digital pin to the reset pin. That doesn’t seem like a safe reset at all), but a lot of people would agree that a watchdog reset is the best and safest way of doing a software reset.
NASA’s Curiosity is an example of a system implementing a watchdog timer.
The watchdog timer is a well-known module in embedded systems, since in most cases we don’t have direct access to embedded systems and they have to reset themselves in case of a failure. An example of this is the Curiosity emergency reset in 2013, when it had an unexpected software reset. In case any part of the Curiosity code gets stuck, you won’t expect anyone to go to Mars and hit the reset button, so you have to foresee these kind of situations. Usually after a watchdog reset, you have to check what caused the reset. As part of the watchdog module, usually after the reset it provides some information about the reset, like in which memory address the program was, or which code line, etc. Refer to links below for more information.
And that’s all so far! Stay tuned if you’re interested in the code (by what I’ve heard from friends, we all want to have a display at home that shows when the next train/bus is coming!) and comment with any question or any information you want to ask/add. Thanks for reading!
PS: In case anyone living in Saskatoon was wondering, no, the recent changes on the bus lines hasn’t affected the code 🙂 It works just as fine as it did before!
Links of interest:
Watchdog timer in Wikipedia: https://en.wikipedia.org/wiki/Watchdog_timer
Detect lockups in Arduino: http://www.megunolink.com/articles/how-to-detect-lockups-using-the-arduino-watchdog/
JaviG-Hawk 