[aprssig] APRS bit I/O
aprs at mulveyfamily.com
Thu Jun 28 12:40:04 CDT 2007
'Scott Miller' wrote:
> Also kind of related... I got a bunch of Dallas DS2405 1-wire switches the
> other day. These are in 3-lead TO92 packages, like transistors. I brought
> the 1-wire bus from a Tracker2 out to a protoboard and dropped a DS2405 on
> it, and it IDs just fine. Drop another one in parallel, and it shows up to.
> You can do that with however many devices the bus will support - I forget
> the actual number.
> So far I've had two problems to deal with before I can really make use of
> arbitrary 1-wire peripherals like this. First, you've got to uniquely
> identify the chips - each has its own serial number, and the most obvious
> approach would be to store each serial number in the T2's configuration.
> That's 8 bytes per part, though, and it chews up a lot of configuration
> space fast.
> I think I've come up with a solution to that, though - with only 8 bytes of
> RAM to store the last ID, I can scan through all matching IDs for a
> particular part family in sequence. So instead of specifying ID
> 05a8004000005812, you'd just say part #3 and it'd search for the third
> matching part.
> So now the big problem is what to DO with these things. I mentioned an
> expanded APRS telemetry format before - I suppose one approach to digital
> and analog input would be to just scan every device and report it in
> sequence in that format. For output devices, though, maybe just a new
> command? Like SWITCH 3 ON to turn on the 3rd device of the 'switch' family.
> There's still the issue of setting parts up for either input or output if
> they're bidirectional.
> I'm rambling a bit, so I guess what I want to say is that if anyone has any
> clear ideas on how they WANT an APRS device to interact with multiple 1-wire
> peripherals, let me know!
For APRS use, it would be preferable to use something like the
DS2408, so you get the option of multiple channels
in one addressable device.
When reporting the inputs, you could just emit the device ID, and
single byte representing the state of the eight channels.
For output, I would use something like:
You can't just assume that if you have multiple devices, you'll
always get their addresses back in the same order
when you do a 1-wire ROM SEARCH command. It's completely arbitrary -
especially if you have other 1-wire
devices on the bus with the same family code, but that may respond
quicker. I see this happen all the time on my
1-wire environmental monitoring network.
More information about the aprssig