Gadgeteer standard V2?

Hi all, I have been speculating about the topics arising from some of the hot threads the last week. I have been searching the Gadgeteer specs, and there is a cruel lack of low-power considerations in the core standard.

I am thinking about the ability to shut-off modules, to hibernate modules, and to control deep sleep or whatever.

An interrupt driven sleep for each module and the mainboard itself that is controlled in software and part of the standard is in my eyes very important to push us further?

Low power as a central part of new Gadgeteer revision?

What do you think?


I can’t speak to controlling the various power saving states of the processors. But both Gadgeteering core and GHI are moving to make the determination of module power easy.

In the latest release of Gadgeteer, if you are in the visual designer, and right click a module you get power estimates. As this is new, they aren’t all there, and some may be off, but it is a start in the direction you suggest.

In GHI’s catalog we have been beta testing a new “Specifications” tab, it is our intent that every electrical product we offer will have power stat.s. Again they aren’t all done, but this is a work-in-progress.

Estimates are nice. Control is needed.

1 Like

This is one of the things Gadgeteer needs to borrow from netduino Go!. The difference in architectures makes this much more difficult for Gadgeteer, unfortunately.

Enlighten me, what is it exactly in the netduini go architecture that makes it good for power-saving? Please.

Each socket has a transistor which allows you to turn on/off any module.

That’s clever. And why has GHI boards not that?

Was not part of the Gadgeteer specification. :wink:

With Go! every socket is a virtual node of an SPI bus. So, it basically has unlimited pins available to it. With Gadgeteer, this means that you would have to use a pin to turn on/off the socket and manage the direct pin connections that would suddenly be physically disconnected. Not to say it couldn’t be done in Gadgeteer but the bus that Go! uses makes this a much simpler task. I agree this is an important feature that needs to be added to the Gadgeteer spec.

Let’s not forget with netduino go all modules become very difficult to make as they all carry a chip…

Gadgeteer does have something similar which is daisychain, and if one would choose that route I’m sure the firmware of the daisychain module can be updated to allow for module hibernation…


Yes. I didn’t mean to imply that Go! was superior in every way - only that it had this one great feature.

You mean DaisyLink. If you think creating a Go! module is tough, try creating a DaisyLink module… There’s a reason you don’t see many of them.

That’s my point, we don’t need a new spec but what we need a simple USBIZI like chip for daisylink, hence GHI…


Personally I think creating DaisyLink modules are easier. I’ve made one (I haven’t done any Go modules though).

You can use DL40 module which has all DaisyLink plumbing already implemented.

I think one of the reasons we don’t see a lot of them yet, because the existing set of modules pretty much covers any common need.

I have never understood the DL40 module, can you explain?

Perhaps but many of those modules could benefit from DaisyLink functionality. DaisyLink would be the default way of doing things if it were as easy & cheap as not adding it.

But to address the original problem, I think Gadgeteer could have the ability to turn modules off by tapping into the SPI bus and giving each socket a transistor that could turn off the power to that socket. It would mean adding a few more parts to the mainboard and an event would need to be added to the module driver to allow power-off to happen smoothly. DaisyLink would need to handle this on-module. Perhaps GHI & community could build a prototype and propose to Microsoft for a core spec change?

Personally, I think there’s a point we’ve missed in the discussion so far. And I only point this out because I think the history is important, not to try to hamper suggestions to build on what we have today.

The original focus of Gadgeteer was to allow rapid prototyping. That means, quickly connect an assortment of devices you have, to a controller you have, and not have to write drivers for everything, just go to the application logic portion of the problem. It’s driven to help researchers solve problems quickly, no custom boards needed, and they can iterate on a problem quickly with little hassle.

The reason you want rapid prototyping is to prove the components can be made work in the way you want and that a commercial design can then proceed. Do you care if that uses more power than optimal? Do you care that you can’t power it in anything other than one state? Probably not.

And finally, once the research has been completed or the prototype done, the components can be broken down and reused. No more shelves full of dedicated hardware that will never see the light of day after the original work.

This is what unlocks the money, when someone says yes lets invest in that new tool/item/object. Then the hard work starts, building custom devices into a single unit, and that’s where power consumption and powering off unneeded devices etc becomes more important (and it’s the bit that Gadgeteer didn’t help you with but if you’re commercialising a product you would be able to draw on that expertise)

The scenario we’re all seeing now is that the commercialisation of Gadgeteer puts this capability in makers hands, and the same goals don’t always apply. Our projects aren’t always short term or research in nature, some times we really want to leave the “product” in it’s housing and use it for months configured in one and only one way. We use it to make the products that interest us. There’s also this IoT fad that’s coming along that is changing what we do with these projects. (yes, I know, calling it a fad doesn’t mean it is one :slight_smile: ) And if we want to let makers take full advantage of this, yes we will need a way to be very frugal with power, but I also don’t think we need to be OTT and have everything trimmed to bare bones - it’s likely a few core modules that really would benefit from this that we’d expect to be needing in these scenarios (wifi or 3g modem, and if a sensor used a lot of power all the time even when not sampling)

The one thing I would like to hear more about is the “indirect” feature recently added in Gadgeteer Core, is that an opportunity to build an “isolator” module that can manage the downstream power? I guess the one gap I can currently identify right now is a re-initialisation process since many modules will revert to the default state and need to be re-init-ed if you chop power to them.

This is why I suggested that the module driver spec would need to be changed to allow for a PowerOff event where state could be stored and components shutdown gracefully. Of course, you would also need a PowerOn event to complement it.

I don’t type fast (more correctly, I was multitasking and this site had no timeslices :slight_smile: ), so my reply was in draft while you posted yours. Yes, you certainly would need to cater for this, although you may not need to extensively expand it to add the state management piece if it’s a simple/dumb module, but harder if for instance you wanted to return a display to it’s previous state.

First to explain the DaisyLink protocol, basically it is a protocol that allows you to daisy chain multiple modules and then dynamically assign each module an ID based on the modules position in the chain.

The protocol is very similar to I2C (in fact it uses I2C as a core component of the implementation) the key difference being that allows for the device id to be assigned dynamically.

Once the devices on the DaisyLink bus have been initialized with their ID you can communicate with each device on the chain. There is a theoretical limit of 255 devices on the chain.

The other key feature of the DaisyLink protocol is that a device on the chain can raise an interrupt to the mainboard to notify the mainboard that something interesting has occurred on the device. When the interrupt it raised the mainboard can interrogate each device to see which one raised the interrupt and then initiate communication with the device if required.

So that is the very simplistic overview of the DaisyLink protocol, what is the DL40? Well the DL40 is a generic DaisyLink module that ships with a basic firmware which allows you to either set one of the pins on the DL40 high or low, IIRC you can also read the state of the pin.

Using the GHI firmware as a starting point, I have built a more elaborate firmware that allows you to access almost all of the capabilities of the DL40’s LPC1113 processor, you can read the analog inputs, respond to interrupts on the pins, control the state of the pins, even hand off PWM to the module. This is nice if you need a few extra input/out put pins or want a few extra PWM pins etc.

You can find the custom firmware and the Gadgeteer module driver on codeplex

1 Like

@ taylorza - This is cool stuff dude. Thanks for sharing, and thanks for explaining. :slight_smile:

My problem with understanding the DL40 module is the fact that it only has two sockets. I need a socket to connect backwards, and one to connect forward in the chain, and then one for the module that I need on the chain.

And furthermore, how do I power individual modules on and off? Is that a capability of the module?