I deployed the Netduino Plus version of the firmware with OneWire again, to secure I didn't make a mistake with that. I also put OneWire.cs and DS18B20.cs in my own project and removed the DLL. No build errors. When I deploy on the Netduino I get a NotSupported exception on instantiating OneWire, so clearly I did something wrong. I better stay off this for a while .

The Netduino Plus ZIP doesn't contain the DLL or the other code, only the firmware. If I use the one for Netduino the code builds, including with some of the example code, so the class is used, but I get a "hardware error" (very "descriptive") when deploying. Anything obvious I might have done wrong? Cheers, Anders

Hi Anders

Are you using SAM-BA 2.12 fixes some issues with x64 os's...
Also are you using the driver in "drv" folder where you installed sam-ba too or the generic GPS camera driver that windows update discovers, try uninstalling the driver in device manager and manually installing the Atmel driver?
Finally have you erased your ND (3.3v to the gold erase pad) before you try and connect with sam-ba?

Nak.

Yes it's 2.12+.

I used the generic driver (actually I didn't do anything with that). I erased as per the instructions.

I'll try the advice. Thanks.

Hi Anders,

That's very odd. So it did work alright after moving the Netduino to another USB port?

Also, are you using SAM-BA v2.12+? The earlier versions had some issues with Win7 x64.

Chris

Yup. In both cases the ports were detected (COM8 and COM10), so it was nothing wrong with that. My PC supposedly has two different USB controllers, so that might be the reason.

I used 2.12+ (just installed).

I have it going now, so maybe I can help. Did you perform all these steps? http://wiki.netduino...ep-by-step.ashx Cheers, Anders

Revised: It worked if I moved to another USB port (??!?!). After SAM-BA has detected the USB driver and I've selected at91sam7x512-ek and then click "Connect", SAM-BA pops up "Error in startup script" "Error h_handle returned zero" etc. I'm using Windows 7 64, .NET 4.2 and SDK 4.2. Any idea what could cause this to happen? Cheers, Anders

Hi Anders,

Garbage collection should happen automatically whenever memory gets tight. If you allocate an object when there's not enough contiguous memory available, garbage collection should kick in then to try to find you enough space.

I'm following your example but don't quite understand...are you saying that the garbage collector in NETMF 4.2 is not collecting fully and that you need to call Debug.GC(true) to force it to collect?

Chris

I've now updated to 4.2 firmware, so I'll check if it behaves differently, which it should not the least due to the more free RAM, but in any case Debug.GC took the problem away for 4.1. Not that my application uses large arrays or such.

At the time of testing I had .NET 4.2, SDK 4.2 and firmware 4.1.

Hi Anders,

Okay, great, thank you for the clarification.

The Garbage Collector in .NET MF 4.1 had a few limitations--which were fixed in .NET MF 4.2. This is one of the reasons it is so important that all NETMF boards are upgraded to .NET MF 4.2. Incorrectly running out of memory--in production devices deployed in the field--is not a good scenario.

Chris

Agreed!

With .NET 4.2 came changes to how analog inputs (separate from digital pins and scaling) and serial output (Write no longer returns bytes sent) work. I resolved that, yet I get InvalidOperationException instead. I'm not sure on what, as it doesn't point to a specific line in my code. Hopefully I'll find a remedy.

This is how the code looks now. adapt() is somewhat redundant as I can do scaling via AnalogInput, yet I also do border detection there.

public static bool scan(out int X, out int Y)
{
analog1 = new AnalogInput(aX2);
analog2 = new AnalogInput(aX1);
digital1 = new OutputPort(dY1, false);
digital2 = new OutputPort(dY2, true);

int valueX = (int)(analog1.Read() * range);
X = adapt(valueX);

Debug.Print("1: " + valueX);

analog1.Dispose();
analog2.Dispose();
digital1.Dispose();
digital2.Dispose();

analog1 = new AnalogInput(aY1);
analog2 = new AnalogInput(aY2);
digital1 = new OutputPort(dX2, false);
digital2 = new OutputPort(dX1, true);

int valueY = (int)(analog2.Read() * range);
Y = adapt((range - 1) - valueY);

Debug.Print("2: " + valueY);

analog1.Dispose();
analog2.Dispose();
digital1.Dispose();
digital2.Dispose();

analog1 = null;
analog2 = null;
digital1 = null;
digital2 = null;

return valueX != range - 1 && valueY != range - 1;
}

Hi Anders,

Can you please provide a repro case which we can run here? A small, complete project file which raises the exception?

Also, SerialPort.Write should still return the number of bytes written. Are you getting "0" returned each time?

Chris

I include the latest build (with debug info), yet not the source. I can provide that as well if needed.

SerialPort.Write is now void, so it can't return anything.

System.InvalidOperationException occurs both for Microsoft.SPOT and SecretLabs.NETMF classes. For both it usually happen in Thread.Sleep(10) based on Debug.Prints. I never see from the exception what line is causing the problem. When that happens I need to power cycle or reset the Netduino to be able to deploy new software. It's still scan() that causes it, as it works fine if I simply comment out the call to scan and simulate values for touched, X and Y, but I can't see how it's my code's fault per se.

Noted: With Debug.GC: "A first chance exception of type 'System.InvalidOperationException' occurred in Microsoft.SPOT.Hardware.dll", likely at the first call to Debug.GC. Without Debug.GC: Loops for almost 20 times, then hangs.

Hi Anders,

We'll need the source. To understand why you're getting an exception, we need to run the code and see where the exception is thrown.

Alternatively...what line is the exception thrown on?

Chris

OK. Here goes.

I couldn't see what line it happened on. I'm using Express, so maybe it's limited in this regard.

Forgot to attach the file...

A touch screen, using the principle described in Practical Arduino (chapter 8), transferred to Netduino. Except for the "memory loss" problem it all works nicely. The project is described here: http://abiro.com/w/2...uch-the-screen/ I dusted the project off yesterday, to see if I can improve it.

First of all, you can safely upgrade to 4.2, for the Netduino Plus, follow this link:
http://forums.netdui...-firmware-v420/

In that thread, the correct SDKs are linked.

1-Wire is not yet supported in a non-beta build, it's only supported in a specific 4.1.1 beta build.

Good question, I don't -think- it's performed during a sleep. I thought the GC is started at the end of a loop or method. But I can't say for sure, I'm no expert in these matters.
I do know though, that it's possible to force garbage collecting, with Debug.GC(true);

I'm not sure what you're trying to do to be honest. I see you are using the same pins for both digital and analog, but what is connected to it? I ask this, because this could be potentially dangerous. Digital signals are 5V tolerant, analog signals are not.

Great about 4.2, despite 1-Wire. This would be hard to implement on my own in C#, so I won't try in any case .

Garbage collect after a loop or call seems very unlikely (and potentially very inefficient). I'll use Debug.GC instead of Debug.print. Thanks.

A separate response describes the project.

You're looking for broadcast UDP? You should be able to do most/all UDP via the standard firmware.

I believe that Pascal posted something about enabling broadcast UDP. If that's interesting, we could enable that in v4.1.1 pretty easily.

Chris

+1 or even +2 from me too.

Several different topics, but hopefully the answers don't have to be elaborate.

It says "netduino go (and all 4.2 upgrades)" on the download page, and Plus is not mentioned. So should I not upgrade to .NET Framework 4.2 and SDK 4.2 if I have a Plus?

I also wonder if there's new released firmware, as I've been looking for 1-Wire support that was discussed in the forum some time ago. I now have 4.1.1.0.

I upgraded to .NET 4.2 and SDK 4.2 (anyhow) and there's a weird problem with possibly garbage collect. If I run this with a Thread.Sleep of 10 or 100 doesn't matter. It will anyway get out of memory after a rather short while. If I add a Debug.print it will not. Isn't memory management performed during Thread.Sleep?

Sadly below is the only way I've found to switch meaning of different ports. This should not have been handled as instances, for memory and performance reasons. Is there a way to address the ports and port configuration more directly?

The code:

public static bool scan(out int X, out int Y)
    {
        analog1 = new AnalogInput(X2);
        analog2 = new AnalogInput(X1);
        digital1 = new OutputPort(Y1, false);
        digital2 = new OutputPort(Y2, true);

        int valueX = analog1.Read();
        X = adapt(valueX);

        analog1.Dispose();
        analog2.Dispose();
        digital1.Dispose();
        digital2.Dispose();

        analog1 = new AnalogInput(Y1);
        analog2 = new AnalogInput(Y2);
        digital1 = new OutputPort(X2, false);
        digital2 = new OutputPort(X1, true);

        int valueY = analog2.Read();
        Y = adapt((range - 1) - valueY);

        analog1.Dispose();
        analog2.Dispose();
        digital1.Dispose();
        digital2.Dispose();

        analog1 = null;
        analog2 = null;
        digital1 = null;
        digital2 = null;

        return valueX != range - 1 && valueY != range - 1;
    }

Cheers,
Anders

All considered, it works fine if I have one Debug.print in the external loop calling scan(), and hopefully it doesn't lower performance too much when not communicating with a PC, but it seems redundant and a crutch.

I'll post a feature request. Here's a classical case (Nintendo touch screen) where it becomes hairy (and inefficient). Without Dispose I can't re-use/configure the ports, etc. Maybe not all Dispose are needed, but I went for the RAD approach. analog1 = new AnalogInput(X2); analog2 = new AnalogInput(X1); digital1 = new OutputPort(Y1, false); digital2 = new OutputPort(Y2, true); int valueX = analog1.Read(); X = adapt(valueX); analog1.Dispose(); analog2.Dispose(); digital1.Dispose(); digital2.Dispose(); analog1 = new AnalogInput(Y1); analog2 = new AnalogInput(Y2); digital1 = new OutputPort(X2, false); digital2 = new OutputPort(X1, true); int valueY = analog2.Read(); Y = adapt((range - 1) - valueY); analog1.Dispose(); analog2.Dispose(); digital1.Dispose(); digital2.Dispose(); analog1 = null; analog2 = null; digital1 = null; digital2 = null;

I didn't say it was switching between analog and digital, only that I wanted that ability _too_, apart from switching between digital input and output without instantiating. I understood from other posts what you say about the timing. Very nice with upcoming 1-Wire support in the system, and I'll check out the "alpha" version. Thanks.

Yes, that should work, and thanks for the example, but it's essentially compensating for a software design flaw with otherwise perfectly good hardware, which is the wrong way around. Instantiation could still set the initial mode. The only thing needed would be possibility to switch modes via methods afterwards. Analog vs digital is still an issue though, as those classes have different characteristics, but solvable if done as one Port class. My touch screen implementation works fine as it is, but as I've worked with writing hardware drivers I can see the heap getting filled, cleaned up, filled, cleaned up all the time in my mind. Ignorance would be bliss .

I've been hoping someone knowledgeable about wireless options might do a comparison and contrast. And would still welcome it. In the meantime, I stumbled across this one Wireless Comparison

My opinions, seeing it from an overall perspective:

These 433 MHz modules are in my opinion the lowest you can go (price and functionality) in terms of getting any wireless communication at all (except home-brewed solutions). They have a lot of drawbacks except for pure "wireless serial" applications though.

The more expensive 802.15.4 modules work fine too, but are considerably more expensive and are still not directly compatible with everyday equipment like broadband routers, PCs, mobiles etc.

Wi-Fi is the best overall local wireless solution in my opinion, when you consider that it provides Internet access (via an access point), smartphone access (think the phone as a control panel / remote, potentially using custom apps) and potentially also MCU-to-MCU communication (but see above for that). What is not so good is the cost. Power consumption might also be a problem.

Both 802.15.4 and Wi-Fi handle many wireless devices in the same network gracefully, but Wi-Fi is much more contemporary from a network topology and usage perspective in that you simply open IP sockets to communicate with anything, including sites across the world (Pachube anyone?).

If you want a solution that works long distances and potentially globally when talking point-to-point you need GSM/3G. There are a few shields available for that. I haven't seen any CDMA modules so far. On the other hand, point-to-point communication is not so important if the device is static, as it can communicate via the Internet. GSM still beats Wi-Fi if the device is moved around, for instance by being placed in a truck, bus, boat or similar and needs to communicate independently of other equipment, possibly combined with GPS and other means for locating/tracking vehicles.

For a little more (actually cheaper than your suggestion if you needed to do duplex) you could go with this one which has a data rate of 115 Kbps, with buffering, duplex and plenty of other features for $7

And for a little bit more you can get this multi frequency unit which has even more features… why, I don’t know, but it has extra 8 bit ADC, temperature sensor and RX and TX FIFO, and low battery detection for $12.

"Pins spaced by 2 mm." Oh heck!

"Look for a breakout board coming soon!" Someone should make a shield.

In any case both these are probably much better than the solution I bought, for a similar price.

This is how my modules look like: http://twitizer.com/q6y7M (sorry for the flickery photo)
No doubt very easy to connect to a Netduino or Arduino, so I'll still try them first. Maybe I can scare them up to 31.25 kbps somehow. The problem is that it needs to be sustainable speed, so buffering won't help polishing off the peaks.

Thanks for the hint.

I'm working on communicating with a DS18B20 temperature sensor, and part of the example code in Wiring I found in Practical Arduino looks like this: digitalWrite(Pin, LOW); pinMode(Pin, OUTPUT); delayMicroseconds(5); pinMode(Pin, INPUT); delayMicroseconds(60); If I understand correctly, when using the Netduino class library I need to re-instantiate for every new setting of pin mode. Am I right? If so, this is bad design, as generally instantiations for such a simple and very repetitive task should be avoided on a resource-constrained platform like Netduino (and in general). Doing so is extremely "expensive" compared to just switching mode via a static method implemented in Assembly. Has it been considered to not require instantiation when switching modes, including between analog and digital? Cheers, Anders

If you want to go wireless, this is an inexpensive solution: http://www.sparkfun.com/products/10534 http://www.sparkfun.com/products/10532 I wanted to use this solution for making wireless MIDI, but sadly it's too slow (standard MIDI is 31.25 kbps). I haven't checked whether this can be pushed up somehow. The bearer frequency indicates the information bit rate could be much higher than 4800 bps. But for many other uses it should be fine.

You can do multi-threading on Arduino too, yet not as user-friendly. I think the main benefit with Netduino/NETMF is the much better development environment, but in part that's compensated by a more extensive library of drivers, faster code execution, better commercial applicability etc in favor of Arduino. You gain some, you lose some. I'd like to see a model of Netduino with a touch display, making it more suitable as a controller, including in Gadgeteer setups. I2C or 1-Wire seem like good choices for communication between MCUs in general.