FEZ Domino with IO60P16

NETMF & Gadgeteer
1

I’m new to FEZ and bought these two together.

First off, it appears there were semi-significant issues getting the IO60P16 working correctly, even with Gadgeteer mainboards. Was a stable driver completed? Does the thing even work? It was on sale…

If good drivers exist:
-What is the best way to connect Gadgeteer stuff, such as the IO60P16, to my Domino? SDA, SCL, etc. seems straight-forward enough, but where do I connect the INT pin to the Domino?
-After that, how difficult will it be to tweak the driver to use the new pin?

2

Welcome to the forum!

Any interrupt capable pin on Domino will work. Check documentation on Domino.

http://www.ghielectronics.com/downloads/FEZ/Domino/Broch_FEZ_Domino.pdf

In the pinout tables pin names that have * at the end are interrupt capable

3

Welcome to the community!

GHI’s Gadgeteer driver can be found here. It could easily be adopted to pure NETMF use.

http://gadgeteer.codeplex.com/

My driver is here. It is the only one that currently supports interrupts. Again, it is a Gadgeteer driver and would need some minor refactoring to work in pure NETMF.

This module has mostly been plagued by problems with the SoftwareI2C classes. I think perhaps the last of those bugs is going to be squashed in the next SDK coming in another day or so. However, if you can give up a hardware I2C pin then I would highly recommend going that route. You’ll find the module is more reliable when running in that mode. I haven’t tried it with a Domino or anything besides a Gadgeteer mainboard. I’ll be curious to hear your results.

Good luck!

4

Thanks guys. I ordered the ‘duinoproto’ yesterday rather than jumper or soldering the thing myself.

On the software side, I poked around in VS and discovered how simple it is to add a new mainboard. I’m hoping this will allow me to use the Gadget designers. The only remaining issue should be that the Domino does not have GadgetCore ‘built on’.

Most of the Gadget core does not appear to even require Gadget includes, only SPOT. And the ones that do have Gadget includes, only import an enum or two. Gadget appears to be just a wrapper around the SPOT hardware which the new mainboard appears to wholly encapsulate. Since the new mainboard includes, and inherits from Gadget, should it not already deploy Gadget.dll with the rest of my code? There is nothing I see in the source that indicates that the assembly needs to be ‘embedded,’ at all. I would assume there is a performance or other trade-off in running Gadget from user code? ‘SoftGadget,’ so to speak.

Also, if I have the same source as the .dll on actual Gadget mainboards, should I just add the GadgetCore source to my project and reference it instead of the one in GAC? Even if I don’t have to tweak it, I’d be able to instantly. With as simple as Gadget appears to be, WOULD I ever need to tweak it? It doesn’t seem like it, right now, since when you break it all down, we are only timing the cpu pins high and low.

Was still unclear on interrupts last night until I reread the datasheets of both modules, GadgetCore, Builders templates, Gadget templates, etc…, etc…, etc… I can, now, plan on using DaisyLink with the Domino, as well. Very cool!!!

Will know more when parts arrive :slight_smile:

P.S. GHI’s website is not as awesome as they, themselves, are… Which mainboard is ‘best’? The prices do not increase linearly with any one factor (speed, features). The Hydra appears to be the fastest, but it’s cheaper than the slower Spider. I bought the Domino to convert from Arduino because it was on sale and the cheapest. Then, I discovered the benefits of Gadget mainboards and wish I’d read more, before buying.

5

If you are using Domino, don’t mess with Gadgeteer libraries. Try the IO60P16 module using NETMF primitives instead.

6

@ Architect - By that, do you mean port the Gadget driver to pure NETMF? If not, please post an example or link explaining ‘NETMF primitives’.

[quote]My driver is here. It is the only one that currently supports interrupts. Again, it is a Gadgeteer driver and would need some minor refactoring to work in pure NETMF.

[/quote]

7

Yes.
Domino is not a Gadgeteer.

It makes more sense to have non-Gadgeteer version of the module driver then have a Mainboard driver for Domino.

8

‘Ported’ Ian’s driver, basically inheriting IO60P16 module from custom I2CDevice wrapper, rather than GTM.Module. Module pins appear to generate interrupts correctly; waiting on pin headers to fully test all capabilities.


public class I2CDevice : Microsoft.SPOT.Hardware.I2CDevice
    {
        public I2CDevice(Configuration config) : base(config) { }

        ///Fields
        public static object lockObject = new object();

        ///Methods
        public byte[] ReadRegister(byte register, byte length = 1)
        {
            byte[] data = new byte[length];
            Execute(new I2CTransaction[] { I2CDevice.CreateWriteTransaction(new byte[] { register }), CreateReadTransaction(data) }, 20);
            return data;
        }
        public void WriteRegister(byte[] registerAndBuffer) { Execute(new I2CTransaction[] { CreateWriteTransaction(registerAndBuffer) }, 1000); }
    }
9

Nice!

10

Great job! What specific functionality are you planning to use? I’ll try to stay a step ahead of you in the testing to make sure you’re not going into unchartered waters. The chip on that module still has several capabilities that I haven’t implemented yet.

If you’re comfortable in Git, then perhaps you would fork my repo as a pure NETMF version? It might make merging future changes easier and will perhaps be useful to others later on.

11

@ ianlee74 - I noticed you had a bunch of stubs/comment-blocks to test-drive its’ functions. I will probably use those and implement any that are missing to enable everything possible. I am happy to share whatever I come up with, although I don’t know Git, or how to ‘fork’ your repo.

12

No problem. If you add anything substantial you think I should add to the source, please send them my way. Thanks.