|
These notes are for users
who need more details - they are not necessary to get started. The
code examples supplied on disk are intended as the primary means for the
user to establish efficient and reliable operation of the co-processors.
Description
This co-processor off-loads the process
intensive tasks of 1-Wire communication. It does not require real-time
support from its Host, it can independently handle multiple commands
handed over in a Packet form.
Its EEPROM can store up to eight 64 bit
IDs on-chip and thereby allow addressing of eight devices using a one byte
command. That can be of significant help where the Host cannot temporarily
handle an array of up to 64 bytes.
An internal Strong Pullup has proven more
than sufficient during our testing, but there is also a separate signal to
drive an external MOSFET as recommended by Dallas.
As a measure of performance, Dallas
quotes a Pentium under Windows as being capable of 10 searches per second,
whereas these 8 pin devices can achieve in excess of 100 searches/sec in
Adaptive mode. Adaptive mode is endorsed by Dallas but is normally too
demanding for the active processor.
Main Features of CP-1W
| |
Features |
| 1 |
Handles
Packets of multiple commands |
| 2 |
64
Bit Device Searches and Addressing |
| 3 |
EEPROM
storage of eight 64 bit IDs |
| 4 |
Option
for both Internal & External Strong Pullups |
| 5 |
Option
for Auto-wait on Conversion Complete |
| 6 |
Option
for Adaptive Timing |
| 7 |
Option
for User specified Timing |
| 9 |
Read
back of Time-Slot to +/- 1uSec |
Operation:
Dallas 1-Wire Format
The Dallas datasheets should be consulted
for the exact details of transactions for specific 1-Wire Devices, but
here are the basics:
- Initialisation (Host Reset &
Device Presence response)
- Followed by a ROM Command (plus any
associated data transfer)
- Then a Function Command (plus any
associated data transfer)
The initialise sequence establishes whether
any devices exist, and resets them in preparation for a new ROM Command.
If there is only one device then the 'Skip ROM' command can be used and
thereby avoiding the need to use the 64 bit ID address. If more than one
device exists then 'Match ROM' must be used which is a smart but lengthy
process to establish communication with just one device as all others
remain connected to the same wire.
With only one device now active (until
another Reset sequence) then the intended Function Command can be issued,
for example 'Convert Temperature'. Any additional Functions for the same
device such as 'Read Scratch Pad' to recover the result, require a repeat
of the Initialise & Address stages to that very same device. Some
later devices have a 'Resume Command' for greater efficiency.
The CP-1W can relieve a host of a substantial amount of
work, especially when using 64 bit addressing.
CP-1W Format
The CP's role is basically to relay the ROM, Function
Commands, and Data from the Host to the 1-Wire devices, and interact in
accordance with data sheet sequence for that device.
There is no distinction between data and
command bytes, they both use 0-255. And some command values initiate
different sequences depending on the device type that has been addressed.
Therefore, when the CP is handed a packet of bytes all equal to 0-255, it
needs a little extra information to understand what they will represent to
the unknown device types, and therefore how to interact.
[ Note that this is not a problem in any
way when a computer communicates directly with the 1-Wire devices - its
programmer is fully aware of the device types that are being used, and has
all the data sheets on how they will react. ]
The small differences will be shown by
example. Below we are using a Dallas sequence with the CP-1W equivalent
line for line.
Write Scratch Pad example (only one
device on bus):
| Host |
Dallas
Format |
CP-1W
Packet |
| Tx |
Reset |
- |
| Rx |
Presence |
- |
| Tx |
Skip
ROM |
SkipROM_+4 |
| Tx |
FxWrSPad |
FxWrSPad |
| Tx |
<3
Data Bytes> |
<3
Data Bytes> |
| Tx |
Reset |
- |
| Rx |
Presence |
- |
| Tx |
Next
ROM Command |
Next
ROM Command |
Differences:
- Reset/Presence commands should not be
included
- ROM Commands require a non-inclusive
count of the bytes separating them
Looking closely at the 'Command_'
equates in the supplied files will show that their Dallas values of $F0,
$FE, $55, & $CC have been changed to simply $00, $10, $20, & $30.
That provides the space needed for adding a nibble count of the bytes that
separate one ROM Command from another.
The user simply specifies Match, Skip
etc. '+count', and the CP restores the true Dallas Command values once it
has figured out what is intended.
Another noticeable difference is that
Reset and Presence are not needed, but they will be added automatically
before reaching the 1-Wire device.
Write Scratch Pad example (more than
one device on bus):
| Host |
Dallas
Format |
CP-1W
Using E2 IDs |
CP-1W
Using Immediate ID |
| |
- |
SAandID_+0-7 |
SAandID_+$F
8 Bytes of ID |
| Tx |
Reset |
- |
- |
| Rx |
Presence |
- |
- |
| Tx |
Match
ROM |
Match
ROM_+4 |
MatchROM_+4 |
| Tx |
8
Bytes of ID |
- |
- |
| Tx |
FxWrSPad |
FxWrSPad |
FxWrSPad |
| Tx |
<3
Data Bytes> |
<3
Data Bytes> |
<3
Data Bytes> |
| Tx |
Reset |
- |
- |
| Rx |
Presence |
- |
- |
| Tx |
Match
ROM |
Match
ROM_+cnt |
Match
ROM_+cnt |
| Tx |
8
Bytes of ID |
- |
- |
Differences:
- The Device ID must precede all other
Packet data and is only required once per Packet regardless of number
of ROM Commands
- If Immediate Mode of '+$F', all 8
bytes of ID must also be included
- If stored in EEPROM then just the 0-7
slot# is needed
Regardless of whether using EEPROM or
Immediate ID addressing, those details precede all other Packet data. All
commands in the same Packet use a copy of that ID, it should not be
repeated.
When using EEPROM the SAandID_ symbol has
the extension of '_' in order to prompt the entry +(0-7) for one of the 8
IDs. In the case of specifying the ID as Immediate bytes then use +$F.
When not using the Immediate IDs, there
are 8 bytes that could be re-claimed for the buffer in order to hold more
commands or for returning more data. This can be achieved for cases 0-6
(does not apply to 7) by adding 8 to give a range of 8-$E.
Read Scratch Pad example (only one
device on bus):
| Host |
Dallas
Format |
CP-1W
Packet |
| Tx |
Reset |
- |
| Rx |
Presence |
- |
| Tx |
Skip
ROM |
SkipROM_+1 |
| Tx |
FxRdSPad |
FxRdSPad |
| |
|
ReadDev_+3 |
| Rx |
<3
Data Bytes> |
<3
Data Bytes> |
Differences:
- A directive is needed to indicate that
the Function Command transfer of bytes is a Read rather than the
default Write.
The Function Read S/Pad has a value of
$BE, or it could be a different value in the future. All that CP-1W
needs to know is that data will be read, and the number of bytes, hence
the directive 'ReadDev_+3'. Note that this should be the last operation of
a packet.
Example Code:
There are approximately 30 ready-to-run
code examples on the support disk supplied with CP-1W, and covering 10
different devices/buttons. When combined with the above should prove
adequate for most applications.
Download
Example Files
|
