4 replies to this topic

[Szymon]

Hi, Last couple of days I was trying to write drivers for the DS18B20 one-wire temperature sensor. I converted the code from arduino library found here: http://milesburton.c...Control_Library Since it relies on one-wire protocol I also tried to convert the OneWire arduino library. The latest version is here: http://www.pjrc.com/...bs_OneWire.html Unfortunatelly I couldn't get it to work using managed ports (I used a TristatePort for data pin). I first confirmed my setup is correct by connecting the sensor to Arduino. It works fine there. I think the problem again is the correct timing. I don't have an osciloscope so I can't confirm this, but since one-wire doesn't even use a clock pin it has to rely on tight timings. As explained on http://en.wikipedia.org/wiki/1-Wire to transmit logical "0" master needs to send short 1-15 µs pulse. To send "1" the pulse should be 60 µs. The arduino code implements direct write through registers and microsecond delays. I don't think we can achieve this timing accuracy in managed code as was already observed by Pavel Bánský http://bansky.net/bl...k/comments.html However guys from GHI have included one-wire support in their firmware. So I run the same code for the temperature sensor on FEZ Mini board (but using their OneWire library instead) and this time it works perfectly. Chris Seto implemented it on FEZ a while ago as well http://files.chrisseto.com/8DC So I'm afraid that to interface with this type of devices we would need native support in the netduino firmware. It doesn't look very complex so I hope it could be added quickly. EDIT: I submited change proposal to the .NET MF team http://www.netmf.com...bf-3e8d70abfffb

Edited by Szymon, 26 August 2010 - 09:46 AM.

[Szymon]

Here is my delay microseconds method:

        private const long TicksPerMicrosecond = TimeSpan.TicksPerMillisecond/1000;

        private static void DelayMicroseconds(int microSeconds)
        {
            long stopTicks = Utility.GetMachineTime().Ticks + 
                (microSeconds * TicksPerMicrosecond);

            while (Utility.GetMachineTime().Ticks < stopTicks) { }
        }

[CW2]

I am working on native 1-Wire driver, I have developed proof-of-concept prototype that communicates with DS18B20 thermometer. Right now I am implementing interop class that provides managed interface to the native driver, much like GHI's OneWire. I am also coordinating my work with Chris, so the 1-Wire support can be included in the future firmware version - however, there is no exact date yet and personally, I don't think I will make it into upcoming 4.1.1, there are some things that has to be done (e.g. support for open-drain I/O) to have 'production' quality code, not to mention testing. So please be patient.

I think the problem again is the correct timing.

I use my own firmware build compiled with GCC 4.4 and the code is almost at the limits. For example, functions to change pin state take about 7 µs, so there is no time for 'A', 'D', 'E' delays (6, 10, 9 µs). Additionally, firmware delay functions are twice as slow, so they need GCC-specific adjustments, which further complicates development, because the official firmware is compiled with RVDS - likely all 1-Wire functions need conditional compilation and calibration for the specific compilers.

However guys from GHI have included one-wire support in their firmware.

Please note Netduino runs at 48 MHz, while FEZ boards at 72 MHz. While Netduino is indeed a great board, it is positioned at the bottom (in terms of performance, memory etc.) of existing platforms, so not everything that works on other boards can be easily ported to Netduino.

[Szymon]

Thats great news! Let me know if I can help with testing or anything.

[CW2]

...compiled with RVDS - likely all 1-Wire functions need conditional compilation and calibration for the specific compilers.

I've just switched to RVDS 4.1, functions to change pin state now take ~4.2 µs, which is almost 2× faster than code produced by GCC. Thus, I have to leave GCC (at least for now), it makes no sense for me to develop time-critical code that has to be completely changed for the release firmware build produced by Chris and his team.