Show Posts
Pages: 1 2 [3] 4 5 ... 67
31  Forum 2005-2010 (read only) / Troubleshooting / Re: NewSoftSerial not working under Arduino 016 on: June 06, 2009, 01:51:17 am
Ron, I just completed a run testing every baud rate from 300 to 115.2K with NewSoftSerial 9 under Arduino 0016 (Windows) and didn't see any TX problem.  TX is the easy part of soft serial and 9600 is pretty slow.  I'm starting to suspect something else is wrong.  What operating system are you developing with?

Mikal
32  Forum 2005-2010 (read only) / Troubleshooting / Re: NewSoftSerial not working under Arduino 016 on: June 06, 2009, 01:36:57 am
Ron,

I am unable to reproduce the trouble you are seeing with 0016 and NewSoftSerial.  Actually, I had a lot of trouble when I first tried 0016, but then I realized that I hadn't deleted my library .o files when I copied them over from 0015.  Did you delete all the library binaries?

Could you try a simple test of, say, printing "Hello" to the LCD?  Does "regular" SoftSerial work?  That should be an easy test.

Is anyone else experiencing any unexplained behavior with NewSoftSerial?

Mikal
33  Forum 2005-2010 (read only) / Troubleshooting / Re: Serial error rate (Hardware) on: June 02, 2009, 11:38:33 pm
A common misconception is that an N baud connection implies that you are transmitting N bits per second.  No, the baud rate only refers to the width of the bits within each byte.  At 3Mbaud, each bit is 1/3,000,000 of a second in length.  Once a byte has been transmitted, there is no guarantee that the next byte will immediately follow on its heels.  You could send 1 byte every 10 seconds at a nominal 3Mbaud bitrate, but really only be getting an effective rate of 10 bit per second.

What I'm getting around to is that your problem is not due to "pushing the limits of the Atmel328".  The slowest processor in the world can transmit at 3Mbaud as long as it is connected to a UART that can transmit a byte at that bit rate.  You won't get 3 million bits per second, but you will get 3Mbaud.

Mikal
34  Forum 2005-2010 (read only) / Troubleshooting / Re: How to show better error messages? on: January 27, 2009, 08:33:30 pm
I get that "error" sometimes.

Just on a hunch, try adding

Code:
#include <WProgram.h>
to the top of nunchuck_funcs.h.

Mikal
35  Forum 2005-2010 (read only) / Troubleshooting / Re: Simple problem with serial loop on: April 18, 2009, 11:16:41 pm
lzhang--

Your logic seems quite reasonable.  Do you see the "ASCII Table ..." message?

If you are connecting using the Arduino serial monitor, be advised that it does not actually send anything until you press Enter.

Good luck.

Mikal
36  Forum 2005-2010 (read only) / Troubleshooting / Re: Cant get PROGMEM to work on: April 17, 2009, 12:23:24 pm
Hi chupit,

Flash (the library) doesn't really make any decisions about where to write data.  It simply provides a layer on top of already existing technology that makes the reading of flash data simpler.  For example, if you wanted to write a program to print "Hello, world" without the use of my library, you could write something like this:

Code:
#include <avr/pgmspace.h>

const char PROGMEM str[] = "Hello, world!";

void setup()
{
  Serial.begin(9600);
  for (int i=0; ; ++i)
  {
    byte c = pgm_read_byte(str + i);
    if (c == '\0')
      break;
    Serial.print(c, BYTE);
  }
}
void loop(){}

In this short program, the compiler determines where in flash memory to put the code and where to put the "Hello, world!" string.

When you use the Flash library to do the same thing, you aren't doing anything differently.  The same allocation technique is going on "under the covers".  It's just that it's syntatically simpler:

Code:
#include <Flash.h>
FLASH_STRING(str, "Hello, world!");
void setup()
{
  Serial.begin(9600);
  str.print(Serial);
}
void loop(){}

Is that clearer?

Mikal
37  Forum 2005-2010 (read only) / Troubleshooting / Re: Cant get PROGMEM to work on: April 15, 2009, 10:04:53 pm
Hey, you were close!  You are far from the first person to stumble over pgm_read_word, etc.

Just FYI, if you want to use Flash to print out a flash-based string, you can avoid having to copy to an intermediate buffer (and save the 64 bytes) if you don't mind this slightly funky syntax:

Code:
FLASH_STRING(fstr, "String");
Serial << fstr << "\r\n";

EDIT: One other thing: If you do want to use the copy method, there is no need to specify the length if you are just copying the whole string.  This will work fine in your example:

Code:
fstr.copy(buffer);

Mikal
38  Forum 2005-2010 (read only) / Troubleshooting / Re: Cant get PROGMEM to work on: April 15, 2009, 09:54:04 pm
Van,

The line

Code:
 char* p = (char*)pgm_read_word(&(str));

reads a two byte word at the address in read-only memory referenced by "str".  These are the two bytes 'S' == 0x53 and 't' == 0x74.  p is now an artificially created pointer with value 0x7453.  Now when you call strcpy_P, you are telling it to copy from offset 0x7453, which is way outside the legal flash address space.

What you want is simply:

Code:
strcpy_P(buffer, str);

... or use the Flash library. smiley

Mikal
39  Forum 2005-2010 (read only) / Troubleshooting / Re: Cant get PROGMEM to work on: April 13, 2009, 11:06:39 pm
Van,

Can you share your code?

At the risk of seeming self-promoting, may I suggest you look at my "Flash" library, which considerably simplifies the PROGMEM stuff?

Mikal
40  Forum 2005-2010 (read only) / Troubleshooting / Re: IDE 0013: error compiling (WProgram.h stlib.h) on: February 12, 2009, 12:30:06 pm
No, the problem here is caused by the fact that in wiring.h we still for some reason define our own version of abs.

I'm glad we removed all the #define int... etc. from 0012, but I really think we should also remove the definitions for macros that are also #defined elsewhere, especially since stdlib.h seems to be automatically included these days.

You might try simply adding

Code:
#undef abs

at the top of your sketch right after all the #include lines.

Mikal
41  Forum 2005-2010 (read only) / Troubleshooting / Re: Compilation error with 0012 Alpha and MMC librairy on: January 29, 2009, 03:26:31 pm
I was able to get mmc1_v2 to compile by:

a) adding #include <WProgram.h> at the top of mmc.h
b) deleting the wprogram.h tab in the project.

(I'm using 0013, but I bet it works for 0012 also.)

Mikal
42  Forum 2005-2010 (read only) / Troubleshooting / Re: MsTimer2 and arrays on: February 07, 2009, 11:48:00 pm
Hey, greendude...

When you declare a variable like "array" inside a function, it is only visible from within that function.  Since your "array" lives inside setup(), the code inside shift() can't get to it.  An easy solution is just to move it outside of setup() like this:

Code:
int array[] ={0,0,0,0,0,0,0,0};

void setup() {
...

Mikal
43  Forum 2005-2010 (read only) / Troubleshooting / Re: Incompatibility between arduino 10 and version 12 on: February 04, 2009, 11:42:10 am
Ah, this shouldn't be too hard.  Simply remove the line

Code:
extern volatile unsigned long timer0_overflow_count; // timer0 from wiring.c

and replace all other references to "timer0_overflow_count" with "millis()".  <- don't forget the parentheses.

Mikal
44  Forum 2005-2010 (read only) / Troubleshooting / Re: Incompatibility between arduino 10 and version 12 on: February 02, 2009, 12:52:37 pm
It looks like the bottom of your program got truncated.  The problem is that timer0_overflow_count is no longer supported as of 0012.  This kind of problem can probably be fixed, but we'd need to see the remainder of the code.

Mikal
45  Forum 2005-2010 (read only) / Troubleshooting / Re: Serial Help on: February 01, 2009, 07:25:34 am
Quote
im not sure if you hooked up any LEDs and tried this but cranking up the DELTA...

No, I'm afraid I only tested this in the Arduino in my brain, but I'm glad to hear it works.  Post a video?  smiley  I'd like someday to extend the concept to, say, 256 LEDs.  Power won't be a problem as long as I keep TAILLENGTH somewhat low, but I'll have to get out some shift registers or something.  Thanks.

Mikal
Pages: 1 2 [3] 4 5 ... 67