I am not sure yet what the best way to go is.
Personally I prefer with simple solution of using the standard SoftwareSerial class, such that in theory it will work with different platforms. It should then also work with both Hardware or Software.
My preference is the best solution that works on all platforms. If this requires forking the Orion libraries and continuing on from there, that is absolutely OK with me. I want a solution that can be easily expanded to work on other future platforms. I tire of proprietary solutions, even if I do have the source code.
But the rub is on their own Robots. They have their own Arduino 328 based board. They also use their own version of Playstation 2 controller that uses a serial protocol at 38400 on one IO pin. They do their own version of half duplex, which he added to BMSerial. So for this device probably need their library and you can not have both libraries in your sketch as they both want to define ISR handlers for every possible interrupt...
If I want to get an Orion Robotics robot platform, I'll use their hardware and software. Beyond that, I don't have any aversion to forking their code and creating something more cross platform, even if it doesn't work on
their robots. Orion has the code that works best here. I have one of Lynxmotion's PS2 wireless controllers here, and I'd like to eventually be able to use that on W.A.L.T.E.R.
So if we go with BMSerial, probably still won't work for their PS2. I might try this out soon. May have to either update their serial to act like your version of SoftwareSerial and/or add tables for the different CPU speeds.
Let's please not worry too much anymore about how things may or may not work on the Orion robots. We need something that works for
us, on
our chosen platforms.
Orion has created some great robot platforms, and they have their own hardware and software that works best for those. Ideally, we'd have a solution that encompasses all platforms, including those from Orion - this would be my first preference.
Actually personally, I would probably prefer to update RoboClaw class some more. Instead of being derived from SoftwareSerial or BMSerial, have it be derived from Stream. Then on either it's constructor or Init/Begin function, pass in a pointer to the actual Stream object (&Serial2 or &MySoftwareSerial or ...). Have everything inherit from default lower class and have low level Read/write functions, which forward to the actual object... This way we don't have to decide... But I am not the owner of this library.
I prefer the constructor route for this. We just have to have more than one constructor, which is fine. We might even be able to do what we want to do within the RoboClaw library by overloading functions where necessary for different platforms or using if..#else..#endif blocks, if we must.
Will try to get Nathan's input on this. As the Roboclaws are one of their biggest sellers, they may be interested in helping out.
It would be great if Nathan would be willing to help out on this. It could give him a wider audience for his motor controllers, which would be great for him. We could gain the ability to use his products easier on multiple platforms. That sure looks like a win-win all the way around to me.
I bought the RoboClaw 2x5 Motor Controller because it has features (handles motor encoders, etc) way above what I could get by using a Sabertooth 2x5. I was a bit leary with this choice, because I know how Basic Micro/Orion can be when they write software to support their products. I'm
very happy to see they have become more open, at least in some areas, and I hope this is a trend that continues.
8-Dale