go!bus feature announcement: chained go!bus modules - 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

go!bus feature announcement: chained go!bus modules


  • Please log in to reply
24 replies to this topic

#1 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 17 July 2012 - 09:04 AM

We were planning this surprise for this autumn, but several community members have asked if go!bus supports chained modules.

The answer to that question is: yes.

We built chaining support into the hardware specs for go!bus and Netduino Go from the beginning, knowing that we wanted to enable this feature via software. All Netduino Go mainboards will support this feature.

A few quick technical details:
  • any go!bus module can be attached to any go!bus module chain.
  • chained go!bus modules use fast, error-corrected, streamed packet relaying.
  • go!bus modules with downstream (chained) sockets use a Cortex-M0 or better microcontroller.
  • chaining adds $1.00-$2.00+ to the component cost of a module. On average, it probably adds $3-$5 to the end user cost.
This brings up a good question:
What modules would you like to see with a downstream (chain) port?

BTW, we will include "zero coding" chaining support in the standard io firmware for STM32F microcontrollers. We're working on the standard io firmware for STM8S now...but STM32F is next on our list. Module builders will be able to simply specify which pins and features of the microcontroller to expose, attach one SPI channel and one UART and a few GPIOs to both sockets, and assign a module GUID.

Any questions...please feel free to ask here. There are some technical details that we're holding off on until after we've completed performance testing, but we have a lot of deep technical detail we can share for those who are interested in building or using chained go!bus modules (or who are just curious).

Chris

#2 nakchak

nakchak

    Advanced Member

  • Members
  • PipPipPip
  • 404 posts
  • LocationBristol, UK

Posted 17 July 2012 - 09:27 AM

Awesome stuff Chris!!! :)


Well heres a quick list of modules i would like to see to be chainable...

  • Motor Module
  • Environment Sensors (Temp, Humidity, light, pressure etc.) although i suspect that would need some sort of sensor bus spec as well to allow different sensors to communicate over a single bus...
  • Rotary Encoder's
  • RS232/IrDA Serial Ports
  • Relays
Sure i will think of more... ;)




Nak.

#3 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 17 July 2012 - 09:29 AM

Hi nakchak, Thanks for the list! I'm curious: why could these modules in particular benefit from chaining? Is it because it's an extra feature which is useful? Because it adds "one more port"? Because those module types are intrinsically suitable for chains due to physical layout of modules chaining from the mainboard? I agree that chaining support is cool... Now we need to figure out a good set of "best practices" to recommend its use in modules that benefit the most. Chris

#4 neslekkim

neslekkim

    Advanced Member

  • Members
  • PipPipPip
  • 350 posts
  • LocationOslo, Norway

Posted 17 July 2012 - 09:30 AM

Does the chaining need to be done on the actual module?, that would require new modules of everything? What about an bus-extender, an plank with say, 4 to 8 sockets?, and where sockets are chained..

--
Asbjørn


#5 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 17 July 2012 - 09:36 AM

Okay, here's a quick technical tidbit to inspire a few technical questions: Let's say that a module at the end of a chain runs at a low speed and only supports ~40kbps communication. In this case, messages to that module will still be carried down the chain at the fastest possible speed (up to tens of mbps). The root module in that chain will raise an IRQ to the mainboard when the message has been delivered, freeing up the mainboard's go!bus channel for other traffic. In this way, other traffic can flow on the bus and chained modules can actually free up more bandwidth. Counter-intuitive, I know. In many circumstances this speed boost may be negligible, and in some cases the chaining may increase bus utilization slightly, but it's this kind of attention to detail which hopefully creates strong value for both users and module builders. Chris

#6 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 17 July 2012 - 09:43 AM

Does the chaining need to be done on the actual module?, that would require new modules of everything?

If a module wanted to support chaining, it would add a downstream socket. But every module (past, present, and future) supports being plugged into a chain.

We're not planning on adding downstream ports to any of the current modules: chaining seems to make the most sense for specific types of modules. In most cases, it's nice to leverage the extra BOM budget to use really nice components (rather than adding a socket that might not add value).

What about an bus-extender, an plank with say, 4 to 8 sockets?, and where sockets are chained..

That's certainly possible. Since all the sockets are interchangeable on the mainboard, most users may be well served by eight sockets. But if users need a switched hub or chained modules with multiple downstream ports...we can evaluate support for that as well.

Chris

#7 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 17 July 2012 - 09:54 AM

  • i suspect that would need some sort of sensor bus spec as well to allow different sensors to communicate over a single bus

Ooh, that brings up a good question (and usability note) about go!bus chains.

With I2C, each module on a chain has to have a distinct address. If you plug in two sensors with the same I2C address they conflict.

There are lots of ways that people work around this (DIP switches, pin rotation mechanisms that limit the # and/or type of sensors that can be used, etc.).

But with go!bus chains, you just plug in modules and they work. Multiple modules of one type are fine as are mixed modules.

Chris

#8 nakchak

nakchak

    Advanced Member

  • Members
  • PipPipPip
  • 404 posts
  • LocationBristol, UK

Posted 17 July 2012 - 10:23 AM

I'm curious: why could these modules in particular benefit from chaining?


  • Motor Module - Would be nice to be able to chain controllers together, for uses such as 3d printing, i.e. each chain link is an axis, plus quite a lot of motor controller IC's intrinically support chaining (mostly SPI, so unsure how applicable it is to GO chaining)
  • Environment Sensors (Temp, Humidity, light, pressure etc.) although I suspect that would need some sort of sensor bus spec as well to allow different sensors to communicate over a single bus..., well chaining thermomters or other measuring devices would allow you to average results/have multiple probes
  • Rotary Encoder's, would strike me as being a bit wasteful to require a port per encoder, especially for control surfaces, often want several pots/encoders, also would be pretty sweet for motor control as you could add an encoder per motor module thus adding a feed back loop per motor for rotational measurement which would allow cheap motors to become servo's....
  • RS232/IrDA Serial Ports, always useful to be able to add multiple serial ports for interfacing to other bits of hardware.
  • Relays, when is one relay enough ;)


Nak.

#9 neslekkim

neslekkim

    Advanced Member

  • Members
  • PipPipPip
  • 350 posts
  • LocationOslo, Norway

Posted 17 July 2012 - 10:35 AM

Downstream ports would add extra complexity on the modules, and for us who want to make our own modules, and add downstream ports we would have to test every scenario that all modules would work, like rgb, buttons etc. Chaining directly would make more sense, and should not add extra complexity on the exsisting modules (but I don't know the architecture of go!bus (is it released somewhere?)) Regarding i2c, if one had an specific module, with i2c connector, you could yourself add all the i2c devices in the world to this module, and thereby chain yourself, I suspect the same applies to other busses like spi? (haven't read up properly on that yet) I have seen this, and are not sure if I like this scenario: http://www.tinyclr.c...m/topic?id=7257 The only module there that i would have chaining for is led matrixes, but think I would add my own chaining for that exact usage, than to use an generic allpurpose chaining mechanism that would make me have to tweak and follow other rules.

--
Asbjørn


#10 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 17 July 2012 - 10:50 AM

Hi neslekkim,

Downstream ports would add extra complexity on the modules, and for us who want to make our own modules, and add downstream ports we would have to test every scenario that all modules would work, like rgb, buttons etc.

That's actually one of the beautiful things about go!bus chaining... Your downstream port is switched packet traffic, handled by the go!bus firmware on the module's microcontroller. So you just need to test that you wired it up properly...and all modules should just work.

The pins aren't just being "connected through"...the data is being forwarded like IP traffic going through a router.

Regarding i2c, if one had an specific module, with i2c connector, you could yourself add all the i2c devices in the world to this module, and thereby chain yourself, I suspect the same applies to other busses like spi? (haven't read up properly on that yet)

Yes, exactly. Creating an "I2C" module would let you connect a chain of I2C devices to that module. It would appear to the mainboard as an I2C bus. No go!bus chaining needed.

You can also do this with RGB LED strips that use their own chaining protocol...just create an RGB LED strip controller and hook up the strip.

The only module there that i would have chaining for is led matrixes, but think I would add my own chaining for that exact usage, than to use an generic allpurpose chaining mechanism that would make me have to tweak and follow other rules.

Now that is a cool application that makes sense. You could use either go!bus chaining or your own system (wrapped by your module's driver). You have total freedom there which way to go...

Chris

#11 neslekkim

neslekkim

    Advanced Member

  • Members
  • PipPipPip
  • 350 posts
  • LocationOslo, Norway

Posted 17 July 2012 - 11:09 AM

That's actually one of the beautiful things about go!bus chaining... Your downstream port is switched packet traffic, handled by the go!bus firmware on the module's microcontroller. So you just need to test that you wired it up properly...and all modules should just work.

The pins aren't just being "connected through"...the data is being forwarded like IP traffic going through a router.


That's exactly what I don't want to get involved in, if I create say, and an 7segment module, and used that chaining protocol, i would implement maybe an stm8 to control it (or some other easy stuff), but to use that protocol to chain next 7segment, or add an button at the end, I need to program that controller to also handle all incoming data, find out what's for me, and what's not, and pass that on, and I need to do this fast, so I don't add to the latency for next module.
If I buy an other module and add into these, I and that module is not coded properly, and it adds extra delay or latency, I cannot do anything about it, than pray that the developer of that module fixes the code, or remove it.
With plain chaining, all pins through, everyone gets the data at the same time, and picks what's addressed to them.
(I still have to add that I know to little about the go!bus today, as of what of this are applicable or not.. )

Is there any document on the go!bus?

--
Asbjørn


#12 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 17 July 2012 - 11:26 AM

That's exactly what I don't want to get involved in, if I create say, and an 7segment module, and used that chaining protocol, i would implement maybe an stm8 to control it (or some other easy stuff), but to use that protocol to chain next 7segment, or add an button at the end, I need to program that controller to also handle all incoming data, find out what's for me, and what's not, and pass that on, and I need to do this fast, so I don't add to the latency for next module.

For scenarios like this where you want to treat multiple pieces of hardware as one, need precise timing, etc. then using your own custom (non-go!bus) chaining is the right choice. Multiple 7-segs chained together is a really good example.

Is there any document on the go!bus?

Here's a good start:
http://wiki.netduino...ders-Guide.ashx

There's additional documentation in the go!bus team's internal wiki and being drafted for the new profile and packet specs. I'll see if we can start copying that over and getting it in document form as well. We hadn't intended on bringing module developers onboard until later this summer or autumn, but there has been so much interest that we've been manually seeding details...and it would be good to get it all in one place so everyone can benefit early on.

Chris

#13 neslekkim

neslekkim

    Advanced Member

  • Members
  • PipPipPip
  • 350 posts
  • LocationOslo, Norway

Posted 17 July 2012 - 11:53 AM

For scenarios like this where you want to treat multiple pieces of hardware as one, need precise timing, etc. then using your own custom (non-go!bus) chaining is the right choice. Multiple 7-segs chained together is a really good example.


Here's a good start:
http://wiki.netduino...ders-Guide.ashx

There's additional documentation in the go!bus team's internal wiki and being drafted for the new profile and packet specs. I'll see if we can start copying that over and getting it in document form as well. We hadn't intended on bringing module developers onboard until later this summer or autumn, but there has been so much interest that we've been manually seeding details...and it would be good to get it all in one place so everyone can benefit early on.

Chris



Btw, the cpu on the go does have 3 spi channels, 37mbit/s each, but there are only two that is used today right?, with 4 sockets each?
So if you add an highdemanding module, like sdcard, ethernet, display, or soundmodule, you need to be careful to where you add these, since the bandwith will be shared.
And then, when you add ie stm8 based daisychained modules, they typically have only 8mbit/s bandwith on their spi bus to share, so there need to be some considerations as to how to attach stuff so you don't get into problems.

With all the features that the stm32f4 shares, it's kinda sad that only the spi and uart are exposed, but I guess we will have some guidelines about how to do things similar to the shieldbase so we can add extra features, but for .net code, it will look like it's directly on the mainboard.

--
Asbjørn


#14 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 17 July 2012 - 12:15 PM

Hi neslekkim,

Btw, the cpu on the go does have 3 spi channels, 37mbit/s each, but there are only two that is used today right?, with 4 sockets each?

It has 3 SPI channels, although only one of them is 37mbps (and only at certain MCU frequencies). We recommend a speed closer to 20mbps.

The third SPI channel is currently being used to control the power FETs to each socket. We did some number crunching and 4 sockets per go!bus channel (and therefore per SPI channel) worked out to be a nice match.

So if you add an highdemanding module, like sdcard, ethernet, display, or soundmodule, you need to be careful to where you add these, since the bandwith will be shared.

Our goal with go!bus is to take these worries away. The same issue exists on USB, with shared bandwidth per "root hub". But it's hardly ever, ever an issue. There are some smart bandwidth management techniques we can use, and I'm sure we'll refine these over time.

For advanced users, sure you can dedicate a go!bus channel to an IO module to get the maximum possible throughput. Just like you can with USB. Seeking maximum performance goes with the hacker territory :)

And then, when you add ie stm8 based daisychained modules, they typically have only 8mbit/s bandwith on their spi bus to share, so there need to be some considerations as to how to attach stuff so you don't get into problems.

Won't be a problem with chained modules. The modules with downstream ports must run Cortex-class micros with 10s of mbps transfer speed. If you plug an STM8S module into a chain, it won't have a downstream port...and any messages being relayed to it will transfer at faster speeds until they get to the STM8S module. [Responses will also be relayed via the fastest switched packets back to the mainboard.]

With all the features that the stm32f4 shares, it's kinda sad that only the spi and uart are exposed, but I guess we will have some guidelines about how to do things similar to the shieldbase so we can add extra features, but for .net code, it will look like it's directly on the mainboard.

Oh, you can use lots of features on the STM32F4. On the socket, the SPI is used for fast DMA transfer of go!bus packets...and the UART is used for reflashing the module. But on your module itself, you can use an STM32F4 to provide tons of AnalogInputs, I2C channels, UARTs, etc. You could even use the display feature.

[On the Netduino Go mainboard, yes we are only using the SPI and UART of the STM32F4. But that's on purpose. The mainboard is designed so that all microcontroller peripherals are added on externally...so UART and SPI are just a means for reflashing and data transfer. Effectively the mainboard is "naked" until you add features via modules.]

These are great questions. Thanks for your insights, and please keep the questions coming!

Chris

#15 neslekkim

neslekkim

    Advanced Member

  • Members
  • PipPipPip
  • 350 posts
  • LocationOslo, Norway

Posted 17 July 2012 - 12:40 PM

For advanced users, sure you can dedicate a go!bus channel to an IO module to get the maximum possible throughput. Just like you can with USB. Seeking maximum performance goes with the hacker territory :)


Yes :), when it's documented that way, so one know the limitatons and posibilites. (I sometimes read threads that makes me wonder :) )

Won't be a problem with chained modules. The modules with downstream ports must run Cortex-class micros with 10s of mbps transfer speed. If you plug an STM8S module into a chain, it won't have a downstream port...and any messages being relayed to it will transfer at faster speeds until they get to the STM8S module. [Responses will also be relayed via the fastest switched packets back to the mainboard.]


Ah, so one requirement for all chained modules would be an stm32 then?

Oh, you can use lots of features on the STM32F4. On the socket, the SPI is used for fast DMA transfer of go!bus packets...and the UART is used for reflashing the module. But on your module itself, you can use an STM32F4 to provide tons of AnalogInputs, I2C channels, UARTs, etc. You could even use the display feature.

[On the Netduino Go mainboard, yes we are only using the SPI and UART of the STM32F4. But that's on purpose. The mainboard is designed so that all microcontroller peripherals are added on externally...so UART and SPI are just a means for reflashing and data transfer. Effectively the mainboard is "naked" until you add features via modules.]


This is kinda what I started to think about with arduino's, they kinda suck a bit when it comes to do lot of things at the same time, so I wanted to use smaller duino's for smaller tasks, that would talk back to an master duino that collected and sendt information to an maincomputer (have been fiddling with ideas for an chicken/egg-farm, reading temperatures, lightlevel, airquality and so on, on multiple places in the building)

But now the netduino is doing the same, and on better hardware so it's more fun about what's going on here :)

--
Asbjørn


#16 nakchak

nakchak

    Advanced Member

  • Members
  • PipPipPip
  • 404 posts
  • LocationBristol, UK

Posted 17 July 2012 - 01:43 PM

Ah, so one requirement for all chained modules would be an stm32 then?


The answer is in Chris's original post:

3. go!bus modules with downstream (chained) sockets use a Cortex-M0 or better microcontroller.

So i guess STM32F0's are the cheapest options, with STM32F4's for maximum grunt :)

Nak.

#17 neslekkim

neslekkim

    Advanced Member

  • Members
  • PipPipPip
  • 350 posts
  • LocationOslo, Norway

Posted 17 July 2012 - 02:01 PM

The answer is in Chris's original post:

3. go!bus modules with downstream (chained) sockets use a Cortex-M0 or better microcontroller.

So i guess STM32F0's are the cheapest options, with STM32F4's for maximum grunt :)

Nak.


Ah, I think I stumbled in the paragraph after that, where stm8s is mentioned :)

--
Asbjørn


#18 Matt Isenhower

Matt Isenhower

    Advanced Member

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

Posted 17 July 2012 - 03:32 PM

Great stuff Chris! :)

chaining adds $1.00-$2.00+ to the component cost of a module. On average, it probably adds $3-$5 to the end user cost.


Just to expand on this point a bit, I imagine the downstream socket would need to implement the same features as those present on each socket on the mainboard, including:
  • A socket connector (of course ;))
  • Two P-channel MOSFETs to switch the 3.3V/5V power lines
  • A gate driver to control the two power MOSFETs from the 3.3V microcontroller (e.g., an NPN transistor + base resistor + 5V pullup resistor)
  • An LED (and resistor, and possibly a transistor to drive it) next to the socket connector to indicate status

Then it would just be a matter of wiring up everything to the microcontroller. Is that all correct? :)

Matt
  • Chris Walker and Arron Chapman like this
Komodex Labs
Follow me on Twitter: @mattisenhower

#19 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 17 July 2012 - 06:59 PM

Hi nak and Matt,

So i guess STM32F0's are the cheapest options, with STM32F4's for maximum grunt :)

For now, yes. But I'm hoping to see Cortex-M0+ (and possibly other manufacturers' chips) as options in the future too...possibly reducing the cost even more.

Then it would just be a matter of wiring up everything to the microcontroller. Is that all correct? :)

Yes, that sounds about right! We might have some tweaks to this for cost optimization purposes.

Chris

#20 nakchak

nakchak

    Advanced Member

  • Members
  • PipPipPip
  • 404 posts
  • LocationBristol, UK

Posted 18 July 2012 - 02:55 PM

Had another thought... Will the downstream port act as as a repeater i.e. rebuffer the signals (much like an ethernet switch or hub will do) so you can run longer leads etc. And what would the realistic maximum length of interconnect you could use be? I guess its a bit late now but its a shame you cant use cat5/6 as the interconnect medium as its easy to get hold of shielded cables which would help with long lead lengths in a noisey environment... Nak.




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.