Netduino home hardware projects downloads community

Jump to content


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 Content

There have been 16 items by Cuno (Search limited from 29-March 23)


By content type

See this member's

Sort by                Order  

#63834 Invalid address messages when deploying

Posted by Cuno on 10 August 2015 - 08:09 AM in Netduino 3

Try upgrading to the latest firmware, and you should be good to go.

Hi Chris

 

What did you change?

 

Best regards

 

Cuno




#63591 M2Mqtt Library

Posted by Cuno on 21 July 2015 - 08:24 AM in Netduino Plus 2 (and Netduino Plus 1)

Can someone tell me the secret to getting Paste to work in this box?

Does MQTT work on the NetDuino Plus version 1?

thanks

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 concept

Posted by Cuno on 17 July 2015 - 06:59 AM in General Discussion

 

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

 

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 concept

Posted by Cuno on 13 July 2015 - 11:18 AM in General Discussion

Of course a static binding would be simpler, but...bah...I don't know pros/cons...maybe it's me having an obsessive eye toward the pluggability.

What do you mean about "less confusion" between NETMF and Win-IoT?

 

Really was considered a COM interface for MF?

 

Finally, I agree on the "high-degree of hackability", but whenever you need some hires capture/reproduce signal, the GC makes all that unreliable. IMHO, it should be designed some "sandboxed" section dedicated to the RT drivers: a very specific extension with RT capabilities.

Whether the code is interpreted or compiled, should not matter: the sandboxed code has to behave always the same.

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 concept

Posted by Cuno on 12 July 2015 - 06:43 PM in General Discussion

Maybe a tiny-tiny Windows COM interface or so...

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 concept

Posted by Cuno on 09 July 2015 - 09:14 AM in General Discussion

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

:-)

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 concept

Posted by Cuno on 09 July 2015 - 09:11 AM in General Discussion

This project includes quite a bit of tech that Microsoft has already built--as well as an integration of the NETMF stack

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 debugging

Posted 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 2

Posted by Cuno on 15 February 2015 - 10:02 AM in General Discussion

That's very nice, but...some questions:

  • where are the I/O pins (or else) for sensors and related?
  • the Wi-Fi is an option/alternative to Ethernet, or is unavailable?
  • could you post an image of the bottom view?

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 NETMF

Posted by Cuno on 14 January 2015 - 09:26 PM in Netduino.IP Technical Preview

The lwIP community has been fixing quite a few of the bugs, but merging those back into NETMF can be a big project (as you alluded).

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 NETMF

Posted by Cuno on 14 January 2015 - 01:10 PM in Netduino.IP Technical Preview

while we do love lwIP, it also has quite a few...let's call them bugs.

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 team

Posted 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

I'm super excited to announce that the Robotics from Xamarin.Labs team has an add-in for Xamarin Studio that allows you to build and deploy .NET MF apps to Netduino from Xamarin Studio on Mac!

 

If you want to give it a shot, you can find instructions here.

 

have fun, let us know if you have any issues.

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...

  • What would need to be changed to also support other NETMF boards than Netduino, e.g. our Mountaineer boards (http://www.mountaineer.org), the GHI boards or the MikroBus.Net Boards?
  • When migrating the Metadata processor to C#, did you also correct some of the long standing problems, e.g. caching bugs? As any long-time NETMF programmer knows, there are many, many small glitches during build, deploy and debug. One of them e.g. that you sometimes have to switch transport from USB to something else and back again, and many more such hassles. It would be outstanding if you had resolved some of these as well!
  • Are you in contact with the new NETMF team? This could make life easier for them as well I guess.
  • Is it easier in Xamarin Studio compared to Visual Studio to have multiplatform setups, so that the same sources can be used e.g. for NETMF 4.2, NETMF 4.3.1 and (where appropriate) in NETFX 4.5 in the same solution?

 

Thanks and best regards

 

Cuno




#60237 Auto update delpoyed code on boot

Posted 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 modules

Posted by Cuno on 08 September 2014 - 07:42 AM in Netduino Go

Hi Cuno,

 

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.

We tend to include the latest bits from Secret Labs, from the Netduino community and from Microsoft (and bits from NETMF which were contributed to NETMF by Secret Labs and the Netduino community) in the latest firmware releases. We will do so with 4.3.2. There's a ton of new code in there and a ton of testing that's been and being done.

 

I read this as a confirmation of my assumption ;)




#60018 Beta program new firmware and modules

Posted by Cuno on 07 September 2014 - 05:34 PM in Netduino Go

Quick update: we're currently testing an early version of the 4.3.2 firmware.

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.





home    hardware    projects    downloads    community    where to buy    contact Copyright © 2016 Wilderness Labs Inc.  |  Legal   |   CC BY-SA
This webpage is licensed under a Creative Commons Attribution-ShareAlike License.