Some odd things on Cerbuino

Bec_a_Fuel · July 14, 2012, 4:36am

I’m trying to see why the Keypad 3x4 driver ( http://www.tinyclr.com/forum/topic?id=7877 ) is performing well only on socket 3 of the Cerbuino board. On sockets 1 & 2, there’s no keypad event generated

What I’ve done to check is to connect a Phidget interface kit board, which permits me to see and act on various I/Os.

So, I’ve connected the 4 “outputs” and the 3 “inputs” needed by the keypad on the corresponding places on the Phidget board and ran the following program :

void ProgramStarted()
        {
            Cpu.Pin P3 = GT.Socket.GetSocket(1, true, null, null).CpuPins[3];
            Cpu.Pin P4 = GT.Socket.GetSocket(1, true, null, null).CpuPins[4];
            Cpu.Pin P5 = GT.Socket.GetSocket(1, true, null, null).CpuPins[5];
            Cpu.Pin P6 = GT.Socket.GetSocket(1, true, null, null).CpuPins[6];

            OutputPort Port1 = new OutputPort(P3, false);
            OutputPort Port2 = new OutputPort(P4, false);
            OutputPort Port3 = new OutputPort(P5, false);
            OutputPort Port4 = new OutputPort(P6, false);
            while (true)
            {
                Thread.Sleep(500);
                Port1.Write(true);
                Port2.Write(true);
                Port3.Write(true);
                Port4.Write(true);
                Thread.Sleep(500);
                Port1.Write(false);
                Port2.Write(false);
                Port3.Write(false);
                Port4.Write(false);
            }

Goal was to see if all inputs/outputs were reacting as expected. The code snippet doesn’t show inputs because the test was ok and so there’s nothing more to say about them.

Which is not the case for output ports… I’ve run this programm 3 times, each time changing the socket number, from 1 to 3. Here are the results :
Socket 1 : type PSUY
[ul]pins 3 & 4 : blink immediately
pins 5 & 6 : low then stay high[/ul]

Socket 2 : type AIKUY
[ul]pins 3 & 4 : blink immediately
pins 5 & 6 : low then stay high[/ul]

Socket 3 : type AOPY
[ul]pins 3 & 4 : blink immediately
pin 5 : low then stays high
pin 6 : low, then stays high for some time, then blinks as expected (but doesn’t seem to be as accurate timing as pin 3 & 4, though)[/ul]

See this video for socket 2 : http://www.lsp-fr.com/FEZ/cerbuino.mpg

As more or less expected, sockets 1 & 2 do seem to behave differently than socket 3. But it’s not enough to conclude, since I was expecting all four pins to blink, even on socket 3 !
At the beginning, I was thinking that maybe the “U” type may cause problem because both socket 1 & 2 have it, but even if it’s the case, it doesn’t explain why all the pins are not blinking on socket 3…

Right now, I still don’t know what to think about this because what I’ve seen here is not what I was expecting. At least on socket 3

The day will be long, today…

[em]EDIT[/em]
Here’s the same program running on socket 7 of the Hydra : http://www.lsp-fr.com/FEZ/hydra.mpg
As you can see, it’s fine, as all pins are blinking.

Bec_a_Fuel · July 14, 2012, 5:55am

Well… how could I say that without being seen as an idiot ?..

The Phidget board I use is given for : High Voltage Min 3.8 VDC. Ahem… kof…

If I plug a voltmeter instead of the Phidget board and run the same program as above, then I can see all of the output ports “blinking” from 0 to 3,3V, as expected.

So, new conclusion is : back to the beginning
But with some important information : hardware is working properly and it seems (I’m careful, here ) that it’s only software related. Which is a good news, I think.

Brett · July 14, 2012, 7:23am

Hey BecA,

remember that you should make sure ProgramStarted() actually is allowed to terminate, don’t put it in a while() loop. http://blogs.msdn.com/b/net_gadgeteer/archive/2011/12/19/why-not-while-true.aspx

May not be relevant to your situation, but not necessarily a good test

Bec_a_Fuel · July 14, 2012, 8:30am

Hi Brett,

you’re right, about the ProgramStarted() thing. I don’t think it matters here but I’ve modified my test program to be sure I’m doing things correctly. Now it starts a new thread containing the while loop.

But still there are some strange behaviours…

I’m currently trying to read only the first row of keys (1, 2 & 3). So, I put the Pin 3 high and then read Pins 7 to 9. And here I have different results and different behaviours on different sockets

Test program is quite simple :

Port3.Write(true);
            while (true)
            {
                Debug.Print("Pin 7 : " + Port7.Read());
                Debug.Print("Pin 8 : " + Port8.Read());
                Debug.Print("Pin 9 : " + Port9.Read());
                Debug.Print("====");
            }

I have put a pulldown resistors network to ensure that the inputs are indeed pulled down.

Results on socket 1 :

at startup, no key pressed : false, false, false
key “1” pressed : true, false, false
key “1” released : true, false , false
key “2” pressed : true, true, false
key “2” released : false, false , false
key “3” pressed : true, false, true
key “3” released : true, false , false

Results on socket 2 :

at startup, no key pressed : false, true, true
key “1” pressed : true, true, true
key “1” released : false, true, true
key “2” pressed : no change
key “2” released : no change
key “3” pressed : no change
key “3” released : no change

Results on socket 3 :

at startup, no key pressed : false, false, false
key “1” pressed : true, false, false
key “1” released : false, false, false
key “2” pressed : false, true, false
key “2” released : false, false, false
key “3” pressed : false, false, true
key “3” released : false, false, false

As you can see, only socket 3 behaves correctly !

Gus_Issa · July 14, 2012, 10:10am

Can you take the keypad out of the picture and give us a simple test showing the problem please?

RorschachUK · July 14, 2012, 10:16am

Hi, I’ve just been playing with this codeshare code, I’ve got a slightly different keypad (from Sparkfun [link]) but operates on the same principle, and have connected it to Cerbuino on Arduino header pins D0-D6 instead of using sockets, I added an additional pin-oriented constructor, and works great on all keys.


        public Keypad3x4(Cpu.Pin col1, Cpu.Pin col2, Cpu.Pin col3, Cpu.Pin row1, Cpu.Pin row2, Cpu.Pin row3, Cpu.Pin row4)
        {
            // set up the matrix
            Rows[0] = new OutputPort(row1, false);
            Rows[1] = new OutputPort(row2, false);
            Rows[2] = new OutputPort(row3, false);
            Rows[3] = new OutputPort(row4, false);
            Columns[0] = new InputPort(col1, true, Port.ResistorMode.PullDown);
            Columns[1] = new InputPort(col2, true, Port.ResistorMode.PullDown);
            Columns[2] = new InputPort(col3, true, Port.ResistorMode.PullDown);
        }
... ... ...
            //Cerbuino D0-D6 to Keypad k1-k7
            //D0 - k3 (col1)
            //D1 - k1 (col2)
            //D2 - k5 (col3)
            //D3 - k2 (row1)
            //D4 - k7 (row2)
            //D5 - k6 (row3)
            //D6 - k4 (row4)

            keypad = new Becafuel.Keypad3x4(Cerbuino.Pins.D0, Cerbuino.Pins.D1, Cerbuino.Pins.D2, Cerbuino.Pins.D3, Cerbuino.Pins.D4, Cerbuino.Pins.D5, Cerbuino.Pins.D6);

RorschachUK

Bec_a_Fuel · July 14, 2012, 10:36am

This should have been my next test !!! But since you did it, I will trust you and your good result Thank you !

May I assume that you have only changed the constructor and nothing else ? If yes, then it shows that the Read_Matrix() method is correct, and that there is something else to see about sockets 1 & 2 here. Maybe some kind of initialization or similar ?

Sorry Gus, but I’m not sure I understand what you want from me, here.
But before anything else, I’m not saying that there is a problem on the Cerbuino. That should be clear.
What I say is that I see differences between different sockets behaviours. Maybe I don’t do something I should when using sockets 1 or 2, I don’t know at this moment.

Back to your request, can you please be more precise, like if you were speaking to an idiot

My latest tests only show that the same code does not produce the same results on the 3 sockets. But I can’t remove the keyboard since it’s what I’m testing !?

Gus_Issa · July 14, 2012, 10:48am

@ Bec a Fuel - What I am asking is this, How do I see the problem here if I were to test it?

RorschachUK · July 14, 2012, 10:48am

Almost nothing else - there was a line about “if (Board is GHIElectronics.Gadgeteer.FEZHydra)” which caused trouble as it didn’t recognise ‘FEZHydra’ at all on my Cerbuino, I just took that if-branch out entirely as I didn’t care and wasn’t even using that socket constructor, though perhaps some alternative could be done with Board.Name or something instead.

I was assuming your problems on sockets 1 and 2 were likely to do with I2C, as per the note on the wiki [here] which reads: “Note - On socket 1 and 2, GPIO pins are set in open drain mode as they are the I2C pins.”.

RorschachUK

Bec_a_Fuel · July 14, 2012, 11:33am

@ Gus : ok, now I understand Without a keypad, though, it will be difficult to reproduce, I think.

This simple code is enough to see what’s happening (but not why, of course )

Cpu.Pin P3 = GT.Socket.GetSocket(1, true, null, null).CpuPins[3];
            Cpu.Pin P4 = GT.Socket.GetSocket(1, true, null, null).CpuPins[4];
            Cpu.Pin P5 = GT.Socket.GetSocket(1, true, null, null).CpuPins[5];
            Cpu.Pin P6 = GT.Socket.GetSocket(1, true, null, null).CpuPins[6];
            Cpu.Pin P7 = GT.Socket.GetSocket(1, true, null, null).CpuPins[7];
            Cpu.Pin P8 = GT.Socket.GetSocket(1, true, null, null).CpuPins[8];
            Cpu.Pin P9 = GT.Socket.GetSocket(1, true, null, null).CpuPins[9];

            OutputPort Port3 = new OutputPort(P3, false);
            OutputPort Port4 = new OutputPort(P4, false);
            OutputPort Port5 = new OutputPort(P5, false);
            OutputPort Port6 = new OutputPort(P6, false);
            InputPort Port7 = new InputPort(P7, true, Port.ResistorMode.PullDown);
            InputPort Port8 = new InputPort(P8, true, Port.ResistorMode.PullDown);
            InputPort Port9 = new InputPort(P9, true, Port.ResistorMode.PullDown);

            byte a = 0;
            Port3.Write(true);
            while (true)
            {
                Debug.Print("P7 = " + Port7.Read());
                Debug.Print("P8 = " + Port8.Read());
                Debug.Print("P9 = " + Port9.Read());
                Debug.Print("========");
            }

Here, I’m only dealing with the first row by setting “Port3.Write(true);” and then I loop on the inputs to see what’s happening when I press the 1, 2 or 3 key on the keypad.

You will see a correct behaviour on socket 3 (don’t forget to replace 1 by 3 in the GetSocket() ), which is P7, P8, P9 becoming true and then false when you press and release 1, 2 or 3 respectively. But you won’t see anyting good on the two other sockets.

But RorschachUK may be right, at least on one point about I2C.

I was looking at the Cerbuino schematic and the first thing I’ve seen is that socket #2 is of type X on it, but is printed type Y on the board… Of course, it can’t be Y if (hardware) I2C is present. So, socket #2 is “unusable” for the keypad. This is were RorschachUK is right and I won’t test any further on this socket.
Btw, on the Hydra, none of the I sockets are marked Y, but instead X. So I think it’s more a typo on the Cerbuino than anything else. Maybe something to remember for next batches if my guess is correct ?

Now, about the socket #1, although it has I2C pins, there’s no resistors connected to those pins. So I think it should keep the “Y” type compatibility. You can note that this socket is not a type I socket, both on board and on schematics.
But then, why does it still not work correctly ? Yet, types P, S & U are compatibles with type Y…

Let’s have some beer to help thinking…

Bec_a_Fuel · July 14, 2012, 11:39am

Ok. Then it’s fine with the “ReadMatrix()” part.

About the FEZHydra type, I think it could be because you miss a reference to some Gadgeteer lib. This can be the case since you’re not using your board as a Gadgeteer board.
But still, I will double-check to be sure. Thank you for pointing this.

RorschachUK · July 14, 2012, 11:43am

I am using it as a Gadgeteer board, and have things plugged into sockets as well as the Arduino headers, and it’s a Gadgeteer project not a NETMF one. If I’m missing a reference that names FEZHydra, I’m missing it because it’s not needed for anything. My project has GHIElectronics.Gadgeteer.FEZCerbuinoBee referenced, but not GHIElectronics.Gadgeteer.FEZHydra which it doesn’t need at all. Best to decide what the board is via Mainboard.Name instead, I think - or better yet, trap the exception when trying to set resistor pullups and divert to code that doesn’t instead, to work with future boards that behave like Hydra.

RorschachUK · July 14, 2012, 3:23pm

A quick experiment shows that if I attach HD44780 display (which requires Y socket, all three Cerbuino sockets are marked Y) to socket 3 and write my keypad’s keypresses to it, works fine. If I move it to socket 1, doesn’t work, raises a non-specific ‘System.Exception’ at runtime when attempting the write, though there was no exception to say it was in the wrong socket.

RorschachUK

Gus_Issa · July 14, 2012, 3:53pm

Clarification, char dispkay module raises an exception on socket 1? Nothing else is connected beside the char display module? Any code is needed?

RorschachUK · July 14, 2012, 4:21pm

In that particular quick test Gus I was using an I2C device (Chucky module) on socket 2 at the time, and also the keypad on arduino-header pins D0 to D6. Have just tried with the I2C device out of the equation, still had trouble in the keypad initialise when trying to setup pin D4 as digital output - only happens when LCD is in socket 1, works fine in socket 3. Could there be clashes between the arduino-style pins and the socket pins?

Gus_Issa · July 15, 2012, 10:13am

While pin sharing on sockets is allowed and encouraged, GHI only use unique pins on all sockets. The pins that are shared are I2C and sometimes SPI pins.

What surprises me though is that the gadgeteer designer is aware of this and the designer should have pointed out the right connections before you end up in run-time error. We will check with gadgeteer team.

RorschachUK · July 15, 2012, 10:29am

I guess the designer can’t know at design time that I plan to use the Arduino pins D0 to D6 until I actually use them, though. Still, that’s just my experiment, doesn’t explain Bec a fuel’s findings, which the designer should catch.

Gus_Issa · July 15, 2012, 10:48am

Oh I see, yes the designer is not aware of anything outside the “socket” scope. That explains it.