Chris Walker's Content

#63529 Network stops working on the hour or one minute after

Posted by Chris Walker on 15 July 2015 - 01:02 AM in Netduino.IP Technical Preview

Hey Tim,

Do you have Wireshark, and either an old-fashioned hub or a switch/router which will copy all packets to all ports? The easiest way to debug the networking traffic-on-the-wire side of this is by using Wireshark.

Is there any special action you take based on packets received after the start of a new hour? Extra threads (or blocking threads) that happen on that hour marker? Networking does live at the managed code layer--so if there's a blocked thread within an event handler...NETMF may not be so happy to let network traffic through.

This is a very curious issue, very interesting. Let's figure it out.

Chris

#63522 Visual Studio version for N3?

Posted by Chris Walker on 14 July 2015 - 06:06 PM in Netduino 3

Cool - I'm will to try to document and share as much as possible!

(highfive)

#63521 How to Rename N3 for classroom

Posted by Chris Walker on 14 July 2015 - 06:05 PM in Netduino 3

Hey Hobbit,

Just to clarify, there is no way to change the name of the N3 correct? Also, I changed the friendly USB name in MFDeploy but in visual studio it still shows up as Netduino3)Netduino. I have to figure out a way that the students know which board is which. I will label them but it would be nice to see the friendly name in VS.

The USB name is fixed in the Netduino firmware (to "Netduino"). Should I put USB device name changes on the feature request list for Netduino vNext firmware?

Chris

#63516 Why not clock it @ 180MHz?

Posted by Chris Walker on 14 July 2015 - 04:34 PM in Netduino 3

Hey xc2rx,

You're welcome to hack your board to tweak speed settings. There are two main reasons why Netduino 3 is running at 168MHz (instead of clocked up to 180MHz).

The first reason is SPI bus speed. The SPI bus uses a divider to clock peripherals. While 180MHz might make it sound like that would enable faster communication with devices, some devices run at 21MHz. A 168MHz main clock allows a 21MHz SPI clock speed whereas a 180MHz main clock drops that speed to 11.25MHz (since 22.5MHz would be too fast for those devices).

The second reason is because of concerns over USB reliability. In the past there has been some concern about the core clock settings and multipliers not providing the correct USB clock. This may be an issue which has been solved in recent STM32F4 chip revisions--but to date our engineering team has not signed off on use of an 180MHz clock with USB peripherals. [And yes, we have seen other solutions driving USB with an 180MHz main clock...but we over-engineer things around here.]

If we get comfortable with an 180MHz clock by default, we may tweak this via a firmware update (or a board revision which changes the crystal speed) in the future. But for now, we recommend and use 168MHz.

Chris

#63515 SPLIT: Integrated MAC and 10 vs 100 mbps

Posted by Chris Walker on 14 July 2015 - 04:23 PM in Netduino 3

Hi xc2rx,

For full-speed 100mbps data transfer, you're probably best off looking at native code solutions (or higher-end PC hardware). NETMF is really targeted towards lower-bandwidth applications, single-chip devices, etc. We used the integrated PHY on Netduino Plus 1...but it offered little real-world application performance benefit over an external MAC+PHY solution. And with an external MAC+PHY solution, makers building custom boards can scale down to a 64-pin lower-resource chip and still affordably hook up Ethernet if/when desired.

We designed Netduino.IP to logically separate out the link layer (MAC portion) from the IP implementation. So if you wanted to create a native code interop driver for an on-chip MAC you can use the rest of the stack as-is.

Chris

P.S. Netduino.IP also has built-in driver support for the Asix AX88796C which supports 100mbps speeds for people whose hubs/switches prefer 100mbps devices.

#63508 CC3100 external memory/flash requirements?

Posted by Chris Walker on 14 July 2015 - 01:02 AM in Netduino 3

Nevermind, I found the JTAG connector part number in the schematic: FCI 20021121-00010C4LF

Since you picked up your board from Amazon, here are some Mini-JTAG headers from Amazon to go with it. These are SMD and go on the bottom side (with notch on the same side as the golden arrow pointer).
http://www.amazon.co...6835668&sr=8-17

Chris

#63504 Getting started with Netduino Mini (early instructions)

Posted by Chris Walker on 14 July 2015 - 12:05 AM in Netduino Mini

Dr. Who is wise

Yeah, RS-232 adapters vary a lot in quality, especially USB to RS-232 adapters: I typically always recommend the Keyspan 19-HS.

Chris

#63503 How to Rename N3 for classroom

Posted by Chris Walker on 14 July 2015 - 12:03 AM in Netduino 3

Hey Hobbit,

BTW I love the N3!!! It is so cool to have WiFi built in. I used your suggestion about how to keep the WiFi connected... works great. Thanks again.

We're in love with the gen3 hardware too, and it is probably over-engineered: it should serve you well.

Thanks for the feedback, and let us know how things go with your class!

Chris

#63502 Noob System.NotSupportedException

Posted by Chris Walker on 13 July 2015 - 11:59 PM in Visual Basic Support

Hi darky8,

Very interesting. If you run MFDeploy, select your device, and press Ctrl+Shift+C (Device Capabilities), what does it show?

Also, critically: what board are you using?

Chris

#63499 CC3100 external memory/flash requirements?

Posted by Chris Walker on 13 July 2015 - 10:21 PM in Netduino 3

Hey xc2rx,

Two quick things:
1. Netduino 3 Wi-Fi uses a hybrid stack version of Netduino.IP. It's letting the CC3100 do all the low-level sockets and buffering logic and taking care of the upper-layer interfaces, network configuration, wireless integration, etc. [CC3100 also has raw sockets support...which is where you'd marry the full Netduino.IP stack to it.]
2. The CC3100 module on Netduino 3 Wi-Fi has a flash chip inside it. If you want, you can look up CC3100MOD on the TI website for all sorts of technical detail goodness.

Chris

#63496 MFDeploy Requirements

Posted by Chris Walker on 13 July 2015 - 07:49 PM in Netduino Plus 2 (and Netduino Plus 1)

Hi bgreer,

I believe that you need .NET Framework 2.0 (at least with the older versions of MFDeploy). The newer copies might use .NET Framework 3.5. [I am speaking of the desktop versions.]

You'll also want the Netduino (MFUSB and WinUSB) drivers. The Netduino SDK installer should take care of that--and you can also just copy the drivers from the Netduino SDK installer and manually install those from Device Manager if desired.

Chris

#63494 How to Rename N3 for classroom

Posted by Chris Walker on 13 July 2015 - 06:23 PM in Netduino 3

Hi Hobbit,

There's no NETBIOS support built into NETMF or Netduino. This is the sort of thing that could be added to Netduino.IP via a firmware update in the future.

[Anyone want to help take on mDNS or NETBIOS as a project?]

The easiest thing to do is to add a DNS entry for each board in a DNS server. You could even use an unrelated domain name and local IP addresses. It's really just easy resolution you're looking for.

BTW, one potential pointer... Valkyrie put together a driver for CC3100 that, IIRC, supports mDNS. So that might provide the kind of capability you're looking for. Check out "mIP" and his CC3100 driver.

Chris

#63480 Netduino.IP in use

Posted by Chris Walker on 13 July 2015 - 07:17 AM in Netduino.IP Technical Preview

Looks very cool.

Not sure what's going on there. This sounds like something where we need to whittle it down to a simple repro (to determine where the issue is happening--in Netduino.IP or in threading etc.)

It's very odd that it would run so long and just stop, in any case.

Chris

#63451 Netduino.IP Firmware v1.0.0 (for Netduino Plus 2)

Posted by Chris Walker on 10 July 2015 - 05:29 PM in Netduino.IP Technical Preview

Hi lable,

For the v1.0 release, we support network configuration using MFDeploy. Netduino.IP was built for the future of NETMF (where Microsoft.SPOT.Net may be deprecated) so the SPOT-specific EnableStaticIP function is not implemented.

That said, this is something that could be added in a follow-up release of Netduino.IP.

If you set the network configuration to static IP using MFDeploy (target > configuration > network config), does everything work properly for you?

Chris

#63445 Introducing Llilum, the native-compiled (NETMF) proof of concept

Posted by Chris Walker on 09 July 2015 - 04:30 PM in General Discussion

I'll keep my fingers crossed, but I won't hold my breath...

Yes, please...no holding your breath

Llilum is really really cool but, again, it's a proof of concept right now. It will keep getting better and better, and there are a lot of things to get excited about, but we should get excited about them as they become available.

Chris

#63443 Introducing Llilum, the native-compiled (NETMF) proof of concept

Posted by Chris Walker on 09 July 2015 - 04:14 PM in General Discussion

Hi gismo,

So, does this mean we would have access to input capture and direct access to counters/timers on the chip?

Potentially. There is a lot that could be done, but a project like this also needs to set realistic goals on what can ship in v1, what makes the cut-list for vNext, etc. This is certainly something that would be _very_ interesting though, with a native-compiled .NET platform for Cortex-M devices.

Chris

#63442 Introducing Llilum, the native-compiled (NETMF) proof of concept

Posted by Chris Walker on 09 July 2015 - 04:13 PM in General Discussion

Hey Cuno,

In which way is the NETMF stack integrated? As far as I have seen, Llilum is a completely separate technology stack, no NETMF code involved anywhere.

Llilum is still proof of concept, but the plan is to integrate the NETMF stack into the Llilum toolchain. Here's a quick note about this from Lorenzo's post on the NETMF blog.

We will grow this project side by side with .NET Micro Framework 4.4 and eventually integrate the .NET MF stack into the LLILUM tool chain to achieve both a smaller code size and higher execution speed.

Please note that this doesn't mean that the NETMF runtime will be imported as-is. The goals here will likely include code reuse. Again...this is all very early and still proof of concept...but lots more to come (including exception handling in a future release).

Chris

#63441 Introducing Llilum, the native-compiled (NETMF) proof of concept

Posted by Chris Walker on 09 July 2015 - 04:08 PM in General Discussion

Hey Paolo,

However bit banging and high frequency gpio are good but the best could be to have a real time and deterministic system (on the interrupts side) that you can program in managed code as C# but with performance of a system developed in C

With a native-compiled proof of concept like Llilum, you still have real-world issues like garbage collectors to deal with. There is a possibility that a GC-less application could be built, and there is a possibility that a GC which honors determinism around interrupts is possible. But to be clear none of these are announced features--or necessarily on the roadmap. It's all very early still, and we're just super-excited for the new bits.

Chris

#63434 Introducing Llilum, the native-compiled (NETMF) proof of concept

Posted by Chris Walker on 09 July 2015 - 04:55 AM in General Discussion

Hey Paolo,

Chris this is a great new ... net mf can be definitely a platform for competing with other native.

Not just competing... Superior in oh so many ways

You talk about gpio bit banging and it's ok as we can see from performance but what about the real time feature strictly related to determinism and interrupts system ?

Llilum isn't currently spec'd to be a deterministic interrupt system. You could potentially run it inside CMSIS RTOS and put deterministic code there...or otherwise use native code directly from interrupts. Sometime in the future there could even potentially be an option for mixed native and managed-compiled-to-native code in a single project, although that's probably way too much to ask for a first version.

Chris

#63430 Introducing Llilum, the native-compiled (NETMF) proof of concept

Posted by Chris Walker on 09 July 2015 - 01:13 AM in General Discussion

Hey Dan,

Please keep me on the front edge of this. I am presenting "Are You an Explorer? IoT and Blazing you own trail." at That Conference 2015.

Dang, I wish I could come camping with you guys. That sounds pretty fun.

Llilum is still proof of concept and probably won't be ready for major demos by next month, but stay tuned longer-term. It's pretty cool technology.

P.S. Thanks a bunch for bringing your Netduinos to the campout... Super cool.

Chris

#63428 Introducing Llilum, the native-compiled (NETMF) proof of concept

Posted by Chris Walker on 08 July 2015 - 10:56 PM in General Discussion

And just to set good expectations...please note the words "proof of concept".

The combination of NETMF (C# to IL) + Zelig (IL to ARMv4/v5) + LLVM (ARMv4/v5 to ARMv7) + Netduino.IP with Cortex-M is really, really mouthwatering.

But for now...still just a proof of concept. Let's all give the NETMF team lots of love and encouragement on this direction. And once this gets a bit further along perhaps we can all push our Netduino gear to do all sorts of cool new tricks.

Chris

P.S. There are tradeoffs between IL interpreters, JIT, and AOT. If and when this proof of concept becomes a production release, both the NETMF Interpreter and Llilum will have applications where they excel over the other. The key here is that the two options combined effectively make .NET the perfect solution for the majority of IoT projects. Super cool.

#63427 Introducing Llilum, the native-compiled (NETMF) proof of concept

Posted by Chris Walker on 08 July 2015 - 10:42 PM in General Discussion

Netduino 3 and Netduino.IP were designed from the ground-up to work great with the upcoming NETMF 4.4 (MSIL interpreter)--but they were also designed to excel with a native-compiled NETMF.

The NETMF interpreter is really great for a lot of applications, but there are some applications where a native-compiled runtime for Cortex-M devices would be really awesome. Think "up to 300 times faster" awesome.

Today Microsoft has published a sneak peek into Llilum (pronounced "LIL-EEE-UM"), an AOT-compiled "NETMF" proof of concept for Cortex-M devices.

Here are some links to explore:

Llilum dev overview
Llilum system description
Very early performance data

This project includes quite a bit of tech that Microsoft has already built--as well as an integration of the NETMF stack, LLVM compilation and more.

There is a lot to digest in the tech overview...so here's a quick simplification in my own words:

Summary Description
"[The llilum proof of concept] is a future native-compiled option for .NET Micro Framework applications. For Cortex-M class micros. Up to 300 times faster for some operations like GPIO bitbanging. Additional C# language features. Code share-ability with Windows IoT UWP apps (think of the UWP APIs from NETMF 4.4). And all the hardware benefits of inexpensive, power-saving Cortex-M micros."

This is all still technically proof of concept, but that said...lots of great stuff to come. Kudos to the NETMF team (and all others who have been involved on this) for all the great work.

Chris

#63425 What is the latest firmware version for Netduino 1

Posted by Chris Walker on 08 July 2015 - 08:36 PM in Netduino 2 (and Netduino 1)

Hi Ron,

Go ahead and install VS2013 and the Netduino 4.3.x SDK, and then install the legacy templates (see downloads page).

For Netduino 1 devices, just use the (Legacy) template when you create your new projects.

Chris

#63421 Strange Analog Output

Posted by Chris Walker on 08 July 2015 - 05:05 AM in General Discussion

Hi rseedle,

Which Netduino mainboard are you using? What version of firmware?

And...do you have anything plugged into the other analog pins? [If not...can you try connecting them all to GND really quickly to see if that affects your results?]

Welcome to the Netduino community,

Chris

#63419 Dev Environment for Netduino 2, NP1, FEZ Spider on One PC?

Posted by Chris Walker on 08 July 2015 - 01:25 AM in Visual Studio

Hi John,

We can't officially support non-Netduino devboards, but as long as those other boards' SDKs support Visual Studio and the newer NETMF SDKs, you should be fine. Worst case scenario you can just create a base "Micro Framework Console" project for the non-Netduino boards.

Chris

By content type

See this member's