Introducing GoBus 1.5 - Netduino Go - Netduino Forums
   
Netduino home hardware projects downloads community

Jump to content


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.
Photo

Introducing GoBus 1.5


  • Please log in to reply
39 replies to this topic

#1 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 05 September 2012 - 08:25 PM

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.

Attached Files


Edited by Chris Walker, 15 September 2012 - 02:58 AM.
updated attachment


#2 Fred

Fred

    Advanced Member

  • Members
  • PipPipPip
  • 302 posts
  • LocationUK

Posted 05 September 2012 - 08:34 PM

Awesome. Although it makes me a bit embarrassed that I still haven't found the time to do any module development. :o

#3 Matt Isenhower

Matt Isenhower

    Advanced Member

  • Members
  • PipPipPip
  • 74 posts
  • LocationSan Diego, CA

Posted 05 September 2012 - 08:41 PM

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 :D Matt
Komodex Labs
Follow me on Twitter: @mattisenhower

#4 Gutworks

Gutworks

    Advanced Member

  • Members
  • PipPipPip
  • 363 posts
  • LocationOttawa, Ontario

Posted 05 September 2012 - 09:40 PM

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! :D

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!!

Cheers,
Steve

#5 nakchak

nakchak

    Advanced Member

  • Members
  • PipPipPip
  • 404 posts
  • LocationBristol, UK

Posted 05 September 2012 - 10:28 PM

Awesome stuff Chris! :)

Cant wait to get stuck into building some modules!

Keep up the good work.


update
Initial comments on the beta documentation are as follows:
  • Should have a table on contents
  • Possibly worth putting a "Beta" watermark on all pages, save hassle of someone printing a copy then discovering that the docs were out of date?
  • Page numbers (especially helpful for people posting feedback to be able to refer to the exact page...)
  • Some message exchange diagrams would be invaluable to help people get their heads around correct sequence of operations/application.
Hopefully these comments wont be taken negatively, just some thoughts for improvement :)



Nak.

(ps. now feels honoured that he has a frame type named after himself :P ;) )

#6 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 06 September 2012 - 12:56 AM

Initial comments on the beta documentation are as follows:

Those are all great comments. We'll get some/all of those suggestions incorporated as the document evolves.

(ps. now feels honoured that he has a frame type named after himself :P ;) )

:lol:

Chris

#7 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 06 September 2012 - 01:06 AM

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

#8 Nevyn

Nevyn

    Advanced Member

  • Members
  • PipPipPip
  • 1072 posts
  • LocationNorth Yorkshire, UK

Posted 06 September 2012 - 07:58 AM

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.

Regards,
Mark

To be or not to be = 0xFF

 

Blogging about Netduino, .NET, STM8S and STM32 and generally waffling on about life

Follow @nevynuk on Twitter


#9 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 06 September 2012 - 09:22 AM

Hi Nevyn,

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.

Chris

#10 supra

supra

    Advanced Member

  • Members
  • PipPipPip
  • 210 posts
  • LocationOntario, Canada

Posted 06 September 2012 - 10:18 AM

@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.Posted Image

So i ordered last tuesday. My item will be arriving todayPosted Image. Do i have to get new shield base v1 .5?Posted Image

Btw, I was reading gobus protocol specification. ThankPosted Image

#11 nakchak

nakchak

    Advanced Member

  • Members
  • PipPipPip
  • 404 posts
  • LocationBristol, UK

Posted 06 September 2012 - 10:26 AM

@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.Posted Image

So i ordered last tuesday. My item will be arriving todayPosted Image. Do i have to get new shield base v1 .5?Posted Image

Btw, I was reading gobus protocol specification. ThankPosted Image


Hi Supra

Its a software change not a hardware change.

Nak.

#12 supra

supra

    Advanced Member

  • Members
  • PipPipPip
  • 210 posts
  • LocationOntario, Canada

Posted 06 September 2012 - 10:35 AM

Hi Supra

Its a software change not a hardware change.

Nak.



Thank godPosted Image

Btw, is software or not?Posted Image

#13 supra

supra

    Advanced Member

  • Members
  • PipPipPip
  • 210 posts
  • LocationOntario, Canada

Posted 06 September 2012 - 10:51 AM

Awesome. Although it makes me a bit embarrassed that I still haven't found the time to do any module development. :o



Count me inPosted Image

#14 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 07 September 2012 - 12:15 AM

Hi nakchak,

Page numbers (especially helpful for people posting feedback to be able to refer to the exact page...)

Update: I just added page numbers and also a section on royalty-free licensing of the gobus interoperability logo.

Chris

#15 awaiK

awaiK

    Advanced Member

  • Members
  • PipPipPip
  • 90 posts

Posted 07 September 2012 - 05:31 AM

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.

#16 supra

supra

    Advanced Member

  • Members
  • PipPipPip
  • 210 posts
  • LocationOntario, Canada

Posted 07 September 2012 - 10:33 AM



Update: I just added page numbers ........

Chris


Where is attach file?Posted Image

#17 nakchak

nakchak

    Advanced Member

  • Members
  • PipPipPip
  • 404 posts
  • LocationBristol, UK

Posted 07 September 2012 - 10:37 AM

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.

#18 supra

supra

    Advanced Member

  • Members
  • PipPipPip
  • 210 posts
  • LocationOntario, Canada

Posted 08 September 2012 - 03:30 AM

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.


Thank! I didn't even know abt this updated at the top.

#19 neslekkim

neslekkim

    Advanced Member

  • Members
  • PipPipPip
  • 350 posts
  • LocationOslo, Norway

Posted 08 September 2012 - 04:02 PM

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.

--
Asbjørn


#20 supra

supra

    Advanced Member

  • Members
  • PipPipPip
  • 210 posts
  • LocationOntario, Canada

Posted 08 September 2012 - 04:53 PM

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..


YEAH! Posted Image




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

home    hardware    projects    downloads    community    where to buy    contact Copyright © 2016 Wilderness Labs Inc.  |  Legal   |   CC BY-SA
This webpage is licensed under a Creative Commons Attribution-ShareAlike License.