I'm running the Test service which whips the auto-magic elves into looking in every nook & cranny for little bugs. They found lots hiding in AdafruitMotorShield.
I don't think its worked for years :P
It relied on code being "injected" into MrlComm before being compiled and uploaded. It also required the AdafruitMotorShield library to be included/compiled into the upload.
So how to get AdafruitMotorShield worky ?
- port the library into MrlComm - even if successfully ported, I suspect it would be very difficult to make it "generalized"
- wrap the library as a new MrlCommAdafruitMotor.cpp and add new methods to arduino.schema
- retire this shield - remove it so people don't get confused about this currently unsupported shield
- do nothing
The "wrap library" probably would work, but it also means the Adafruit library is dragged into every MrlComm compile and upload, even if the user doesn't want it (wasted space)
Ok, any preferences or ideas mates ?
Hmm .. library consists of a
Hmm .. library consists of a single class - https://github.com/adafruit/Adafruit-Motor-Shield-library/zipball/master
And that is certainly nice.
So MrlAdafruitMotor wrapper is starting to appear a little more desirable ....
may we never forget
So, this is too much of a depricated pieceof hardware to consider fully supporting, especially seeing that the newer versions are i2c...
hate to say it.. but to davy jones locker with it...
Let us always remember that as we want to integrate new arduino device support, we will need to think about pulling in additional libraries into mrlcomm. That means if we want to support new hardware for the arduino, it's on us to ensure the integration between arduino & the new hardware.
as we lay this device to rest, let us look forward to better support for arduino shields of the future...