(Image removed)
Sorry, had to remove that image… Funny but can’t be here 
But they are both “arms”… Ferrari and Fiat have 4 wheels and both get you to work.
Same drawings for Fiat vs Ferrari 
It’s a matter of needs and feelings, I think. And money sometimes, of course.
Can we also have the holeyboard back? Make the holey board in 3 or 4 dimensions and everyone can start prototyping again …
My 2 cents worth.
I think Gadgeteer, by design or fluke, hit a market sweet spot. It was the combination of C# coding, an embedded NET environment, and easy to use hardware. It was a middle ground between the C++ embedded world and the entry level Arduino. It did four things: it gave software people easy access to a wide range of hardware, it gave hardware people easy access to feature rich software, it allowed the software/hardware people to focus on the solution rather than the mechanics, and importantly this was all in an environment that could translate into commercial product and job skills.
You could argue that this can be achieved today using development boards and available modules. True and I do this regularly. What was nice about Gadgeteer hardware was the cables provided a more robust prototype than jumper wires, the mounting options of Holey Moley boards and modules with mounting points gave flexibility to layout. In some cases a Gadgeteer “prototype” was very useable in the field. For true productisation there will always be an optimisation step, but this is common to all prototyping systems.
Where Gadgeteer failed, in my opinion, was the whole environment never reached a stable point. This was mainly on the embedded NET side but there was a significant turn over of processing boards as well. It got close to having all the essential capability to serve both hobby and professional users but then something would change and there would be a feeling of starting over again. This made it a hard “sell” (Gadgeteer as a whole, or just the C# and NETMF/TinyCLR aspect) into a work environment, particularly against an established embedded development environment. I acknowledge the fantastic work from Gus and the GHI team. The long term support they offer is great, but this is a different to the long term stability of the concept and maturity of the development environment. I am excited with TinyCLR 2 and SITCore, I hope that this marks that stability point where a personal or business return on investment can be achieved. I appreciate the delicate balancing act required by Gus and the team to continue the embedded NET concept, while ensuring a long term viable business in challenging times.
I should add that this community is also a strength to the whole Gadgeteer / TinyCLR concept. It is the sum of the pieces that makes Gadgeteer what it is, not a specific element. Which makes answering Gus’s original survey difficult.
5 Likes
I had / have them in 3 different sizes 
1 Like
This is really cool. If you get some of that including the quattro in your shop, than the gadgeteer is back! Perhaps even other designers will start creating modules too… nice. Qwiic solutions can also benefit from the holeyboard if they simply adhere to the holyboard grid, perhaps with only one or two screws?? C# is going places…
@Drovers_Dog thank you for the great reply and the fantastic feedback.
It is very wrong to say one system is the answer to every need but we are here learning from the community’s thoughts on what we did right and what we did wrong. We think we know the answer but only the community can decide if we were correct or not.
What size holey board do you want?
I will go box diving and see what I have here.
What do you think about something like the Wio Terminal or the M5Stack, programmable in C# and having a Gadgeteer Sockets plate to be plugged on the back?
And here is the prototype:
2 Likes
Requirements
- Uses tiny JST connector (vertical vs horizontal TBD)
- Uses I2C bus
- Each module has a tiny micro
- Simple high-level protocol stack over I2C (inspired by USB)
- DUE on each module (no TinyCLR) for easier maintenance by GHI and also available for advanced users
- Works with everything under the sun, with provided host samples out-of-the-box (arduino, RPI, TinyCLR, microbit, MicroPython, C++…)
- Marking on each module indicated its “endpoints”, no need to open any datasheet!
- Backward-compatible with Grove, STEMMA and QWIIC
- Standardized mounting holes and size
- Connects in through a dumb hub instead of daisy chain to eliminate the long wire issue.
- TH connection option for header use
- mounting holes with signals to support alligator clip use
- status indicator led
The Ecosystem
Note the lack of mainboards… you should be able to use what you have, including Gadgeteer!
Connections
- breakout HDR
- breakout TB
- Holey
- Holey Moley
- Debugger/programmer
- cables 5cm
- cables 15cm
- hub x4
- hub x16
- powered hub x4
- power bank (lipo)
- stand offs
- IO long range expander endpoint
- IO long range expander midpoint
Displays and LEDs
- OLED display
- 1.8 color display
- character display
- 7" display
- RGB led
- RGB analog Clock
- RGB xmas tree
- RGB ring
- RGB strip
- LED neopixel interface
- LED matrix
- LED matric interface
- digit display
- Tarffic light
HMI Input Sensors
- touch c8
- touch l12
- pot
- slider pot
- keypad
- button
- joystick
- game controller
- cap touch
- limit switch
Sensors
- accelerometer
- magnometer
- gyro accelerometer
- IMU
- IR reflector
- line follower (3 or 5 reflectors)
- hall effect
- microphone
- light sensor
- temp sensor
- barometer
- distance sonar
- dc current sensor
- non invasive ac current sensor
- thermocouple
- gas sensor
- color sensor
- PIR
- flame
- rain drop
- heart beat
- pulse count
- rotary encoder
- sound spectrum
- air quality
Comm
- IR Receiver
- IR Transmitter
- WiFi
- Ethernet
- Bluetooth
- simple wireless
- Lora
- Cell
- RS485
- RS232
- CAN
- ftdi
- DMX
Output
- vibrator
- load module
- maxo
- buzzer
- motor controller
- 3A motor controller
- relay
- relay x16
- moisture
- servo x8
- stepper motor
- 3 axis stepper controller
Function
- GPS
- flash storage
- SD card files
- USB stick files
- micro SD files
- IO expander x16
- RFID
- RTC
- pulse in out
- mp3
- MIDI
How is this for an initial idea?
4 Likes
It’s pretty much everything plus the kitchen sink. Lots to love there, especially in the area of rapid prototyping and rapid development. It fills a nice space.
As a firmware and protocols fellow, I am curious about the I2C protocol and how/whether things like async notification work (even if backed by some form of I2C polling)?
Just like how USB does it, polling. But this is optional… I think.
This will not be real time, just like USB, and even worse than USB. But what module should require real time responses?
It all adds up nicely in my head but maybe I am missing something.
Surprisingly, I was thinking at it the other way around : the mainboard should host different connectors for the “same channel” (call it what you want), so that any or most of the existing sensors could be plugged in.
For example : a Mikrobus socket and, between the headers, a Gadgeteer header and, say, a groove header. If room permits, a third header of another kind like angled male headers in front of the Mikrobus socket.
Those are only examples to expose the idea.
I was thinking at that because it would not imply rebuilding modules with (yet) another different connector. This would be kind of reinventing the wheel.
And there would always be the question about which module, which version of the chip/sensor, and so on. Leave that to Sparkfun, Groove and others.
And, btw, GHI has serious background and knowledge in building mainboards. You should rely on that knowledge, to me : be the best in your domain and not only good in another one.
1 Like
I’m not disagreeing - just wondering about some of the design points and trying to imagine how various scenarios would work.
Real time response : Accelerometer on a balancing robot, maybe? Even there, tens to hundreds of updates per second is probably good enough and polling is probably overall ‘good enough’.
A generalized model for status/errors, polling, and eventing would make driver authoring and app writing easier, so whatever I2C spec comes out of this should include that. I think you are already thinking about device enumeration on the bus too.
Adafruit has their Seesaw platform. Overview | Adafruit seesaw | Adafruit Learning System
“Adafruit seesaw is a near-universal converter framework which allows you to add add and extend hardware support to any I2C-capable microcontroller or microcomputer. Instead of getting separate I2C GPIO expanders, ADCs, PWM drivers, etc, seesaw can be configured to give a wide range of capabilities.”
I am not saying that this is the way this should be done but it might give some ideas of something similar. I have never used it, I just saw it in their new product update a few minutes ago and made me think of this conversation.
One of the modules they use it on is for interfacing to a rotary encoder. Adafruit I2C Stemma QT Rotary Encoder Breakout with NeoPixel [STEMMA QT / Qwiic] : ID 4991 : $5.95 : Adafruit Industries, Unique & fun DIY electronics and kits
Correct and unified status LED. I will update my post.
1 Like