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.
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:
#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 ), 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.
While we are at it, I would like to complain about the free() bug which causes a lot of heartache. And that is across all the supported platforms.
Help me, I know that free() will fracture memory and cause the board to run out. Is that what you're talking about? That particular problem of fragmentation is not only on the arduino, it's everywhere. I once had to write code for a unix system to recover that memory and pack the usage back down to reasonable, for an ATM strangely enough. Yes, I read your other post. As part of that project, I searched around and found out that that was a conscious decision back when it was being developed. It was either eat time tracking and keeping memory usage under control, or run fast and let it get out of hand. Remember how slow machines were back in the '80s? they chose fast.
Which meant, every night after midnight sometime, the ATM would pause, clean up memory and then continue. Took too long to reboot the darn thing and it was hard on the hardware to go through the entire boot up diagnostics on the depositor and dispenser for something like this.
No, I'm not talking about fragmentation. There is a bug in the library. Code that should work perfectly well (eg. allocating 10 bytes, freeing those 10 bytes, and then allocating them again) fails.
Right, that was the tool set using an older version of free(). I thought that was fixed in the later IDEs; that's what I get for assuming.