Gadgeteer 4.3 changes

I am just finishing off my Gadgeteer 4.3 SDK and i thought i would share a few tidbits

All of the IO is now done using a factory design patterns.

So for DigialOutput:


Gadgeteer.Interfaces.DigitalOutput _dataPin = new Gadgeteer.Interfaces.DigitalOutput(socket, GT.Socket.Pin.Seven, true, null);

Is now:



SPI:


```cs
Gadgeteer.Interfaces.SPI.Configuration _config = new  Gadgeteer.Interfaces.SPI.Configuration(true, 0, 0, false, true, 4000);
Gadgeteer.Interfaces.SPI _spi = new Gadgeteer.Interfaces.SPI(socket, _config, Gadgeteer.Interfaces.SPI.Sharing.Shared, socket, (Socket.Pin)csPin, null);

Is now:

Gadgeteer.SocketInterfaces.SpiConfiguration _config = new Gadgeteer.SocketInterfaces.SpiConfiguration(false, 0, 0, false, true, 2000);
Gadgeteer.SocketInterfaces.Spi _spi = Gadgeteer.SocketInterfaces.SpiFactory.Create(socket, _config, SpiSharing.Shared, socket, GT.Socket.Pin.Five, null);

etc etc

Also note the change from

Gadgeteer.Interfaces to Gadgeteer.SocketInterfaces

And the case for SPI / Spi

*Edit - fixed cut and paste for SPI

5 Likes

Thanks for sharing

Was a rationale given for these changes?

so Justin, when is all this happening, no chance of generics I suppose, :naughty:

@ godefroi - dunno, will ask on Friday

@ Peter Kenyon - which bit? No generics I’m afraid. My sdk will be this week.

Wouldn’t generics require runtime code generation? If so, I imagine it would significantly increase the footprint of NETMF.

yeh its a forlorn hope, trouble is in the good old days I had common code between pc and netmf, but now with linq and await, they look like different languages, so mental context switch required when tapping the old keyboard…

Why would it? Is there anything about C# generics that isn’t (or couldn’t) be achieved through the compiler alone? They would increase the size of the resulting binary, though.

and linq is just IEnumerable plus yield.

Only if the compiler knew ahead of time every type that would be used with a generic. That would only be possible if all of the generic types and methods were private, and not callable through reflection.

There’s a really good explanation of why generics aren’t compile-time templates here (and it’s Eric Lippert, so you know it’s good): http://blogs.msdn.com/b/ericlippert/archive/2009/07/30/generics-are-not-templates.aspx

And more specifically, a large library of generic extension methods. A sort of linq-lite could be implemented today, but it’d involve a lot of boxing and unboxing. Performance, I imagine, might not be stellar, and you’d be doing a lot of casting.

Something like this?
http://blogs.oberon.ch/tamberg/2009-02-06/implementing-linq-on-the-dotnet-mf.html
:whistle:
Or this?
http://microlinq.codeplex.com/

3 Likes

Linq performance on a PC is far from stellar. I definitely wouldn’t expect any more on NETMF. For our code at work that requires high performance we avoid Linq at all costs.

Yes, just like that :wink:

@ ianlee74 - Interesting that you say that. What sorts of things cause your performance troubles? The linq language syntax, or the exension methods themselves, or is it that it encourages inefficient algorithms because of code convenience?

The only real “issue” I’ve seen personally (if it can really be called such) is that iterators result in an allocation. When you use a lot of them, the allocations add up. This was only an issue for me when I was doing extremely high-performance parsing of a text format known as HL7, and calling an iterator once for each field in the message. It was much more efficient to do the parsing in a single iterator instead of having iterators calling iterators.

I wish I had the exact examples around still. We used to have a lot of Linq code. Then in a performance improvement release we went through and tracked down the worst offenders. Linq was very often the problem and replacing it with simple FOR loops often resulted in much faster code. Since then we still use Linq for quick & dirty stuff or apps where milliseconds don’t matter but the default otherwise is to stick with the basic loops.

I’ve written my share of HL7 parsers. All pre-Linq, though.

I try to write one a month, just for fun :slight_smile:

Cool but for which main board ?

@ Rajesh - octopus, master spi, blue genie, smart scour and a couple of others that might or might not exist.

and for a giggle i might do Cerberus and Hydra if i get time.

2 Likes