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
<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
<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
