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.
On 13/11/15 06:53, Colin Reese wrote:
First, I just noticed the HOWTO is much improved and has some
details about using the uart. Thanks Matthias.
I assume all of the data appears somewhat transparently via owfs
as indicated in the HOWTO, which is how I plan to use it
typically. Using other code, e.g. through LabVIEW or otherwise,
how would one read this data? Is there a modified command set?
Thanks,
C
On 11/12/2015 9:06 PM, Colin Reese wrote:
Understood.
From what I can see, 1Wire should be on INT0 (D2) per 152 in
world.cfg. With the world.cfg below, everything compiles fine and
loads from my USBTiny. I verified my fuses are xFF, xDE, x05,
which looks good. I still don't see anything on my DS9490R.
One more thing -- anybody know what I need to do to select and
enable the debug UART? I can see that the default baudrate is
38400; I just need to select a port, pin and enable it. I can't
quite see what needs to be defined to do it.
C
_include: world.cfg
devices:
_default:
_ref: defaults.target.m88
types:
_ref: defaults.types
code: []
m328test:
_ref: mcu.mega328
defs:
f_cpu: 16000000
port:
1: B0~
2: B1~
onewire_id: x0f361b8bff8a
On 11/12/2015 12:28 PM, Johan Ström wrote:
You'd have to step through the "_ref" in your def, and the
"default" section in world.cfg to found out any defaults.
In my example, I only have specifically 'ref: mcu.mega328'.
Checking the mcu.mega328 section in world.cfg (included) we do
not have a f_cpu def.
So continue to global 'defaults' section, check defs. no f_cpu
there either.
So for this target, there is no "default". In my example, it was
explicitly set to 8Mhz though.
If we would instead use 'ref: defaults.target.m88' we would find
_ref 'defaults.target.m8x_base' which contains the f_cpu def.
The reason it is not in code is that world.cfg controls all
dynamic/configurable properties. During build, it will write a
device/$TARGET/dev_config.h which is then included in the actual
code.
On 12/11/15 18:17, Colin Reese wrote:
I understand, but if not already defined, what is the default
value? Or, why is this not defined in the code already?
On Thu, Nov 12, 2015 at 9:13 AM, Johan Ström
<jo...@stromnet.se> wrote:
Yes, the f_cpu define only controls timing calculations,
which must match the clock speed. If incorrectly
configured, it won't be able to talk on the 1wire net.
On 12/11/15 18:04, Colin Reese wrote:
I see this in main:
#elif defined (__AVR_ATmega168__) || defined
(__AVR_ATmega88__) || defined(__AVR_ATmega328__)
// Clock is set via fuse
is the f_cpu definition necessary here?
C
On Thu, Nov 12, 2015 at 8:44 AM, Johan Ström
<jo...@stromnet.se> wrote:
As long as your built it for 16MHz it should probably
be compatible (I'm
not familiar with any specific fuses the m328 might have).
Thus, f_cpu: 16000000
On 12/11/15 03:39, Colin Reese wrote:
> So to avoid trying to get WinAVR to behave, on a
windows machine with
> avrdude I would do something like:
>
> avrdude -c usbtiny -p m328p -U flash:w:image.hex -U
eeprom:w:eprom.hex
>
> That should do the trick? Do I really need to set
the fuses? I have it
> set up as external 16Mhz. I assume this is compatible.
>
> C
>
> On 11/11/2015 12:34 PM, Matthias Urlichs wrote:
>> On 11.11.2015 20:45, Colin Reese wrote:
>>> In the meantime, getting an updated libc from
elsewhere than the apt repos is an option?
>> I'd be wary of compiler/libc or libc/header
incompatibilities when
>> upgrading partially. IMHO it'd be safer to examine
your existing
>> pgmspace.h and add a patch to MoaT that works
around not having the
>> current version of pgmspace.h. (I already tried
that, but apparently not
>> quite successfully.)
>>
>> In fact you might just email your version to me, I
can certainly take a
>> look.
>>
>>
>> -- Matthias Urlichs
>>
>>
>>
------------------------------------------------------------------------------
>> _______________________________________________
>> Owfs-developers mailing list
>> Owfs-developers@lists.sourceforge.net
>>
https://lists.sourceforge.net/lists/listinfo/owfs-developers
>
>
------------------------------------------------------------------------------
> _______________________________________________
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
>
https://lists.sourceforge.net/lists/listinfo/owfs-developers
------------------------------------------------------------------------------
_______________________________________________
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
<mailto:Owfs-developers@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/owfs-developers
------------------------------------------------------------------------------
_______________________________________________
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
<mailto:Owfs-developers@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/owfs-developers
------------------------------------------------------------------------------
_______________________________________________
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
<mailto:Owfs-developers@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/owfs-developers
------------------------------------------------------------------------------
_______________________________________________
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
------------------------------------------------------------------------------
_______________________________________________
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
------------------------------------------------------------------------------
_______________________________________________
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
------------------------------------------------------------------------------
_______________________________________________
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
------------------------------------------------------------------------------
_______________________________________________
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
------------------------------------------------------------------------------
_______________________________________________
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
------------------------------------------------------------------------------
_______________________________________________
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
------------------------------------------------------------------------------
_______________________________________________
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
