.NET Micro Framework

Commented Issue: Add support for IronPython [1839]

khmesmer — Sat, 18 May 2013 17:05:35 GMT

In our work with embedded systems, more and more platforms are supporting Python as their language of choice. Although we love C# (and even love seeing VB being used!) we really would like a way to standardize our embedded development on a single language ... and currently Python is growing to be that language.

I know that IronPython seemed to fall by the wayside, and shift outside ... but it would be awesome to get Python support back in ... and in the .NET Micro Framework.
Comments: ** Comment from web user: khmesmer **

Python support for the micro frame work would expand the product base considerably and it would be very much in the interest of Microsoft and the open source community to provide this.

My understanding of doing this is that by providing Python support in the .net Micro Framework that boards built on this standard can seamlessly interact in environments where Python is used. From remote shell programming to system integration the support base expands considerably. If Shell support is possible with these boards now remote access is possible opening up robotic applications and so on.
This is not currently available with the current languages provided and is a limiting factor. Limits are to be avoided if possible.

The logic follows : "Well then why not just integrate all languages into it and maximize the support?"
The answer is make the full dot net framework integrate seamlessly into the micro framework where you simply down load the latest version of the full dot net framework and the framework decides what the board supports based upon the standards established by the open source community. That goes beyond the scope of this post however.

Python would be a major step in this direction and would truly move the .net micro framework forward in the market. I am not an expert on the subject but I am unaware of any other language not python based that can accomplish what python does with the same wide user base python has. It's a very smart step.

Created Unassigned: StringBuilder.Replace previous bug resurfaced again [2012]

jcherrabi — Thu, 16 May 2013 13:53:59 GMT

Hello guys,
the following code have already demonstrated a bug with StringBuilder.Replace back in 4.1 which supposedly was patched according to the link below.
https://netmf.codeplex.com/SourceControl/list/patches?page=1

but now it is back in 4.2, and 4.3 can you guys confirm and apply a permanent patch...

test code:
String replaced = new StringBuilder("My car is a a0a a1a a2a").Replace("a0a","blue").ToString();
Debug.Print(replaced); // replaced: yMy car is ablue a1a a2a

thanks.

Created Unassigned: StringBuilder.Replace previous bug resurfaced again [2011]

jcherrabi — Thu, 16 May 2013 13:53:12 GMT

Hello guys,
the following code have already demonstrated a bug with StringBuilder.Replace back in 4.1 which supposedely was patched according to the link below.
https://netmf.codeplex.com/SourceControl/list/patches?page=1

but now it is back in 4.2, and 4.3 can you guys confirm and apply a permanent patch...

test code:
String replaced = new StringBuilder("My car is a a0a a1a a2a").Replace("a0a","blue").ToString();
Debug.Print(replaced); // replaced: yMy car is ablue a1a a2a

thanks.

Closed Feature: Support SerialPort.ReadExisting [107]

ZachLibby — Thu, 16 May 2013 11:52:33 GMT

Please vote to express your interest for this work item.

SUGGESTION (from Jan Kucera, forums on http://www.netmf.com) :

"... I wonder if exposing a Stream (SerialPort.BaseStream on .NET Framework) for use with the StreamReader/StreamWriter methods would help [...] ? Adding a stream wrapper might be cheaper than adding all these methods, and it should be even easy enough to implement it yourself... "

Closed Feature: Sample support for Dallas / Maxim 1Wire devices [1142]

DoingNZ — Thu, 16 May 2013 11:52:10 GMT

Please find in the attached ZIP a simple interop layer to utilise the free SDK for Dallas / Maxim 1Wire devices.

Feel free to use in any way that may be useful to you. Use entriely at your own risk. No warrenty etc ...

This code uses a single GPIO pin to talk to attached 1Wire device(s). You set the selected GPIO in the managed C# code.

A demo application is included that will scan the 1Wire bus for devices and return a collection of IDs of devices found.
The attached code has only been tested with a single 1Wire device attached to read its 64 bit ID.

Sample code to read the list of IDs of attached 1Wire Devices looks like this:

OutputPort port = new OutputPort(DeviceSolutions.SPOT.Hardware.Meridian.Pins.GPIO4, false);
OneWire ow = new OneWire(port);
ArrayList IDs = ow.FindIDs();

The free Dallas 1Wire SDK includes samples for other 1Wire devices. The Interop may need some extending for some of the other devices as it currently only has basic support for read / write of bytes of data on the serial 1wire bus. More complex functions then use these to achieve higher level functions.

The idea was that where the Dallas C/C++ SDK has code like:
// success
printf("Port opened: %s\n",argv[1]);
owTouchReset(portnum);
owWriteByte(portnum,0x33);
SwitchSN[0] = (uchar)owReadByte(portnum);
SwitchSN[1] = (uchar)owReadByte(portnum);
SwitchSN[2] = (uchar)owReadByte(portnum);
…

The C# code would become
OutputPort port = new OutputPort(DeviceSolutions.SPOT.Hardware.Meridian.Pins.GPIO4, false);
OneWire ow = new OneWire(port);
ArrayList IDs = ow.FindIDs();

Debug.Print("Port opened");

ow.TouchReset(portnum);

ow.WriteByte(portnum,0x33);
SwitchSN[0] = ow.ReadByte(portnum);
SwitchSN[1] = ow.ReadByte(portnum);
SwitchSN[2] = ow.ReadByte(portnum);
…

Explination of Folders in zip

Managed Inerop assembly: \MicroFrameworkPK_v4_1\Interops\ManagedCode\Pulsecor.SPOT.OneWire
Native Driver DLL: \MicroFrameworkPK_v4_1\Interops\NativeCode\Pulsecor.SPOT.OneWire
Sample: \MicroFrameworkPK_v4_1\Product\Samples\OneWireDemo

Hope this is useful.

Regards
Richard.

Closed Feature: Better information on deploying [1209]

lorenzte — Thu, 16 May 2013 11:52:07 GMT

The #1 (almost daily) support issue we see is not having the correct firmware on the device. In the device boot up messages, you see "checksum mismatch" message but this is hidden between so many other messages.

A very small addition that would have great value to every NETMF user is by VS checking the assemblies checksum before it deploys the assemblies and give the user a warning message box. Perhaps, "Checksum Mismatch. Possible outdated firmware." message.

Not just new users, experienced users also run into this trap. They download a new SDK or get an old device from the field and all they know is their device is not booting. A message box will save them hours of frustration.

GHI would love to contribute this but this has to be done in SDK not in PK.

Closed Issue: TimeService not closing socket after successful update [1702]

lorenzte — Thu, 16 May 2013 11:51:56 GMT

The SNTPClient::Connect() method is not closing the socket after a successful update of the time.
A proposed fix for DeviceCode\pal\timeservice\driver\ntp.cpp (based on netmf 4.2 community branch) is attached.
This fix also propagates socket error numbers to the managed application, which helps locating a failure.

Closed Issue: Debug.EnableGCMessages(true) Does not work in .NET MF 4.2 [1711]

lorenzte — Thu, 16 May 2013 11:51:56 GMT

See the thread here. It appears that the EnableGCMessages method is broken.
http://forums.netduino.com/index.php?/topic/4807-cant-get-gcmessages-to-work/

Closed Issue: Real world projects/devices? [1857]

lorenzte — Thu, 16 May 2013 11:51:53 GMT

I was not able to find any real world project/device that is using the .NET MF for getting started. How "important" is .NET MF compared to .NET CF? Since devices are getting better and better I am asking myself it makes sense getting started with .NET MF ...Thank you in advance for putting me into the right direction!--hfrmobile (Windows Mobile & Windows Phone developer)

Commented Issue: EWR weak points [2010]

leforban — Tue, 14 May 2013 07:33:43 GMT

Saving data into flash is an important feature for most of embedded devices. It allows to store configuration settings and user settings. On .netmf this is done by using EWR. While I recognize that serialization rises the level of abstraction in a lot of cases (xml, data transfert...), I consider that EWR suffer of a lack of detail. As a result, debugging EWR is really complex. I am using EMX module from GHI Electronics and even if the premium library provides a method to flush extended weak reference, we need more details about the saving scheme. We need to know how much space are needed to store the data but there's no convenient way to compute it and therefore we can't know how long it takes to save data into flash memory.

Finally for now I save an arraylist containing custom objects and there's no convenient way to modify just a member of a given object. I am obliged to resave the arraylist entirely, which is time consuming and reduce the lifetime of the flash memory. I think this could be enhanced.
Comments: ** Comment from web user: leforban **

An other thing that suffer of a lack of information.
I am storing an array list of custom object and these objects can have different size (there's an other array list inside each instance). Let's consider that I store 3 instances A, B and C that have the same size. Then I modify B by adding elements to the inner array list. How is performed the memory management? B won't have enough place to be located between A and C. Does C is moved? is there fragmented memory?

Commented Issue: EWR weak points [2010]

gus_ghielec — Mon, 13 May 2013 17:33:18 GMT

The EWR flush and data integrity issue was point out long ago https://netmf.codeplex.com/workitem/1156

I think a direct user control over a flash section is better suited for many embedded users.

Gus - GHI Electronics

Created Issue: EWR weak points [2010]

leforban — Mon, 13 May 2013 14:48:33 GMT

Created Issue: StreamReader.Peek() misses last character [2009]

michag — Fri, 10 May 2013 19:42:02 GMT

#Description
When using a StreamReader on a MemoryStream, the StreamReader.Peek() method will not return the last character.

#Steps to Repro:
You can use the snippet below to repro the issue.
``` C#
const string s = "Hello, world!";
var b = Encoding.UTF8.GetBytes(s);
var memStream = new MemoryStream(b);
var reader = new StreamReader(memStream);

int p;
while (( p = reader.Peek()) >= 0)
{
Debug.Print(p + "\t"+ (char) p);
reader.Read();
}
```
This will produce the following debug output (notice the '!' is missing):

```
72 H
101 e
108 l
108 l
111 o
44 ,
32
119 w
111 o
114 r
108 l
100 d
```
#Possible Solution:
After looking at the StreamReader.Peek() implementation, I think the problem can be found in this loop section
``` C#
....
// Move any bytes read for this character to front of new buffer
int totRead;
for (totRead = 0; totRead < m_curBufLen - m_curBufPos - 1; ++totRead)
{
m_buffer[totRead] = m_buffer[m_curBufPos + totRead];
}
...
```
It should work if the "- 1" is removed as follows:
``` C#
....
// Move any bytes read for this character to front of new buffer
int totRead;
for (totRead = 0; totRead < m_curBufLen - m_curBufPos; ++totRead)
{
m_buffer[totRead] = m_buffer[m_curBufPos + totRead];
}
...
```

Commented Issue: VS2012 deploy and code stepping is very slow [2004]

WeegieBoy — Wed, 08 May 2013 17:03:52 GMT

Upgrading from VS2010 to VS2012, we noticed that deploying is very slow, which can be worked around but then stepping in code is very slow as well.

First, we thought it maybe the device but it is very slow even in the emulator. This machine we tested, is i7 processor with 12MB of RAM. This also seem the case for many who have reported on our forums.

Maybe votes and replies will show us if other users are or aren't noticing this behavior.

Please revisit debugging to see what can be done to speed up the debugging features. We are ready to run any tests and provide any help as necessary.

Thanks

Gus - GHI electronics
Comments: ** Comment from web user: WeegieBoy **

Using Windows 7 64 bit and VS2012 Express for NETMF and slow here too.

Commented Issue: XmlReader discrepancy between NETMF and full framework [2007]

yummolambert — Wed, 08 May 2013 11:31:46 GMT

There is a discrepancy in XmlReader from NETMF and Full .NET. I know both have a different code base but maybe it's convinient to maintain the same functionality.

The following is going different:

The xml:
<request><parameters /><name>yummo</name></request>

It's going different on the element 'parameters'. In the full framework the reader iterates on startelement and endelement where NETMF only iterates on startelement and the next read is on startelement of the element 'name'.

Framework versions i use:
* Micro framework v4.2
* Net Framework v4.0
Comments: ** Comment from web user: yummolambert **

After some researching i noticed the 'IsEmptyElement' property on XmlReader instance. Which didn't give a true on the normal framework but it does on NETMF. With this the situation is clear and all works like it should.

This can be closed. Thank you.

Created Issue: XmlReader discrepancy between NETMF and full framework [2007]

yummolambert — Wed, 08 May 2013 09:02:24 GMT

Commented Issue: HTTP Client possible memory leak when using HTTPS [2005]

BrynL — Tue, 07 May 2013 08:52:05 GMT

While testing a NetMF V4.2 application which connected to the Azure Service bus I found that after a while it ran out of memory and crashed. After some digging I found that each HTTPS request appeared to leak roughly 45K(forcing a GC appeared to make little or no difference). Basically the BINARY_BLOB_HEAD value increases until the application dies.

I only have one NetMF device which can do HTTPS so I wasn't able to repro on another platform. The problem occurred over both [wireless](http://http://www.ghielectronics.com/catalog/product/282) & [wired](http://http://www.ghielectronics.com/catalog/product/284) connections The attached demo application runs on a Fez Spider V4.2

Noted down free memory for 10 requests

HTTPS
7120164 bytes
7074420
7029252
6984036
6938952
6893736
6848520
6803304
6758088
6712740

HTTP
7165980 bytes
7167840
7167840
7167840
7167840
7167840
7167840
7167708
7167840
7167840

HTTPS Memory info – Start
Type 0F (STRING ): 3084 bytes
Type 11 (CLASS ): 14352 bytes
Type 12 (VALUETYPE ): 1512 bytes
Type 13 (SZARRAY ): 7860 bytes
Type 03 (U1 ): 3192 bytes
Type 04 (CHAR ): 852 bytes
Type 07 (I4 ): 1044 bytes
Type 0F (STRING ): 72 bytes
Type 11 (CLASS ): 2616 bytes
Type 12 (VALUETYPE ): 84 bytes
Type 15 (FREEBLOCK ): 7118664 bytes
Type 16 (CACHEDBLOCK ): 216 bytes
Type 17 (ASSEMBLY ): 32688 bytes
Type 18 (WEAKCLASS ): 96 bytes
Type 19 (REFLECTION ): 192 bytes
Type 1B (DELEGATE_HEAD ): 864 bytes
Type 1D (OBJECT_TO_EVENT ): 240 bytes
Type 1E (BINARY_BLOB_HEAD ): 152496 bytes
Type 1F (THREAD ): 1536 bytes
Type 20 (SUBTHREAD ): 144 bytes
Type 21 (STACK_FRAME ): 1632 bytes
Type 22 (TIMER_HEAD ): 216 bytes
Type 27 (FINALIZER_HEAD ): 144 bytes
Type 31 (IO_PORT ): 108 bytes
Type 34 (APPDOMAIN_HEAD ): 72 bytes
Type 36 (APPDOMAIN_ASSEMBLY ): 3552 bytes

HTTPS Memory info – Finish
Type 0F (STRING ): 3084 bytes
Type 11 (CLASS ): 14364 bytes
Type 12 (VALUETYPE ): 1512 bytes
Type 13 (SZARRAY ): 7860 bytes
Type 03 (U1 ): 3192 bytes
Type 04 (CHAR ): 852 bytes
Type 07 (I4 ): 1044 bytes
Type 0F (STRING ): 72 bytes
Type 11 (CLASS ): 2616 bytes
Type 12 (VALUETYPE ): 84 bytes
Type 15 (FREEBLOCK ): 6711372 bytes
Type 16 (CACHEDBLOCK ): 96 bytes
Type 17 (ASSEMBLY ): 32688 bytes
Type 18 (WEAKCLASS ): 96 bytes
Type 19 (REFLECTION ): 192 bytes
Type 1B (DELEGATE_HEAD ): 828 bytes
Type 1D (OBJECT_TO_EVENT ): 240 bytes
Type 1E (BINARY_BLOB_HEAD ): 559476 bytes
Type 1F (THREAD ): 1920 bytes
Type 20 (SUBTHREAD ): 192 bytes
Type 21 (STACK_FRAME ): 1632 bytes
Type 22 (TIMER_HEAD ): 216 bytes
Type 27 (FINALIZER_HEAD ): 168 bytes
Type 31 (IO_PORT ): 108 bytes
Type 34 (APPDOMAIN_HEAD ): 72 bytes
Type 36 (APPDOMAIN_ASSEMBLY ): 3552 bytes
Comments: ** Comment from web user: BrynL **

Some logging info which maybe helpful

GC: performing heap compaction...
Err: 20, 166, 65, C:\MicroFrameworkPK_v4_2\DeviceCode\ghi\pal\OpenSSL\OpenSSL_1_0_0\ssl\ssl_ciph.cpp (1313)
Err: 20, 169, 161, C:\MicroFrameworkPK_v4_2\DeviceCode\ghi\pal\OpenSSL\OpenSSL_1_0_0\ssl\ssl_lib.cpp (1604)

Commented Issue: HTTP Client possible memory leak when using HTTPS [2005]

BrynL — Sat, 04 May 2013 10:17:51 GMT

Hi Gus,

With HTTP there didn't appear to be a memory leak. I initially thought it might have been a problem with tidying up a IO stream or similar in my code but I built really cut back sample which still had the problem

I tried different ways of loading the certificate, plus forcing GCs etc. but it didn't seem to make any difference.

I used Redgate Reflector to drill down into the system.HTTP assembly but hit what looked like native SSL code.

I have got more detail on my [blog](http://http://blog.devmobile.co.nz/2013/03/04/netmf-http-client-possible-memory-leak/) if you're interested.

Bryn

Commented Issue: HTTP Client possible memory leak when using HTTPS [2005]

gus_ghielec — Fri, 03 May 2013 23:11:22 GMT

Is it possible to run the same but without SSL? Maybe we can narrow it to the network not SSL?

Created Issue: HTTP Client possible memory leak when using HTTPS [2005]

BrynL — Fri, 03 May 2013 03:53:54 GMT