Oak and Servos - Hacked/Fixed! (see comments below)

[ripred]

Now that the beta firmware issues are starting to settle down and I can upload sketches to the board I am beginning to attempt making something useful.  One of the thoughts I had about using these Oaks was as a wireless way to control an air-flow damper for the eventual hope of being able to close off the AC/heat registers in various rooms of my house when no one is in them, giving more heat to the rooms that actually have people in them.

My first attempt was just to try the standard servo way.  I #included <Servo.h> but when I compiled I got several warnings and errors that the standard Servo library might not be compatible with this board/architecture.  The output also mentioned that the "/Users/trent/Arduino15/packages/digistump/hardware/oak/0.9.2/libraries/Servo" library was one of the available choices but it was NOT used.  Seeing this I attempted to #include "/Users/trent/Arduino15/packages/digistump/hardware/oak/0.9.2/libraries/Servo/src/Servo.h" which seemed to compile fine.  In order to use the correct Servo.cpp I tried to just included the .cpp file at the top of my test.ino file.  That resulted in a lot of undefined references and conflicts.

I then tried bit-banging my own signal via digital output 5, using micros() as a timing mechanism for the duty cycle.  This ultimately ended up bricking my Oak and I had to do a serial restore to get it back and responding to uploads.   Sooooo...

My question is, how do I make use of the Oak-specific Servo library?  This is on Mac OS X in case that matters.  Any help would be greatly appreciated.

[digistump]

Servo library is on the short list of things to get working - track this github issue for updates: https://github.com/digistump/OakCore/issues/9

[ripred]

Thanks Erik,

I thought perhaps that was what that issue referred to.  Would it just be a simple matter of renaming the class to something unique and then working on it like it was a standard custom class like I would develop myself?  If so I could give it a go..

[digistump]

That might do it - or removing the Arduino servo library to ensure it isn't conflicting - not exactly sure why its not including that as it should prefer the library in the currently selected board's core - this is likely more of an Arduino IDE issue than a code issue, and I'll have to dive into the magic black box of the IDE to figure out whats going on there

[ripred]

With the original Arduino Libraries Servo folder renamed it does correctly resolve to the esp8266 version of Servo, however it seems to be running into 'min' and 'max' being undefined during the time it is trying to compile the esp8266 version of Servo.cpp for what it's worth.  Hopefully that's a clue for you.  I tried #including various files in Servo.cpp but didn't get anywhere productive.

[digistump]

Thanks that's a great clue - I will work on getting that fixed in the next release

[ripred]

Hey Erik, one last clue:  Since I couldn't get anywhere I created two local functions inside Servo.cpp called:

int getmin(int x, int y);
int getmax(int x, int y);

and modified the esp8266 version of Servo.cpp to use those instead of the existing use of min and max.  Everything compiled cleanly and I have a servo working on an Oak.

So it looks like it's only the definitions of min and max during the compile of Servo.cpp that are in the way.  Hope that Helps!

Trent