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

I have upgraded my ShieldBase to the beta 4 firmware and my Go to the 4.2.1.0 firmware. I also unzipped the ShieldBase DLL stuff into the SecretLabs Assemblies directory. And I made sure I added that reference to my project. The simple code below throws a "An unhandled exceptopn of type 'System.Exception' occurred in GoBusSerialTransport.dll" when I try to create the ShieldBase object. Below is some very simple code that fails. I need to know what is causing this issue. I am sure I have just missed something with all of the manual ShieldBase file installations. The line below with ====>> is the line of the exception.

using System;
using System.IO.Ports;
using System.Threading;
using Microsoft.SPOT;
using Microsoft.SPOT.Hardware;
using SecretLabs.NETMF.Hardware;
using SecretLabs.NETMF.Hardware.NetduinoGo;


namespace GoTest
{
    public class Program
    {
====>>> public static NetduinoGo.ShieldBase sb = new NetduinoGo.ShieldBase(GoSockets.Socket4);
        public static SerialPort SP = new SerialPort(sb.SerialPorts.COM2, 9600, Parity.None, 8, StopBits.One);

        public static void Main()
        {
            Debug.Print("Program starting");
            Thread.Sleep(Timeout.Infinite);
          }
    }
}

Hi supra,


We're updating the Shield Base updater to work with the 4.2.1+ firmware. It tries to reserve some I/O pins what are already reserved and an exception is thrown.

We should have an update for it by the end of next week, alongside the 4.2.1.1 update.

Chris

Hmmm...in the other thread on the updater issues you said around 3 days...now we have gone to 2 weeks. I guess that's why I get so frustrated. I keep waiting and waiting for the shieldbase to work fully but then something new comes out and then the shieldbase has to take the back seat to the new toys.

Hi Greg,

We'll need to update the reflash app for the latest Netduino Go firmware. It will take a day or three; we're working on it...

Chris

Ok..I'll give you 2!

I just tried using the Shieldbase updater after upgrading my Go to the 4.2.1.0 firmware. I also made sure to update the .Net Micro framework and the Netduino SDK.

It fails with "An unhandled exception of type 'System.Exception' occurred in Microsoft.SPOT.Hardware.dll" message.

The line of code it stopped on was:

_socketLeds[0] = new OutputPort((Cpu.Pin)0x16, false);

This was in STM32Bootloader.cs

So at this point I cannot update my 2 Shieldbases...how do we fix this?

Greg

Some of us weren't born for a few years yet in 1984 (I'm not even going to mention Omar) hell in 84, my mother was 14 .

You and Chris are making some of us feel really old...

Chris,
serious, try the next:
- deploy your N+ with a static IP address
- Go to your router, forward your port with a new port like 54321 (example)
- in your code, in stead of port 80, the new port.
bye-bye trouble......

snippet example....

const iPORT as integer = 54321 (example)
Dim hostEntry As IPHostEntry = Dns.GetHostEntry(host)
Dim hostAddress As IPAddress = hostEntry.AddressList(0)
Dim remoteEndPoint As New IPEndPoint(hostAddress, iPORT)
Dim connection = New Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp)
connection.Connect(remoteEndPoint)
          

I also see that this example is using a TCP connection where the original code at the top of the thread was using UDP. So more than one thing changed. The protocol changed AND the port number changed.

Oh, gotcha. Netduino Go can definitely support OneWire. But it doesn't have pins for OneWire to work on...it has GoPorts that you can plug modules into.

So we need modules which support OneWire and then we can use it over GoBus. We should be able to do that on Shield Base fairly easily, and maybe on the Gadgeteer Adapter as well.

Chris

I was definitely referring to the Shield Base...not the Netduino Go by itself. I guess the bottom line for me is, since the Shield Base is supposed to bring Arduino 'compatibility' to the Netduino Go then I would expect that it would support everthing that the Arduino supports protocol wise.

Greg

I think the bigger point is what indimini stated about OneWire support: "I still don't understand why, when it is part of the standard 4.2 NETMF build, Go doesn't support it." Greg

Hi eplaksienko,


We're working on the SPI transport for GoBus 1.5 right now. It should be out later in the year. All the GoBus 1.5 gear will be compatible with GoBus 2.0 as well.

The beta program for the Gadgeteer Adapter will start next month. We'll be gathering performance metrics to make sure that we're happy with the performance metrics and then will move it out of beta.

Chris

It's really going to suck if this Gadgeteer Adapter comes out of beta before the Shield Base does...I think I will abandon all of this if that is what happens. Seems like the Shield Base keeps getting put on the back burner for all of the newly announced stuff. I would like to see the Shield Base become fully functional before the Gadegeteer Adapter. Yes...as you can see...I am frustrated.

Greg

Would be interresting to get more insight on this yes.

But I guess, that the cpu on the module/shieldbase need to have enough capability to run the full protocol in hardware, that, spi, i2c etc, and the data is sendt back using spi to the Go mainboard, in chunks. (I think I read about frames somewhere here?)

I would assume that it has to be the full protocol on the shieldbase or otherwise we would have I2C (as well as everything else) available today.

I don't want to have lights for the giggles, as far as I know, the leds on the go are not user addressable?, but are they addressable on the DAQ?

And,yes, you could do things with the display, but then we have this sleep issue.., only way for sleep on the display now, is to shut off the go-port, right?

an rgb light for some info could be nice, pulsate to show that the device is operative, but display is sleeping, one color for warnings, another for other type of notifications perhaps (like what the rgb-led on androids do)

I would still like to see a firmware update that let's us turn the display backlight on and off. That seems like the best solution to this.

Ok, I feel dumb, I know the answer is in an obvious place, but I can't seem to locate it. I even read all the parts of the datasheet for the MCU related to I2C, but no luck. Here goes:

Can someone tell me which pins on the Netduino Plus that are used for I2C? I'm used to arduino with the analog pins being used, and I cant just try it out, because I don't have any I2C compatible things right now, I am just looking into getting them.

Thanks

Daniel

It is on pins A4 (SDA) and A5 (SCL)

Perhaps an SDK setup for your drivers with an actual version to go by so we know if we have the latest Fabien?

I would like to second this also. A simple setup app that installs the assemblies for those of us that don't need the source, etc.

Greg

Greg, Ken,

I wanted to let you know that the Nwazet DAQ module provides an I2C interface and it works with sensors anywhere from 10kHz to 400kHz.
This module only takes a single socket on the Go! main board and uses a 16 MHz SPI interface.

Cheers,
-Fabien.

Fabien,

Looks like a very nice module! But I cannot justify spending another $80 just for I2C when I have 2 ShieldBases just sitting here waiting to be used and collecting dust.

Greg

Did you ever get this working? I have been playing with a DS1621 and I cannot get a temperature reading out of that thing at all.

Hello,
My Netduino projects have been on hold for while, and so I am trying to start up again. I upgraded my tool chain as well as the firmware on my netduino plus to 4.2. I have not changed anything regarding Visual C# 2010 Express (not sure I have to?). The hardware seems to be working fine, but I am having deployment issues and when I check the bin > Release folder for the current project, it's empty. Below is my build and release output. My project properties seem to be the same as earlier projects I've done. Any ideas?

------ Build started: Project: YetAnotherEmail, Configuration: Debug Any CPU ------
YetAnotherEmail -> C:\Users\Mike\Documents\Visual Studio 2010\Projects\YetAnotherEmail\YetAnotherEmail\bin\Debug\YetAnotherEmail.exe
========== Build: 1 succeeded or up-to-date, 0 failed, 0 skipped ==========


Incrementally deploying assemblies to device
Deploying assemblies for a total size of 68956 bytes
Assemblies not successfully deployed to device.
Deployment to the device was not successful.

Since you are building a 'Debug' configuration you need to look in 'bin\Debug' instead of 'bin\Release'

Ok, when do you think I2C will work Chris?

Now it feels like I got me a GO, Nwazet Go Tinker Kit and two sheilds that I can not use as I thought ;-)

/Ken

I'm right here with Ken on this one. Got a table top full of toys...with alot of $$$ invested...but cannot use them the way I thought I could. I was thinking that the Go! would be backwards compatible at a minimum in that I could use the Shield Base connected to the Go! and have it act just like a Netduino/Netduino+. That is not the case..and to be honest I am starting to lose interest. I understand this is a new product...just expected it to be able to do what the previous Netduinos can do from the start.

Just my $.02 worth...

Also, it appears the functionality to turn the power on/off for a specific socket is not yet available.

Hi Greg,

To conserve power when you don't need the display, I'd recommend turning the display off completely instead, through the Go! socket power control.

Cheers,
-Fabien.

That would work but then I have to maintain the state of what is on the display. If I could just disable the backlight everything would stay in place and be immediately readable when the backlight was turned back on. Maybe you can make that available in a future firmware update.

Thanks for the quick response...

Greg

I was just wondering if there is any programatic way to turn off the backlight on the nwazet display. It would be good to be able to do this when the app is idle for a long period of time and you want to save power. Is this possible? Also, what about the power LED on the module? Thanks! Greg