MaxO module - Bug in WritePin

Hi ,

Testdriving the MaxO Module on my Spider was fun. Not much on the fora as of yet, so i had to learn as i got along.

During my experimenting,I discovered a few things, that the next person to start off with the MaxO can use as a starter.
I also found , what appears to be a little BUG in the DLL. When using the WritePin command, pins no 8,16,24 and 32 do not respond to the function.
I looked into the source, and sadly it goes a little beond my knowledge of bitshifting and bit manipulating… but i DID find that the WritePin also uses the
WriteArray Function, and that workes fins, so the error is most probably in the WritPin Function.

I ran some teste and found that when pins 1-7 are passed as _pin parameter, the Byte that is written when the register contained 00000000 is 1,3,7,15,31,63,127 (and that works), but when _pin is 8, (it should set the byte to 254 in this case), the byte is set to 0… (and that goes the same for each byte…
Maybe one of you BitWise men or women can look at the code and change it for e next release…

OK. from what i DID get to work i learnt a few facts that i wish to share for other newbies that might want to start off with the maxO board. I sure am goint to order a few more boards, as i have some ideas where i would need about 100 pins…

  1. Using the Gadgeteer DLL, you have a nice set of functions to make things “easy” ish.
    you have to start by telling the Spider how many board you have chained… maxO.NumBoars=1 (in my case)
    next you have to Enable the outputs… maxO.EnableOutputs();
    then you can either write a complete register (all the pins as bits in an array of bytes (4 bytes per board).
    or change ONE pin…WritePin(board,Pin,position)

  2. The register bytes start counting from the last board & last Pin… That has to do with the LSB being to the right of the board(s)

  3. When an Enablecommand is sent, All Pins will be set HIGH (3.3v)
    sending maxO.WritePin(1,3,false); will switch OFF (set to LOW) pin 3 from the left…
    (exept for pins 8,16,24 and 32, because of a bug, but i Expect that to be solved shortly…



We are about to add tutorials for every single model. We will clarify the pin count and check if there is an error.

I quickly changed the WritePin method to better reflect what I thought should be correct (and what I will use going forward). I’m not a bitwise guy whatsoever, but just from what I believe the counting scheme should be, I switched the bitwise OR and bitwise AND complement. I also changed the blockPos variable because I believe the bytes should start counting from the right, not from the left.

        public void WritePin(int _board, int _pin, bool _value)
            if (!reSized)
                throw new Exception("No boards have been initialized! Please indicate how many modules are chained before writing");

            // check to see if the pin is inside our range
            int length = ((_board) * 4);// +_pin;
            int position = ((_board - 1) * 4) + _pin;

            if (length > data.Length)
                throw new Exception("Invalid pin position. Pin out of range");

            // make a "dummy" to turn our pin on or off
            byte[] dummy = new byte[data.Length];

            Array.Copy(data, dummy, data.Length);

            // find exact bit position
            int blockPos = ((_board - 1) * 4) + (_pin / 8);
            if (_value)
                dummy[blockPos] = (byte)(data[blockPos] | (1 << ((_pin % 8) - 1)));
                dummy[blockPos] = (byte)(data[blockPos] & ~(1 << ((_pin % 8) - 1)));

This way, if _value is true, then that pin is set to 1, and if _value is false, then it is 0.

1 Like


I installed about a month ago v4.2 and WritePin is not working, yes WriteArray
Is there any way GHI may update so WritePin works ? it makes much easier in order to modify a bit status, instead of modifying a full array


What version of the SDK do you have? There was one released around 14th Feb IIRC. Do you have it?

The bugs mentioned in the posts by @ Berto62, @ Maelstrom, and @ xadogi were fixed and will be in the next SDK.