What is the GPIO (pin 3) Line used for on GO modules?
#1
Posted 13 April 2012 - 11:53 PM
I work for Microsoft. Opinions expressed here are my own and do not necessarily reflect those of my employer,our partners or customers.
#2
Posted 14 April 2012 - 12:01 AM
#3
Posted 14 April 2012 - 01:36 AM
#4
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
I work for Microsoft. Opinions expressed here are my own and do not necessarily reflect those of my employer,our partners or customers.
#5
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
Doable?
Pete
I work for Microsoft. Opinions expressed here are my own and do not necessarily reflect those of my employer,our partners or customers.
#6
Posted 14 April 2012 - 02:03 AM
#7
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
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