Hello,
I’ve just got my Hydra and done some (very simple) hello world tests.
One thing has surprised me, though. I have an eBlock expansion connected on connector 6 and a button eBlock on the expansion, pin 3. I’m using InterruptPort, here.
The program simply lights the Hydra’s led when button state == 0, which works fine. Of course :
Now, if I try to plug another device on the eBlock expansion, then the “button pressed” interrupt is fired :o
e.data1 contains the button pin number (113, here). It does the same thing on every eBlock pin.
So, my question is : is it intended behaviour ?
Here’s the code :
using System;
using System.Threading;
using Microsoft.SPOT;
using Microsoft.SPOT.Hardware;
namespace TestHydra101
{
public class Program
{
public static OutputPort Led = new OutputPort((Cpu.Pin)114, false);
public static InterruptPort Button= new InterruptPort((Cpu.Pin)113, true, Port.ResistorMode.PullUp, Port.InterruptMode.InterruptEdgeBoth);
public static void Main()
{
Button.OnInterrupt += Button_OnInterrupt;
Thread.Sleep(Timeout.Infinite);
}
static void Button_OnInterrupt(uint data1, uint data2, DateTime time)
{
Led.Write(data2 == 0);
Debug.Print("Button : data1 = " + data1.ToString() + ", data2 = " + data2.ToString());
}
}
}
Result is the same if I choose Port.ResistorMode.Disabled (Port.ResistorMode.PullDown giving an argument exception, here).
Well, that’s not a big problem, I only wanted to see if I could plug/unplug blocks while the board was running.
Have a nice day,
Christophe
Do you mean while it’s running you plug another device in? You may need to define the other pins on the module first. I’ve noticed that many of the pins on the Hydra have power to them until they are defined and their resistors are enabled. There’s probably some sort of feedback or bounce created by the eBlock when it’s plugged in that is triggering the interrupt.
Nice try 
But no, it’s not that 
Yet it sounded very logical and I was satisfied with your answer. 
But…
I’ve done some more tests and this behaviour depends on what I connect on the expander, in fact. If I connect another button eblock, then nothing happens. If I connect the IR receiver eblock or the temp sensor eblock, then I have an interrupt. No matter how the port is configured (input or interrupt).
I think that those eblocks are somehow “initialized” when they are plugged in, where they are in fact powered on. Hence the small signal at that moment.
Well, I suppose :think:
Yes, I plug/unplug a device while the board is running.
So I know the fix : don’t plug eblocks while the board is running :naughty: :whistle:
Yea, it sounds like you’ve found the best answer 
However, this does point out a down side to the Gadgeteer design. It sounds like you could really use a larger pull-down resistor or other circuitry to better handle this type of behavior. With the plug-n-play design of Gadgeteer, if the module isn’t exactly right then there’s very little opportunity for one to inject additional circuitry between the module and the mainboard. This makes me think there might be an opportunity for a module that could sit between the mainboard and another module that would let you add circuitry in the middle of the cables. Hmmm…
Check back tomorrow for some news on hydra
Oh, I hope that means Gadgeteer framework!
Me too! Game Slate on Hydra :dance:
Maybe PortResistor.PullDown without exception ? :-[
I’ve thought at it (hotplug) a little more and it’s not that easy to deal with…
A pulldown resistor won’t do the trick to me, as the eblocks seem to send signal(s) as soon as they are powered up. This is not a problem when board is booting since such signals will be ignored because software is not loaded yet, but as soon as software is running, then it will catch any interrupt thrown by a newly inserted device.
What is more strange though is the fact that connecting a eblock on a free pin does indeed throw a signal on another one :think: Here I was inserting the IR eBlock on pin4 while button eBlock was using pin 3, and I got interrupt on pin 3 when I plugged the IR eBlock…
I will do some other tests today.
I believe the FEZ docs say something about all the InterruptPorts sharing the same events so that might be by design. Are all the event parameters identical? I would expect there to be something there that specifies which pin initiated the event.
I receive the exact same event.
The above code is enough to show the behaviour : if I plug say the IR receiver eBlock on pin 4, then I get the same event as if I had pressed the button that is plugged on pin 3. Same pin number (113, here) in data1 event parameter.
Unfortunately I don’t have a second eblock expansion board so I can’t tell if this also happens on another connector as well at the same time. However, it does happen at least with 2 connectors on which I’ve checked (#6 & #7)
Anyway, since the whole thing is not meant to be “hot-plug compatible”, I think that such unexpected behaviour is quite logical. Or better, that “expected behaviour” is unknown. Much like floating pins seem weird the first time we have to deal with them :
Sorry Gus, but if it should have been fixed then it’s not the case. Same behaviour with newer firmware.
But don’t get me wrong : I don’t expect correct behaviour with incorrect use 
“Incorrect use” being plugging the eBlock while the board/program is running, here.
I didn’t even read your post yet 
You had used some too early version. Now we can look into this further…
Do you have your switch set to 3.3V? The processor on hydra and the gadgeteer specifications does NOT allow for 5V. This will damage the processor.
By the way, this was already in the tutorial on wiki page http://wiki.tinyclr.com/index.php?title=EBlock_Module
Important Note: While EBlocks are made to run on 3.3V and on 5V, the gadgeteer specification only allows for 3.3V signals. ALWAYS set the switch on the EBlock Expansion Module to 3.3V
Here’s another sample but done the Gadgeteer way :
using Microsoft.SPOT;
using GT = Gadgeteer;
using GTI = Gadgeteer.Interfaces;
using Gadgeteer.Modules.GHIElectronics;
namespace GadgeteerApp2
{
public partial class Program
{
GTI.InterruptInput Bouton1;
void ProgramStarted()
{
Bouton1 = new GTI.InterruptInput(GT.Socket.GetSocket(6, true, eBlockExpansion, null), GT.Socket.Pin.Three, GTI.GlitchFilterMode.On, GTI.ResistorMode.PullUp, GTI.InterruptMode.RisingAndFallingEdge, eBlockExpansion);
Bouton1.Interrupt += Bouton1_Interrupt;
button.ButtonPressed += button_ButtonPressed;
button.LEDMode = Gadgeteer.Modules.GHIElectronics.Button.LEDModes.OnWhilePressed;
}
void Bouton1_Interrupt(GTI.InterruptInput sender, bool value)
{
Debug.Print("Interrupt : " + value.ToString());
PulseDebugLED();
}
void button_ButtonPressed(GT.Modules.GHIElectronics.Button sender, GT.Modules.GHIElectronics.Button.ButtonState state)
{
Debug.Print("Gadgeteer button pressed");
}
}
}
Button eBlock is on pin 3 of the eBlockExpansion. Now if I plug the IR receiver eBlock on pin 6 (other pins “work” as well) then I get the [italic]button pressed[/italic] event and the led is flashing.
About the 3.3V/5V switch : then why do you put such a switch if it can damage the board ? :o
I think I will remove it so that I can’t change it by mistake : I wouldn’t like a $0.xx thing damaging a $xxx device :naughty:
I am still lost to what the problem is. Can you give me steps on what I should do so I can see the problem please?
[ulist]Take the config on the screenshot (display not used)
Use the small source (Gadgeteer version)
Connect a button eBlock on pin3 of the eBlock Expansion
Press the button to check that the Hydra’s led is flashing (and debug print is working)
Now take an IR receiver eBlock
Look carefully at the Hydra’s led while you plug the IR eBlock into the eBlock expansion, pin # is not important
Led is flashing (indicating an interrupt has been received), although the signal has come from another pin than pin3[/ulist]
This does not “work” with a second button eBlock but this “works” with the Temperature sensor eBlock, for example.
Will test it tomorrow, today is holiday in USA. So, I am not suppose to be working…(so what am I doing here on the forum?!!)
I followed your steps exactly, using your Gadgeteer version of the code, and couldn’t get the event to fire more than a few times. It seems like the button is really sensitive, so when you are plugging it in, it may hit the table and look like it is the event. At least thats what was happening to me a lot. Have you tried mounting it to something heavy and facing up, like the screen, so we can rule that out? How many times does the event send when you plug something in? Does it send when you unplug it?
Indeed, it does not fire “more than a few times”. What is weird here is the fact that the interrupt is fired from another pin, with the wrong pin number.
But, as I said, this is not expected use of such module, so I think unpredictable results are the rule in such cases
I wouldn’t bother too much with this problem, but rather have a look at this one : http://www.tinyclr.com/forum/21/4754/
Anyway, thank you for having taken some time to try to figure it out 8)
However, this does point out a down side to the Gadgeteer design. It sounds like you could really use a larger pull-down resistor or other circuitry to better handle this type of behavior. With the plug-n-play design of Gadgeteer, if the module isn’t exactly right then there’s very little opportunity for one to inject additional circuitry between the module and the mainboard. This makes me think there might be an opportunity for a module that could sit between the mainboard and another module that would let you add circuitry in the middle of the cables. Hmmm…
“Incorrect use” being plugging the eBlock while the board/program is running, here.