The GoBus Upgrade
#1
Posted 29 September 2012 - 05:37 AM
With plug and play GoBus modules. And GoBus Virtual I/O. All open source.
And while all of that is cool, the real value comes in what it does for you.
The first six months of GoBus was about creating a platform. The next six months is about delivering new hardware, introducing new capabilities to the core protocol, and enabling ridiculously large projects.
I have lots of news to share. Here are some highlights.
New Hardware
SD Card modules have arrived, and we'll be posting a firmware update to support them soon (within a few weeks). We didn't want to ship them this weekend and have users disappointed that the supporting firmware wasn't available yet...but we'll be releasing them to resellers shortly.
For the Ethernet modules: we discovered two errata in relation to the ENC28J60 chip and the revised design should be going into production this month (October). I'll post an update on that soon...
Finally, GoBus 1.5 enables Virtual I/O for all modules. Over the next month, we'll start laying out a number of new modules (Ambient Light, XBee Adapter, and RS-232 to begin with). We have another ten modules queued up for next year.
Third parties are also working on modules, and we're expediting the interoperability logo approval process for them so that they can get new modules to you quickly. We're also working on a click-through agreement for royalty-free logo licensing.
Hundreds of modules, lots of amps
As more and more GoBus modules arrive in the market, we know that many of you will want more modules in your projects than you have GoPorts on your mainboard. And while Netduino Go can deliver up to 500mA of 3.3V power to modules, we know that some projects will need more power as well.
GoBus was architected for the future. That future includes hubs. Wired and wireless. Powered (adding more available current to your project) and unpowered. And much more.
We're currently developing an 8-port powered hub. It's the size of Netduino Go but it has an upstream GoPort and a power barrel instead of a Micro USB jack. You simply plug it into your mainboard and you get 8 more GoPorts. Plug in an external power adapter and you get a dedicated power boost for downstream modules.
You'll be able to add up to 255 modules to your project, several hubs deep if desired.
Along with the 8-port hub, we'll also be enabling Netduino Go itself to be a wireless hub using an XBee link. Simply plug XBee Adapter GoModules into two Netduino Go mainboards and you can make one the extension of the other. It's pretty awesome. We'll be sharing video of that feature in action in the near future.
Hubs are a feature of GoBus 2.0. All GoBus 1.5+ compliant modules will work with hubs. It's backwards-compatible.
Giving Gadgeteer the GoBus Upgrade
One of the big values of Netduino Go is the ability to use lots of pre-built components in your projects. Without needing to worry if you have enough of a particular feature (UARTs, PWMs, etc.). And without being constrained to any single component system.
After less than six months, there are now over a dozen GoBus modules in production. And the Shield Base is designed to let users plug in hundreds of pre-built Arduino shields. That's a lot of pre-built options.
Two years ago, at World MakerFaire 2010, researchers from Microsoft Research introduced their Gadgeteer component system. They asked if we could give Netduino users the capability to work with their component system as well.
GoBus 1.5 makes that possible. Virtualization is magic that way.
So we're giving Gadgeteer the GoBus upgrade. Without the expense of dedicated motherboards, the complexities of derated sockets, or worries about having too many of a certain letter-type of module and not enough of that type of socket.
Today we introduce the Gadgeteer Adapter module for Netduino Go. 4 Gadgeteer sockets, $14.95, available in November.
Powered by GoBus Virtual I/O, each adapter gives you 4 Gadgeteer sockets. You can plug in multiple Gadgeteer Adapters to support more modules. They will even work on a wireless hub.
Whether you are looking for the ultimate Gadgeteer mainboard or for backwards compatibility with Gadgeteer hardware, Netduino Go has you covered.
For those who would like to help us do final performance testing, we're giving out a limited number of free samples at MakerFaire NY. The beta program starts in November and works with all existing Netduino Go mainboards.
The Future
This is just the beginning. We have several years of enhancements planned and revise these plans based on your feedback. Together we can make magic happen.
Thank you for joining us on this journey. I look forward to seeing what you create.
Chris
- Arron Chapman, Gutworks, ErikN and 2 others like this
#2
Posted 29 September 2012 - 06:47 AM
Attached Files
#3
Posted 29 September 2012 - 06:59 AM
#4
Posted 29 September 2012 - 10:05 AM
Twiiter: https://twitter.com/Gutworks
#5
Posted 29 September 2012 - 11:42 AM
For anyone who doesn't know much about the Gadgeteer modules I found this chart useful:
A - Three analog inputs, with pins number 3 and 4 doubling as general-purpose input/output. In addition, pin number 6 is a general-purpose input/output, and pin number 3 supports interrupt capabilities.
I - I2C interface. Pins 8 and 9 are the dedicated I2C data (SDA) and clock (SCL) lines. Note that a mainboard should include pull-up resistors for these pins, in the region of 2.2K Ohms. Modules must not include their own pull-ups on these lines. In addition, pins 3 and 6 are general-purpose input/outputs, with pin 3 supporting interrupt capabilities.
K - UART (serial line) interface operating at TTL levels, with hardware flow control capabilities. Pin 4 (TX) is data from the mainboard to the module, and pin 5 (RX) is data from the module to the mainboard. These lines are idle high (3.3V), and can double as general-purpose input/outputs. Pin 6 (RTS) is an output from the mainboard to the module, indicating that the module may send data. Pin 7 (CTS) is an output from the module to the mainboard indicating that the mainboard may send data. The RTS/CTS are 'not ready' if high (3.3V) and 'ready' if low (0V). In addition, pins 3 is a general-purpose input/output, supporting interrupt capabilities.
U - UART (serial line) interface operating at TTL levels. Pin 4 (TX) is data from the mainboard to the module, and pin 5 (RX) is data from the module to the mainboard. These lines are idle high (3.3V), and can double as general-purpose input/outputs. In addition, pins 3 and 6 are general-purpose input/outputs, with pin 3 supporting interrupt capabilities.
O - Analog output on pin 5. In addition, pins 3 and 4 are general-purpose input/outputs, and pin 3 includes interrupt capabilities.
P - Three pulse-with modulated (PWM) outputs on pins 7, 8 and 9. Pins 7 and 9 double as GPIOs. In addition, pin 3 is an interrupt-capable GPIO, and pin 6 is a GPIO.
S - Serial peripheral interface (SPI). Pin 6 is the chip-select (CS) line, pin 7 is the master-out/slave-in (MOSI) line, pin 8 is the master-in/slave-out (MISO) line, and pin 9 is the clock (SCK) line. In addition, pins 3, 4 and 5 are general-purpose input/outputs, with pin 3 supporting interrupt capabilities.
#6
Posted 29 September 2012 - 11:58 AM
#7
Posted 29 September 2012 - 12:49 PM
- Arron Chapman likes this
#8
Posted 29 September 2012 - 10:28 PM
#9
Posted 30 September 2012 - 10:53 AM
- Arron Chapman likes this
#10
Posted 30 September 2012 - 12:07 PM
#11
Posted 30 September 2012 - 09:38 PM
#12
Posted 01 October 2012 - 12:25 AM
Along with the 8-port hub, we'll also be enabling Netduino Go itself to be a wireless hub using an XBee link. Simply plug XBee Adapter GoModules into two Netduino Go mainboards and you can make one the extension of the other. It's pretty awesome. We'll be sharing video of that feature in action in the near future.
Will this work the same way as the Netduino Go and Shield Base proxy example?
Where the primary transmits it's functions async over serial via byte arrays to the secondary?
#13
Posted 01 October 2012 - 03:52 AM
Good question, thanks for asking about this.Will this work the same way as the Netduino Go and Shield Base proxy example?
Where the primary transmits it's functions async over serial via byte arrays to the secondary?
Yes, all the data will use the GoBus frame format and GoBus profiles, just like the Shield Base does today. In fact, the XBee wireless hub option is why we're keeping the Shield Base on UART transport for a little bit extra time. We want to make sure that the transport is functioning really well in the field (since we'll use the same code with XBee as well).
The secondary Netduino Go will be receiving hub profile commands, just like a physically-connected hub. That profile will wrap other gobus packets so that they make it to their destination (which can be directly connected to the hub or can be downstream even farther).
Chris
#14
Posted 01 October 2012 - 04:31 AM
- Arron Chapman likes this
#15
Posted 02 October 2012 - 07:10 PM
#16
Posted 02 October 2012 - 07:18 PM
We'll work through the hub profile using a second Netduino Go as a hub this winter (via a serial/XBee link) and then use those profiles on the production hub hardware.What's the expected time frame for the hub, when will it be available? I see you say that they'll be a part of GoBus 2.0 and realize that 1.5 just came out but was just wondering what the expected time frame is.
The eight-port hub module should ship by the spring.
There are three major new features coming with GoBus 2.0: hubs, power injectors, and a hub-related surprise.
Chris
#17
Posted 02 October 2012 - 07:56 PM
The secondary Netduino Go will be receiving hub profile commands, just like a physically-connected hub. That profile will wrap other gobus packets so that they make it to their destination (which can be directly connected to the hub or can be downstream even farther).
How much of this is based in C# serial code vs. using Zigbee source / destination configuration?
Is this approach XBee specific?
Are there any other Zigbee compatible devices frequently used in the Arduino/Netduino community which are not XBee?
Could another serial connection other than XBee be used with the code?
Could two Netduino Go boards be wired up over TX/RX for example and use this code?
#18
Posted 02 October 2012 - 08:00 PM
The wireless hub feature could work under any asynchronous transport. In this case we'll simply be using a SerialPort.How much of this is based in C# serial code vs. using Zigbee source / destination configuration?
Is this approach XBee specific?
Are there any other Zigbee compatible devices frequently used in the Arduino/Netduino community which are not XBee?
So you'll pair the two boards using XBee pairing. And then the Netduino Go acting as a hub will be directing packets to/from the appropriate module.
The Arduino/Netduino community typically uses XBee for 802.15.4-based communication. Generally with the Serial Port profile.
Chris
#19
Posted 07 October 2012 - 01:54 AM
#20
Posted 07 October 2012 - 02:25 AM
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users