Sorry, but I can’t send in private.
I try to use one or two DS18B20 temperature sensors.
Microsoft.SPOT.Hardwawe.OneWire in Reference
m_op = new OutputPort(pin, false); //OK
m_ow = new OneWire(m_op); //OK, reference OK
var devs = ow.FindAllDevices(); //error, Unknown Exception
Exception arise in both cases: without sensor and with sensors.
On forums wrote, that my TinyCLR don’t support OneWire.
you have set the pin to be an output port. Then you want to use it as an input/output pin in the onewire. You only need this:
m_ow = new OneWire(pin); //OK, reference OK
var devs = ow.FindAllDevices(); //error, Unknown Exception
Calling in the Microsoft library Microsoft.SPOT.Hardware.OneWire:
I try to use this class from godefroi for work with DS18B20 on NETMF 4.2:
https://www.ghielectronics.com/community/codeshare/entry/438
but get an error in
```cs]var devs = ow.FindAllDevices();[/code
Code without this class also leads to error:
```cs
OneWire m_ow = new OneWire(new OutputPort(Pins.GPIO_PIN_E_6, false));
var devs = m_ow.FindAllDevices();
Unhandled exception of type “System.NotSupportedException” in Microsoft.SPOT.Hardware.OneWire.dll
My apologies, you are correct, the netmf implementation of OW does need an output port in the constructor.
@ romanstorm
One-wire does work with NETMF 4.3. Have a look at the driver that I wrote for the MikrobusNet (MBN) board using a custom made DS18B20 Sensor. The demonstration and the source code can be found at http://www.mikrobusnet.org/. Look around and you’ll find it.
Thanks for the link, but you have to implement a similar method.
Still the same error at ow.FindAllDevices(); //“System.NotSupportedException”
In my opinion, problem in my CLR based on 4.2.
UPD.
I upgrade my firmware from this site
In filemon’s port netmf 4.2 for stm32f4Discovery added OneWire+SD Card support.
After update my programm work without any corrections.
Thank you all for your advice, you helped me move in the right way.
@ CunoMaster
Hi CunoMaster.
Are you still planing to release source code for your firmware?
Thank you.
Yes. But there is still one bug that we would like to see fixed first. We currently can’t say when there will be time to work on it.
Cuno
Hi Cuno, any news on a build past Beta 3, or an update to the netmf for stm32 delta http://netmf4stm32.codeplex.com/ ?
Good timing 
We should be working on an update to [em]NETMF for STM32[/em] next week. Our focus is on solving this [em]MFUpdate[/em] issue:
https://netmf.codeplex.com/workitem/2236
We need this solved both for a customer project and our Limmat platform.
We just verified that Microsoft has indeed integrated most of the code that we’ve sent them, it’s now on their Codeplex site in vNext:
As far as we can see after a quick check, they’ve copied all our STM32F4-specific files, and even modified some of them.
We’ve also made a small number of changes to the [em]portable[/em] files (as few as we could get away with). They are mostly in two categories:
Network related issues. Here, clearly Microsoft is working an a more fundamental solution of the issues, so it makes sense that they didn’t copy our stopgap fixes.
USB issues. These corrections would be important. The old code, still on vNext, assumes in many places that there only exists one USB controller. We’ll send Microsoft an email about this, hopefully they’ll adopt our corrections eventually.
We didn’t include the Oberon.NaCl crypto stuff, as this is still experimental code. We learned much about it, and as a result will replace one of the algorithms and in particular change the low-level C API. There is no deadline for this yet. Thus the next Mountaineer firmware update will use the current NaCl implementation and we will not yet publish its sources.
Will there be an image for STM32F401?
PS
Our newer solutions are not yet in vNext, e.g. for the 32F429IDiscovery board. We’ll send Microsoft the code.
We hope to get rid of our own Codeplex site, and instead directly contribute source code to Microsoft’s site, in the vNext branch.
There, usually no firmware images are provided. Maybe someone in the community with access to MDK can step in and build and test suitable images for the most relevant boards?
We simply don’t have the time to do it for more than a few boards, and we’ll obviously have to concentrate on the Mountaineer USB/Ethernet/M4-MCU and Limmat boards.
If we [em]did[/em] provide a new image for another board anyway, it would be the 32F429IDiscovery. Maybe. We’ll have to see.
@ Cuno - an image for F429 would be [em]great[/em]. It’s a powerful and moderately priced board, and widely available. Will serve higher need perfectly.
F401, on the other hand, is a very small and [em]cheap[/em] MCU that may run NETMF. Something that NETMF ecosystem doesn’t have at the moment.
You Rang M Lord? :
Give it 10 days or so :whistle:
I can just confirm that on the 401 … it ran and still does run …
@ PiWi - what does the bottom of that board look like?
@ Justin - Ok, starting the countdown timer! 
don’t do that to him ! He might not update his SDK like I want him to :whistle: