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

Shield Base and GoBus 1.5 beta source


  • Please log in to reply
16 replies to this topic

#1 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 24 September 2012 - 11:09 PM

Some of you will be interested in seeing how the GoBus async transport (using UART) works. Here is the early code being used in Shield Base beta 3.

If you dig in, you'll notice that GoBus includes a remote-procedure-call system complete with responses, exceptions, and asynchronous callbacks. Plus error correction, frame retries, re-syncing, virtual i/o profiles, etc.

This code implements the GoBus 1.5 specification we posted a few weeks ago, using the asynchronous transport.

Attachments:
  • NetduinoGo.ShieldBase.zip -- Shield Base C# driver (for Netduino Go)
  • ShieldBaseProxyServer.zip -- NETMF application running on Shield Base
  • GoBusSerialTransport.zip -- GoBus 1.5 serial transport (used by both of the above)
If desired, you can interactively run the ShieldBaseProxyServer on your upgraded Shield Base (using pins D0/D1 to debug) and add the NetduinoGo.ShieldBase project to your Netduino Go application. You can debug both sides simultaneously using 2 instances of Visual Studio.

If you have any questions about the implementation or questions about the enhancements we're working on (such as thread pools), please let us know!

Chris

P.S. We'll be moving the GoBus plumbing around quite a bit for Netduino Go over the coming weeks. This open source code is for educational purposes only.

Attached Files



#2 supra

supra

    Advanced Member

  • Members
  • PipPipPip
  • 210 posts
  • LocationOntario, Canada

Posted 25 September 2012 - 01:19 AM

not bad, chris.
Too much virusPosted Image

#3 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 25 September 2012 - 01:24 AM

Too much virusPosted Image

Are you feeling ill today?

Chris

#4 supra

supra

    Advanced Member

  • Members
  • PipPipPip
  • 210 posts
  • LocationOntario, Canada

Posted 25 September 2012 - 01:53 AM

Are you feeling ill today?

Chris


LOL! i'm talking abt NGo

#5 Nevyn

Nevyn

    Advanced Member

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

Posted 25 September 2012 - 05:48 AM

Some of you will be interested in seeing how the GoBus async transport (using UART) works. Here is the early code being used in Shield Base beta 3.

Something to look forward to playing with this weekend :)

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


#6 SoundWave

SoundWave

    Member

  • Members
  • PipPip
  • 11 posts

Posted 27 September 2012 - 12:56 AM

Thank you for the release of the source code. If I where to want to tinker in the code to play around with an idea I have how would I go about getting it onto the shieldbase? Next question is how would I go about updating both the NGo and the shieldbase from within a custom windows application. Is it possible to do that? I would like to be able to make an automated update for the mainboard and the shieldbase to use in an idea for a hardware/program combination I had. Thanks, Chris

#7 Christopher Clark

Christopher Clark

    Member

  • Members
  • PipPip
  • 18 posts
  • LocationNorth Carolina, USA

Posted 27 September 2012 - 02:08 AM

Interesting code. I can read C#, but a newbie at this hardware stuff. Any concerns about the speed? With operations traveling over that serial connection? The overhead of encode/decode of the byte array data for all the calls?

#8 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 27 September 2012 - 03:11 AM

Hi Chris,

If I where to want to tinker in the code to play around with an idea I have how would I go about getting it onto the shieldbase?

Next question is how would I go about updating both the NGo and the shieldbase from within a custom windows application. Is it possible to do that? I would like to be able to make an automated update for the mainboard and the shieldbase to use in an idea for a hardware/program combination I had.

You can deploy to both Netduino Go and the Shield Base by scripting the MFDeployEngine class into your project.

We'll be moving the Shield Base to a native code solution...but you'll still be able to programmatically deploy to it via gobus.

Chris

#9 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 27 September 2012 - 03:12 AM

Interesting code. I can read C#, but a newbie at this hardware stuff.
Any concerns about the speed?

With operations traveling over that serial connection?
The overhead of encode/decode of the byte array data for all the calls?

The C# implementation is not performance optimized. We'll want to move to native code for that.

The UART transport is really useful for external IO...but the SPI transport (packet switching) will be the solution for fast virtual i/o.

We'll be doing a lot of performance tuning around packing/unpacking frames. It shouldn't be too much overhead, in the grand scheme of things...especially when considering that transfer will take place in the background using DMA.

Chris

Edited by Chris Walker, 27 September 2012 - 01:03 PM.
corrected spelling


#10 Christopher Clark

Christopher Clark

    Member

  • Members
  • PipPip
  • 18 posts
  • LocationNorth Carolina, USA

Posted 28 September 2012 - 03:31 AM

The C# implementation is not performance optimized. We'll want to move to native code for that.

The UART transport is really useful for external IO...but the SPI transport (packet switching) will be the solution for fast virtual i/o.

We'll be doing a lot of performance tuning around packing/unpacking frames. It shouldn't be too much overhead, in the grand scheme of things...especially when considering that transfer will take place in the background using DMA.

Chris


So it's obvious by the code that the shield base can function as it's own Netduino and run micro framework code. Is this an intended use of the shield base? Is there more information about how to use the shield base as it's own Netduino?

#11 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 28 September 2012 - 03:40 AM

Hi Christopher,

So it's obvious by the code that the shield base can function as it's own Netduino and run micro framework code. Is this an intended use of the shield base? Is there more information about how to use the shield base as it's own Netduino?

As a thank you to beta testers, we've upgraded all the early units to the 512KB STM32F2 chip.

To deploy code directly to Shield Base (and use it as a 120MHz Netduino of sorts)...
1. Flash the original 4.2.0.0 firmware to the Shield Base.
2. Hook up a USB-TTL cable from your computer to pins D1/D2/GND on your Shield Base.
3. Power your shield base via external 3.3V power (or from a Netduino Go if you'd like).
4. Deploy and debug!

Chris

#12 Christopher Clark

Christopher Clark

    Member

  • Members
  • PipPip
  • 18 posts
  • LocationNorth Carolina, USA

Posted 28 September 2012 - 10:55 AM

Chris Walker


Thank you for everything that you do. Your passion for this product and community really is awesome. Some folks can fake it and go through the motions, but it shows that you are truly passionate about the product and people. I am a complete newb to this hardware stuff, but I have learned so much reading this forum and posts you have made. I generally skip over all the love posts where people say thanks, but this is my one time where I want to say, Thank You.

#13 baxter

baxter

    Advanced Member

  • Members
  • PipPipPip
  • 415 posts

Posted 07 October 2012 - 09:42 PM

Hi Chris,

I have updated the Netduino GO main board and ShieldBase to the latest software,

4.2.0.1 NETMF firmware
Shield Base Firmware (beta 3)

I can run the following program just fine,
using System;
using System.Threading;
using Microsoft.SPOT;
using Microsoft.SPOT.Hardware;
using SecretLabs.NETMF.Hardware;
using SecretLabs.NETMF.Hardware.NetduinoGo;
using GoBus;
namespace First_Netduino_GO_Shield
{
    public class Program
    {
        private static NetduinoGo.ShieldBase sb;
        public static void Main()
        {
            sb = new NetduinoGo.ShieldBase(GoSockets.Socket5);
            Microsoft.SPOT.Hardware.OutputPort ledPort = new Microsoft.SPOT.Hardware.OutputPort(sb.Pins.GPIO_PIN_A5, false);
            while (true)
            {
                ledPort.Write(!ledPort.Read());
                Debug.Print("hello");
                System.Threading.Thread.Sleep(1000);
            }
         }
    }
}
However, I am having trouble understanding what functionality is implemented on the ShieldBase. I made
an adapter with two GO sockets and a pin header to expose the signals. When I hookup a Saleae Logic to the
SPI interface, I observe no traffic at all, but the Async Serial (from Matt Isenhower) shows the attachment (RX line).
Does this mean that the mainboard is sending a command to the shield to toggle the led? I guess my
question really is; Can the Shield do someting more useful than interact with its pins on command
from the mainboard? Say for example, I wanted to run a Kalman filter to process measurements on the
shield and then tell the mainboard the result; Is it possible, given the current state of the software? From your comments,
it seems that to run the MF on the shield it is necessary to go to a different software set and if this is so, how does the shield talk to the mainboard?

Baxter

Attached Files



#14 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 07 October 2012 - 10:30 PM

Hi Baxter, GoBus is a virtual i/o protocol. Its first purpose is to add features to the mainboard. This is what the Shield Base does...gives your Netduino Go the pins it needs to work with Arduino shields. The Shield Base temporarily uses the GoBus UART transport, so you'll want to monitor the GoBus port's UART pins if you want to analyze the traffic. Some modules will have additional logic on board. Kalman filters would be a good example of that. If you want to add logic to the current Shield Base code, you can certainly do that. Then just return the filtered results from the function calls. [In the near future, you could also use the Stream profile to request specific info or possibly create your own custom GoBus function calls.] Chris

#15 Lunddahl

Lunddahl

    Advanced Member

  • Members
  • PipPipPip
  • 152 posts
  • LocationEurope, Denmark

Posted 08 October 2012 - 09:47 AM

Will moving to non UART gobus require custom non netmf firmware on the shieldbase ? Have you started developing this custom firmware, and is that what you refer to as "standard gobus module firmware for stm32" How much can be reused from the "standard gobus firmware for STM8" ? With the gadgeteer module, is the Shieldbase really that important, it seems like a huge project, and will it ever be really good with shields, many of them are somewhat Arduino focused, as in they have a library that needs to be ported too. ? I don't like the shieldbase in its current state, I think it's somewhat damaging for the go project as a whole, who knows what modules we would have seen if there were no shieldbase spooking arround to make them obsolete in the near future, just a thought. - Ulrik

#16 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 08 October 2012 - 03:18 PM

Hi Ulrik,

Will moving to non UART gobus require custom non netmf firmware on the shieldbase ?

Have you started developing this custom firmware, and is that what you refer to as "standard gobus module firmware for stm32"

It's definitely possible to implement the GoBus SPI transport in NETMF...but right now we're planning on moving the Shield Base to native gobus firmware when we switch over to SPI transport. The Gadgeteer Adapter and Shield Base will both be using the same core firmware (the standard gobus stm32 firmware).

How much can be reused from the "standard gobus firmware for STM8" ?

The STM8S uses a different architecture. We're trying to reuse as much as we can...but at the native code level they're quite different. Also, STM8S supports the required minimum set of GoBus features (single frame window, CRC8) due to the limited flash and RAM. We wanted to make sure there were both low-end and higher-end chip offerings available, so that module builders could pick the chip that works best for them.

With the gadgeteer module, is the Shieldbase really that important, it seems like a huge project, and will it ever be really good with shields, many of them are somewhat Arduino focused, as in they have a library that needs to be ported too. ?

Community members have developed a lot of C# drivers for Arduino shields over the last two years. This provides hundreds of pre-built components (shields) for Netduino and Netduino Go users...plus the ability to create shield-style custom projects based off of Arduino projects.

Gadgeteer modules are basically on par with Arduino shields technically. Arduino shields are simpler in some ways (single pin layout, easy-to-understand pin sharing requirements) and Gadgeteer modules are nicer in some ways (multiple connection points, many of which can be used at the same time). There are fewer Gadgeteer modules with C# drivers than Arduino shields...but of course almost any of the Gadgeteer modules can be used with the Gadgeteer Adapter, including their C# drivers...so that's a bonus there.

I don't like the shieldbase in its current state, I think it's somewhat damaging for the go project as a whole, who knows what modules we would have seen if there were no shieldbase spooking arround to make them obsolete in the near future, just a thought.

Very interesting. One of our goals with Netduino Go is to empower users with the freedom to use whatever style of components or parts they want to use in their project. With the introduction of the Gadgeteer Adapter, this now includes Gadgeteer modules, Grove modules, and INEX modules as well as Arduino shields and GoBus modules.

I don't think that module builders will be too deterred by the fact that Netduino Go provides backwards compatibility with these other pin-mapping component systems. Technology marches on. I have a serial port and USB ports. I appreciate that I can use the serial port to work with existing gear, but when I buy new gear I will almost always pick USB gear because USB is so much more powerful.

We're focused on GoBus profiles/firmware and GoBus hubs right now, but we have plans to introduce even more GoBus features post-2.0. GoBus 1.5+ modules will continue to gain more and more differentiating functionality automatically. It's going to be pretty cool.

Thank you very much for your thoughts and feedback,

Chris

#17 carb

carb

    Advanced Member

  • Members
  • PipPipPip
  • 352 posts
  • LocationCrystal River, Florida

Posted 08 October 2012 - 08:13 PM

Will moving to non UART gobus require custom non netmf firmware on the shieldbase ?

Have you started developing this custom firmware, and is that what you refer to as "standard gobus module firmware for stm32"

How much can be reused from the "standard gobus firmware for STM8" ?

With the gadgeteer module, is the Shieldbase really that important, it seems like a huge project, and will it ever be really good with shields, many of them are somewhat Arduino focused, as in they have a library that needs to be ported too. ?

I don't like the shieldbase in its current state, I think it's somewhat damaging for the go project as a whole, who knows what modules we would have seen if there were no shieldbase spooking arround to make them obsolete in the near future, just a thought.

- Ulrik

Ulrik,

I think the shieldbase is a good module, but would also like to see a shield made that will give me access to the Go Modules.

This would allow me to do about anything that I can imagine with the equipment that I have and to develop new items that are usable by the maximum number of potential customers. I can prototype on the Go and deploy it on whatever Netduino that meets my needs.

With a shield that works on say an arduino could open additional market for Go and Gadgeteer modules.

While the shieldbase is still in Beta and it may seem to been in Beta for a long time it helps to remember that its firmware and protocols will speed up the development of other modules.

The thing like like best is the rate that the system is evolving. Things only imagined months ago are in production or being made available today.

Reguards,
Chuck




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.