MaxO module set all pins true


i got my MaxO.
I soldered pins to it for better prototyping. To test if i’m a got solderer :slight_smile: i want to set all pins to true.

i use WriteArray but not all pins are true. I tested each byte with 0xFF and 0xF.
If i write pin to true all pins ok.

here is my code:

maxO.NumBoards = 1;
byte[] arr = new byte[] { 0xF, 0xF, 0xF, 0xF };

What are the actual “displayed” settings when you use 0xF? 0xF is actually 0x0F, right, so all things considered I would expect the 00001111 pattern. Is that what you see?

Oh sorry, the code was from my second try :slight_smile:
i tried it with 0xFF whats standing for 11111111 each byte, right?
But my maxO is writing 00000000 00000000 00001110 00000000… crazy.

if i WritePin each pin its working.

yep, crazy. Sorry, I don’t have MaxO so I can’t really test for you. Someone who also has one will need to pipe up I think, or we could crack open the driver for a lookee… Codeplex here I come (while waiting for Simon Monk’s Gadgeteer webcast to start)

4.1 or 4.2 project? I’m looking in 4.2 at the moment

4.2 (use cerberus).
Oh yeah webcast …

Thanks a lot!
Greets from Germany

What is not making any sense to me is that the code literally manages a private byte array that is a copy of what is sent. If you use WritePin(), you end up affecting the private byte array, which then gets written using the WriteArray method anyway. So I can’t imagine a scenario where WriteArray is not doing the right thing but WritePin is (although I haven’t stepped in through the logic WritePin uses to manipulate the specific byte). Can you grab the code and try stepping into it and seeing what the array looks like just before the SPI write?

We have discovered the bug in the driver and it will be corrected for the next SDK. The issue was that the values were being inverted (negated) instead of their order being inverted.