Interesting, I see it's not working out of the box with maniacbug-mighty-1284p
__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
__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.
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.
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:
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:
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.
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.
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!
...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.
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.
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.
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.