Trying again since the my message yesterday got moderated due to size..
04 from the m_type enum
(https://github.com/M-o-a-T/owfs/blob/moat/module/owlib/src/include/ow_moat.h#L40)
You will also see in generated file device/$TARGET/_def.h that "port" is
the 4th define (counting from 0. This is included from moat_backend.c
and put in order in moat_calls, which moat.c then looks in).
01 as the channel: in moat_port.c you find read_port(chan, buf), which does
portp = &ports[chan-1];
So chan 01 evaluates to index 0 in the ports structure. The N_PORT right
above is in device/$TARGET/dev_config.h (from your configuration which
tells how many "ports" there should be).
Johan
On 13/11/15 21:02, Colin Reese wrote:
Great. So last question:
Where did the information below come from regarding 04 and 01 bytes?
I'll gladly dig through that part!
I am good to go with git (https://github.com/iinnovations)
I'll give the owfs a build and throw it on a machine and see what I see.
Thanks for the help!
C
On 11/13/2015 11:50 AM, Johan Ström wrote:
Just sending F2 does not work, no. You need to send F2, then two more
bytes identifying what you want to read For example, sending F2, 04,
01 and then two read timeslots would give you the return value 01 0x
where the last x indicates the value of port 1. (Unless I got
something wrong here.. but something like that).
If you do not want to spend time diving down into the code, I suggest
you just build the moat-enabled owfs, by checking out the code and
build it.
If you are unfamiliar with git & manual building, here's a short intro:
git clone https://github.com/M-o-a-T/owfs.git
cd owfs
git checkout moat
then regular ./configure ... make .. make install (if desired,
beware that make install may interfere your packaged version). I
usally just run owserver after 'make' using
./modules/owserver/src/c/owserver --debug --foreground ..etc..
instead of doing install.
Hopefully we can get some positive votes on merging this to mainline,
and the above won't be necessary :)
Johan
On 13/11/15 20:35, Colin Reese wrote:
Thanks Johan,
My goal isn't to write an alternate master -- I just want to use the
Atmega328 as a 1Wire slave, reading the ports (and preferably
configuring them). My understanding is that most of this legwork is
done, but that the support isn't merged into owfs just yet.
In the meantime, I was just trying to test out the slave devices
using my DS9490R and some LabVIEW code I use all the time with the
typical read/write commands. For a read scratchpad, I send in
whatever byte is necessary to initiate the command, e.g. xBE for a
DS18B20, along with a data buffer that is returned with the data. I
was hoping I could insert the xF2 read byte and get data back, but I
don't. I successfully find the ROM on the bus, and get successful
returns from TMAccess and TMRom, but no data on TMBlockstream. My
main question was whether the default configuration I (and you) used
for compilation will return data when sent xF2, and if not, how that
is configured. I will surely do some poking, but it will be uphill.
C
On 11/13/2015 11:05 AM, Johan Ström wrote:
Not sure if there is any good docs on this yet, don't think so, and
the code has a quite a few "clever tricks" which minimizes size &
enhances customability but makes it a bit tricky to follow for the
uninitiated.
Basically, all reads & writes (owfs-side) goes through OW_r_std and
OW_w_std, and have a type and subtype parameter. Ultimately they
end up in moat_read(1) or moat_write (2) in the slave, which
delegates (based on type param) to a specific read/write method.
The type parameter matches one of the "types" defined in the config
file, such as adc/count etc, as defined in in ow_moat.h (3).
The subtype usually identifies a channel (i.e. port 1, port 2 and
so on).
For reads, the master reads 1 byte of length data, followed by data
+ crc (and some special cases, see OW_r_std). It finishes with
writing back an inverter CRC to acknowledge to the slave that the
read went through properly.
For writes, the master writes size + data + crc, and reads back a
confirmation CRC.
The actual data bytes depends on the different methods.
This should provide a good start to start digging. If unsure, I'd
recommend running owfs with --debug --traffic to dump all bytes
sent/received (recompile might be required, don't remember).
Besides that, you probably need to spend some time familiarizing
yourself with the code, if your goal is to write an alternative
master :) But once you get a hang of it, it's quite easy to follow.
Johan
1) https://github.com/M-o-a-T/owslave/blob/master/moat.c#L84
2) https://github.com/M-o-a-T/owslave/blob/master/moat.c#L142
3)
https://github.com/M-o-a-T/owfs/blob/moat/module/owlib/src/include/ow_moat.h#L40
On 13/11/15 19:26, Colin Reese wrote:
Super.
So MOAT read and write are F2 and F4, respectively. Is there yet
any documentation on what these will return by default, what
additional data are required to specify what to read and write,
and how to specify such details in the config file? I apologize if
this is clear from the code; it isn't to me.
I run the xF2 here with my LV library and do not receive a response.
Is uart debug as simple as enabling it and then inserting
uart_putc() and uart_puts() statements where I see fit?
C
On 11/13/2015 12:05 AM, Johan Ström wrote:
Ah, using the latest code is always a good start.. :)
Yes, the 'moat' device uses custom ROM commands. To communicate
with the moat from any other non-owfs master you'd need to
implement the custom ROM commands there.
See
https://github.com/M-o-a-T/owfs/blob/moat/module/owlib/src/c/ow_moat.c
for details.
And to get back where this thread started, this is the actual
code which this thread revolves around, adding support for those
special ROM commands to the official owfs branch.
------------------------------------------------------------------------------
_______________________________________________
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
