The Netduino forums have been replaced by new forums at community.wildernesslabs.co.
This site has been preserved for archival purposes only
and the ability to make new accounts or posts has been turned off.
Since we shipped Netduino Go this spring, thousands of people have been introduced to GoBus and Virtual I/O.
Over the last few months we have been listening to feedback and working on the next version of GoBus.
Today we take things to the next level. Today we introduce GoBus 1.5.
To date, Netduino Go has been using GoBus 1.0. The first version included auto-discovery of devices and provided mechanical, electrical, and reflashing specifications. In effect it laid the physical groundwork for fully interoperable, plug and play-modules for .NET Micro Framework.
With Shield Base, we also introduced the GoBus Virtual I/O concept. With GoBus 1.5, we're performance-optimizing that same Virtual I/O and bringing it to all GoBus modules.
GoBus 1.5 is the first version targeted for module builders. It can be implemented on tiny resource-constrained microcontrollers yet it has powerful features which take full advantage of higher-end microcontrollers. And it's a royalty-free, open source protocol.
Over the coming weeks, we'll be updating Netduino Go and the Shield Base to GoBus 1.5. We'll also be sharing a fully-C# implementation of the GoBus transport layer which can be used on regular Netduinos.
And of course we'll be shipping several new GoBus modules...including a "mystery module" which ships with GoBus 1.5 out of the box.
GoBus 1.5 modules will work side-by-side on your Netduino Go with GoBus 1.0 modules.
Highlights:
Virtual I/O profiles auto-enumerate and add features (peripherals) of slave MCUs to master MCU
Up to 128 instances of each I/O profile per device (UART, GPIO, ADC, PWM, STREAM, etc.)
255 GoBus devices supported per bus
Up to 63 concurrent function calls (threads) per device
No data stream interruptions:
Up to 15 simultaneous outstanding frames per device, ACKs included with every frame
Media independent, supports multiple transport options:
Synchronous fixed-length frames (e.g. SPI frame exchange)
Asynchronous variable-length frames (e.g. UART, XBee, Bluetooth SPP)
I've attached the first beta release of GoBus 1.5 to this post. We wanted to get a bit more feedback from the community before we formalized all the virtual I/O profiles...so please participate in that conversation and we'll update the document as we go.
Chris
P.S. Thank you to Matt Isenhower and others who spent a significant amount of time working through edge case scenarios and implementation details to make GoBus 1.5 a reality.
Thanks Chris! I'm really looking forward to where this takes the platform and some of the new features it will enable
Any bets on the mystery module? So far it seems to be doing a great job creating mysteries
Matt
Great work Chris et al.! It's exciting to see the GoBus evolve into a powerhouse protocol that enables module builders to stretch their imaginations. I'm sure we'll start to see many more innovative modules using the GoBus protocol emerge while watching the Netduino Go ecosystem expand exponentially. GoBus is the way open-source electronics was meant to be!
These are fun times indeed. Now I have to try and wait patiently for the release of the SD, Ethernet, and Mystery Module! There's also something new and exciting cooking up over at Nwazet, and Komodexis on the cusp of releasing it's Character LCD. And, then there's Variable Labs with a couple of really cool new additions coming soon, and ByteMaster with his amazing NiVek Go Quad Coptor threatening to take over the Florida skies. Oh my. So many things, so little money!!
Oh dang, I almost forgot a very important thing:
The SPI transport used by GoBus 1.5 can vary its clock speed based on error rate.
This sets the groundwork for variable-speed SPI transmissions. Longer cables tend to pick up noise and degrade signal quality.
To start with, we will retransmit frames when necessary. Going forward, we'll start to work out smart speed algorithms which adjust the clock rate dynamically.
At its fastest, GoBus can give us a data throughout speed of ~20Mbps. That's up to 50 times as fast as fast I2C.
Zoom zoom.
Chris
I've attached the first beta release of GoBus 1.5 to this post. We wanted to get a bit more feedback from the community before we formalized all the virtual I/O profiles...so please participate in that conversation and we'll update the document as we go.
Good to see that you are allowing for simple devices to use a default feature set.
Profiles (Page 12) - Have you thought about adding a profile to allow the storage of data in the chip (i.e. configuration)?
How will the protocol deal with two modules on the same chain? I'm having problems finding that information in the specification. I'm thinking two modules in a chain of the same type being a worst case.
Are we correct in assuming that default firmware will be available in either source or a "flashable" form?
My main questions around the specification really boil down to the actual implementation. I can see module developers falling into two main groups:
1 - Simple modules where the control is performed by the Netduino GO! and the module acts as a slave using default firmware
2 - Modules with some in built intelligence.
For option 1 I can see that there would be little need for the developer to do anything other than install default firmware on the modules controller. So assuming that you are providing default firmware then I don't really see this being a problem.
With option 2 I would like to think that the firmware could be "plug and play" in the sense that the module developer could remove items not needed in order to give more memory space on the module. One thing running through my mind is that this implementation of this protocol on the STM8 is going to be tight. I can see some instances where the developer is really only going to want to tap into the comms, work out what is for me so I can process the data and have anything else passed on / default behaviour etc.
Profiles (Page 12) - Have you thought about adding a profile to allow the storage of data in the chip (i.e. configuration)?
That's an excellent idea. The STM8S has 128 bytes of EEPROM...which would be great for storing configuration data. On the STM32F0, perhaps we could "emulate EEPROM" using one or two pages of 1KB flash?
Are you thinking page-addressable or byte-addressable?
How will the protocol deal with two modules on the same chain? I'm having problems finding that information in the specification. I'm thinking two modules in a chain of the same type being a worst case.
We'll give each module an address, regardless of where it is in the system. Chains are an interesting feature we can support, coming with GoBus 2.0. We've architected things to allow for them later on...but right now we're focused on delivering the best experience with modules which are plugged directly into Netduino Go.
Are we correct in assuming that default firmware will be available in either source or a "flashable" form?
Yes. As source and probably in both forms, although we're still working out the details of GoBus configuration settings. I like using the EEPROM for that on STM8S, but as you noted it might be good to keep that empty for storage. We want to provide a good variety of simple options.
1 - Simple modules where the control is performed by the Netduino GO! and the module acts as a slave using default firmware
For option 1 I can see that there would be little need for the developer to do anything other than install default firmware on the modules controller. So assuming that you are providing default firmware then I don't really see this being a problem.
We'll make sure it's really easy. We will provide default firmware and source templates for STM8S and STM32. Since GoBus is an open standard, it may get ported to AVR, NXP Cortex-M0, etc. by others as well.
2 - Modules with some in built intelligence.
With option 2 I would like to think that the firmware could be "plug and play" in the sense that the module developer could remove items not needed in order to give more memory space on the module. One thing running through my mind is that this implementation of this protocol on the STM8 is going to be tight. I can see some instances where the developer is really only going to want to tap into the comms, work out what is for me so I can process the data and have anything else passed on / default behaviour etc.
That's really good feedback as well. Our goal is to conditionally-compile all the profiles (peripheral features) so that each one can compiled out with a simple change of constants.
And you are correct...this is especially important on STM8S. The default configuration for GoBus is designed for tiny devices like STM8S with a single-frame window and single function call. But I can see lots of scenarios where a developer might not need virtual PWM but would want larger buffers or more room for their custom code.
For custom modules, the plan is to run the GoBus transport and frame processing as interrupts so that the developer can focus on adding their logic where it makes the most sense for them (main loop or interrupts). And with hardware CRC8 support and the ability to miss frames, we should be able to find a good balance.
We're working on the STM32F0 GoBus 1.5 firmware right now, and will be moving onto the STM8S firmware next. If you'd like to be involved in either effort, we certainly welcome your participation.
@ChrisU said , With Shield Base, we also introduced the GoBus Virtual I/O concept. With GoBus 1.5, we're performance-optimizing that same Virtual I/O and bringing it to all GoBus modules. So i ordered last tuesday. My item will be arriving today. Do i have to get new shield base v1.5?
Btw, I was reading gobus protocol specification. Thank
@ChrisU said , With Shield Base, we also introduced the GoBus Virtual I/O concept. With GoBus 1.5, we're performance-optimizing that same Virtual I/O and bringing it to all GoBus modules.
So i ordered last tuesday. My item will be arriving today. Do i have to get new shield base v1.5?
Btw, I was reading gobus protocol specification. Thank
Hi,
congratulations for releasing GoBus 1.5.
Honestly, I didn't pay GoBus much attention in the past, so I'm might be not up to date. But nevertheless I think, the document needs a (little) introduction which describes what's the purpose of the GoBus protocol is.
The first post has been updated,
Wouldn't be very helpful to post multiple copies of a work in progress, just update the authoritative source at the top, then people can reliably get the most up to date copy
Nak.
Wouldn't be very helpful to post multiple copies of a work in progress, just update the authoritative source at the top, then people can reliably get the most up to date copy
Nak.
Thank! I didn't even know abt this updated at the top.
yes, strange that the forum doesn't show when an post have been edited, normally that is shown in other forums..
Hm, seems it does, if user selects it when editing..
Edited by neslekkim, 08 September 2012 - 04:03 PM.