Pages: [1]   Go Down
Author Topic: SoftwareSerial and HardwareSerial common superclass  (Read 1147 times)
0 Members and 1 Guest are viewing this topic.
Offline Offline
Newbie
*
Karma: 0
Posts: 4
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

I'm writing a library and I'd like it work with either a SoftwareSerial object or HardwareSerial (the "Serial" object).  By clearing the constructor in my library to take a Stream, I can get most of the way there. 

However, I can't call stream.begin(4800) in my library because Stream doesn't have such a begin method, and the two serial classes don't have a common superclass or interface that defines a begin method.

Is there something I'm missing?  If not, it would help in expanding use of SoftwareSerial if there were a common class that could be used.

Leigh.

Logged

France
Offline Offline
God Member
*****
Karma: 11
Posts: 637
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Please check the proxySerial library: it can handle hardware, software and I2C serial ports.

See here and there for documentation, examples, tutorial and code!
Logged


Central MN, USA
Offline Offline
Tesla Member
***
Karma: 72
Posts: 7171
Phi_prompt, phi_interfaces, phi-2 shields, phi-panels
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

However, I can't call stream.begin(4800) in my library because Stream doesn't have such a begin method, and the two serial classes don't have a common superclass or interface that defines a begin method.

Alternative to avenue33's suggestion, what I did with my phi_interfaces library is to REQUIRE a Stream object that has already begun. There is no standard method to begin or end a serial port or I2C interface under Stream. The user will do the begin of whatever port and pass your library the address to the Stream object that has begun smiley
Logged


Offline Offline
Newbie
*
Karma: 0
Posts: 4
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Thank you, all. I am already using the caller-callers-begin() method, so I guess I'll stick with that. I hadn't considered the difficulties of extending to I2C.
Logged

Pages: [1]   Go Up
Jump to: