5 replies to this topic

[jvetter]

I'm interested in getting one of those Dallas one wire temp sensors (DS18S20) working with my netduino, but I'm not sure where to start. Looking at the NETMF framework it doesn't seem possible to provide support for it in managed code due to its time constraints. Is this correct? If so how would you approach supporting these sensors? Could it be done if I wrote a un-managed library for it? If so can you point me in the right direction? Thanks.

[Chris Seto]

I'm interested in getting one of those Dallas one wire temp sensors (DS18S20) working with my netduino, but I'm not sure where to start.

Looking at the NETMF framework it doesn't seem possible to provide support for it in managed code due to its time constraints. Is this correct? If so how would you approach supporting these sensors? Could it be done if I wrote a un-managed library for it? If so can you point me in the right direction?

Thanks.

Although you can't do stuff like that in the managed language, you can do that in the device firmware. Ideally, there would be a One Wire driver developed that would bake into the firmware.

I don't know if such a drive exists for the Netduino just yet, or at least I didn't see one when I was looking through the source code.

[CW2]

Although you can't do stuff like that in the managed language

I have not had a chance to verify it yet on hardware, but it is possible to implement 1-Wire communication using a UART (see Maxim Application Note 214). As the SerialPort class allows setting BaudRate and Parity values and the ARM supports open drain mode for I/O pins (PIO_MDER register), it might work - but the current firmware does not seem to support setting open drain mode.

[Chris Walker]

Adding One Wire support to the Netduino firmware would be pretty awesome. At the very least, it would be simple to enable a managed code One Wire library to set the PIO_MDER registers, if a UART could indeed be used to implement One Wire... We have two UARTs exposed (D0...D3) and both are available by default. Chris

[jvetter]

Although you can't do stuff like that in the managed language, you can do that in the device firmware. Ideally, there would be a One Wire driver developed that would bake into the firmware.

I don't know if such a drive exists for the Netduino just yet, or at least I didn't see one when I was looking through the source code.

You would be able to do it in managed code if the timing controls were better (i.e. microsecond vs millisecond resolution). Granted the garbage collector may take over and screw up your timing, but you get my point.

I'm happy to write one in unmanaged code, just not sure what the micro edition equivalent is to delayMicroseconds when using the arduino. Anyone know?

[Chris Walker]

You would be able to do it in managed code if the timing controls were better (i.e. microsecond vs millisecond resolution). Granted the garbage collector may take over and screw up your timing, but you get my point.

I'm happy to write one in unmanaged code, just not sure what the micro edition equivalent is to delayMicroseconds when using the arduino. Anyone know?

A driver like onewire (if you're doing it bitbang-style) should really be done in unmanaged (C++) code, possibly using interrupts.

There are some platform-agnostic sleep commands implemented in the firmware:
HAL_Time_Sleep_MicroSeconds
HAL_Time_Sleep_MicroSeconds_InterruptEnabled

Chris