I’m currently observing a very strange behaviour on a MaxO.
I wrote a small program that keeps a counter, and each time the mainboard button is pressed it turns on the MaxO output (LED in my case) corresponing to the counter value and increases the counter (modulo 32).
What I am observing, given counter values, is:
counter 0: LED 0 is on
counter 1: LED 1 and LED 24 are on
2: 2+25
3: 3+26
4: 4+27
5: 5+28
6…23: working as expected
24…31: nothing happens
First thought: WTF.
What could possibly go wrong here? Was it just bad luck and I got a broken module???
I checkes the cables about ten times and also observed the same behaviour using a volt meter directly at the output pins.
Can you please show got code?
Yes, of course. I wanted to include it in the main post and forgot. Here you are:
using Gadgeteer.Modules.GHIElectronics;
using Gadgeteer.Modules.Mountaineer;
using Microsoft.SPOT;
namespace MaxOCounter {
public partial class Program {
private MaxO _maxO;
private ButtonForMountaineer _button;
private int _index;
void ProgramStarted() {
Debug.Print("Program Started");
_maxO = new MaxO(5);
_maxO.NumBoards = 1;
_button = new ButtonForMountaineer();
_button.ButtonPressed += (s, e) => ButtonPressed();
}
void ButtonPressed() {
Debug.Print(_index.ToString());
var byteIndex = _index >> 3;
var bitIndex = _index & 0x7;
var mask = (byte)(1 << bitIndex);
var buffer = new byte[4];
buffer[byteIndex] = mask;
_maxO.WriteArray(buffer);
_index = (_index + 1) % 32;
}
}
}
I had strange effects with a much larger program. I wrote this specifically to debug the issue.
Looks about right. Can you try a hardcoded value?
Something like this:
{ 0x02, 0x00, 0x00, 0x00 }
That way there is nothing that is calculated.
1 Like
using Gadgeteer.Modules.GHIElectronics;
using Gadgeteer.Modules.Mountaineer;
using Microsoft.SPOT;
namespace MaxOCounter {
public partial class Program {
private MaxO _maxO;
private ButtonForMountaineer _button;
private int _index;
void ProgramStarted() {
Debug.Print("Program Started");
_maxO = new MaxO(5);
_maxO.NumBoards = 1;
_button = new ButtonForMountaineer();
_button.ButtonPressed += (s, e) => ButtonPressed();
}
void ButtonPressed() {
var buffer = new byte[] { 0x02, 0x00, 0x00, 0x00 };
_maxO.WriteArray(buffer);
}
}
}
When I reset the mainboard and press the button, only LED 1 is lighting up - conforming to the bytes we send to the device.
And now comes the interesting part: When I press the button [em]again[/em], LED 25 is [em]also[/em] lighting up!
After some more tests, I have a hint of an idea what might be happening here. When there is a call to WriteArray, the MaxO seems to copy the first 5 bits of byte 0 to the first 5 bits of byte 3, before setting the other bytes. Additionally, LEDS 29-31 seem to never light up. This copying of bits of the old state is [em]consistent with every wrong behaviour I observed[/em].
I ported the MaxO C# code to NETMF 4.3 before all those tests. I don’t think that I messed it up at that part, there were few compiler errors related to creating Spi and DigitalOutput directly, which I resolved using the factories. I am reluctant to downgrade to NETMF 4.2 again, but if you are going to tell me that I should try it then I’ll probably give it a shot…
I would get MaxO driver code and would try to fix it that way.
What exactly do you mean with “driver code”? I swept through the Gadgeteer sources, thats where I found the 4.2 version of the MaxO C# code. So I migrated it to 4.3 and had a close look at it as well. Some of it is a bit overly complex in my taste, but concerning correctness everything feels exactly right. I currently have no Idea where to search further.
Yes you got the driver. I’ll take a look when get home.
I would try to run the same program on a 4.2 board using the driver that comes with our SDK and see if the problem remains.
@ John: At tne moment I don’t have the means to downgrade to 4.2. Upgrading was easy, downgrading does not seem to be
Meanwhile, I found a solution to my Problem. I inlined the MaxO “driver” code into my program, reduced it to the bare minimum and tried some things. I observed that when I pad the array that is send to MaxO with an extra leading 0x00 then everything works as expected.
using Gadgeteer;
using Gadgeteer.Modules;
using Gadgeteer.Modules.Mountaineer;
using Gadgeteer.SocketInterfaces;
using Microsoft.SPOT;
namespace MaxOCounter {
public partial class Program {
private ButtonForMountaineer _button;
private DigitalOutput _enable;
private Spi _spi;
private SpiConfiguration _config;
private Module _module;
private DigitalOutput _clr;
private int _index;
class MyModule : Module { public MyModule() { } }
void ProgramStarted() {
Debug.Print("Program Started");
_module = new MyModule();
Socket socket = Socket.GetSocket(2, true, _module, null);
socket.EnsureTypeIsSupported('S', _module);
_config = new SpiConfiguration(false, 0, 0, false, true, 1000);
_spi = SpiFactory.Create(socket, _config, SpiSharing.Shared, socket, Socket.Pin.Five, _module);
_enable = DigitalOutputFactory.Create(socket, Socket.Pin.Three, false, _module);
_clr = DigitalOutputFactory.Create(socket, Socket.Pin.Four, true, _module);
_button = new ButtonForMountaineer();
_button.ButtonPressed += (s, e) => ButtonPressed();
}
void ButtonPressed() {
Debug.Print(_index.ToString());
var byteIndex = _index >> 3;
var bitIndex = _index & 0x7;
var mask = (byte)(1 << bitIndex);
var buffer = new byte[5]; // resize this to 4 yields the bug
// SPI's output bytes are reversed
buffer[buffer.Length - 1 - byteIndex] = mask;
_enable.Write(true);
_spi.Write(buffer);
_enable.Write(false);
_index = (_index + 1) % 32;
}
}
}
GHI, please have a look into this and test MaxO usin 4.3. I am reluctant to believe that I just received an ill-functioning one.