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.
@segu & @dichotomousgal
I'm working on my little tutorial right now, and it should be ready before weekend. I let you know here when it's published. Hope you like it :-)
There is a class of the TMP102 from Sparkfun
http://www.sparkfun....roducts_id=9418
It's from Jens Kuehners book Expert .Net Micro Framework. I don't think I can post it because of copyright but now you can find it.
Roel
It's from Jens Kuehners book Expert .Net Micro Framework. I don't think I can post it because of copyright but now you can find it.
Roel
Thank you for noting that book. I will search for One wire (maybe he talks something). TMP102 is I2C, I use 1wire because the wires I use/need are 30 meters long, can not be that long with I2C
OutputPort port = new OutputPort(Pins.GPIO_PIN_D2, false);
while (true)
{
port.Write(true);
port.Write(false);
}
With my oscilloscope I see that the period is 115.28 uS. So it take 115.28 / 2 = 57.64 uS to change Digital Port state. To slow for OneWire communication.
With my oscilloscope I see that the period is 115.28 uS. So it take 115.28 / 2 = 57.64 uS to change Digital Port state. To slow for OneWire communication.
Hi Pascal,
Great that you confirmed this with the oscilloscope. I tried this myself and came to the same conlusion like you and Pavel. See here http://forums.netdui...ntation-needed/
@Segu,
I'm afraid that right now if you want to use any OneWire devices you will have to use FEZ boards.
The wikipedia article on 1-wire talks about bridge chips. http://en.wikipedia.org/wiki/1-Wire
For example I found this one DS2482-800 that works over I2C. This might be a viable short term solution.
The same article also mentions that UART ports could be used:
If a parallel port is inconvenient or the operating system interferes with the timing, a UART running at 100 kbit/s with a few resistors and special software can produce and sense acceptable 1-wire pulses.
This is described in MAXIM Application Note 214. Unfortunately, there is no support for open-drain I/O mode on Netudino, required for this kind of communication (wiring RX and TX together). To be clear, the microprocessor supports open-drain I/O (called Multi-Drive), but there is no way how to set it in the current firmware implementation.
This is described in MAXIM Application Note 214. Unfortunately, there is no support for open-drain I/O mode on Netudino, required for this kind of communication (wiring RX and TX together). To be clear, the microprocessor supports open-drain I/O (called Multi-Drive), but there is no way how to set it in the current firmware implementation.
Hi CW2,
If the MCU supports it, we could certainly enable it...
If the MCU supports it, we could certainly enable it...
I am currently evaluating possibilities how to add open-drain mode to existing GPIO configuration mechanism - it may be actually very easy to do, for example by 'abusing' pulldown resistor mode (which is not supported by the microprocessor), or by adding a new GPIO_RESISTOR enum value (RESISTOR_OPENDRAIN or something like this).
I am currently evaluating possibilities how to add open-drain mode to existing GPIO configuration mechanism - it may be actually very easy to do, for example by 'abusing' pulldown resistor mode (which is not supported by the microprocessor), or by adding a new GPIO_RESISTOR enum value (RESISTOR_OPENDRAIN or something like this).
.NET Micro Framework does support extension methods--so there are some options we could explore there as well...
I tested Elze Kool's SHT11 class and it works great on netduino. It compiled and run without any modifications (besides pin assignments in initialization). So this clearly demonstrates the power of .NET MF code portability (he was using Embedded Master in his demo).
Btw. Elze uses interesting convention to separate input providers from the driver code. I assume he did it in case the sensor would be attached on a different type of bus. For example via an I2C extender chip. I'm curious if you use similar pattern in your code? Are there any other best practices for .NET Micro Framework programming?
I just tried to use Elze's class on my SHT15, finally got the app to deploy (that took a bit of tinkering -- didn't realize I had to recompile for MF4.1 and other goodies). However, the app immediately exits:
Resolving.
Link failure: some assembly references cannot be resolved!!
Assembly: MF_Sensirion_SHT11 (1.0.0.0) needs assembly 'mscorlib' (3.0.7186.0)
Assembly: MF_Sensirion_SHT11 (1.0.0.0) needs assembly 'Microsoft.SPOT.Hardware' (3.0.7186.0)
Assembly: WeatherSensorTest (1.0.0.0) needs assembly 'MF_Sensirion_SHT11' (1.0.0.0)
Error: a3000000
The program '[4] Micro Framework application: Managed' has exited with code 0 (0x0).
Waiting for debug commands...
I'm basically using his demo application as well. Anyone have any bright ideas?
I'm basically using his demo application as well. Anyone have any bright ideas?
It looks like his assemblies were compiled against .NET MF 3.0 (i.e. is looking for the 3.0 core assemblies). You need to grab his source and recompile for .NET MF 4.1.
It looks like his assemblies were compiled against .NET MF 3.0 (i.e. is looking for the 3.0 core assemblies). You need to grab his source and recompile for .NET MF 4.1.
Chris
Already did that. Changed it in the solution and did a rebuild.
EDIT: Ok - got it - after I removed the reference to the project and re-added the rebuilt DLL. Silly me - I thought adding the project as a reference would be enough. Man, I need to learn VS better.
RAW Temperature 12-Bit: 1606
RAW Humidity 8-Bit: 80
RAW Temperature 14-Bit: 6427
RAW Humidity 12-Bit: 1284
Temperature Farenheit: 76.203995019197464
Humidity in percent: 42.401607360044963
Temperature Farenheit: 76.257995016872883
Humidity in percent: 42.402734559991586
Temperature Farenheit: 76.275995016098022
Humidity in percent: 42.372413409314696
Temperature Farenheit: 76.311995014548302
