NewSoftSerial

A New Software Serial Library for Arduino

News: NewSoftSerial is in the core!  Starting with Arduino 1.0 (December, 2011), NewSoftSerial has replaced the old SoftwareSerial library as the officially supported software serial library.  This means that if you have 1.0 or later, you should not download this library.  To port your code to 1.0, simply change all NewSoftSerial references to SoftwareSerial.

NewSoftSerial is the latest of three Arduino libraries providing “soft” serial port support. It’s the direct descendant of ladyada’s AFSoftSerial, which introduced interrupt-driven receives — a dramatic improvement over the polling required by the native SoftwareSerial.

Without interrupts, your program’s design is considerably restricted, as it must continually poll the serial port at very short, regular intervals. This makes it nearly impossible, for example, to use SoftwareSerial to receive GPS data and parse it into a usable form. Your program is too busy trying to keep up with NMEA characters as they arrive to actually spend time assembling them into something meaningful. This is where AFSoftSerial’s (and NewSoftSerial‘s) interrupt architecture is a godsend. Using interrupt-driven RX, your program fills its buffer behind the scenes while processing previously received data.

Improvements

NewSoftSerial offers a number of improvements over SoftwareSerial:

  1. It inherits from built-in class Print, eliminating some 4-600 bytes of duplicate code
  2. It implements circular buffering scheme to make RX processing more efficient
  3. It extends support to all Arduino pins 0-19 (0-21 on Arduino Mini), not just 0-13
  4. It supports multiple simultaneous soft serial devices.*
  5. It supports a much wider range of baud rates.**
  6. It provides a boolean overflow() method to detect buffer overflow.
  7. Higher baud rates have been tuned for better accuracy.
  8. It supports the ATMega328 and 168.
  9. It supports 8MHz processors.
  10. It uses direct port I/O for faster and more precise operation.
  11. (New with version 10).  It supports software signal inversion.
  12. (New) It supports 20MHz processors.
  13. (New) It runs on the Teensy and Teensy++.
  14. (New) It supports an end() method as a complement to begin().

*But see below for an important caveat on multiple instances.
**Be circumspect about using 300 and 1200 baud though. The interrupt handler at these rate becomes so lengthy that timer tick interrupts can be starved, causing millis() to stop working during receives.

Using Multiple Instances

There has been considerable support for an library that would allow multiple soft serial devices. However, handling asynchronously received data from two, three, or four or more serial devices turns out to be an extremely difficult, if not intractable problem. Imagine four serial devices connected to an Arduino, each transmitting at 38,400 baud. As bits arrive, Arduino’s poor little processor must sample and process each of 4 incoming bits within 26 microseconds or else lose them forever. Yikes!

It occurred to me, though, that multiple instances could still be possible if the library user were willing to make a small concession. NewSoftSerial is written on the principle that you can have as many devices connected as resource constraints allow, as long as you only use one of them at a time. If you can organize your program code around this constraint, then NewSoftSerial may work for you.

What does this mean, exactly? Well, you have to use your serial devices serially, like this:

#include <NewSoftSerial.h>

// Here's a GPS device connect to pins 3 and 4
NewSoftSerial gps(4,3);

// A serial thermometer connected to 5 and 6
NewSoftSerial therm(6,5);

// An LCD connected to 7 and 8
NewSoftSerial LCD(8,7); // serial LCD

void loop()
{
  ...
  // collect data from the GPS unit for a few seconds
  gps.listen();
  read_gps_data();  // use gps as active device
  // collect temperature data from thermometer
  therm.listen();
  read_thermometer_data(); // now use therm
  // LCD becomes the active device here
  LCD.listen();
  LCD.print("Data gathered...");
  ...
}

In this example, we assume that read_gps_data() uses the gps object and read_thermometer_data() uses the therm object. Any time you call the listen() method, it becomes the “active” object, and the previously active object is deactivated and its RX buffer discarded. An important point here is that object.available() always returns 0 unless object is already active. This means that you can’t write code like this:

void loop()
{
  device1.listen();
  if (device1.available() > 0)
  {
    int c = device1.read();
    ...
  }
  device2.listen();
  if (device2.available() > 0)
  {
    int c = device2.read();
    ...
  }
}

This code will never do anything but activate one device after the other.

Signal Inversion

“Normal” TTL serial signaling defines a start bit as a transition from “high” to “low” logic.  Logical 1 is “high”, 0 is “low”.  But some serial devices turn this logic upside down, using what we call “inverted signaling”.  As of version 10, NewSoftSerial supports these devices natively with a third parameter in the constructor.

NewSoftSerial myInvertedConn(7, 5, true); // this device uses inverted signaling
NewSoftSerial myGPS(3, 2); // this one doesn't

Library Version

You can retrieve the version of the NewSoftSerial library by calling the static member library_version().

int ver = NewSoftSerial::library_version();

Resource Consumption

Linking the NewSoftSerial library to your application adds approximately 2000 bytes to its size.

Download

The latest version of NewSoftSerial is available here: NewSoftSerial12.zip.  Note: don’t download this if you have Arduino 1.0 or later.  As of 1.0, NewSoftSerial is included in the Arduino core (named SoftwareSerial).

Change Log

  1. initial version
  2. ported to Arduino 0013, included example sketch in package
  3. several important improvements: (a) support for 300, 1200, 14400, and 28800 baud (see caveats), (b) added bool overflow() method to test whether an RX buffer overflow has occurred, and (c) tuned RX and TX for greater accuracy at high baud rates 38.4K, 57.6K, and 115.2K.
  4. minor bug fixes — add .o file and objdump.txt to zip file for diagnostics.
  5. etracer’s inline assembler fix to OSX avr-gcc 4.3.0 interrupt handler bug added.
  6. ladyada’s new example sketch, fix to interrupt name, support for 328p.
  7. etracer’s workaround is now conditionally compiled only when avr-gcc’s version is less than 4.3.2.
  8. 8 MHz support and flush() and enable_timer0()  methods added
  9. digitalread/write scrapped in favor of direct port I/O.  Revised routines now get perfect RX up to 57.6K on 16MHz processors and 31.25K on 8MHz processors.
  10. inverted TTL signalling supported.  20MHz processors supported.  Teensy and Teensy++ supported.  New end() method and destructor added to clean up.
  11. added listen() method to explicitly activate ports.
  12. warn users about 1.0 conflict

Acknowledgements

Many thanks to David Mellis, who wrote the original SoftwareSerial, and to the multi-talented ladyada, whose work with AFSoftSerial is seminal.  Ladyada also provided the “Goodnight, moon” example sketch, fixed a problem with the interrupt naming (see v6) and tested NSS with the 328p.

Thanks also to rogermm and several other forum users who have tested NewSoftSerial and given useful feedback.

The diligent analysis of forum user etracer yielded the root cause of a tricky problem with NSS on OSX.  A bug in avr-gcc 4.3.0 causes the compiler to fail to generate the proper entry and exit sequences for certain interrupt handlers.  etracer identified the problem and provided an inline workaround.  etracer’s fix is in NSS 5.

User jin contributed a large body of work based on NSS and identified a potential problem that could result in data loss (fixed in NSS 5).  jin also made a variant of NSS that supports 4-pin serial, with the additional pins providing a very nice RTS/CTS flow control.  We may see this in NSS in the near future.

Thanks to Garret Mace, who contributed the delay tables for 20MHz processors and claims that he can send and receive at 115K baud.  Cool!

Thanks to Paul Stoffregen, both for his fine work with Teensy and Teensy++, and for contributing some useful suggestions that help NewSoftSerial run on them without modification.

I appreciate any and all input.

Mikal Hart

Page last updated on July 3, 2013 at 7:37 pm
647 Responses → “NewSoftSerial”

  1. Mikal

    15 years ago

    Frits,

    Yes, that is possible. Someday when I get time I may modify the library to allow that. Meanwhile, if you’d like to take a shot at it, you can look at the section in recv() labeled “// skip the stop bit”. Similarly, in the “write” routine, look at the stop bit delay at the very end of the routine.

    Thanks for the note.

    Mikal


  2. Mike

    15 years ago

    Hi,

    Thanks for the library. I’m having a little trouble getting it to read data from a GPS. I’m using a very basic sketch (attached), but I just get strings of garbage on the screen

    I can read the GPS data using hyperterminal without problems, it auto-detects the connections settings as 4800 baud, 8 bit, no parity. The data displayed by hyperterminal is fine, so I know the GPS is working.

    Any suggestions appreciated.

    Regards

    Mike

    #include

    NewSoftSerial mySerial = NewSoftSerial(2, 3);

    #define BUFFSIZ 90 // plenty big
    char buffer[BUFFSIZ];
    char buffidx;

    void setup()
    {
    Serial.begin(4800);
    mySerial.begin(4800);
    Serial.println(“\n\rNewSoftSerial + GPS test”);
    }

    void loop()
    {
    Serial.print(“\n\rread: “);
    readline();
    }

    void readline(void) {
    char c;
    buffidx = 0; // start at begninning
    while (1) {
    c=mySerial.read();
    if (c == -1)
    continue;
    Serial.print(c);
    if (c == ‘\n’)
    continue;
    if ((buffidx == BUFFSIZ-1) || (c == ‘\r’)) {
    return;
    }
    buffidx++;
    }
    }


  3. Mikal

    15 years ago

    Mike, your code looks reasonable, but if I were you I’d try communicating with the console at a higher speed. Can you ratchet that up to, say, 115200?

    Mikal


  4. Mike

    15 years ago

    Any word on when NewSoftSerial will be available for the Mega? I can send ok but can’t receive, using my Mega with the TSS. Primarily, I wish to use NewSoftSerial between these two devices.


  5. Mikal

    15 years ago

    Do any readers have time to port NewSoftSerial to Mega for Mike and the others?

    Mikal


  6. g

    15 years ago

    Having a bit of a problem with what i think is down to a writing baud rate issue..

    I have the PC connected to the Duemilanove via USB, then pin 3 of the arduino (Tx) connected to the serial connection on a Milford Instruments LCD display screen. Data sheet – http://www.milinst.co.uk/shop/LCDs/pdf/6_201.pdf which accepts baud rates of 9600 or 2400 depending on the baud jumper, is 8bit, no parity and one stop bit.

    Basically the Duemilanove should be acting as a USB to serial converter. The sketch is as follows:

    #include

    NewSoftSerial lcd(2, 3);

    void setup()
    {
    pinMode(13, OUTPUT);
    digitalWrite(13, HIGH);
    Serial.begin(9600);
    lcd.begin(9600);
    }

    void loop()
    {
    if(Serial.available())
    {
    char c = Serial.read();
    lcd.print(c);
    Serial.print(c);
    Serial.print((bool) lcd.overflow());
    }
    }

    Should be reading from Serial (1 char at a time) then printing to the LCD display via pin 3 (additional Serial prints for debugging)..

    At the PC side I have a python script to send the commands (clear the LCD display, reset the cursor position and send some ‘test’ text).

    At 9600 baud either side of the Arduino, data is getting through to the display screen but about 50% of the time at least 1 of the 4 characters that make up the initial string is garbled. However the messages that come back through the USB serial port to the PC are always correct and there’s no overflow.

    Connecting the LCD display directly to the PC with a serial cable and with a USB to serial converter (PL2303) it works 100% of the time fine. I’m assuming it’s got to be related to the NSS write function..?


  7. Mikal

    15 years ago

    Hmm… Can you post some samples of the “garbled” text. Logically this seems ok. Are all devices grounded? All operating at the correct voltage? There isn’t any RS-232 anywhere, is there?

    Mikal


  8. miles

    15 years ago

    I’m trying to get data from a sensor that sends data at 1200 baud. My code looks a lot like g’s above. When the arduino is reset, I get the sensor data. All subsequent tries fail. The old softserial library is able to read repeatedly, so I’m pretty sure it isn’t a hardware problem.
    Is this a baud rate problem?

    Since I will have multiple RO devices, can they all share a TX pin?

    Code that doesn’t work:
    NewSoftSerial….h2o1(7,9)

    h2o1.flush(); // flush old stuff before powering on
    digitalWrite(powerpin1,HIGH); // excite sensor and wait for device to settle.
    delay(DECAGONDELAY); // at this point sensor should have sent everything

    while(h2o1.available()>0) {
    c=h2o1.read();
    if (c == -1) { continue; }
    if (c == ‘\n’) { continue;}
    if (c == 0 ) { continue;} // null sometimes sent at beginning?
    if ((buffidx == DECAGONBUFF-1) || (c == ‘\r’)) {
    buffer[buffidx] = 0;

    Serial.println(millis() -startreadline); // tune how long we delay
    digitalWrite(powerpin1,LOW); // reset sensor
    return(1);
    } else {
    buffer[buffidx]= c;
    buffidx++;
    }
    }

    Serial.println(“failed”);
    digitalWrite(powerpin1,LOW); // reset sensor
    return(0);


  9. miles

    15 years ago

    I tightened up my code, and now NewSoftSerial will read 1-3 sensor readings successfully. Then it will fail from then on. Using the goodnight moon code & manually exciting the sensor I get the same result: 1-3 good readings, then failure from then on.

    This is using OS X Arduino 18, and a Duemilanove 328.


  10. miles

    15 years ago

    Never mind, turns out I had a problem with the sensor. When I set up a 2nd arduino to act as a sensor simulator, NewSoftSerial worked without flaw.


  11. Matt Jarvis

    15 years ago

    Hi Mikal,

    I have a problem with using the NNS library and the hardware GPS on a FIO board which I posted here:
    http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1284169934/2#2

    Do you know if it’s possible to change the interrupt or library somehow to patch this issue? (ie get the 4800 BAUD while fooling the arduino somehow it’s running at 57600?).

    If not, do you know if it’s possible to get the em406a GPS serial running at 57600 BAUD?

    Many thanks for all your hard work!


  12. Mikal

    15 years ago

    Miles,
    It looks like your program prints “failed” whenever NSS runs out of data. That’s not a real failure, though, is it?

    Mikal


  13. Mikal

    15 years ago

    Matt, I’m pretty sure that the EM-406A can’t operate at higher speeds.

    As mentioned on the forum, processing a software serial data stream — especially at slow baud rates — requires a great deal of dedicated CPU. I’m not surprised you see overflow on the Hardware Serial link if you repeatedly blast data back and forth.

    That delay(1) is actually the problem. Even without the GPS or NewSoftSerial in the equation your program couldn’t keep up with a full tilt 57.6K data stream on the Hardware Serial connection. At full speed, each byte arrives in about 1/5 of a millisecond. If you delay 1 millisecond for each, you’ll eventually suffer an overflow.

    Mikal


  14. Michael

    15 years ago

    Hi Mikal,

    I am working on a project that requires IrDA interface. I don’t need particularly fast comms so I only want to consider 9600 baud or even 2400 baud (both rates are supported by the IrDA spec). The IrDA standard defines the bit length as 3/16 of the RS232 equivalent hence a normal RS232 hardware UART can’t “talk” IrDA. What would be involved in modifying NSS to enable it to talk (and recieve) IrDA?

    I know I can get a h/w “glue” IC that deal with RS232 to IrDA conversion but I am looking for a no hardware solution.


  15. Mikal

    15 years ago

    Michael,

    I couldn’t say for sure, but if I were involved in such a project the first thing I would do is make a modification of the “table” of delays in NewSoftSerial.cpp. It would be interesting to see if shrinking these values by a factor of 3/16 suddenly “made it work”. Of course, there could be other incompatibilities too. Let me know what you find out!

    Mikal


  16. Jackshowme

    15 years ago

    I am new here. May you show me how to install your NewSoftSerial?


  17. Mark Adams

    15 years ago

    That NewSoftSerial inherits from Print is too cool. What I need is this library to support the SPI in Master or Slave modes! That way, many atMegas can communicate reliably at high speeds. I am designing open source shields with atMega168s; some as SPI Masters, some as SPI Slaves. I know the Ethernet lib uses the SPI, I just want SPI as a serial port. Thanks so much for these tools.
    Mark Adams


  18. Mikal

    15 years ago

    I’ve had a couple of people suggest this Mark. Perhaps I need to learn a bit about SPI. :)

    Mikal


  19. Mark Adams

    15 years ago

    Mikal,

    Actually, both the SPI and the TWI hardware on the Mega168 could be used as general purpose 8 bit serial ports. Years ago, I did a bit-bang serial port emulation and know how hard it is to catch incoming data correctly. These two hardware peripherals free the real time to mostly interrupt driven software allowing higher baud rates and less problems. To develop this, I guess you need someone on the shield side using straight GCC. I am thinking to change my design to just use the native UART. So, I will not likely need these interfaces or your soft ones. Thanks and good luck, when I get something out here, I will drop you a line.

    Mark


  20. MarkH

    15 years ago

    Mikal,

    I’m just getting started with Arduino serial comms. I need to interface two serial devices and was planning to use your NSS library. I don’t have the necessary h/w yet,so I can’t test anything, but I’m struggling to understand how your library maintains two asynchronous input streams. My devices cannot be controlled so will send data when they feel like it. Looking at NewSoftSerial.cpp, it looks like bits sent by a device whilst another is being read will be lost – or an I missing something?


  21. Mikal

    15 years ago

    Hi Mark. Yes, you read correctly. NewSoftSerial can’t support two asynchronous input streams. Not simultaneously anyway. The best it or any software based serial device can do is listen to one for a while, then turn that one off and listen to the other one.
    Good luck!


  22. David

    15 years ago

    Mikal,
    A couple things I see looking through the NewSoftSerial code..
    1. Interupts are disabled on TX for the length of the char.
    This could…
    cause problems to others at low baud rates.
    TX will trash any RX data incoming
    A loop back connection can never work.

    Wouldn’t an interupt driven TX help?

    David


  23. Mikal

    15 years ago

    David, you’re quite right that software serial that disables interrupts is pretty dicey at low baud rates. It works ok, but other threads in the controller can get starved because interrupts are disabled for so long.

    Unfortunately, rewriting TX so that each bit was driven by an interrupt wouldn’t work unless there were no other components in the system using them. If there were — for instance in your “loopback” scenario — then you’d run the fatal risk of having the TX interrupt delayed. And even a tiny delay can corrupt a serial transmission.

    Mikal


  24. Brett

    15 years ago

    Hey Mikal,

    I wrote the “Mega” (Arduino Mega and Mega 2560) changes for NewSoftSerial.

    Beware, though: NewSoftSerial will only be able to *receive* on pins

    10, 11, 12, 13,
    50, 51, 52, 53,
    and 62, 63, 64, 65, 66, 67, 68, 69

    That’s it.

    So if you have a shield or something else that “normally” uses a NewSoftSerial pin in the 0-9 range, it WILL NOT WORK.

    (You can, however, *transmit* on pretty much any pin).

    As a bonus, I’ve already updated it to support Stream.h (you will need to have the latest Arduino IDE – V0021+).

    http://tinyurl.com/newsoftserial-bh-mod

    b


  25. Mikal

    15 years ago

    Brett,

    Your efforts, as usual, are much appreciated. Great work! With your permission I’ll include the Mega support into NewSoftSerial 11.

    Cheers,

    Mikal


  26. Brett

    15 years ago

    No problem, Mikal, go right ahead.

    Since I’m now maintaining the libraries for Wiring, NewSoftSerial will become the new SoftSerial library for Wiring (the father of Arduino – http://wiring.org.co/). Expect to see it in Version 0028.

    b


  27. Creative

    15 years ago

    Hi,

    I’ve found some ¿bugs? on newsoftserial library:

    On line 76, change this “{ 115200, 1, 17, 17, 12, },” for this “{ 115200, 1, 16, 16, 12, },”

    On line 94, change this “static const DELAY_TABLE table[] PROGMEM=” for this “static const DELAY_TABLE PROGMEM table[]=”

    Any possibility to use non-standard baudrates?

    Thanks for this great work


  28. Mikal

    15 years ago

    Hey, thanks, Creative. About the specific values of the table, it’s very hard at high baud rates to say which ones are “correct”. Minute variations in the clocks can mean that while 17 is a good choice for me, 16 is better for other people.

    And about the placement of the PROGMEM keyword, I am under the impression that either placement results in the same code. Do you have evidence to the contrary?

    Thanks,

    Mikal


  29. Collin

    15 years ago

    Hello Mikal,

    Your library looks great!

    I`m using a Sanguino (Atmega644p) and when i compile i get the following error:

    E:\arduino-0021\arduino-0021\libraries\NewSoftSerial\NewSoftSerial.cpp: In member function ‘void NewSoftSerial::begin(long int)’:
    E:\arduino-0021\arduino-0021\libraries\NewSoftSerial\NewSoftSerial.cpp:410: error: ‘NULL’ was not declared in this scope
    E:\arduino-0021\arduino-0021\libraries\NewSoftSerial\NewSoftSerial.cpp: In member function ‘void NewSoftSerial::end()’:
    E:\arduino-0021\arduino-0021\libraries\NewSoftSerial\NewSoftSerial.cpp:428: error: ‘NULL’ was not declared in this scope

    When i compile it for an arduino is works fine.

    What do i need to change, to make it work for the 644?

    Thanks!

    ,Collin


  30. Mikal

    15 years ago

    Collin, yeah, NewSoftSerial doesn’t (yet) support the 644p. If the 644p supports pin change interrupts you could extend the #if block at the top of NewSoftSerial.h to support it. Go for it! :)

    M


  31. Anders

    15 years ago

    Wouldn’t it be better to have NewSoftSerial inherit from Stream instead of Print? That way code could be written to use either Serial or NewSoftSerial by just having a reference to a Stream class.


  32. Mikal

    15 years ago

    @Anders,

    You could certainly argue that, but many people don’t want the overhead of Stream in their project. And if you wanted a reference to a class that could be either Serial or NewSoftSerial, well, just make it a Print &.

    Mikal


  33. Jarvis

    15 years ago

    Are you actively working on the RTS/CTS solution? I’m working on a project, and am about to try implementing the RTS/CTS, but I’ll be doing it as a “hack” job I’m sure. So I just wanted to see if there’s something I can either help with, or if you’re close I would love to help test. I literally have till Monday night to get my solution working.

    Thanks,
    Jarvis


  34. Anders

    15 years ago

    @Mikal
    The overhead of the Stream class is negligible since it’s virtual. I changed the NewSoftSerial to inherit from Stream (about four lines of code difference) and testing with the NewSoftSerialTest example project the code gets 46 bytes bigger (4920 to 4966 bytes). Same result with the TwoNSSTest project.

    The problem with using the Print class is that it’s one-directional. If we want to be able to read() the Stream class is needed, and NewSoftSerial already implements the methods needed (just change available() to return an int).

    Anyways, thanks for your awesome contribution to the Arduino community! This class should be included with the IDE.


  35. kerbero

    15 years ago

    I´m trying to sync an Arduino FIO with XBee with the coordinator of my network. The code works as follows:

    1. A coordinator sends to arduino FIO its UNIX time.
    2. Arduino FIO receives the UNIX time of the server, process it and set the system time with setTime();

    The time is set correctly but the system allways reports the same time (calling to hour(), minute() and second() ). I am using newsoftwareserial to debug the information.

    example:

    11:17:58 2 12 2010
    11:17:58 2 12 2010
    11:17:58 2 12 2010
    11:17:58 2 12 2010
    11:17:58 2 12 2010



    11:17:58 2 12 2010

    It is possible that newSoftwareSerial disables the interrupts that works with the system time???


  36. Mikal

    15 years ago

    @kerbero,

    NewSoftSerial does indeed disable the interrupts that run the millis() counter, but only for very short durations. The practical effect is that occasionally a timer interrupt might be occasionally delayed, but not enough to affect the system time.

    EXCEPT that at very slow baud rates (300 or 1200 on a 16MHz processor) the bytes get so long that a second or third timer tick interrupt might arrive before an earlier one gets processed. This causes interrupt starvation and the result is that the system millis() clock appears to slow down. But I wouldn’t expect it to stop completely.

    What happens when you print the value of millis() instead of the system time? What baud rate are you running at? Is there anything else going on in the system?

    Mikal


  37. RobotGrrl

    15 years ago

    Has anyone had any troubles trying to go from NSS->NSS? It never seems to work for me, but if it is:
    UART->NSS
    or
    NSS->UART
    it works fine. Is it because the Arduino boards that I am using are of different sizes? Or speed?

    Just wondering! :)


  38. dullard

    15 years ago

    Mikal,

    Thanks for putting out useful tools such as NewSoftSerial.

    I know that you have the MEGA in the “upcoming improvements” section. How is that coming? I have a use for the MEGA that I can’t seem to get to communicate with equipment such as the Touchshield Slide. The best that I can figure out is to use NewSoftSerial to transmit data from the MEGA to the Touchshield, but I can’t seem to get data to be received from the Touchshield. If you want, see more comments here: http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1291762907


  39. Mikal

    15 years ago

    @dullard,

    I sent a beta copy of the new version to your email. Try it out!

    Mikal


  40. liudr

    15 years ago

    Mikal,

    Thanks a lot for writing this library. I am using it with your TinyGPS library on one project. It’s great to have it up and running in minimal time on my side:) I love all your reverse geocache stories too. I’ve told it to a bunch of people already.

    Here is a request for you: can you add an event handler on the newSoftSerial library so that when the buffer is full, an event handler is called.
    Like: nss.attach(&feedGPS);

    The reason to my request is that if I am running a GPS routine with other stuff, I have to feed the GPS constantly, making programming more difficult and less efficient. If I attach that feedGPS to the event handler of the newSoftSerial, then it automatically feeds the GPS so the GPS will be up to date if I read it any time. I can just call gps.getXXX() any time I need GPS information. Other times I can have arduino run an LCD and gather uer input and display proper information, not all of which are GPS-related.

    Liudr


  41. Kamilion

    15 years ago

    I’d like to have a look at that Mega beta as well. I’ve got a 2560, three fast serial devices, and two slow serial devices that I need to talk to.
    Love TinyGPS, gets along great with my Venus at 115.2K and 8Hz update rate.


  42. blalor

    15 years ago

    Hey, Mikal. I started to make some changes to your code in my GitHub project. I noticed that you started a GH project for NSS a couple of months ago, but haven’t added the code yet. I was hoping to create a fork, but couldn’t wait any longer. :-)

    I’ve implemented a few changes you might be interested in, including inheriting from Stream and adding peek(), peek(offset), and remove(offset) methods. The relevant commit is here: https://github.com/blalor/NewSoftSerial/commit/daab2811182b808d73d27e27ce7006d4c9ce14a6

    I’d appreciate your feedback!

    Thanks,
    Brian


  43. Mikal

    15 years ago

    liudr,

    This is a good suggestion and one that I have considered in the past. However, because NSS may be soon migrating to Arduino, I am a little reluctant to introduce new functionality at this point.

    Mikal


  44. Coofer Cat

    15 years ago

    Hi Mikal,

    Firstly, thank you for an excellent library, and article describing it.

    I’d like to ask if there’s a way I can ‘piggy back’ on the interrupts you use, or else use a separate interrupt. The reason I ask is that I’d like to add some simple networking to this (as a separate library). The idea being that you can send a message something like this:

    [dest][source][length][message][checksum]

    Obviously, to receive that string of characters requires a bit of careful state work, but it means you can send short messages reliably between devices (sort of like VirtualWire does). My plan is to have an interrupt constantly check the NewSoftSerial available() method, and then attempt to receive messages (into an RX buffer). The main loop() can then be checking networking.available() to see if actual messages were received.

    So… the thing is another layer of interrupt handling (for receiving). I could either use the same interrupt (so long as I write very efficient code), or else use another (lower priority?) interrupt. What do you think my chances are? ;-)

6 Trackbacks For This Post
  1. Moving Forward with Arduino – Chapter 17 – GPS « t r o n i x s t u f f

    […] devices. At this point you will need to install two libraries into the Arduino software – NewSoftSerial and TinyGPS. Extract the folders into the libraries folder within your arduino-001x […]

  2. Moving Forward with Arduino – Chapter 17 – GPS « Hey it’s my blog…

    […] this point you will need to install two libraries into the Arduino software – NewSoftSerial and TinyGPS. Extract the folders into the librariesfolder within […]

  3. Sonar | Starter Kit

    […] there is one more library – “NewSoftSerial”, which is free of these defects and, in addidion, handles inverted serial […]

  4. Advanced RFID with Arduino and Python! | App Delegate Inc

    […] NewSoftSerial […]

  5. RFID Door Opener – Update 3 – LCD Woes - Sommineer

    […] one on some other pins.  Per the suggestion of some people on the Arduino forums, I decided to use NewSoftSerial to do the communication.  Being interrupt driven, it was much more efficient than the older […]

  6. keyHelper final project

    […] the code you will need a very useful NewSoftSerial library, that, among other things, allows you to assign TX and RX on other pins then 0 and 1 and that way […]

Leave a Reply