No, I haven't, mem.  But you're right that there would almost certainly be a conflict.  

I added an end() method in NewSoftSerial 10 (now in beta) that allows for you to turn off a NewSoftSerial interrupt stream.  (Previously, interrupts were enabled forever.)  

Could someone test this with Servo and Tone, i.e. start a NewSoftSerial stream, turn it off with end(), run a Servo, play a Tone, then turn NSS back on with begin(...)?

http://arduiniana.org


Mikal

Hi all--

I can officially confirm that NewSoftSerial (and really any software serial library) is incompatible with the new Servo library that ships with Arduino 0017.  The problem is that the new Servo library, which is really quite cool, depends on reliable interrupts, where software serial solutions require interrupts to be disabled -- at least for short periods of time.  I discovered this issue when I was trying to upgrade my Reverse Geocache box to 0017, and the only workaround I could come up with was to downgrade the Servo library back to 0016.

I wonder if it would be possible to retain both libraries in 0018?

Mikal

Yeah, also remove the #define of abs() in wiring.h.

Mikal

Right-o!  maca, if you follow mem's example and add the #ifdef/#endif to your copy of wiring.h (effectively removing the five #defines in between), you will probably get happiness.

Mikal

Mem, I *haven't* tried this code, but these are exactly the types of errors (stdlib.h:80) that people get when compiling old libraries with 0012.  My guess is that it works for you because you disabled or undefined those pesky "function-style" cast macros in wiring.h"?  If so, perhaps you'd care to share your method?

Mikal

Joker,

The express you propose,

elapsed_time = (max_counts + this_tick - last_tick) % max_counts;

is indeed more succinct and readable than the equivalent

if (this_tick < last_tick)
  elapsed_time = max_counts + this_tick - last_tick;
else
  elapsed_time = this_tick - last_tick;

However, I think you'll find that many programmers opt for the latter for the simple reason that in most computer architectures the modulus operation is much more costly in terms of CPU consumption.

Cheers,

Mikal

Thanks for the update.  I'm glad that it's working.

Mikal

Hi Rene--

Could you share the error messages more explicitly?  That might help me help you figure out what's going wrong.

Mikal Hart

That code looks fine now.  My guess is that you are hooking RX to RX and TX to TX.  It should be TX  to RX and RX to TX.  Whatever you initially connected to pin 0, now connect it to pin 2.

Mikal

Yes, Ron, the .o files are the compiled versions of the source.  Unfortunately, I think the only time the libraries are recompiled is when you delete the .o files, or possibly if you select a different species of Arduino board.  In any case, I learned soon enough that an 0015 binary will not work in 0016.

I'm relieved that your problem is solved.  Thanks for sharing.

Mikal

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

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

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

I get that "error" sometimes.

Just on a hunch, try adding

Code:

#include <WProgram.h>

to the top of nunchuck_funcs.h.

Mikal

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