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.
@ 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.
@ 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 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?
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…
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…
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]
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?
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.