Lunddahl

Check this:

 

http://forums.netdui...tedgelevelhigh/

You you are right, or not, the correct answer is:

 

It depends, and on more than one thing... :-)

 

1. There is more than one Netduino, and they don't all work alike, there is the Netduino Series 1, those includes the Netduino, Netduino Plus and the Netduino Mini, the have a Atmel Micro controller  And then there is the Netduino Series 2, those includes the Netduino 2, Netduino 2 Plus and the Netduino Go, thay have a STMicro STM32 Series Micro controller.

 

2. There is more than one PWM class, and while they do the same, they work differently: SecretLabs.NETMF.Hardware.PWM and Microsoft.SPOT.Hardware.PWM.

 

You will have to add a reference to one of them in your project, and often you also choose to use a using statement, and most code snippets on the forums does not specify witch one is used, because the first one is done in the GUI, and the second one is just often omitted when posting code.

 

While i don't know much about the Series 1 Netduinos, i think they only worked with the SecretLabs PWM class.

 

The Series 2 originally only worked with the Microsoft PWM class, but for the above reasons a lot of people was confused, so one of the resent updates made the Secret Labs class work again, this was part of a lot of things that was done to make code easier to port from the Series 1 Netduinos.

 

When you know the difference it easy to figure out what to do, there is one more thing that might make you life easier.

 

Starting the PWM class with values that "overloads" the MCU, makes it appear hanging, and you will have reset and stop the program to be able to deploy to it again, often that means a reflash, however there are other ways.

 

- Ulrik Lunddahl

Tutorials that are up to date, well written and updated along with the firmware should be here:

 

http://www.netduino.com/projects/

 

Best for everyone.

 

But how do we get them there, Chris ?

This might inspire you if you have a Netduino 2 or Netduino 2 Plus.

 

namespace NP2.Examples_PWM{    public class Program    {        static PWM led1;        public static void Main()        {            led1 = new PWM(PWMChannels.PWM_ONBOARD_LED, 1000, .5, false);                        led1.Frequency = 1000;            led1.DutyCycle = .5;            led1.Start();                        while (true)            {                double startValue, endValue;                for (startValue = 4.712; startValue < 10.995; startValue = startValue + 0.1)                {                    endValue = System.Math.Sin(startValue) * .5 + .5;                    led1.DutyCycle = endValue;                    Thread.Sleep(5);                    if (startValue == 4.712)                    {                        Thread.Sleep(1000);                    }                }            }        }    }}

I have used endless hours getting my Netduino 2 plus to talk to cosm for more than 24-48 hours, it simply just hangs, and it happens in random places of the code.

 

Now i have tried to post the data to a local web server, and the Netduino has been stable for +7 days.

 

This, compared with the fact that only 10-25% of the packets i send to cosm actually gets there, or should i say gets logged in the cosm database, tells me that there is something wrong with cosm, or a combination of me being in europe and cosm being in the states.

 

The local web server logged the requests into a text file, not a single packet missed.

 

However a C# PC console application also posting to cosm, works exactly as expected, no datapoints missing, and the program ran for days before i terminated it.

 

I have no clue as to why, and no change of debugging with external debuggers, but to replicate one only needs a netduino 2 plus + a single DS18B20 sensor and my code, i will be happy to supply my code to SL.

 

I have 3 NP2s, all works the same.

 

- Ulrik Lunddahl

I would recommend to go for the Netduino 2 Plus.

 

The Netduino Go is a very smart concept, but it has proved to be hard to bring to market, and IMHO the most common modules is missing for now.

 

Earlier it was a lot more powerful than the other netduinos, bit with the new netduino 2's the Go does not have that advantage.

 

I still hope the Go will be more attractive in the future, but right now, i only pull it out when there is new firmware updates.

 

- Ulrik Lunddahl

And the current hardware based on STM Cortex MCU's is also Little Indian.

 

Just for the reference...:-)

It's the shield base in disguise...;-)

Upgraded a few NP2 boards today, no problems detected...

From: http://wiki.tinyclr....re_-_TempSensor

 

Better hope it's not freezing...:-)

 

- Ulrik Lunddahl

Sorry for my rant but some people need to learn when it's their turn to speak and to gather more information before they speak.

I hope you include yourself when you mention some people!

You were clearly and in this thread told this:

I understand your feelings, I can tell you that Chris is currently working around the clock to get this dealt with. Please understand it will take some time. I spoke with Chris, and he's away from the Internet working on I2C repro scenarios right now.

However 2 days later you are talking about Secret Labs closing it's doors.

I have talked to my business partners and just based on the complete lack of communication from Secret Labs, we are cautious of continuing to design any products using these boards. They pointed out that lack of communication like this happens when a company is about to bang up and close it's doors. I certainly hope for everyone's sake this is not the case.

The result is this:

I get the "The Debugging Target is not in an initialized state; rebooting" message. I've looked at some of the suggestions for getting over this..some seem to date back a while, and some of the advice seems to expect you to work quite a bit just to get this thing actually working, and frankly I'm a little intimidated I might screw things up.

From what I've read above, should I return this now while I can? Didn't expect these headaches.

From my point of view you should have hold your horses before you went to the keyboard with your frustrations.

I see no reason why i should comment on what i think of your competences as a professional bushiness owner, or when you first were able to go to the toilet by yourself. And i don't understand why you think you have the right to waste the community's time with what you think of the other community members in public on this board.

This whole debate is so derailed that is should be removed from the forum, it serves no constructive purpose.

- Ulrik Lunddahl

Hi There!

I was trying to solve the classic problems around a bouncing contact for my Beer Timer project, and i got caught up into trying to understand all about how an simple InterruptPort works.

Now from what i seem to read InterruptEdgeHigh and InterruptEdgeLevelHigh is generating an interrupt at the same time, on the rising edge, but the latter one is only generating one interrupt and then disables interrupts until the .ClearInterrupt() method is called on the InteruptPort object.

However running the code below, is working fine, but trying to use the "level" type InterruptModes fails with an error, when i try to subscribe to the interrupt event.

A first chance exception of type 'System.ArgumentException' occurred in Microsoft.SPOT.Hardware.dll

on:

Button.OnInterrupt += new NativeEventHandler(Button_OnInterrupt);

The full code is here, however the failing lines is commented out:

using System;
using System.Net;
using System.Net.Sockets;
using System.Threading;
using Microsoft.SPOT;
using Microsoft.SPOT.Hardware;
using SecretLabs.NETMF.Hardware;
using SecretLabs.NETMF.Hardware.Netduino;

namespace NP2.Example_Button_InterruptPort
{
    public class Program
    {
        static OutputPort Led;
        static InterruptPort Button;
        static DateTime Button_LastInterruptTime = DateTime.Now;
        static Boolean Led_State = false;

        public static void Main()
        {
            Led = new OutputPort(Pins.ONBOARD_LED, false);
            Button = new InterruptPort(Pins.ONBOARD_BTN, false, ResistorModes.Disabled, InterruptModes.InterruptEdgeHigh);
            //Button = new InterruptPort(Pins.ONBOARD_BTN, false, ResistorModes.Disabled, InterruptModes.InterruptEdgeLevelHigh);
            Button.OnInterrupt += new NativeEventHandler(Button_OnInterrupt);
            
            Thread.Sleep(Timeout.Infinite);
        }

        static void Button_OnInterrupt(uint port, uint state, DateTime time)
        {
            if (Button_LastInterruptTime.AddMilliseconds(200) < time)
            {
                Led_State = !Led_State;
                Button_LastInterruptTime = time;
                Led.Write(Led_State);
            }

            //Thread.Sleep(10);
            //Button.ClearInterrupt();
        }
    }
}

Why is it not working, is there another thing i do not know yet. :-)

- Ulrik

Well, i'm keeping mine, i think Chris Walker has done a tremendous amount of work to make the netduinos a reality. I do work with other devices, and they are different, they have other bugs and other features, but they are not overall better, just different, and certainly not as loveable as the netduinos and the surrounding community. I see the lack of communication from Chris as a sign of health, he has been under a lot of pressure for a long time, and i guess he is either drinking margaritas or fiddling with fixing bugs. In either case i think he will be coming back strong and full of energy very soonish, and i like to think that this is the best for the netduinos in the long run. Sometimes people just need a recharge, and no one have promised you anything other than a prototype development platform with community support. - Ulrik Lunddahl

I just completed the investigation of the issue and here's what I have observed and my recommendations to move forward.

Congrats on your findings, and thank you for taking the time to write it all up and sharing it.

- Ulrik

Very nice, those reference sheets should be linked to on the product specifications pages. Thanks a lot Steve.