IO60P16 Interrupts issue

Archive
#1

I have used the IO module to generate interrupts on button clicks, but the IO module sometimes works for 15hours, then sometimes it locks up 5 times a day.
The only thing that helps is sending the reset command to the module ( and most of the time I need to send it 2 times) because the first time does not resolve the issue.

So my setup is IO module connected to socket 5 and the fez hydra has a network firmware with the ENC28 connected to network.

I saw that Ian driver on GitHub supports Hardware I2C because it seems like a timing issue on the software I2C bus. But when I enable the hardware bus the interrupts won’t even trigger… On the scope I see the commands being send and I can set other ports as output and see them change on my scope…

I created a basic test project with the following code and this is not working:
Added the source of Ian driver from Github and added HARDWARE_I2C as compile option. I used to extender modules to rewire the X socket to I.

IO Hydra
1 ---------- 1
2 ---------- 2
3 ---------- 3
4 ---------- 9
5 ---------- 8
10 ---------- 10


public partial class Program
    {
        private static bool _ledOn;

        private IO60P16Module _io60P16Module;
        private InterruptPort _interruptPort;

        void ProgramStarted()
        {
            Debug.Print("Program Started");

            _io60P16Module = new IO60P16Module(5);
            _interruptPort = new InterruptPort(_io60P16Module, IOPin.Port0_Pin0, ResistorMode.ResistivePullDown, InterruptMode.RisingEdge);
            _interruptPort.OnInterrupt += interruptPort_OnInterrupt;
        }

        void interruptPort_OnInterrupt(IOPin pin, bool pinState, DateTime timestamp)
        {
            Debug.Print("int!!!");
            _ledOn = !_ledOn;
            Mainboard.SetDebugLED(_ledOn);
        }
    }
}
#2

Also did a small test with a breakout board to test if I can get Interrupts from Hydra pins from socket 9 (Y socket)


_extender = new Breakout_TB10(9);
                _interruptInput = _extender.SetupInterruptInput(Socket.Pin.Three, GlitchFilterMode.Off, ResistorMode.Disabled, InterruptMode.RisingEdge);
                _interruptInput2 = _extender.SetupInterruptInput(Socket.Pin.Four, GlitchFilterMode.Off, ResistorMode.Disabled, InterruptMode.RisingEdge);
                _interruptInput3 = _extender.SetupInterruptInput(Socket.Pin.Five, GlitchFilterMode.Off, ResistorMode.Disabled, InterruptMode.RisingEdge);
                _interruptInput4 = _extender.SetupInterruptInput(Socket.Pin.Six, GlitchFilterMode.Off, ResistorMode.Disabled, InterruptMode.RisingEdge);
                _interruptInput5 = _extender.SetupInterruptInput(Socket.Pin.Seven, GlitchFilterMode.Off, ResistorMode.Disabled, InterruptMode.RisingEdge);
                _interruptInput6 = _extender.SetupInterruptInput(Socket.Pin.Eight, GlitchFilterMode.Off, ResistorMode.Disabled, InterruptMode.RisingEdge);
                _interruptInput7 = _extender.SetupInterruptInput(Socket.Pin.Nine, GlitchFilterMode.Off, ResistorMode.Disabled, InterruptMode.RisingEdge);
                _interruptInput.Interrupt += interruptInput_Interrupt;
                _interruptInput2.Interrupt += interruptInput_Interrupt;
                _interruptInput3.Interrupt += interruptInput_Interrupt;
                _interruptInput4.Interrupt += interruptInput_Interrupt;
                _interruptInput5.Interrupt += interruptInput_Interrupt;
                _interruptInput6.Interrupt += interruptInput_Interrupt;
                _interruptInput7.Interrupt += interruptInput_Interrupt;


void interruptInput_Interrupt(InterruptInput sender, bool value)
        {
            _led = !_led;
            Mainboard.SetDebugLED(_led);
        }

Even this code is not working, I have flashed my Hydra with the latest ethernet firmware and using the latest gadgeteer/ghi libs

#3

With the DL40 and the DL40IO firmware and driver from Codeplex I don’t have any issues …

#4

@ krikke999 - I can’t speak to the IO60P16 module, I have one but I have not used it much. The test you did with the Hydra could be a problem, only Pin 3 on a X/Y socket is guaranteed to be interrupt capable.

The DL40 uses the LPC1113 MCU which conveniently supports interrupts on all pins.

#5

@ taylorza - I looked at the specs of the Hydra (atmel) and it seems all GPIO’s support interrupts. Although it is true that the gadgeteer Y sockets only support interrupts on pin3, but I would have expected that the trigger on pin3 would have triggered the callback function.

I’m already used to low level programming to uC in C(+) and I worked on automations and vending machines, but with the high level abstraction it is not always clear if it is NETMF or the drivers. I like the higher level of abstraction to work with because during my daytime hours I’m a software developer in C# and it helps to know the basics of low level uC programming in C. It isalways hard in the beginning to learn new stuff :slight_smile: that’s why I like my job…

What happens with the gadgeteer components, once you figured everything out to built your product on this platform, how about the flash procedure, will the Fez tools still work when I want to flash my custom built board with the same schematic built? Do I need to worry about licensing? if I understand Gadgeteer correctly it is all opensource and that you can use and reuse/change everything without licensing problems?

#6

I did a quick test with the Hydra and all the pins successfully raise interrupts, but using ResistorMode.Disabled seems to be very noisy and plain unreliable.

When I changed the interrupt configuration to use Pullup resistor and interrupt on the falling edge it works on all pins reliably.

Unfortunately the AT91SAM9RL does not support programmable pulldown resistors so you would need to physically wire those in.

That is good info to include in your bio.

A few members have built custom boards based on the Cerberus OSHW and the FEZ tools work just fine with the ones that I have. GHI has OSHW and Premium hardware, with the OSHW you can build your own devices based off the schematics from GHI (see their requirements for attribution). For the Premium devices you would need to use one of GHI existing SOMs in your design you will not be able to build your own version of the SOM and load the firmware onto that. There are community members that have actually done this so I will defer to them and GHI elaborate further…

1 Like
#7

@ taylorza - Thanks for the intel!, I was not aware of the pulldown/disable

For the attribution I found the following page https://www.ghielectronics.com/docs/39/fez-hydra-developer.

So it should be enough to add the following text on the board:

And in all documentations I should mention:

[quote]Based on GHI Electronics’ Open-Source-Hardware FEZ Hydra design files.
Visit this page for more details http://www.ghielectronics.com/docs/39/fez-hydra-developer[/quote]

What does it take to make the derived hardware closed source?

Currently my application is running continously with 2 daisylinked DL40 (with DL40IO firmware and drivers) trigging all interrupts correctly and driving my x16 Relays, good good good!

If I have more time I will give the IO60P16 another go, but DL40IO has much greater reach for later projects…

I was not aware of that

#8

You would need to read through the correct open source license that the OSHW has been created and released under.

From the developer page, where you’ve already been, there is a section on licensing. I quote:

[quote]Licensing

The design files are available to everyone to use, even commercially. The software is licensed using Apache2. This license allowing for changes, for commercial use and for even close sourcing the derived designs. The hardware is licensed using Creative Commons Share Alike 3.0. This license allows for commercial use and for derived work but doesn’t allow closing the source of derived work. Please contact GHI if you need to close source your derived work.
[/quote]

So you need to meet the CC-BY-SA3.0 requirements http://creativecommons.org/licenses/by-sa/3.0/ or you can contact GHI if you need to close-source your design based on the open-source start.

#9

I am glad to hear that you are having such great success with the DL40IO firmware, it is good to know that people are getting value from it.

#10

i was just reading the datasheet for the CY8C9560 chip on the IO60P16. If I interpreted it correctly, there is one single interrupt output pin from that chip that would be used to send interrupt events back to the master processor. Since there is only one “pipe” back to the master (in my case a Cerberus), does this mean that interrupt events queue in some fashion? Asked another way, if I have ten inputs on the IO60 set up as interrupts and all ten of them are triggered in rapid fashion, would some of the interrupt events queue up until sent back, or would i just lose the interrupt events for times when the Cerberus is busy processing other things?

#11

You are correct in that it sends one hardware interrupt (module level event). However, in the driver I then do an inspection of which pins triggered the interrupt and raise individual events for each pin that has a handler setup. This reminded me that in krikke999’s example he is not exactly writing the code the way I originally intended the driver to be used. Although, I think others have used it his way w/o problems. On the module there is a CreateInterruptPort() function that I intended to be used as a factory for creating the port objects. This function takes care of doing all the necessary intializations. You may want to try using it instead of new-ing up an InterruptPort object on your own. Ex.


void ProgramStarted()         
{             
             Debug.Print("Program Started");
             _io60P16Module = new IO60P16Module(5);
             _interruptPort = _io60P16Module.CreateInterruptPort(....);
             _interruptPort.OnInterrupt += interruptPort_OnInterrupt;         
}
1 Like