An alternative Serial Library for Arduino 1.0

Interesting, I see it's not working out of the box with maniacbug-mighty-1284p :grin:

__vector_20 is USART0_RX_vect. The 1284P defines the USART0 vectors, HardwareSerial picks them up. Shouldn't this also have the same problem on a Mega?

Looks like this library is demanding access to the USART0_RX_vect?

maniacbug:
Interesting, I see it's not working out of the box with maniacbug-mighty-1284p :grin:

__vector_20 is USART0_RX_vect. The 1284P defines the USART0 vectors, HardwareSerial picks them up. Shouldn't this also have the same problem on a Mega?

Looks like this library is demanding access to the USART0_RX_vect?

Oh? I was able to build a few of the examples that came with this library using your cores. I had suspected it was a core issue, but after I was able to build the examples I assumed it must be my code.

If I remove the HardwareSerial.cpp file, then the compilation fails. Its getting dragged in somewhere.

Hmm, I mis-spoke. As you say, examples compile fine on mighty-1284p.

What's happening is that the LINKER wants to include these symbols from HardwareSerial. There's no avoiding the compiler picking them up.

It would be interesting to see the errors you get when removing HardwareSerial.cpp.

A number of libraries access Serial. This causes HardwareSerial to be loaded even if you don't call the functions that access Serial. These libraries can't be used with SerialPort.

All released SD.h and SdFat libraries cause HardwareSerial to be loaded and can't be used with SerialPort. I will soon release a version of SdFat that does not access HardwareSerial.

A beta version of this SdFat is in SerialLoggerBeta20120108.zip here Google Code Archive - Long-term storage for Google Code Project Hosting..

fat16lib:
A beta version of this SdFat is in SerialLoggerBeta20120108.zip here Google Code Archive - Long-term storage for Google Code Project Hosting..

Okay, when I use that beta I can link if I remove another library from my system. I was taking a look to see how I might be able to modify that library, and I looked into your headers and saw that in sdFatUtil.h:

#include <avr/pgmspace.h>
#if ARDUINO < 100
#include <WProgram.h>
#else  // ARDUINO
#include <Arduino.h>
#endif  // ARDUINO

WProgram.h brings in:

#include "HardwareSerial.h"

But my app includes that header.

How did you resolve this conflict?

I played around with this when the library was first posted, trying to understand how it all worked.

The problem is not including HardwareSerial.h but using Serial, Serial1 etc.

The first time you call Serial.begin() you will pull in all the code in HardwareSerial. If you reference a library that calls Serial.print() etc you will also pull in the HardwareSerial code.

If it's your library that's causing the problem, the easiest fix is to add a variable to your library:

Stream* activeSerialPort;

and initialise it in setup()

#include <MyLib.h>

void setup()
{
  Serial.begin(115200);
  activeSerialPort = &Serial;
}

or if you switch to SerialPort:

#include <MyLib.h>
#include <SerialPort.h>

SerialPort<0, 64, 64> serialPort;

void setup()
{
  serialPort.begin(115200);
  activeSerialPort = &serialPort;
}

HardwareSerial and SerialPort inherit from Stream, so it just works. Remember that any calls in your library will change from Serial.print() to activeSerialPort->print() etc.

Hope that helps.

Iain

Thanks Lain, but nowhere in my code am I using Serial or Serial1 any longer. I found the library that I need to exclude to "fix" the problem, but I can't see anywhere in that library where Serial or Serial1 is being used either. I sent a note to the author of the other library, perhaps he will have an idea.

Thanks again.

Ah! I take it back, thanks sixeyes! That other library had a diagnostic function that was in fact using Serial. I commented it out, and all is good now, thanks! With any luck, the new SD Beta Library will work well and I'll be off to the races!

From looking at the code, it does not appear that the buffer sizes are restricted t powers of 2. Is that correct?

Correct. See post #40 in this thread for confirmation. Would have posted a link but I don't know how to link to a specific message.

Iain

Reply #40...

...next to "Reply #" there is a message icon. It is a link to that message. On this message it is an exclamation mark. The title over each message is also a link to that message.

Thanks for the tutorial. Most helpful.

Iain

fat16lib:
A number of libraries access Serial. This causes HardwareSerial to be loaded even if you don't call the functions that access Serial. These libraries can't be used with SerialPort.

All released SD.h and SdFat libraries cause HardwareSerial to be loaded and can't be used with SerialPort. I will soon release a version of SdFat that does not access HardwareSerial.

A beta version of this SdFat is in SerialLoggerBeta20120108.zip here Google Code Archive - Long-term storage for Google Code Project Hosting..

Hi...

I was just wondering if there is an update to this beta?

Hi All...

I noticed some interesting behavior from this beta SD library.

After running bench, the L LED (attached to the SCK line on my board, like an original Uno) remains lit. If I then set the pinMode to output and try to manually turn that led on or off, it just stays on.

Any ideas?

skyjumper:

fat16lib:
A number of libraries access Serial. This causes HardwareSerial to be loaded even if you don't call the functions that access Serial. These libraries can't be used with SerialPort.

All released SD.h and SdFat libraries cause HardwareSerial to be loaded and can't be used with SerialPort. I will soon release a version of SdFat that does not access HardwareSerial.

A beta version of this SdFat is in SerialLoggerBeta20120108.zip here Google Code Archive - Long-term storage for Google Code Project Hosting..

Hi...

I was just wondering if there is an update to this beta?

Never mind, this has been traced to a hardware error.

Would you consider a different design?
Or is compatibility with previous API more important than versatility?

I find the monolithic approach to these 'libraries' really restricting.

Just curious.

I find the monolithic approach to these 'libraries' really restricting.

Define the API you want and say why you need it.

Are there optimizations here that we should be incorporating into the default Serial library? If so, please open a Google Code issue for them so I know to incorporate them.

I have posted an update for this library as SerialPort20130222.zip Google Code Archive - Long-term storage for Google Code Project Hosting..

A fast Serial port to SD logging sketch is included. This sketch can log Serial data at up to 115200 baud.