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

What is the GPIO (pin 3) Line used for on GO modules?


  • Please log in to reply
6 replies to this topic

#1 Pete Brown

Pete Brown

    Advanced Member

  • Members
  • PipPipPip
  • 138 posts
  • LocationAnne Arundel County, MD

Posted 13 April 2012 - 11:53 PM

It's labeled the IRQ line and is attached to the processor on at least the LED module. What is it used for? Do you need that to indicate to the module code that one of the virtualized pins has an interrupt? I was going to use it as a signal line to tell my module which mode to put itself in, but looks like it's already spoken for. :) Pete
Pete Brown - http://10rem.net (NETMF, C++, Windows, C64, and general geekery) Twitter: @pete_brown
I work for Microsoft. Opinions expressed here are my own and do not necessarily reflect those of my employer,our partners or customers.

#2 Fabien Royer

Fabien Royer

    Advanced Member

  • Members
  • PipPipPip
  • 406 posts
  • LocationRedmond, WA

Posted 14 April 2012 - 12:01 AM

the GPIO line on the Gobus! can be used as a signaling method from the module to the main board. For instance, I use it as a synchronization mechanism in the Touch Display firmware to let the main board know that the display has completed processing a command set and that it's ready for a new batch. There's no reason why you couldn't use it for signaling something from the main board to the module, with one caveat: on the STM32Fx, it's also used to kick a module into bootloader mode for reflashing purposes( when the GPIO line is held high on module boot). If you keep that restriction in mind, you can use the GPIO line which ever way you please :) Hope this helps. -Fabien.

#3 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 14 April 2012 - 01:36 AM

Hi Pete, In simple (i.e. 589-based ID-only) modules, pin 3 is used as a GPIO pin. You can use it to turn things on/off on the module (such as with an LED or relay). Or to signify state to the mainboard (such as with a button or contact switch). On advanced go!bus modules, pin 3 acts as an IRQ pin. It tells the mainboard that the module needs attention. This will be handled by the standardized virtual IO firmware for you... It will be asserted whenever there's more data for the mainboard to retrieve (incoming serial data or an InterruptPort event for instance) or when a response has been generated (a response to a go!bus protocol message like "how much power do you need?"). Remember that when you're designing advanced modules...go!bus is virtualized. So you're effectively just hooking up the MCU to connect the mainboard to its pins...and then you write your driver intelligence in C# on the mainboard. You will of course be able to tweak the firmware on the module to add some intelligent processing on that nice dedicated MCU...but you won't be able to create your own communication protocol between the mainboard and the module. There are really good reasons for that which will become very clear as we unveil more go!bus goodness--and which I think you'll really appreciate. Chris

#4 Pete Brown

Pete Brown

    Advanced Member

  • Members
  • PipPipPip
  • 138 posts
  • LocationAnne Arundel County, MD

Posted 14 April 2012 - 01:40 AM

the GPIO line on the Gobus! can be used as a signaling method from the module to the main board. For instance, I use it as a synchronization mechanism in the Touch Display firmware to let the main board know that the display has completed processing a command set and that it's ready for a new batch. There's no reason why you couldn't use it for signaling something from the main board to the module, with one caveat: on the STM32Fx, it's also used to kick a module into bootloader mode for reflashing purposes( when the GPIO line is held high on module boot). If you keep that restriction in mind, you can use the GPIO line which ever way you please :)

Hope this helps.
-Fabien.


Thanks Fabien. So on the STM8S, I should be ok keeping it high or low as required by my module?

I'm thinking of using this as a general pattern for switching between go!Bus and regular uart (or gpio) communications for modules that will target the GO as well as classic arduino form-factor and Gadgeteer.

Unless there's a better way built-in to the design, I plan to have the go!bus driver hold that pin high to tell the module to run in GO mode. Anything else would just keep the pin low to tell it to use the default communication mechanism. (Or swap high/low here if that makes more sense).This would also cause a switch chip to reroute the usart lines to the SWIM/reset lines, which is the main reason behind this added complexity.

Short of physical jumpers (which I suspect will go agianst the "it just works" statement Chris made about the GO logo), I'm not sure how else to approach the problem. If I missed something simple, please let me know :)

Pete
Pete Brown - http://10rem.net (NETMF, C++, Windows, C64, and general geekery) Twitter: @pete_brown
I work for Microsoft. Opinions expressed here are my own and do not necessarily reflect those of my employer,our partners or customers.

#5 Pete Brown

Pete Brown

    Advanced Member

  • Members
  • PipPipPip
  • 138 posts
  • LocationAnne Arundel County, MD

Posted 14 April 2012 - 01:53 AM

Remember that when you're designing advanced modules...go!bus is virtualized. So you're effectively just hooking up the MCU to connect the mainboard to its pins...and then you write your driver intelligence in C# on the mainboard. You will of course be able to tweak the firmware on the module to add some intelligent processing on that nice dedicated MCU...but you won't be able to create your own communication protocol between the mainboard and the module. There are really good reasons for that which will become very clear as we unveil more go!bus goodness--and which I think you'll really appreciate.


Hmm. Ok. I'm at a real loss here then. I want to create modules that work with the GO bus, but the non-GO bus market is quite a bit bigger (Netduino Classic, Plus, Arduino, Gadgeteer). How can I intelligently create hardware modules that work with all of the above, while leveraging the go bus? Tying up four ports for compatibility mode doesn't seem like a good design. I know I wouldn't buy modules that did that unless I had no other choice. I get the virtualized pins concept, but was planning to leverage these modules a bit more.

From other discussions, I had assumed that the Go bus communication code on the module chip can be just part of what's on there (IOW, doing more than a tweak). If I need to offload a bunch of processing to native code on the chip, I could do that. Is that not the case?

Take the MIDI module, for example. I'm thinking it would be good to be able to offload certain functions to the module chip:
  • Soft thru
  • Responding to Active Sense messages (which some synthesizers send every 300ms during idle)
  • Discarding incomplete messages
  • Filtering messages to only those targeting channels you are interested in
In that way, I can lessed the load on NETMF. (btw, this is why I asked you if there's a standard way for me to set configuration options/settings/variables on the modules)

Doable?

Pete
Pete Brown - http://10rem.net (NETMF, C++, Windows, C64, and general geekery) Twitter: @pete_brown
I work for Microsoft. Opinions expressed here are my own and do not necessarily reflect those of my employer,our partners or customers.

#6 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 14 April 2012 - 02:03 AM

Hi Pete, You can definitely do that processing on the module. You could aggregate data, wrap up all your communication in a read/write stream, or whatever you'd like. You have a lot of freedom...we just need to make sure that the mainboard sees the module as a virtual device. It's a similar concept to USB...you just plug things in and they're added to your system. As far as compatibility with other boards go...we can certainly make that happen. The GPIO on STM8S modules _is_ free during boot...and you could use that and perhaps the SPI_SS pin to signify a mode switch (between go!bus mode and custom mode). We can work this into the official protocol standard so that there's an easy way to "kick out of go!bus mode" for you. Chris

#7 Pete Brown

Pete Brown

    Advanced Member

  • Members
  • PipPipPip
  • 138 posts
  • LocationAnne Arundel County, MD

Posted 14 April 2012 - 02:10 AM

Hi Pete,

You can definitely do that processing on the module. You could aggregate data, wrap up all your communication in a read/write stream, or whatever you'd like. You have a lot of freedom...we just need to make sure that the mainboard sees the module as a virtual device.

It's a similar concept to USB...you just plug things in and they're added to your system.


Awesome, thanks. I think the virtual device will be fine. I need to play with it, but it sounds like everything I do will fit into that concept.

As far as compatibility with other boards go...we can certainly make that happen. The GPIO on STM8S modules _is_ free during boot...and you could use that and perhaps the SPI_SS pin to signify a mode switch (between go!bus mode and custom mode). We can work this into the official protocol standard so that there's an easy way to "kick out of go!bus mode" for you.


Now we're talking. I'm happy to help you with use-cases here. Specifically, I want to think about the ones I mentioned: Arduino, Netduino Classic, and .NET Gadgeteer. If the modules can work with those just by setting SPI_SS to a certain state by the driver, when the board is booted (and user code is executed), that could work.

I still need to sort out the actual line switching (usart rather than SWIM/Reset), but having a standard approach in the protocol is a good start.

Pete
Pete Brown - http://10rem.net (NETMF, C++, Windows, C64, and general geekery) Twitter: @pete_brown
I work for Microsoft. Opinions expressed here are my own and do not necessarily reflect those of my employer,our partners or customers.




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.