allanonmage:
In this case it just appeared to not be executing when it actuality it was; without proper conditional logic another function was just writing all over it and it was looping fast enough that it appeared to not work. The dim LED was somewhat of a clue, albeit it too faint for me to pick up on.
Yes, that can happen. If possible, use a logic analyzer or oscilloscope to check whether an output is on all the time or switching on and off rapidly.
allanonmage:
Is it not a good idea to use this library? Or does this fall under the fact that if it doesn't work normally it won't work optimized?
I'm suggesting that you were flying off on a tangent here. The problem was not with digitalWrite.
allanonmage:
I'm not trying to be rude, but I'm going to be blunt here: it's in the OP. In a code block labeled "Here's the test code I'm working on:"
Sorry. I acknowledged that in my next post.
allanonmage:
Someone once said that you can't actually debug your own code because if you're not capable enough to see the problem, you can't see it. Or something like that. It was smart & deep. Anyways, I thought I had double and triple checked my code at that point, which is why I started to wonder about other things.
I understand, but it would have been good to make a test case with a half-dozen lines of code that simply turned pins on and off in quick succession. That would prove/disprove your theory about timing. Once you establish that the processor can, in fact, turn pins on and off quickly you might have looked more closely at the surrounding logic.