Turning Popular Breakout Boards into Gadgeteer Modules

Lately I have been asking some questions about the MikroElecktronika Thunder Click ( Thunder click - board for AS3935 lightning sensor with Coil antenna ) and so I thought I better show why as some other folks have expressed some interest or similar ideas and I would like to keep the duplication of effort to a minimum.

In an effort to increase the number of Gadgeteer modules I started looking around and noticing that most of the cool chips are available on breakout boards, so why not build a Gadgeteer module based on mounting the breakout board onto a Gadgeteer X1 Breadboard module (yes you can also use other ‘connection’ modules), and then writing a Gadgeteer driver for it and then making it available to the Gadgeteer community. That would make the latest technology easy to use for the whole expanding Gadgeteer community regardless if you know how to solder or not. So as part of the documentation there is a diagram showing you how to wire things up (note these are just rough diagrams just to illustrate the concept), see the first attachment, and then there would be a Gadgeteer module installer so you could use this breakout board as you would any other Gadgeteer module (see second attachment and third attachments).

Now while I’ve used a Thunder Click breakout board as the price and shipping were a good price for me, but you could use any AS3935 breakout board for example Playing With Fusion - Digital Lightning Sensor AS3935 SPI and I2C Breakout Kit or Embedded Adventures - Products - MOD-1016 AS3935 Lightning and Storm Sensor Module just as long as it uses a SPI as that is what the current driver is designed for (a I2C interface could be available as well). I’m wanting to make the driver full featured and robust as it needs to be worthy of Gadgeteer so I’ve included a number of unique features and such to this driver.

So some folks have express and interest in doing this and given my target audience is fellow Gadgeteer users I thought I better open this up to the Gadgeteer community for feedback.

If anyone is interested in the code I’ve got so far complete with a couple of bugs and issues which I’m working on which have required AMS questions/answers), I’d be happy to post the code as my intention is once its done to open source it.

Comments, suggestions, questions or general abuse???

8 Likes

I like where you’re going with this. There’s some room for improvement in the icon diagram but I realize this is a first draft.

For this particular example I’m wondering since there’s been so much talk about Click modules lately if there’s perhaps a need for a Click-to-Gadgeteer adapter needed.

@ ianlee74 - These ones? http://www.mikrobusnet.org/product-category/shopgadapters

2 Likes

That looks like the ones :slight_smile: I’ll admit that I’m almost completely ignorant of all things Click.

Over the weekend, I ordered one of each of those Click adapters (and several of the Type S ones. I think they’re quite the boon hardware-wise, but they might add some complexity to Gadgeteer development, For instance, several of the G-modules map UART RX/TX to Click, so in addition to knowing what Click module you are using, the author of the Gadgeteer module has to specify which G-Adapter you should use so that s/he knows which socket type you need to bind to.

In other words, for a given module, there may be more than one usable G-Adapter, and as a driver author, you either need to specify which one the end-user has to use, or we need to find a way to map a single Gadgeteer module to multiple socket types (maybe that exists already). Can a module specify compatibility with more than one socket type in the templates?

Bottom line, I would definitely suggest using G-Adapters for any new drivers - cheaper and a nicer end result than the protoboard. And anyone that can’t or doesn’t want to acquire a G-Module can just wire a protoboard accordingly.

1 Like

@ andre.m - That’s good to know, but I think it solves a different problem. That solves the problem of “I have module ‘Foo’ and it can plug into any one of S, U, or X” for instance. That enumeration you pointed out is the set of compatible sockets. But how do we guide the user in the choice of the right G adapter when one or more can work, and when that choice of adapters determines the set of compatible socket types?

My suspicion is that we’ll have to say “You must use module ___ with a Type _ adapter” whenever there is the potential to use more than one and where that choice changes the target socket set.

What about? https://www.youtube.com/watch?v=rZjJxOnJVGs

:smiley:

@ Martin

It is not as simple as plug in a click board and connect it to a Gadgeteer mainboard. Due to the differences in socket definitions between the MikroE click socket specification and the Gadgeteer Socket definition, there are going to be some Click boards that will not simply work with a one socket solution.

The MBN G-Adapter was created with making Gadgeteer Modules available for use with a MBN Mainboard in mind. We soon realized that the reverse will also work in some cases.

For instance, some SPI based Click boards require three (3) GPIO Pins and one of which is Interrupt Capable. The Gadgeteer S socket definitely provides such capability, but the pin that would be required to be interrupt capable on the Gadgeteer Socket is not.

Please have a look at Codeshare entry that demonstrates how to use various Click Boards with a Gadgeteer Mainboard. https://www.ghielectronics.com/community/codeshare/entry/1025. This is a proof of concept and is not meant to be an all inclusive test.

Click boards will have to be evaluated on a board-by-board basis to determine a best fit solution using the Click board with a G-Adapter on a Gadgeteer mainboard.

@ andre.m. That is correct and even though the Gadgeteer socket provides an interrupt capable pin, it does not necessarily coincide with the MikroE pin that requires an interrupt.

@ scardinale - Regarding this and your other post, I see what you mean. Click boards will work with Gadgeteer through 0 or more potential choices of G-Adapters. The ‘0’ case is what it is - it just won’t work. The ‘1’ case is a happy outcome. The ‘or more’ case just means we’ll probably have to specify which G-Adapter to use.

Now, for the zero case, I see a few options…

  • If the pin mapping is different, but still compatible with a socket, then a Gadgeteer protoboard, or yet-another-G-Adapter-that-doesn’t-exist-yet could be made.
  • If the pin set does not map onto any SINGLE Gadgeteer socket, then a multi-socket adapter is a possibility.

Both of those two zero-case solutions assume that a) the cost/complexity of an adapter board is less than the cost/complexity of just doing a Gadgeteer board and b) that the cost/complexity of either solution is justified by demand for that particular peripheral overall.

Did you do a survey of Click boards anywhere to get a list of the ones that require different pin mappings or additional sockets? I’m starting to work my way through them, but don’t want to duplicate work.

@ mcalsyn. I have not compiled a list of Click boards that would be a fit for Gadgeteer through a G-Adapter. It is on my to do list as time permits.

For what it is worth, MikroE offers Click board Customization Services. So if a click board does not meet your exact needs, they can customize it to your specifications. This of course comes at a price.

Another option is to use a MikroE Proto Click and to remap the pins to whatever suits your requirements. This is exactly what I did for the SHT11 Click that was using the I2C Pins on the MikroE Socket. And as we all know, the SHT11 does not use the I2C protocol for communication. We could have chosen SoftwareI2C for the driver but chose to do it the pure NetMF way and just re-map the pins via a carrier board.

A special reason that I’m ignorant? Genetics I guess. I take after my sister :wink:

Only reason I’m ignorant of Click is just haven’t had a need to explore it yet. I much prefer the Gadgeteer module form factor and try to stick with it whenever possible or create a new module when I can’t but I don’t really have any big complaints about Click or reason not to use them.

Excellent I have some time scheduled with the AMS application engineer for the AS3935 when they get back from vacation, so I’m very much looking forward to this as its a cool chip and not everyone is using it to its full potential which I’m trying to do.

My current driver does seem to be working, but my weather forecast isn’t helping, so anyone else got a AS3935 SPI based breakout board they would like to try my driver on, if so please IM me so we can figure out the best way to get the code/bits to you.

What other breakout boards / chips would people like to see work with Gadgeteer?

All of 'em. I tried this type of thing once, but nobody seemed interested: https://www.ghielectronics.com/community/forum/topic?id=14328&page=2#msg145580

GHI’s (discontinued) Bluetooth module was pretty much an HC-05 (or something similar) on an adapter board with a Gadgeteer socket. It sold for (memory fails me) something like $30. You could reintroduce something like that, sell it for $10, and still make a healthy profit.

it wasn’t a HC-05, although it used the same chips - it was certainly a different firmware.

@ Brett - Yeah, not the standard HC-05 firmware, assuming there is such a thing. They’re all over the place. Either way, they’re all extremely similar.

All over the place, very true :slight_smile: You get what you pay for, for sure !!
I have more than a handful of HC-05’s bought at different times from different vendors, they all appear externally and internally the same (ie they respond to commands the same). Going from memory here (2+ years since last looked in any serious way) but the GHI module has a much better firmware to handle things like name changes and IIRC error situations too. Made a driver much simpler.

I also thought I saw only a few months ago someone selling exactly what you suggested - a HC05 with Gadgeteer socket. Can’t find it now though :frowning: :frowning:

I’m not really interested in selling hardware, just in writing the drivers which likely would be free (I’m not going to decide for folks who do this what is or shouldn’t be free, but I suspect the drivers I write will be freely available). The ultimate idea is just to get more easy to use ‘modules’ for Gadgeteer and really as a software guy help out the hardware guys with drivers.

1 Like

@ Brett - working on the AS3935 chip I’ve looked at all sorts of public drivers and some of them flat won’t work, and some aren’t too bad, but none of them come close to using the full features of the chip, which is one of my objectives (good learning opportunity as well). Now given they are all open source I applaud their authors for posting their code, but certainly not all drivers are created equal.

1 Like

I’ve found that true for the vast majority of DIY hardware out there for sale. Somebody puts together a bare bones implementation (pick any popular chip) and if it works, the usual social channels and forums pick it up. After a very brief surge of interest, they get left behind as the next new shiny thing appears. Even reputable places like Adafruit and Sparkfun leave a lot unfinished. They do encourage the OSHW community to take it and run, but that rarely seems to happen. One exception of late has been the ESP8266. I’ve (literally) got piles of small boards that promised some cool feature, only to find that the provided driver just does the basics. If I was independently wealthy, I might be inclined to implement some of the promised functionality, but reality keeps that dream in check :slight_smile:

1 Like