I found it strange that if you set a pin high and the deploy another project that does not change the state of that pin, that pin remains high. I do not recall observing this behavior before. It could potentially lead to some unexpected behavior/results.
To replicate it on Cobra II:
- Create two empty Gadgeteer projects simultaneously.
- In one project add the following line:
3. Deploy that project and stop debugging.
4. Deploy the second empty Gadgeteer project.
LED will be still on and I expect it to be either off or weakly pulled-up high.
The same happens if you use for example LED on Button module or if you use bare NETMF.
So, is it a bug or "an expected behavior"?
Are you sure second project was deployed and not the first one? Try it from two different VS instances each holding just one project.
Yes, I am pretty sure, I have 6 instances of VS running right now.
@ iamin - I imagine if you reset the board the pin is no longer driven?
@ iamin - Since we do not explicitly set all pins to a state on startup, they default to inputs on board startup, and Visual Studio does not do a full reset of the board, GPIO state carries over.
Was it behaving this way all the time? I have not noticed it till recently.
Can you do anything on your side to force mainboard to reset each time the code is deployed? If not, I would suggest making a note about this behavior somewhere (preferably in mainboard manuals) as it is a definite trap for young players.
@ iamin - I believe it has been. I’ve noticed it a few times myself. I do not think we can force the board to do a reset, but we might be able to reset the GPIO to the default state. It’s something we will look into.
@ John - I see. Just a note: the 1st and the 3rd port on Cobra II are not affected by this issue.