Show Posts
Pages: [1] 2 3 ... 10
1  Forum 2005-2010 (read only) / Troubleshooting / Re: My program stops after 9h32m on: February 01, 2007, 06:18:44 pm
This is because the millis() function overflows after that amount of time.  See here:

2  Forum 2005-2010 (read only) / Troubleshooting / Re: direct access of PORTD? on: January 29, 2007, 11:44:57 am
DDRD will not work because that is for defining whether each pin is input/output.
PORTD does not work because that is for reading/writing the current output state (HIGH/LOW).
What you want is: PIND, which is the array of input state bits.
3  Forum 2005-2010 (read only) / Troubleshooting / Re: Arduino crashes on Windows 2000 / Athlon 64 on: January 03, 2007, 09:54:55 am
I had problems when I tried to execute arduino.exe directly, but if I execute "run.bat", it works fine.
4  Forum 2005-2010 (read only) / Troubleshooting / Re: Serial speed and syncronization problem on: January 09, 2007, 01:22:03 pm
For what it's worth, the serialAvailable() bug I found would have no effect on your code, because you are just using Serial.available() to test yes/no is there at least one byte available.  Even when it returns the wrong value, it will be nonzero, so your code will react properly.
5  Forum 2005-2010 (read only) / Troubleshooting / Re: Serial speed and syncronization problem on: January 07, 2007, 09:24:11 pm
hehe you tricky little kitty Wink
you are right...
thanks for the code tip
Meow!  smiley

this doesn't solve my other problem though...I can't still push the Serial line above 38400 smiley-sad
Meow?  smiley-sad
What exactly happens when you go above 38400 baud?
6  Forum 2005-2010 (read only) / Troubleshooting / Re: Serial speed and syncronization problem on: January 07, 2007, 06:07:51 pm
OK, now I think I see what the problem is.  In loop() the code calls Serial.available() to see if at least one byte is ready in the serial input.  Then it reads one byte:

    byte s =;

So far, so good.  But then you have a problem because you call Matrix_serialRead(), which tries to read a whole bunch of bytes inside the for loops with:

    Matrix_string[c][r] =;

The problem is that does NOT WAIT for serial data to be available.  If a byte is not ready, it will immediately return -1.  If you change the above line to the following, and take out all the other things you used for artificial delay, I bet it will work fine:

    while (Serial.available() == 0) {
        // do nothing... just wait for a byte to arrive
    Matrix_string[c][r] =;

You might even add the following utility function which will always wait for a byte to be available:

char getbyte()
    while (Serial.available() == 0) {
        // do nothing

Then you could just do:

    Matrix_string[c][r] = getbyte();
7  Forum 2005-2010 (read only) / Troubleshooting / Re: Serial speed and syncronization problem on: January 07, 2007, 04:17:30 pm
I use 115200 baud all the time and it works fine.  Try posting your code here; maybe then we can see what the problem is.
8  Forum 2005-2010 (read only) / Troubleshooting / Re: Arduino crashes with Serial bug?! on: January 06, 2007, 10:36:06 am
One thing to watch out for is that returns -1 if there are no characters ready.  At 16 MHz, the processor can easily outrace the slow baud rate.  When you introduce a Serial.print, you are probably slowing things down to the point that another incoming character has time to arrive.  You can either check for -1, or you can wait for a character to arrive by using the following busy-loop:

while (Serial.available() == 0) {
    // do nothing... just wait for a character to arrive

If you do decide to check for -1, you should use an "int" to store the return value of  The -1 will be converted to 255 (0xff) if you store it in an "unsigned char", so there is no way to distinguish it from the byte 255 being received.
9  Forum 2005-2010 (read only) / Troubleshooting / Re: EEPROM not always reliable on: December 03, 2006, 05:55:03 pm
OK, I just had the same thing happen again, this time to very first byte in EEPROM (address 0).  I definitely had the character 'l' (lowercase 'L', ascii value 0x6c) stored there.  The first few times I retrieved it, I got the correct value back.  But then all of a sudden, it got corrupted.  I added special code this time to figure out what the value was, and it was 255 (or 0xff if you prefer).

Any ideas why my EEPROM is getting overwritten at random times?
10  Forum 2005-2010 (read only) / Troubleshooting / EEPROM not always reliable on: December 03, 2006, 03:04:36 pm
I have been playing around with the functions eeprom_write_byte and eeprom_read_byte, for writing and reading the nonvolatile 512 bytes of EEPROM on the Atmega8.  I had stored an ASCII string in this memory, and I had a command to retrieve the contents of this string and play it in Morse Code.  For several days, I had used this command to play the string without any problem.  Then, this morning, the second byte in the string got corrupted, though all the other bytes were still correct.  Like an idiot, I overwrote the string with a new string without determining what the corrupt byte's value had become.  I just know it was corrupt because my Morse Code algorithm treated that character as a space by delaying for a while, as it does for any character it does not recognize.  (If this happens again, I will add code to determine what the corrupt bit pattern is.)

My question is, has anyone else encountered erratic EEPROM behavior like this?


- Don
11  Forum 2005-2010 (read only) / Bugs & Suggestions / Re: Interupts on: December 24, 2006, 09:21:49 pm
I just made a similar reply in another thread:  when you do something like this line of code:

    MCUCR |= (0<<ISC00);  // should set a falling slope for int0 = arduino pin 2

You are not really doing anything at all.  Doing a bitwise OR with zero does not change the value of MCUCR.  I suspect what you meant was to ensure that the given bit was turned off.  In that case, what you really need is:

    MCUCR &= ~(1<<ISC00);  // should set a falling slope for int0 = arduino pin 2

Just thought I would point this out, because I keep seeing this in code posted here.  What you had might be working correctly simply because the given bit was already zero.
12  Forum 2005-2010 (read only) / Bugs & Suggestions / Re: Request: bootloader options for brownout detection on: September 15, 2008, 03:12:16 pm
BroHogan, thanks for confirming that!  I need to get one of those variable power supply thingies! smiley

The problem with the 2.7V default is that the processor is already mis-executing instructions at this point, leading to unpredictable results, including corrupting program memory.  I was aware of this lower setting when I read the data sheet, but I probably did not make this clear.  It's pretty scary when your chip can do random stuff and corrupt memory before getting reset!  I was having to re-flash my ATMEGA8 every now and then before I made this fuse bit change on it.

- Don
13  Forum 2005-2010 (read only) / Bugs & Suggestions / Re: Request: bootloader options for brownout detec on: September 10, 2008, 08:50:38 pm
This might give some help with the ATMEGA168 fuse bits:

Also... we always have the multi-hundred-page confusingly written data sheets!!!  smiley

- Don
14  Forum 2005-2010 (read only) / Bugs & Suggestions / Re: Request: bootloader options for brownout detec on: September 10, 2008, 06:59:04 am
When reading the ATMEGA8 data sheet, the disadvantage they mention about brownout detection is that it consumes slightly more current from the power source.  However, this is a small price to pay for most applications.  I would think brownout detection should be the default, since most of us experimentalists have enough problems trying to get stuff to work!  However, disabling brownout detection should be an option for projects that are trying to be as power efficient as possible, and that have well-regulated power with auto-shutdown of the power supply when the voltage gets too low.
15  Forum 2005-2010 (read only) / Bugs & Suggestions / Request: bootloader options for brownout detection on: August 11, 2008, 08:52:09 pm
I have been having problems with my ATMEGA8 program memory getting corrupted when I cycle the power on my experimental digital clock board:

I am using a 9V wall adapter, and apparently what was happening was that when I unplug it, it has a capacitor that gradually loses its charge, so the voltage it supplies to the voltage regulator gradually (meaning many, many milliseconds!) falls to zero.  I confirmed in the ATMEGA8 data sheet, and elsewhere, that this can cause the ATMEGA8 to execute instructions incorrectly, and thereby overwrite program memory.

I also found a fix:  for the ATMEGA8 only, you can change the low fuse byte from 0xdf to 0x1f.  This will NOT work on ATMEGA168; I have not yet read that microcontroller's data sheet to figure out the proper value.  Quit out of Arduino if you are running it, then edit the file hardware/boards.txt in your Arduino install and add the following lines at the front of the file:

############################################################## with brownout detection



Note that I just copied the "Arduino NG or older w/ ATmega8" configuration, renamed all the "atmega8" prefixes to "atmega8bod" (bod = Brown Out Detection), changed low_fuses from 0xdf to 0x1f, and the "name" field.  

After saving boards.txt, run Arduino, hook up your bootloader hardware (I use the do-it-yourself parallel port), and select Tools/Board.  Choose the "Custom ATMEGA8 with brownout detection" option (the one we just added to boards.txt).  Then choose Tools/Burn Bootloader, and then the appropriate hardware connection.

Afterward, you will need to hook up the serial port and reload whatever software you want to run on the chip, because the bootloader burn will have erased anything in there.

So far this seems to be working... my program memory is no longer corrupted, no matter how many times I unplug and replug my wall adapter.

My request to the Arduino developers is, can you provide options for all of these in the standard Arduino install?  If it would help, I can try to research what all the fuse bits should be for the other microcontrollers.  I will need somebody else to help me test in all the hardware configurations I do not own.


Pages: [1] 2 3 ... 10