GregR

I've finally come to the conclusion that the Go was a 'lesson learned' about jumping in on something early.  We have seen the Go passed up many times in favor of the other boards.  It's almost like the people that spent the $$$ on Go stuff are the ones that are funding all of the new stuff.  I'm to the point where I think Secret Labs should have a 'buy back' program for all of the Go stuff that people bought that is still sitting and gathering dust.  As Olaf said above...there are many things that have been saying 'Shipping soon' and have had that status for over a year now.   I am starting to feel like others and now believe that the Go is basically dead.  If that was not the case then we would see more priority and effort put into it.  Heck...even the Go forum is dead.  I can stay away from them for weeks and when I come back there is only 1 or 2 new posts...and most of them are asking for an update on the stuff that is still missing.  At this time the Gadgeteer Starter Kit looks like a much more sound investment.  It might not all be open source but at least the stuff works when you buy it.

Looks like you are in a constant reboot loop...I would suggest reflashing your Netduino Go. Greg

Chris...it looks like the exceptions are gone. So we will let that go for now.

I will begin doing some tinkering to see if I can capture the data that the Netduino Plus sends as well as the Go. It might take me a few days or so to do this so don't give up on me just becuase I don't respond back to this immediately!

Thanks for the help!

Greg

Chris,

Problem solved...as soon as I captured some of that data I saw that something was amiss. I found the issue in the way I was sending the data to the com port and corrected...now everything works on both boards as expected. It's really cool to see how transparent the GO/Shieldbase is really going to be! Thanks again for your help...and thanks again to Ulrik for his help too!


Greg

Hi Greg,

The static constructors (and the order they're called in) can be an issue in NETMF. Moving the constructors to your Main function where you control the order is the thing to do.

Now that you've done that, are you getting the exception?

Can you tell what data is being sent from the COM2 port on Shield Base? Do you happen to have a logic analyzer (or a cable to attach COM2 to your PC...so you can capture the received data there)?

We're using Shield Base with COM in projects here and it's working great so far. But there is always potential for something that we need to tweak or improve. If we can find out what's going on in your scenario, we can help address it and get you back up and running.

Chris

Chris...it looks like the exceptions are gone. So we will let that go for now.

I will begin doing some tinkering to see if I can capture the data that the Netduino Plus sends as well as the Go. It might take me a few days or so to do this so don't give up on me just becuase I don't respond back to this immediately!

Thanks for the help!

Greg

Thanks Ulrik...After playing around with this I do not think it has anything to do with the order or placement of the initializations. But..just to be safe I have done like you said. It looks like the exceptions were from doing a restart within VS and the Shieldbase was not getting reset when the Netduino go is rebooted...which seems like an issue to me that needs to be fixed.

If I am understanding things correctly then the following 2 code chunks should work identically...the first on the Netduino Plus and the second on the Netduino Go with a Shieldbase connected. (of course they are separate projects and include the appropriate reference for the Netduino model being used).

        public static SerialPort SP;

        public static void Main()
        {
            Debug.Print("Program starting");
            SP = new SerialPort(SerialPorts.COM2, 9600, Parity.None, 8, StopBits.One);
            SP.Open();
            Thread.Sleep(500);
            volume(0x16);
            Thread.Sleep(500);
            set_mode(0x00);
            Thread.Sleep(500);
            Debug.Print("Play SD Track 1");
            play_sd(0x0001);
            Thread.Sleep(500);
            SP.close();
            Debug.Print("Sleep.....");
            Thread.Sleep(Timeout.Infinite);
        }

        public static NetduinoGo.ShieldBase sb;
        public static SerialPort SP;



        public static void Main()
        {
            Debug.Print("Program starting");
            sb = new NetduinoGo.ShieldBase(GoSockets.Socket5);
            SP = new SerialPort(sb.SerialPorts.COM2, 9600, Parity.None, 8, StopBits.One);
            SP.Open();
            Thread.Sleep(500);
            volume(0x16);
            Thread.Sleep(500);
            set_mode(0x00);
            Thread.Sleep(500);
            Debug.Print("Play SD Track 1");
            play_sd(0x0001);
            Thread.Sleep(500);
            SP.close();
            Debug.Print("Sleep.....");
            Thread.Sleep(Timeout.Infinite);
        }

Of course all of the functions I call (volume, set_mode, etc) are included in the project but did not need to be included here as they work on one device but not the other. The only difference between the two chunks of code is that the second one creates a Shieldbase object which is then used in the SerialPort declaration.

When I attach the shield I am working with to my Netduino Plus and use the first code snippet it works perfectly fine and plays audio as expected.

When I attach it to my Netduino Go with a Shieldbase and use the second code snippet above it nevers plays any audio.

So something is not working right with the Shieldbase when trying to use the serial port. I know I've read that other people are using the serial port without issue...so I am trying to understand if I just have something misconfigured or if there is an problem with the Shieldbase stuff, etc. The code is not doing anything weird...it just sends commands as 3 or 4 bytes (one byte at a time) to the shield via the serial port.

Greg