I was trying to get the Bluetooth demo up and going, and the compiler choked on the inclusion of SoftwareSerial.h, as in it apparently couldn't find it. The documentation with the demo implied that it was part of the Arduino core libraries, but a search of them turned up nothing. Does anyone know where I can get this, and presumably the .cpp file that goes with it?
UPDATE: I did fine the SoftwareSerial subdir in the Arduino/libraries dir, but it isn't showing up on the list in the Sketch -> Import Library... menu item. Note that I am using the DUE and thus the 1.5.x of the Arduino compiler -- this is something related to that version?
Any help needed, as my project, a demo for investors, has only the Bluetooth part to be done to have it finished. Thanks in advance.
Yes, I had already come to that realization. Most fortunately, Serial1 did cooperate, and the Bluetooth board, as physically designed, did make it easy to jumper wire this option in.
Most unfortunate that SoftwareSerial was not seen fit to support on the Due, and I personally don't see why this exclusion.
Beyond little use, typically because of three superior hardware serial ports there is the known bug (AVR) where SoftwareSerial can miss characters. It's a poor workaround that gave me fits several years ago in trying to use a GPS receiver on an Uno due as I remember to checksum errors.
About a year ago, I wrote a alternative library, called AltSoftSerial.
AltSoftSerial solves these problems with concurrent data streams by using a timer's input capture unit to receive the data, include of busy looping inside an interrupt, and the timer's output compare units to transmit, rather than busy looping with interrupts disabled. It can even tolerate a significant amount of interrupt latency imposed by other libraries without losing timing accuracy.
However, it does use up one of the 16 bit timers, which are in short supply. You can only use the specific pins that timer supports.
Oh, and it also only works on AVR. But maybe someone could port it to Due? Due's timers appear to have 2 signals that can be either capture or compare, so the necessary hardware is present, and the timers are 32 bits instead of 16, so the prescaler probably isn't even needed for the entire range of useful baud rates.