Gadgeteer = Bad for Apps

[twospoons]

@Skewworks

@twospoons

There isn’t a lot of overhead writing maintainable code. Cost is not just hardware, it’s how easy it is to maintain the code, fix, find bugs and change code with confidence.
We are using C#. It’s OOP. Running on .netmf. If you want the smallest possible footprint you probably shouldn’t have started with this platform to begin with.

We are already trading memory and cost for easy of use, maintainability and tooling.

There are whole MVC frameworks written for low end devices which are about 2K lines of code. I see no reason to use global variables, pass device pointers around instead of wrapping this in a small class which controls how it’s being interacted with. And perhaps just some simple DI for injecting the hardware devices into this wrapper upon construction.

I thought the whole idea of this was to get away from the arduino; “oh I wonder if GPIO 5 is used somewhere else?”, “hmm… are all the interrupt timers used somewhere else?” etc.

Just because you already have overhead doesn’t mean you need to add more of it unnecessarily.

As for the Arduino comment, I don’t even know where to start, so I won’t.

Take a look at the ardu pilot 2 source code and that should give you a good starting point

[Skewworks]

@twospoons

Take a look at the ardu pilot 2 source code and that should give you a good starting point

I was more referencing that it was a silly comparison. No one moves from Arduino to NETMF because of pin abstraction. The move is for power. That would be akin to someone moving to embedded Linux because you don’t like TInyCore’s dispatcher.

[twospoons]

@godefroi

@twospoons

There are whole MVC frameworks written for low end devices which are about 2K lines of code. I see no reason to use global variables, pass device pointers around instead of wrapping this in a small class which controls how it’s being interacted with. And perhaps just some simple DI for injecting the hardware devices into this wrapper upon construction.

I thought the whole idea of this was to get away from the arduino; “oh I wonder if GPIO 5 is used somewhere else?”, “hmm… are all the interrupt timers used somewhere else?” etc.

Another way to look at this is, “I’m already wasting enough cycles because it’s managed code, I might as well not waste more using an additional layer of abstraction”.

When I wrote the software for my sprinkler timer, I did some of this. I had an XML configuration where I could change the hardware pins used for various I/O functions. Then, I thought to myself, “self, that’s nonsense. It’s not like this is going to be changed around. The pins in use are dictated by the board the chip is soldered onto.”

You’re not wasting a lot of cycles calling a function. Two jumps vs one. Again, if performance is your only concern then C# is a horrible choice for micro controllers.
You should be hand coding hex code. Not even use assembly.

[twospoons]

@Skewworks

@twospoons

Take a look at the ardu pilot 2 source code and that should give you a good starting point

I was more referencing that it was a silly comparison. No one moves from Arduino to NETMF because of pin abstraction. The move is for power. That would be akin to someone moving to embedded Linux because you don’t like TInyCore’s dispatcher.

I moved to .netmf because of the tooling. A good debugger. A good language. And a heck of a lot easier to write maintainable code.
There are tons of micro controllers out there with more power which doesn’t use .netmf, why didn’t you use those?

[Skewworks]

I do, actually

I develop on PCs, NETMF, Assembly, Arduino and a host of others. For me the choice of devices will often be a power-to-cost ratio, but this is moving well beyond the original point.

[twospoons]

@Skewworks

I do, actually

I develop on PCs, NETMF, Assembly, Arduino and a host of others. For me the choice of devices will often be a power-to-cost ratio, but this is moving well beyond the original point.

I do too, my point was that there is no reason to throw out sound programming standards and techniques just because it’s a micro controller. I see that very often. Just be a tad more careful on a micro controller and most people will be fine.

[dizzy]

Doesn’t this force you to apply good architecture…i.e. decoupling your applications/processes and relying on a more service based approach to communication (wether it be sockets, wcf services, http, etc.). I think its a good thing…