Try upgrading to the latest firmware, and you should be good to go.
Hi Chris
What did you change?
Best regards
Cuno
  | ||||||||||||||
The Netduino forums have been replaced by new forums at community.wildernesslabs.co.
This site has been preserved for archival purposes only
and the ability to make new accounts or posts has been turned off.
Cuno's ContentThere have been 16 items by Cuno (Search limited from 29-March 23) #63834 Invalid address messages when deployingPosted by Cuno on 10 August 2015 - 08:09 AM in Netduino 3
Hi Chris
What did you change?
Best regards
Cuno #63591 M2Mqtt LibraryPosted by Cuno on 21 July 2015 - 08:24 AM in Netduino Plus 2 (and Netduino Plus 1)
Unfortunately it looks like the forum software does not support Internet Explorer. It works in Firefox...
Cuno #63567 Introducing Llilum, the native-compiled (NETMF) proof of conceptPosted by Cuno on 17 July 2015 - 06:59 AM in General Discussion
Ah, this may have been a somewhat misleading statement. It is not clear if there will be any shared code eventually, and what it would be. It's too early to tell. The toolchain (apart from VS) and the runtime are completely separate, and the APIs will probably be substantially different as well, at least for the foreseeable future.
Lorenzo made the positioning a bit clearer here: https://github.com/N...mment-122144288
"As llilum gradually comes online, we will see how to integrate llilum into both the netmf ecosystem and the llilc technology."
PS Regarding dynamic loading: "We do know that we will not support features such as dynamic loading with llilum, and that alone suggests that llilum will never replace .NET MF." #63486 Introducing Llilum, the native-compiled (NETMF) proof of conceptPosted by Cuno on 13 July 2015 - 11:18 AM in General Discussion
Today, the border between NETMF and the larger .NET implementations is not very clear. Mostly this is a problem of positioning, leading to the question where a given platform stops being a good fit. Maybe we will evolve towards a clearer situation where we have the Raspberry Pi class of microprocessors, with large external memories, dynamic code loading, and Windows IoT on the one hand, and Llilum tools for Cortex-M based systems, with static code and no operating system in the traditional sense.
And possibly we will have real-time capabilities, who knows. In our experience, it is often possible to initialize an embedded application which may involve memory allocation and garbage collection, and then start one or several real-time tasks, which do not allocate any memory. Thus the GC does not run after the initialization step. This is e.g. how we implemented our quadrocopter code in C# (https://www.ghielect...id=12602&page=1). Maybe this approach could be supported more systematically, e.g. by giving compile-time errors wherever real-time code might inadvertantly cause memory allocations.
But I agree: a sandboxed approach that partitions part of the processor bandwidth statically to real-time code would also be the preferred approach as far as I am concerned. My hope is that Llilum will be hackable enough that we could implement something like this ourselves with relatively little effort. For example, it is one of the goals for Llilum that you could provide your own thread implementation. We'll see.
Yes, a COM-based NETMF variant has indeed been considered some time ago.
As for your obsession regarding pluggability - actually a high degree of pluggability could be provided at build time as well, if the tool chain were prepared for it, e.g. using compile-time reflection and similar concepts. Not sure how much of a design goal this is for Llilum, though. And it's much more complex to correctly design suitable tool chain APIs, compared to supporting the COM memory layout and calling conventions.
Best regards
Cuno #63464 Introducing Llilum, the native-compiled (NETMF) proof of conceptPosted by Cuno on 12 July 2015 - 06:43 PM in General Discussion
This would support dynamic loading and also component evolution in a very clean and neat way, with relatively little overhead. But on the other hand, if a static system is accepted, still a lot of overhead can be shifted to build time, thereby allowing to reach much smaller microcontrollers than the one of a Netduino - and this approach would create less confusion regarding the positioning of NETMF versus the IoT version of Windows.
A COM-based evolution of NETMF was actually considered for the future of NETMF. But the focus for Llilum is to reach smaller microcontrollers. It should also allow for a high degree of hackability, without the need to combine different languages. #63438 Introducing Llilum, the native-compiled (NETMF) proof of conceptPosted by Cuno on 09 July 2015 - 09:14 AM in General Discussion
Yes, I would love to create such a system :-) Done it many years ago for Java. But unfortunately, no budget ;-) #63437 Introducing Llilum, the native-compiled (NETMF) proof of conceptPosted by Cuno on 09 July 2015 - 09:11 AM in General Discussion
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. #61752 Netduino runs faster when debuggingPosted by Cuno on 01 March 2015 - 09:07 PM in Netduino 2 (and Netduino 1) I've reported this problem to Microsoft: https://netmf.codepl...m/workitem/2179
They are currently working on fixing a number of issues, hopefully this one will also be addressed.
Cuno #61616 Another custom PCB based on Netduino Plus 2Posted by Cuno on 15 February 2015 - 10:02 AM in General Discussion
Seems to be a pure gateway between GSM or Ethernet on one side and some nRF24L based radio network (2.4 GHz) on the other side, so no I/O pins are needed. #61259 Introducing Netduino.IP, the shiny new TCP/IP stack for NETMFPosted by Cuno on 14 January 2015 - 09:26 PM in Netduino.IP Technical Preview
Microsoft confirmed that the various networking issues in NETMF come from the NETMF design, not from lwIP. They intend to tackle the problem at the core rather than symptomatically - by changing the way in which NETMF integrates lwIP. They verified that a correctly used and configured lwIP stack has none of the known NETMF networking issues. #61253 Introducing Netduino.IP, the shiny new TCP/IP stack for NETMFPosted by Cuno on 14 January 2015 - 01:10 PM in Netduino.IP Technical Preview
The problem has never been with lwIP. The problem was a bad architecture in NETMF for integrating lwIP. The new Microsoft NETMF team is aware of that and working towards a fundamentally sound new integration architecture. This will allow lwIP to work just fine, at native code speed. #60984 Colin Miller back to NETMF teamPosted by Cuno on 15 December 2014 - 10:02 PM in General Discussion As you may have heard, Colin Miller, the long-time program manager for NETMF, is back! With the return of NETMF from China to the US, the platform has been revived. And Colin has revived the NETMF blog as well. For obvious reasons, I particularly like his new post of today :-)
http://blogs.msdn.co...ion-plants.aspx
Cuno
#60288 Netduino + Xamarin Studio - Add-in in beta testing!Posted by Cuno on 29 September 2014 - 10:20 AM in Mono
Hi Bryan
This is extremely interesting indeed, as most of our engineers are actually working on Macs even for NETMF programming. I am one of the few holdouts...
Thanks and best regards
Cuno #60237 Auto update delpoyed code on bootPosted by Cuno on 26 September 2014 - 10:51 AM in General Discussion There is a standard mechanism for this in NETMF, it's called MFUpdate. We implemented it for our NETMF port:
http://www.mountaine...-field-updates/
Unfortunately, Netduino firmware doesn't support it yet.
#60038 Beta program new firmware and modulesPosted by Cuno on 08 September 2014 - 07:42 AM in Netduino Go
I read this as a confirmation of my assumption #60018 Beta program new firmware and modulesPosted by Cuno on 07 September 2014 - 05:34 PM in Netduino Go
I assume that this is your own 4.3.2 firmware, and does not include any new bits from Microsoft? Except of course support for VS 2013 and later VS versions, which has been announced by Microsoft earlier this year.
| ||||||||||||||
|
||||||||||||||
This webpage is licensed under a Creative Commons Attribution-ShareAlike License. | ||||||||||||||