This is a VERY big, HUGE, tutorial. But it does cover "everything" (well... lots, anyway.) It follows on from a similar tutorial in which I explained the fundamental workings of the Dallas MicroLan, the system for connecting 1-Wire ® chips to a computer or microcontroller. You should probably struggle through that... and it will be a struggle... before attempting the following, which is also hard. But not as hard if you have mastered, or at least tried to get to grips with, the material in the other essay first.
Before you read another paragraph: "Restore" your browser's window... i.e. make it take less than the whole screen. Then adjust the width so that lines are not so long as to be hard to read. (You may need to stretch it out again when it comes to the Big Diagram, though, to make the text on that readable. Sorry. Open the Big Diagram in a second window, so you can refer to it separately, without scrolling.)
You may also, if using Firefox, at least, want to press ctrl and the + key one or more times, which will magnify the text. To restore the page to normal viewing: ctrl and the zero key.
Right. done that? Onward. Don't try to digest all of this in one sitting. If it is too rich, too academic, too theoretical for you, almost all of my other pages are the opposites. My other pages tend to dwell on "do this, to get that."
But mastering the material in this page, and the one before it, will be a BIG help to you, if you want to make 1-Wire chips obey your every whim.
I'm going to repeat myself several times in the following. Don't think that I wasn't paying attention to what I was writing... I am re-iterating points to try to help you consolidate the ideas. The 1-Wire system is incredibly elegant, but it can be a little hard to grasp initially because there are several interlocking elements which all have to be understood "at once."
So... TMEX, etc. The rest of this is couched in "doing it using a PC for the master" terms.
So here's how it goes...
At the heart of a MicroLan managing program, whatever the language, you will see calls to the TMTouchByte function. The examples below are from Delphi programs, using the same syntax as the perhaps more widely known Pascal.
If I say....
... then the TMTouchByte procedure will attempt to "catch" a number. That number is the number that we hope is being sent from a 1-Wire chip on the MicroLan. (If no one is (about to) send, we called TMTouchByte at a silly time.
"TMTouchByte" is a "word" that your programming environment will "know" after you have installed the 1-Wire SDK. In future, I will convey similar facts with the more telegraphic "TMTouchByte is a function supplied in the 1-Wire SDK." (Actually, just having the file IBTMEXPW.PAS available to your compiler, if you are using Delphi, and a few DLLs in the right places, are all you need to do MicroLan programming with Delphi, but a full install of the SDK gives you local access to help files, etc.)
liSHandle is a variable which we have filled with something before we try to use TMTouchByte. I'll explain the filling process in a moment.
iTmp is just a variable that we don't have anything still important in before we make the function call. It should be capable of holding a signed 16 bit integer.
That brings me to a little "gotcha". You might expect that TMTouchByte would return a byte, and you might think that a "byte" is a number from 0-255 inclusive. Nah Nah. "Wrong" on several counts.]
1) TMTouchByte will return a 16 bit number, and you are supposed to treat it as a signed integer.
2) A byte IS, everywhere that knows what "byte" means an eight bit binary number. (The word comes from "by eight" said rapidly). But do you "translate" those 8 bits into 0-255, in everyday (decimal) terms, or into -128 to 127 decimal? I couldn't find an answer to that! (So, hopefully, the TMEX documentation doesn't use the term "byte" in any context without being explicit, or where it matters how you are going to interpret the 8 bits of the byte.
There is a page in the help file that is important in this context: The TMEX Type Descriptions page. Be especially careful with the following, and remember how they are being used in the TMEX documentation...
short 16 bit signed integer long 32 bit signed integer char 8 bit signed integer unsigned char 8 bit unsigned integer
... and remember that your programming language may be using the same words DIFFERENTLY. Delphi, after Delphi 2, anyway, for instance, uses the following...
Smallint 16 bit signed integer Longint 32 bit signed integer Shortint 8 bit signed integer Byte 8 bit unsigned integer Word 16 bit unsigned integer
Beware: Both SMALLint and SHORTint exist... and they are different things.
(Did you notice, in the TMEX definitions, "char" and "unsigned char"? Each is an 8 bit number. The difference is in how you interpret the 8 bits. The first would be able to show decimal numbers from -128 to 127, inclusive, and the second would be able to show decimal numbers from 0 to 255 inclusive.)
While the TMEX types list doesn't mention the TMEX name for 32 bit unsigned integers, it may be useful to you to know that Delphi calls them "Cardinal"s. (The DS2423 counters are 32 bits wide, and they encode the numbers as unsigned numbers.)
In the Delphi table, you can see that within a Delphi program "byte" means something more specific that "byte" means in the wider world. Likewise, Delphi narrows the definition of "integer" to a signed 32 bit number.
(Delphi "cardinals" and "integers" are both 32 bits wide. You can't tell if something is a cardinal or an integer by looking at it. But knowing which it is tells you how to interpret the 1s and 0s, how to convert that number to decimal, if the urge takes you, and what range of numbers can be shown in the 32 bits.... 0 to 4294967295 inclusive (cardinal), or -2147483648 to 2147483647 inclusive ("integer"... in Delphi programs)
Head spinning? This essay is definitely one you need to go through a number of times. Sorry. But we're laying lots of groundwork, which will give you a good foundation, once you get past the early part of the learning curve. Think about doing jigsaw puzzles... the start is tedious, but gradually sections of the result begin to come together, and from there the sections eventually come together to generate the final, whole, result. So too getting to grips with something like using 1-Wire where you have hardware and software "sections", and have to stay on top of what is going on in the 1-Wire chip, and what is going on in the master.
Back to TMTouchByte....
If I say...
... then the master will transmit 57 onto the MicroLan. That line is how we achieve things like the "Master TX Memory Function Command" called for in the process explained over the many paragraphs above. The "Memory Function Command", remember, is just a number. "57" is an unused number, as far as I remember, but if you did....
... at the right moment, you would be requesting the "Read Memory + Counter" we talked about. We said that the number for that is $A5, and indeed it is. Indeed, you could say....
... which is exactly the same thing as what we said in the previous command... because 165 is the "everyday" (decimal) way of saying $A5.
But wait a minute... Earlier we said...
... is a way to read FROM the MicroLan, but
... writes TO the MicroLan? A neat little trick was employed by the people who wrote the code that is executed when you call TMTouchByte: If we use 255 (also frequently written as "$FF") for the second parameter of the function, then we will do a READ FROM. Use any other number, and TMEX understands that you want to do a WRITE TO. The catch? You can't SEND 255, can you? Happily, you never need to.
And now another wrinkle...
It is obvious (I hope!... If not, re-read the previous paragraphs!) what will be in iTmp after a successful call of TMTouchByte(liSHandle,255). But what about after a call using a different second parameter. We are "just" writing TO the MicroLan, right? Well, yes... but even so, something will be "returned", and will be available to us in iTmp. If all went well, iTmp will hold 0 or 254, or something in between. If iTmp holds 255, it means that the MicroLan was shorted when the TMEX drivers tried to send a message out over DQ. If iTmp holds something less than zero after a call of TMTouchByte, it tells you that something went wrong. There's a table in the TMEX help files that says....
(-1) PORT_NOT_INITIALIZED - Specified MicroLan has not been initialized with a call to the TMSetup function. (-2) PORT_NOT_EXIST - Specified MicroLan nonexistent. (-3) NO_SUCH_FUNCTION - Function not supported. (-12) BCOM_FAILURE Failure to communicate with hardware adapter (-13) BCOM_EVENT An unsolicited event occurred on the 1-Wire (-200) INVALID_SESSION - session not valid (not applicable in DOS TMEX) (-201) HS_NOT_FOUND - Hardware_Specific driver not found and is required.
Here's how you interpret that....
If iTmp holds, for example, -2, then it means that when you tried to do TMTouchByte, the port/ MicroLan you asked to use (we'll come to how you ask) didn't exist at the time you tried TMTouchByte. The "PORT_NOT_EXIST" part is probably an "official" abbreviation for the name of the error reported by the "code" "-2"... but I wasn't able to use the phrase in compiling a Delphi 1-Wire project. The phrase might be used in other parts of the TMEX documentation.
Not only does iTmp report errors after an attempted write- to- the- MicroLan, but it will also report an error after an unsuccessful attempt to read from the MicroLan.
If it holds 255, the MicroLan might be shorted... but you would probably have detected this at another point in the process. If iTmp has 255 in it after a TMTouchByte(liSHandle,255), the MicroLan was probably sending a 255. If iTmp holds 0-254 (inclusive), that's what the MicroLan was sending. But if iTmp holds a negative number, then an error is being reported, just as it was before, after an attempt to write to the MicroLan.
The relevant entry in the TMEX help is...
Return Value >=0 => byte returned from MicroLan while sending byte 0xFF => 1-wire bus is shorted. <0 => TMEX Hardware Specific Error Return Code
... about which I have several comments...
The first ">=" in that DOES mean "greater than or equal to". Every other ">=" is merely "punctuation"... so the little block of text quoted above should be read as follows....
Return Value If the value returned is greater than or equal to zero, (but not 255, which the TMEX help forgets to say explicitly) then what is returned is the byte returned from MicroLan. (I think the "while sending byte" is an irrelevant, unnecessary qualification. Or perhaps 0-254 are meaningless when returned after a "read" is done, which happens if you call TMTouchByte with something other than 255 in the second parameter.) If the value returned is "0xFF", which is another way of saying FFh or $FF, aka 255, then the 1-wire bus appeared to be shorted when a write was attempted, and MAY have been shorted during a read, but this would probably have been caught elsewhere. TMTouchByte, when reading from the MicroLan cannot tell the difference between a "sent 255" and a short. If the value returned is less than zero, then the TMEX system is reporting a problem. You consult the "TMEX Hardware Specific Error Return Code" page in the help file to "de-code" the message.
Whew! Fear not, we ARE getting there!
Think back to the flowchart setting out all the things we need to arrange. Right at the start, the flowchart says that the master should send a "reset" message to all the chips on the MicroLan.
Here's another link to the flowchart for you. I would suggest you print it out, or at least open it in a separate window which you can move to one side on your desktop. The link will open in a separate tab or window, depending on how you have your system configured. With Firefox, if you right-click on the link, you will be offered "Open in new window", among other things.) Don't be overwhelmed by how much is in the diagram.
To send a "reset" message to all the chips on the MicroLan, we call the TMTouchReset function, another function supplied in the 1-Wire SDK. And it is (relatively!) simple: You just say....
... where things are as they were for
(Apart from the fact that TMTouchReset only takes one argument, of course... one "thing" passed to the function inside the parentheses after it.)
Again, After the call, what's in iTmp tells you whether all went well. It even gives you a little bit of information that relates to any "presence pulses" sent back to the master in the moments after the reset pulse was sent. Again, the page in the help file rather unhelpfully uses "=>" as mere punctuation, but this time, at least, it is more obvious, I hope. In the following I've replaced each "=>" with the word "means". And don't panic... I'll be simplifying what's in the quote...
Return Value 0 means no presence pulse detected. 1 means a non-alarming presence pulse detected. 2 means an alarming presence pulse detected. (Not available on all platforms.) 3 means MicroLan was shorted when reset attempted. 5 means TMTouchReset not supported on the system you are working with.
First a quick other possibility: If TMTouchReset returns a negative number, that is an error message, and the "code" is the same as before. Whew. See... I told you that the things we struggled with earlier would pay multiple dividends.
Now... back to those return values.
A moment after you send a reset signal out across a MicroLan, all of the devices on it "shout at once" saying "we're here." That "shout" is in the form of a "presence pulse". If there are no 1-Wire chips on the MicroLan, you get no presence pulses, and after...
... iTmp will equal zero.
In our simple world, we haven't yet looked at "alarming" devices, and we aren't going to look at them closely here. But I will explain this: A lion in your back yard is always "alarming". It will cause you to become alarmed if you see it.
A ringing telephone is not always "alarming" in the sense that a lion is alarming. You may be expecting a phone call from your mother.
In the world of 1-Wire chips, when the documentation speaks of an "alarming" chip, it is saying something about a STATE of the chip, and saying nothing about how you may or may not react. It might have been better to call it the "ringing" state. Many 1-Wire chips can be in the "alarming" state, or not, depending on circumstances.
If when the MicroLan is reset, no chip on it is in the "alarming" state, then iTmp will hold 1 after TMTouchReset. One or more presence pulses were detected coming in from the 1-Wire chips on the MicroLan. But no chip was sending the special presence pulse which says "I'm here, and I am in the 'alarming' state, i.e. something has set me 'ringing'".
Can you detect if there were any "ordinary" presence pulses in the "fusillade" of "I'm here" shouts, if one of them was a presence pulse from a chip that was in the "alarming" state? No.
Why we have "alarming" states, how we focus on the chips in the "alarming" state are fascinating and useful topics... for another day.
There must be about 50 function calls in the list of the functions provided by TMEX.
We've looked at two. Admittedly, one of them (TMTouchByte) is cleverly, and gives you "two functions" in one, but, believe it or not, we've covered all the functions we need (sort of) to! With them, we can do all of the things called for by the flowchart we studied so long ago, at least if all we want to do is to read the counter registers inside the DS2423... or read a temperature sensed by a DS1820.... or set the output bit of a DS2408 high... etc!
Oh. Well. There is the tedious little detail of checking whether an error code was returned any time you call any of the TMEX functions, and dealing with it when it arises. But that is a detail. (The error codes any function can return are detailed in the TMEX help pages.)
There's just one little catch. Of course. But it is a little one!
Before you can use TMTouchByte or TMTouchReset, you have to "set things up". And when you are done. you should "put away your toys.
But you only have to master five more TMxxx functions to cover all of that! You are, believe it or not, nearly done!
I have done a separate tutorial which, in Delphi, gives you a full program (sourcecode too) to read the counter registers in a DS2423. It creates a little window with two buttons. One fetches the current A counter register value from the DS2423, and the other fetches the current B value. That tutorial covers much of what you have been reading about here, but in more specific terms. There's not much left on this page... I would suggest you finish it, to complete your "general education". It will help you race through the page about the program for reading the DS2423. I'll give you another link to it at the end of this page.
We have seen that the TMEX routines are at the heart of interacting with our MicroLan.
Before we can call TMTouchByte, to read or write information to or from the MicroLan, the TMEX system needs to know certain basic things. What sort of adapter are we using? Where is it plugged in to our computer?
Not only is that basic information needed, and preferably passed once before we "get down to business", but also it would be helpful if our program and TMEX had a common "scratchpad" of memory space which could be used for "passing messages back and forth" when those "messages" are a bit too big for the simple passing of parameters which functions and procedures use. You should also remember that you can "talk" to TMEX from almost any programming language. By using the "scratchpad" (more properly called "the state buffer") to pass things between the calling program and the TMEX routines, we reduce the need to get into the details of any language's passing conventions.
Part of "getting set up" is to "clear out" (as far as necessary) and initialize as "not used yet" the contents of the state buffer.
So... what calls are needed?
We start with a call of TMExtendedStartSession. We pass to TMEX where the adapter is connected, and what type it is. TMExtendedStartSession returns a number, which we store for future use. That number is the current "Session Handle". (It is like a "File Handle", as used in some routines for accessing files on disk, if you know about them. It doesn't matter if you don't.) We don't care much about what the number is, unless it is one of several rogue values which tell us that there was an error during the execution of TMExtendedStartSession. Have a look at the TMEX help file for the details of those error messages. All but one are negative numbers. If the routine returns a zero, the one non-negative rogue value, then it means that the port is currently in use by someone else, and you can't use it now. (Just try again later, assuming that your system is only running things which will not "hog" the resource.
That brings up an interesting issue. You might be tempted, especially if you read certain things in the TMEX documentation, to do TMExtendedStartSession, to do it just once, as your application is firing up. I think this is a Bad Idea. Better to start a session just before each need of the MicroLan, and then shut down the session (and release the resources) as soon as you are done, for now, with using the connection to the TMEX, and thus (indirectly) to the MicroLan.
If you decide to leave your session active for extended periods, you should look into TMValidSession, which allows you to check if the session you think is open is actually still open. I believe that they are shut down if a certain period of inactivity elapses, among other things.
By the way, why TMExtendedStartSession? Would you ever want to use the "basic" "StartSession" (TMStartSession). No. Unless you were writing for a system which didn't have the 3.xx 1-Wire drivers.
Now you have told TMEX where the adapter is, and what sort it is. (TMEX will take care of the details associated with those two facts "invisibly" from now on... you ONLY need to change the numbers you pass to TMExtendedStartSession to use the same program in a different hardware environment. Ah, the joys of a good API!)
The next call you will always, I think, make is to TMSetup.
To quote from the TMEX help files. There's a lot in this, which I will pick apart in a moment. It isn't a complicated call... you can think of it as the second stage of initializing the TMEX system.
The TMSetup API function must be called before any other TMEX functions except the Session layer of API calls. No other TMEX API calls will operate correctly until the MicroLan has been called with this function. It is intended to be called once at the beginning of an application to initialize the MicroLan and verify the physical integrity of the MicroLan. Note that execution of this function will reset all the parts on the specified MicroLan.
Discussion of above:
...."except (functions relating to) the Session layer of API calls"...
"...It is intended to be called once at the beginning of an application..."
This is the item in the TMEX help which I question. I discussed above my preference for starting and ending sessions within an application, so that one isn't open except when it needs to be. An open session ties up the adapter and port it relates to. There may be situations where the time overheads of opening and closing sessions may lead you to decide that your application needs to create an environment where other 1-Wire applications will operate unreliably. (This possible clash of sessions is why I rarely run OneWireViewer at the same time as I am running one of my own 1-Wire applications.)
"execution of this function will reset (all of the chips on the connected MicroLan..."
This isn't the pain you might fear it could be. The simple DS2423 we are using for our discussion wouldn't mind being reset repeatedly. (The counters don't go back to zero upon a reset, as used here, if you have provided the DS2423 with the backup power that I haven't discussed, but which you would probably want to supply. (It is easy... see datasheet). There are other, fancier, 1-Wire chips which you initialize before using. There are ways with these, too, to go through a reset without having everything go back to "square one". (There are chips, for instance, with real time clocks (RTCs, "clocks" which track year/ month/ day/ hour/ minute/ second... like your wristwatch. You can "reset" one of these without having to then re-enter the current date and time.)
So... TMSetup demystified?
It has some "error" codes which are not negative numbers. For full details see the TMEX help, but note two return values in particular:
Before we make our next call to a TMEX function, we need to fill a part of the StateBuffer with some data. Don't worry, it isn't as bad as it sounds.
The data is the serial number of the specific 1-Wire chip on our MicroLan which we wish to interact with.
(Something you may understand, should understand... but don't need to: We're just about to get TMEX to take care of a "Match ROM" command for us, the stuff under box "B" on the big diagram.)
I'm talking about the chip's own, unique serial number... not just the general number shared by, say, all DS2423s ($1D).
You can most easily find a chip's number by using OneWireViewer. (Details of this are in the tutorial with the details of actually reading the DS2423's counter registers. The chip numbers are in the box at the left. They will always consist of eight bytes, although they are written many ways....
17 00 00 00 0D D1 31 1D 1700.0000.0DD1.311D 170000000dd1311d ... etc....
(They are sometimes written back to front, e.g.
1D 31 D1 0D 00 00 00 17
(Note that the reversal is only of the 8 bytes, not of the characters within each byte.)
You can tell if something has been reversed, because the device's general code will be at one end or the other, at the "right" end in what I consider the "un-reversed" state. In the example, the device code was $1D, the code present at the end of all DS2423 serial numbers.
Now... as I started to say, those eight bytes need to be put in a specific part of the StateBuffer, and the "putting" is taken care of by the TMEX call TMRom... Oh Good! Something easy. Almost.
Before you can call TMRom, you have to put the eight bytes into another, smaller buffer, which you set up for that purpose. Or, you can have the IDs stored in multiple buffers, and change your call of TMRom to reflect the chip you want to work with. (I've never used the latter approach, but it is probably a good one. I just keep re-filling my one buffer, which I called siaROM in the example program which is covered in my Using the DS2423 tutorial)
And here's a little "gotcha"... It seems weird, so double check this, if you don't get good results, but I'm pretty sure that TMRom expects the contents of the RomID buffer to look like this, to pass the ID string I gave you earlier....
00 1D 00 31 00 D1 00 0D 00 00 00 00 00 00 00 17
Two things to notice here:
1) In the buffer, the eight bytes of the ID are spread across 16 byte sized memory locations. The first byte of each if the 16 bit fields is 00.
2) The ID is stored in the order I call "backwards". (Double check that in particular! The code in my Using the DS2423 tutorial works fine, but there are several ways for all of this to get turned upside down, inside out! Don't fall prey to one of them!
Right! Now that you have the ID in the buffer for that (which you have to create and fill, and have a way to refer to with a "pointer".. "@siaROM", if you've done things my way, and in Delphi or Pascal) you've done the hard thing.
You already have the "Session Handle", (in the variable liSHandle if you did things my way). You already have a block of memory set aside for the StateBuffer, and a way to identify it with a pointer ("@baStateBuffer", if you've done things my way, and in Delphi or Pascal)
You'll need someplace to put the value returned from the call. It will be a signed 16 bit integer. For the example we're doing, we'll assume there's a variable called "siResult" for that.
Whew! But it was worth it. After all that, all you need to do is... in my terms...
That will fetch the chip's ID from the buffer "siaROM" and move it to the right place in the StateBuffer "baStateBuffer" associated with the session handle that you obtained earlier.
ALL OF WHICH is just to prepare you for what comes next...
We're now moving past the "set up our interface to TMEX" and into using it. We're starting into the big flowchart of 1-Wire operations.
We need to make a call to either TMAccess or TMStrongAccess. There are pros and cons. (The TMEX help pages will tell you about the calls.) I've mostly used TMStrongAccess, and will talk about that.
TMStrongAccess takes care of everything on the 1-Wire flow diagram (above) From "A", though "B", to "F"!!! Wow! That was quick! If you read the first half of this discussion, you may remember that it took us many, many words to discuss all that has to be done to get from "A" to "E". It is important that you understand what is going on... but aren't you glad that the TMEX API takes care of so much for you with so little hassle?
Celebrate! You may not know it, but you've done a Really Big Thing. A thing that you will need to do again and again in all of your 1-Wire programming. (Except you are using the ultra simple "one chip per digital input/ output line" scenario).
You are now at "F" in the big diagram.
From "F" onward, we have to check the datasheet peculiar to the chip we are using. While they all operate in similar ways, the details vary from one type of chip to another.
In the diagram above, the material at the bottom is the detail of part of what a DS2423 can do.
"All" that is left to work with the DS2423... apart from a call of TMEndSession which I'll explain in a bit... is a bunch of TMTouchByte and maybe a TMTouchReset call or two. the TMTouchByte calls will be of both sorts... the one that reads a byte from a 1-Wire chip which has been told to transmit onto the MicroLan. (I.e. a call of TMTouchByte with $FF for the second parameter), and calls of TMTouchByte which send a byte out onto the MicroLan.
Remember: Both sorts of TMTouchByte call return a 16 bit signed integer to the calling program; they don't return just a byte (8 bits). The returned value may indicate that an error occurred during the call of TMTouchByte. the call is not badly named, though, because only 8 bits are returned except when the returned value is flagging an error.
In part H of the big diagram, we see how to fetch the numbers in the DS2423's counter registers. We have to fetch other stuff along the way, which in another life we might want to use, but for now, we're only interested in the numbers in the counter registers. (There are two registers. We have to pass through "H" twice to fetch both of them.)
The details are given in my Using the DS2423 tutorial, but here's an over-view. And don't forget that TMEndSession still needs discussion... but that's all that is ahead!
Executing the steps below "H":
"Master TX TA1": First you have to know that "TA1" is just a number. Use $C0 here if you want the register associated with Input A, and $E0 for the register for B. (Or is it the other way around? Whatever's in the "details" tutorial is right.
Once you know that TA1, here, would be $C0 or $E0, then all that's left to know is that to accomplish what the box calls for, you use....
"Master TX TA2": Even easier. For reading the counter registers, TA2 is again just a number, this time always $01.
To accomplish what the box calls for, you use....
"DS2423 Sets Memory Address": This box is just telling you about something that is happening. You don't need to do anything.
For now, just ignore the two decision diamonds. (They are explained in the tutorial with details.)
What we've done so far is enough to get the DS2423 "spitting out" numbers, and to have the adapter on the master ready to receive them.
We do a certain number of....
... calls, and they "harvest" the bytes the DS2423 is spitting out. In among them are four bytes which we combine to form an unsigned 32 bit number. That's the number which was in the counter register inside the DS2423!
We're done.... apart from one last simple but important step....
A long time ago, we did a TMExtendedStartSession. That "tied up" the MicroLan for our use. We should now release the MicroLan. All it takes is....
The value in siResult after this call will tell us if the session close uneventfully.
As I said, I also I have also done for you a separate tutorial with you the full sourcecode for an application to read the counter registers in a DS2423.
I'm sorry, but I'm going to end this somewhat abruptly here (again!), as there's a lot of work to do still to get the text online for you, and I suspect you'd rather I did that than do a flowery "concluding remarks" section?
Long ago, I addressed using the DS2423 once before. I don't think I did nearly as well as the explation above, and in the associated general overview of doing programming for 1-Wire, but if you want to look at another DS2423 reading program, here's a zip with sourcecode for that.
Page WILL BE tested for compliance with INDUSTRY (not MS-only) standards, using the free, publicly accessible validator at validator.w3.org
....... P a g e . . . E n d s .....