Cuno - Viewing Profile: Likes - Netduino Forums
   
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

Member Since 19 Jul 2010
Offline Last Active Sep 04 2015 12:50 PM
-----

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

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

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




#60237 Auto update delpoyed code on boot

Posted by Cuno on 26 September 2014 - 10:51 AM

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.

 




#57881 Calling HTTPS webapi's using NetDuino

Posted by Cuno on 01 May 2014 - 07:49 PM

Unfortunately, no. See also this thread:

http://forums.netdui...ion/#entry57880




#57520 Light-weight security also for Netduino?

Posted by Cuno on 13 April 2014 - 09:14 AM

If you are interested in strong cryptography on STM32 microcontrollers, as used in the newer Netduinos, you may be interested in our latest Mountaineer Firmware 4.3.1 Beta 3.

 

This new beta release, which is based on our NETMF for STM32 open source software like the firmware of the Netduino 2 family, contains a new experimental crypto library:

 

Oberon.NaCl is a light-weight cryptographic library for NETMF-based IoT devices. It is a small and easy-to-use tool box that you can use to build secure communication protocols, secure firmware update mechanisms, etc.

It is based on NaCl, pronounced "salt", a highly regarded suite of cryptographic algorithms designed and implemented by D. Bernstein et. al. It can be implemented efficiently even on single-chip microcontrollers and supports both symmetric and asymmetric cryptography.

A great introduction is given by Marco Poponi here:
http://www.tinyclr.i...1-platform.aspx

Links to examples and additional background are given here:
http://www.mountaine...crypto-library/

We are considering to contribute our code, along with a test suite, as a new core component of NETMF. Under the Apache 2.0 open source license, like the rest of NETMF. This will depend on the community feedback. At the moment, we see Oberon.NaCl as an experimental feature that may or may not find its way into the final release of the Mountaineer firmware.

Microsoft told us that they intend to set up a community process for contributions like this one. Until that process is in place, we use this forum here as a sounding board. Please let us know whether you feel that such a library would add value to NETMF, whether you see any issues with the API, and especially how you would like to use the library.

I´d like to thank Dan Berstein and his team for their impressive work and for making it public domain, Marc for finding and choosing NaCl, Pascal for implementing, testing and documenting our adaptation, Beat for understanding the involved math in-depth and for seeing the optimization potential of an already fast implementation, and Stephan, Etan and Thomas for multiple API and code reviews.

Cuno




#55734 Committing File to SD Card

Posted by Cuno on 29 January 2014 - 07:07 PM

@ncos: does this mean the workaround does not work for you?

The issue is on Codeplex (issue 2149 - I can't paste the link, paste command seems to be broken), but not resolved yet.

 

Cuno




#54050 Committing File to SD Card

Posted by Cuno on 12 November 2013 - 09:08 PM

wait a few minutes before dropping power to the Netduino, the file will actually be written to the SD card.  I assume there is some delay or time period that the Netduino firmware waits to commit data in RAM to the SD to prevent excess writing to the card, but the time is much too long IMO.

Yes, we have seen the same effect on our Mountaineer boards. Either it is an explicit delay for the reason you mentioned, or it is a bug (e.g. the flush may later be triggered by the finalization phase of a garbage collection run).

 

Anyway, the workaround in my previous post seems to work for Mountaineer boards. As the problem is probably in the porting kit and not Netduino-specific, it should also work on Netduinos. I have posted an issue here: http://netmf.codeple...m/workitem/2149

 

Cuno




#53814 Netduino Plus 2 Firmware v4.3.0 (beta 1)

Posted by Cuno on 04 November 2013 - 09:16 AM

Hi Chris, I upgraded  to 4.3 and I got a problem I want to use OutputPort and pwm in same pins. but when i dispose pwm and the netduino puls will missing.

... motor.Dispose(); OutputPort pwmOut = new OutputPort(Pins.GPIO_PIN_D9, false);

NETMF has several bugs in the code for the disposal of hardware resources. We corrected them for our Mountaineer 4.3 release, but sometimes a workaround is possible with older code: does the problem disappear if after motor.Dispose() and before opening the new OutputPort, you call Debug.GC.Collect(true)? This lets the garbage collector force a finalization of disposable objects, which sometimes solves the problem.

 

Cuno




#28804 NETMF with STM32 ARM Cortex M3

Posted by Cuno on 11 May 2012 - 09:56 AM

I am happy to announce that the new F4 Edition of our NETMF for STM32 software is now published as a first public beta release:

Mountaineer news

Codeplex site

As the Netduino Go firmware is derived from the F1 Edition, I hope that the new F4 Edition will also be a useful contribution for future Netduino Go firmware releases.

Cuno


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.