Oh OK. After I got done putting in all the rubbish to make the C++ and C symbols work together I did feel it would be better as a class. I'm away from that hardware until Tuesday, I'll redo it as C++ then.

I've finished. I  packaged the 1-wire functions into a library for Arduino. It includes the read and write byte functions, reset, device enumeration, and CRC computation. The comments about how one might use it are in the library source.  Sadly, it won't fit in a post anymore.

You can pick up the files at http://core.federated.com/~jim/onewire/

Create an arduino-0007/lib/targets/libraries/OneWire/ directory and put them in there. You will probably need to quit the arduino program and restart to get it to notice.  The test.c program doesn't go in the library, it was a little test program you might find useful.

The test is working fine on my unit with 4 DS18S20s connected.

Physically, I have all the DQ lines connected to my IO pin, all the grounds connected to a ground, and 4.7k ohm resistor from a Vcc to the DQ lines. It would be best to connect all the remaining pins of the DS18S20s to either Vcc or GND, then a regular DS18S20 (not a -P) would still work in either normal or parasite mode depending how you connected it.

If you are going to have any kind of wire run I would suggest looking at some of the ESD protection variations (resistor in series with IO pin and 5.5v Zener diode to ground) to keep the stress down when bad things happen.  Likewise, I think it would be possible to make this work using the internal pull-up of the Arduino, but decided that would be a needless stress with there is a short, and the resistor is a bit too big so it would be bad on longer cable runs and possibly not able to supply parasite power.

I have the grounds connected, the DQ pin on the DS18S20P connected to the pin of the Arduino, and a 4.7kohm resistor from DQ to +5v as the pullup. It is good to connect the Vdd pin of the DS18S20P to ground also so if you get a non-parasite version (DS18S20) it will also work in parasite mode.

If you are going to use more than a few of these on the same pin you will need to use a pullup transistor and another pin, as shown in the DS18S20 datasheet, but for a few, say less than 10? of them the Arduino has enough current capacity.

Ok, the world has not gone crazy.  The Atmels really do provide >20ma on the pins and the DS18S20P does take about 1ma.  The problem was in the timing. As soon as the DS18S20 receives the 0x44 it will start taking current for the conversion. Unfortunately, the write_byte function is sitting around for many microseconds with the pin in a high impedance state in order to provide timing margins. The DS18S20P crashes before the power gets turned on.

The solution is to not let the external pull-up bring the pin high after the low period of the final bit of the 0x44 is written, force it high with the output driver. Then after the 750ms conversion period passes flip the pin back to an input and let the external pull-up take over.

My little sensor is now happily converting away on my desk.

I'll clean up my changes to the one-wire code and put them up here soon.

I'm missing something here, looking at the atmel source current spec (~20mA) and the ds18s20p current (~1.5mA) draw during a conversion it should be able to power a dozen temperature sensors on a single pin without a problem. Very odd. It is almost as if the Atmel is using its internal pull up resistor to go high instead of the buffer, but I don't see a combination of settings that would cause that. I'll try a bunch of resistors and make a current/voltage plot when I get back to m analog bench and see what those ports are really doing.

You almost certainly have a DS18S20P on your hands. This is a variant that only uses parasitic power, the power lead is not connected in the package. You can verify this by using another pin to trigger a scope just before you write the 0x44, you will then see the 8 bits followed by a tragically sagging voltage on the data pin.

I ran out to the FET shop and got a VN2406L (the guy said "everyone buys these", good enough for this) and wired it to another pin like the data sheet shows and everything works now.

The only sad part about this is that now you have to blindly wait 750ms for the temperature to read instead of waiting just long enough.

You have a linux server handy, can you just have the PHP script run there and send serial commands down to the Arduino? It really is 20x easier than making a dedicated ethernet front end. There is a class that might help... http://phpclasses.promoxy.com/browse/package/3679.html. Unfortunately PHP Developer's Network is apparently designed to annoy visitors and they have worn out my patience with redirects and asinine policies before I managed to get the code downloaded.

Remembering that I am but a simple cave programmer that does not know about fancy tools...

I access some Arduinos over the WWW using cgi bins that are simply shell scripts that echo strings to the serial ports and read back the results.

I suppose slightly more evolved  programmers might use PHP or something similar.

If you knew the URL to this and sent an 'R' in the query string you would set off my corporate "compromised server" alert and send me into a panic.

Code:

#!/bin/sh


echo "Content-type: text/html"
echo ""
echo "<HTML><HEAD><TITLE>Set Lights</TITLE></HEAD>"
echo "<BODY>"

echo "$QUERY_STRING" > /dev/usb/tts/0

echo "<br>You have just set the lights."
echo "</BODY></HTML>"

There is a function hiding in the AVR libraries version of <stdlib.h> to convert an integer to its string representation...

Code:

char *itoa( int value, char *string, int radix );

You need to make sure there is enough space in "string" to hold the resulting string and its NUL terminator.

It would be nice if all of the libraries used this. It is a little large, but by the time the wiring_serial implements a conversion, and the SoftwareSerial, and the LCD, and my own interrupt driven serial output functions there are a lot of similar functions hanging around.

You have an LED and a phototransistor. When the LED is powered and nothing is blocking the light the phototransistor will conduct in one direction. If the LED is not powered or something is blocking the light then it will not conduct.

Take a look at the wikipedia article on Opto-isolators, that is basically what you have except something can block it.

I little Ohm's Law work will tell you to use a 220 ohm resistor for R1 to keep the LED current to about 20mA, safely inside the pin capacity of the Arduino and the capacity of the LED. R2 is a little trickier. I think I'd size that for a 1mA current flow, no need to get crazy with the power use, maybe a 4.7k ohm resistor. You might need to play with that a bit to balance out the sensitivity with varying ambient light levels.

So to continue, if you connect an input pin between R2 and the phototransistor then it will be low until a coin slides by when it will blip high.

You must poll very fast to catch it or use an interrupt pin.

The Arduino sets timer0 to increment every 64 cycles. When it overflows after 256 cycles it increments a variable that controls the millis() function. To get better resolution, you could peek at the counter by looking at TCNT0. You must be careful though, there are race conditions to confuse you. For instance... between the time you call millis() and check TCNT0 you don't know if millis() changed. It might be safest to do something like...

Code:

m1 = millis;
t0 = TCNT0;
m2 = millis;
if ( m1 == m2) {
  // I know what I'm doing.
} else {
  // I don't know. A low t0 might mean it is from after the millichange
  // and a high might mean before, but we can't be really certain.
}

And this isn't a documented API, so you never know when a release will change the resolution of timer0 and really mess you up very badly.

Sound only moves 1-2mm in air at this timer resolution, so it should be good. You just have to deal with the hassle of the race condition and the checking your code after Arduino releases. Welcome to life "outside the lines".

Perhaps you could use some sort of signature? Say, if the the EEPROM begins 0xdeadbeef or whatever you choose then you will believe that you have initialized it and it has your data in it. Otherwise, initialize it in your code. You probably want a version number in there too so you know when it is initialized with old format data after you inevitably change formats.

You can call millis() inside your ISR. Don't call delay(), it will hang.
You will need to think about doing the sending as well... depending on your baud rate you might take too long and lose a timer interrupt. I think I'd just right the timestamp to a global variable in the ISR and let the loop() notice the timestamp was written and do the sending.

You can use portModeRegister() to get from a port to the data direction register for fast direction changes. I think a 1 in the bit position is output and a 0 is input.

I'd use pinMode() in the constructor. It does some checking, but you only do it once so its no big deal. Also in the constructor I'd save the port,pin, and mask for the pins in instance variables. Then the rest of your operations will be very fast.

One note on constructors that has bitten me... The Arduino initialization routines run after your constructors, so you have to watch out for things being altered by the initialization code. I don't think the data direction registers are set in the initialization, but you might want to check if it seems your output pins are not being outputs. I know it forced me to add .begin() functions to a couple classes that use timers because the initialization code would overwrite their settings.