Re: [Owfs-developers] Merging "moat" device specific code

[Johan Ström]

With my "ftdi" branch now merged to master, I'm picking this up again, 5 
months since I wrote the last message below.

Any thoughts on the F0 family code, or other reasons for not merging?


On 10/11/15 20:10, Johan Ström wrote:
> Hi,
>
> a ticket was opened a few days ago regarding merging the "moat" device
> specific owfs code into master:
>
> http://sourceforge.net/p/owfs/feature-requests/9/
>
> Does anyone object that I merge this? I've run this code myself for
> months without any issues.
> The only reason I can come to think of is that it uses the family code
> 'F0' (re older discussion:
> http://sourceforge.net/p/owfs/mailman/message/33029728/).
> Paul's last comment regarding type/version fields is almost fulfilled;
> there is no version field, but the device advertises which different
> data types (adc, counter etc) it has support for.
>
> I don't know about Matthias Urlichs' ideas regarding any
> commercialization, for me it is for private use. But as he (I assume it
> his him) mentions in the ticket, it apparently has a few users now.
>
> As this is a well-working and pretty easy-to-use open-source variant of
> a custom owslave, I'd love to see "official" support for it!
>
> Regards
> Johan
>
> --
> ___
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers


--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785111=/4140
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Merging "moat" device specific code

[Matthias Urlichs]

On 22.11.2015 02:42, Colin Reese wrote:
> Now this error on make on armhf:
> 
> In file included from ../include/ow_devices.h:56:0,
>   from ow_daemon.c:14:
> ../include/ow_moat.h:93:1: error: expected identifier before '<<' token

bah. Sorry about that. Will fix ASAP.



--
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Merging "moat" device specific code

[Matthias Urlichs]

On 22.11.2015 00:18, Colin Reese wrote:
> Looks like same error:
> 
> ./configure: line 16287: syntax error near unexpected token `LIBUSB,'
> ./configure: line 16287: `  PKG_CHECK_MODULES(LIBUSB, libusb-1.0 >=
> 0.9.1, ENABLE_USB=true,ENABLE_USB=false)'

If you even have "PKG_CHECK_MODULES" in your configure script, you have
far worse problems than a libusb conflict. You need to install
"pkg-config", re-run the whole autoconf stuff, and pay more attention to
its error messages next time. ;-)

Install that, and a current libusb*dev package, run ./bootstrap, then
check what's going on.

I pushed a patch removing that old header inclusion to the m-o-a-t
repository.

-- Matthias


--
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Merging "moat" device specific code

[Matthias Urlichs]

On 22.11.2015 17:03, Matthias Urlichs wrote:
> bah. Sorry about that. Will fix ASAP.

Fix pushed.

-- Matthias


--
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Merging "moat" device specific code

[Matthias Urlichs]

On 21.11.2015 07:46, Colin Reese wrote:
> standard owfs builds fine on amhf debian, with owfs-moat results
> previously reported.
> 
> On ubuntu 14.04 LTS, owfs standard owfs 3.0.2 config is fine. owfs-moat
> gives:
> 
MoaT patch is based on 3.1, which has/had some issues with libusb.

I have pushed a merge to the current main branch to
github/m-o-a-t/owfs, which hopefully fixes this.

-- 
-- Matthias Urlichs



--
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Merging "moat" device specific code

[Colin Reese]

Interestingly, config runs fine on my Raspbian armhf. I'm attempting a 
make right now.

C

On 11/21/2015 5:16 PM, Gregg Levine wrote:
> Hello!
> Aren't we fighting with the moat monsters here regarding the error?
> Why not examine the entire method behind how the token is created. In
> fact how's the entire configuration script written? That should answer
> it.
>
> Meanwhile where's Paul, I'm surprised he hasn't commented by now.
> -
> Gregg C Levine gregg.drw...@gmail.com
> "This signature fought the Time Wars, time and again."
>
>
> On Sat, Nov 21, 2015 at 6:18 PM, Colin Reese  wrote:
>> Looks like same error:
>>
>> ./configure: line 16287: syntax error near unexpected token `LIBUSB,'
>> ./configure: line 16287: `  PKG_CHECK_MODULES(LIBUSB, libusb-1.0 >=
>> 0.9.1, ENABLE_USB=true,ENABLE_USB=false)'
>>
>> C
>>
>>
>> On 11/20/2015 10:46 PM, Colin Reese wrote:
>>
>> standard owfs builds fine on amhf debian, with owfs-moat results previously
>> reported.
>>
>> On ubuntu 14.04 LTS, owfs standard owfs 3.0.2 config is fine. owfs-moat
>> gives:
>>
>> ./configure: line 16305: syntax error near unexpected token `LIBUSB,'
>> ./configure: line 16305: `  PKG_CHECK_MODULES(LIBUSB, libusb-1.0 >=
>> 0.9.1, ENABLE_USB=true,ENABLE_USB=false)'
>>
>> C
>>
>>
>> On 11/16/2015 12:04 AM, Johan Ström wrote:
>>
>> That's not moat-related, nor owfs-related: "Internal compiler error".
>> I'd check for updates on your env, or change Linux dist or something.
>>
>> For the record, line 476 of ow_moat.c is
>>
>> static ZERO_OR_ERROR FS_r_alarm_status(struct one_wire_query *owq)
>>
>> i.e nothing fancy at all.
>>
>>
>> On 16/11/15 01:10, Colin Reese wrote:
>>
>> After bootstrap and configure, I get the following on make:
>>
>> ow_moat.c:476:22: internal compiler error: in set_lattice_value, at
>> tree-ssa-ccp.c:457
>>
>> C
>>
>>
>>
>>
>> --
>> Presto, an open source distributed SQL query engine for big data, initially
>> developed by Facebook, enables you to easily query your data on Hadoop in a
>> more interactive manner. Teradata is also now providing full enterprise
>> support for Presto. Download a free open source copy now.
>> http://pubads.g.doubleclick.net/gampad/clk?id=250295911=/4140
>>
>>
>>
>> ___
>> 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

Re: [Owfs-developers] Merging "moat" device specific code

[Colin Reese]

Looks like same error:

./configure: line 16287: syntax error near unexpected token `LIBUSB,'
./configure: line 16287: `  PKG_CHECK_MODULES(LIBUSB, libusb-1.0 >= 
0.9.1, ENABLE_USB=true,ENABLE_USB=false)'


C

On 11/20/2015 10:46 PM, Colin Reese wrote:
standard owfs builds fine on amhf debian, with owfs-moat results 
previously reported.


On ubuntu 14.04 LTS, owfs standard owfs 3.0.2 config is fine. 
owfs-moat gives:


./configure: line 16305: syntax error near unexpected token `LIBUSB,'
./configure: line 16305: `  PKG_CHECK_MODULES(LIBUSB, libusb-1.0 
>= 0.9.1, ENABLE_USB=true,ENABLE_USB=false)'


C


On 11/16/2015 12:04 AM, Johan Ström wrote:

That's not moat-related, nor owfs-related: "Internal compiler error".
I'd check for updates on your env, or change Linux dist or something.

For the record, line 476 of ow_moat.c is

static ZERO_OR_ERROR FS_r_alarm_status(struct one_wire_query *owq)

i.e nothing fancy at all.


On 16/11/15 01:10, Colin Reese wrote:

After bootstrap and configure, I get the following on make:

ow_moat.c:476:22: internal compiler error: in set_lattice_value, at 
tree-ssa-ccp.c:457


C




--
Presto, an open source distributed SQL query engine for big data, initially
developed by Facebook, enables you to easily query your data on Hadoop in a
more interactive manner. Teradata is also now providing full enterprise
support for Presto. Download a free open source copy now.
http://pubads.g.doubleclick.net/gampad/clk?id=250295911=/4140


___
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

Re: [Owfs-developers] Merging "moat" device specific code

[Gregg Levine]

Hello!
Aren't we fighting with the moat monsters here regarding the error?
Why not examine the entire method behind how the token is created. In
fact how's the entire configuration script written? That should answer
it.

Meanwhile where's Paul, I'm surprised he hasn't commented by now.
-
Gregg C Levine gregg.drw...@gmail.com
"This signature fought the Time Wars, time and again."


On Sat, Nov 21, 2015 at 6:18 PM, Colin Reese  wrote:
> Looks like same error:
>
> ./configure: line 16287: syntax error near unexpected token `LIBUSB,'
> ./configure: line 16287: `  PKG_CHECK_MODULES(LIBUSB, libusb-1.0 >=
> 0.9.1, ENABLE_USB=true,ENABLE_USB=false)'
>
> C
>
>
> On 11/20/2015 10:46 PM, Colin Reese wrote:
>
> standard owfs builds fine on amhf debian, with owfs-moat results previously
> reported.
>
> On ubuntu 14.04 LTS, owfs standard owfs 3.0.2 config is fine. owfs-moat
> gives:
>
> ./configure: line 16305: syntax error near unexpected token `LIBUSB,'
> ./configure: line 16305: `  PKG_CHECK_MODULES(LIBUSB, libusb-1.0 >=
> 0.9.1, ENABLE_USB=true,ENABLE_USB=false)'
>
> C
>
>
> On 11/16/2015 12:04 AM, Johan Ström wrote:
>
> That's not moat-related, nor owfs-related: "Internal compiler error".
> I'd check for updates on your env, or change Linux dist or something.
>
> For the record, line 476 of ow_moat.c is
>
> static ZERO_OR_ERROR FS_r_alarm_status(struct one_wire_query *owq)
>
> i.e nothing fancy at all.
>
>
> On 16/11/15 01:10, Colin Reese wrote:
>
> After bootstrap and configure, I get the following on make:
>
> ow_moat.c:476:22: internal compiler error: in set_lattice_value, at
> tree-ssa-ccp.c:457
>
> C
>
>
>
>
> --
> Presto, an open source distributed SQL query engine for big data, initially
> developed by Facebook, enables you to easily query your data on Hadoop in a
> more interactive manner. Teradata is also now providing full enterprise
> support for Presto. Download a free open source copy now.
> http://pubads.g.doubleclick.net/gampad/clk?id=250295911=/4140
>
>
>
> ___
> 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

Re: [Owfs-developers] Merging "moat" device specific code

[Colin Reese]

Now this error on make on armhf:

In file included from ../include/ow_devices.h:56:0,
  from ow_daemon.c:14:
../include/ow_moat.h:93:1: error: expected identifier before '<<' token
../include/ow_moat.h:104:20: warning: 's_names' defined but not used 
[-Wunused-variable]
Makefile:1001: recipe for target 'ow_daemon.lo' failed


C

On 11/21/2015 6:29 AM, Matthias Urlichs wrote:
> On 21.11.2015 07:46, Colin Reese wrote:
>> standard owfs builds fine on amhf debian, with owfs-moat results
>> previously reported.
>>
>> On ubuntu 14.04 LTS, owfs standard owfs 3.0.2 config is fine. owfs-moat
>> gives:
>>
> MoaT patch is based on 3.1, which has/had some issues with libusb.
>
> I have pushed a merge to the current main branch to
> github/m-o-a-t/owfs, which hopefully fixes this.
>


--
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Merging "moat" device specific code

[Colin Reese]

standard owfs builds fine on amhf debian, with owfs-moat results 
previously reported.


On ubuntu 14.04 LTS, owfs standard owfs 3.0.2 config is fine. owfs-moat 
gives:


./configure: line 16305: syntax error near unexpected token `LIBUSB,'
./configure: line 16305: `  PKG_CHECK_MODULES(LIBUSB, libusb-1.0 >= 
0.9.1, ENABLE_USB=true,ENABLE_USB=false)'


C


On 11/16/2015 12:04 AM, Johan Ström wrote:

That's not moat-related, nor owfs-related: "Internal compiler error".
I'd check for updates on your env, or change Linux dist or something.

For the record, line 476 of ow_moat.c is

static ZERO_OR_ERROR FS_r_alarm_status(struct one_wire_query *owq)

i.e nothing fancy at all.


On 16/11/15 01:10, Colin Reese wrote:

After bootstrap and configure, I get the following on make:

ow_moat.c:476:22: internal compiler error: in set_lattice_value, at 
tree-ssa-ccp.c:457


C




--
Presto, an open source distributed SQL query engine for big data, initially
developed by Facebook, enables you to easily query your data on Hadoop in a
more interactive manner. Teradata is also now providing full enterprise
support for Presto. Download a free open source copy now.
http://pubads.g.doubleclick.net/gampad/clk?id=250295911=/4140


___
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

Re: [Owfs-developers] Merging "moat" device specific code

[Johan Ström]

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: 1600
>> 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 > 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
>  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: 1600
>
> 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,

Re: [Owfs-developers] Merging "moat" device specific code

[Johan Ström]

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

Re: [Owfs-developers] Merging "moat" device specific code

[Colin Reese]

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: 1600
port:
 

Re: [Owfs-developers] Merging "moat" device specific code

[Colin Reese]

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

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 

Re: [Owfs-developers] Merging "moat" device specific code

[Colin Reese]

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 

Re: [Owfs-developers] Merging "moat" device specific code

[Johan Ström]

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

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

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

Re: [Owfs-developers] Merging "moat" device specific code

[Colin Reese]

Finally got it. Built it on a machine without the updated code. 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: 1600
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 > 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
 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: 1600

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

Re: [Owfs-developers] Merging "moat" device specific code

[Colin Reese]

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

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


   

Re: [Owfs-developers] Merging "moat" device specific code

[Colin Reese]

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

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

https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Merging "moat" device specific code

[Johan Ström]

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

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

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

Re: [Owfs-developers] Merging "moat" device specific code

[Colin Reese]

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  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  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: 1600
>>
>> 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
>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>>
>
>
>
> --
>
>
>
> ___
> Owfs-developers mailing 
> listOwfs-developers@lists.sourceforge.nethttps://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

Re: [Owfs-developers] Merging "moat" device specific code

[Colin Reese]

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

Re: [Owfs-developers] Merging "moat" device specific code

[Johan Ström]

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

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
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Merging "moat" device specific code

[Colin Reese]

I have tried on deb Linux (Ubuntu 14.04) with apt distros, also winavr. Just 
downloaded owslave and tried fresh with the exact cfg you listed. 

C

> On Nov 11, 2015, at 1:57 AM, Johan Ström  wrote:
> 
> Hm, first this was commited:
> https://github.com/M-o-a-T/owslave/commit/960a7decb26ee1aa792ef41400c306ec563e77ab
> 
> but then this:
> https://github.com/M-o-a-T/owslave/commit/e573863d5a62072945dd6c07eb4e6109a6108c16
> 
> Are you perhaps using either old revision of the owslave code, or
> perhaps old AVR-libc headers?
> 
> Johan
> 
>> On 11/11/15 09:09, Colin Reese wrote:
>> I get a number of errors on compile similar to:
>> 
>> /moat.c:182: undefined reference to `pgm_read_ptr_near'
>> 
>> C
>> 
>>> On 11/10/2015 1:07 PM, Johan Ström wrote:
>>> _include: world.cfg
>>> devices:
>>>_default:
>>>  _ref: defaults.target.m88
>>>  types:
>>>_ref: defaults.types
>>>  code: []
>>>m328test:
>>>  _ref: mcu.mega328
>>>  defs:
>>>f_cpu: 800
>>>  port:
>>>1: B0~
>>>2: B1~
>> 
>> --
>> ___
>> 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

Re: [Owfs-developers] Merging "moat" device specific code

[Johan Ström]

Hm, first this was commited:
https://github.com/M-o-a-T/owslave/commit/960a7decb26ee1aa792ef41400c306ec563e77ab

but then this:
https://github.com/M-o-a-T/owslave/commit/e573863d5a62072945dd6c07eb4e6109a6108c16

Are you perhaps using either old revision of the owslave code, or
perhaps old AVR-libc headers?

Johan

On 11/11/15 09:09, Colin Reese wrote:
> I get a number of errors on compile similar to:
>
> /moat.c:182: undefined reference to `pgm_read_ptr_near'
>
> C
>
> On 11/10/2015 1:07 PM, Johan Ström wrote:
>> _include: world.cfg
>> devices:
>> _default:
>>   _ref: defaults.target.m88
>>   types:
>> _ref: defaults.types
>>   code: []
>> m328test:
>>   _ref: mcu.mega328
>>   defs:
>> f_cpu: 800
>>   port:
>> 1: B0~
>> 2: B1~
>
> --
> ___
> 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

Re: [Owfs-developers] Merging "moat" device specific code

[Johan Ström]

It would help if you can post specific version numbers of avr-libc (or
whatever it is named in Ubuntu), and winavr.
Also try to search for pgm_read_ptr_near and/or pgm_read* in the include
files which your avr-libc package installs (check with your package
manager how to list installed files).

On 11/11/15 11:04, Colin Reese wrote:
> I have tried on deb Linux (Ubuntu 14.04) with apt distros, also winavr. Just 
> downloaded owslave and tried fresh with the exact cfg you listed. 
>
> C
>
>> On Nov 11, 2015, at 1:57 AM, Johan Ström  wrote:
>>
>> Hm, first this was commited:
>> https://github.com/M-o-a-T/owslave/commit/960a7decb26ee1aa792ef41400c306ec563e77ab
>>
>> but then this:
>> https://github.com/M-o-a-T/owslave/commit/e573863d5a62072945dd6c07eb4e6109a6108c16
>>
>> Are you perhaps using either old revision of the owslave code, or
>> perhaps old AVR-libc headers?
>>
>> Johan
>>
>>> On 11/11/15 09:09, Colin Reese wrote:
>>> I get a number of errors on compile similar to:
>>>
>>> /moat.c:182: undefined reference to `pgm_read_ptr_near'
>>>
>>> C
>>>
 On 11/10/2015 1:07 PM, Johan Ström wrote:
 _include: world.cfg
 devices:
_default:
  _ref: defaults.target.m88
  types:
_ref: defaults.types
  code: []
m328test:
  _ref: mcu.mega328
  defs:
f_cpu: 800
  port:
1: B0~
2: B1~
>>> --
>>> ___
>>> 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

Re: [Owfs-developers] Merging "moat" device specific code

[Colin Reese]

The header files seem to be installed to primarily:

/usr/lib/avr/include/avr

Cat/grep on all in the directory yields nothing for pgm_read_ptr, and a 
number of functions, e.g. pgm_read_byte, pgm_read_word, float, etc., 
which are all present in pgmspace.h

I included the code provided by Matthias for pgm_read_ptr_near in the 
pgmspace.h, and also added the code below to a pgm.h file that now 
consists of:

#include 
#define pgm_read_ptr(address_short) pgm_read_ptr_near(address_short)

It now compiles.

I assume the code Matthias posted could be added to the pgm.h with some 
thoughtful IFNDEFs to make this complete.

C

On 11/11/2015 4:42 AM, Johan Ström wrote:
> It would help if you can post specific version numbers of avr-libc (or
> whatever it is named in Ubuntu), and winavr.
> Also try to search for pgm_read_ptr_near and/or pgm_read* in the include
> files which your avr-libc package installs (check with your package
> manager how to list installed files).
>
> On 11/11/15 11:04, Colin Reese wrote:
>> I have tried on deb Linux (Ubuntu 14.04) with apt distros, also winavr. Just 
>> downloaded owslave and tried fresh with the exact cfg you listed.
>>
>> C
>>
>>> On Nov 11, 2015, at 1:57 AM, Johan Ström  wrote:
>>>
>>> Hm, first this was commited:
>>> https://github.com/M-o-a-T/owslave/commit/960a7decb26ee1aa792ef41400c306ec563e77ab
>>>
>>> but then this:
>>> https://github.com/M-o-a-T/owslave/commit/e573863d5a62072945dd6c07eb4e6109a6108c16
>>>
>>> Are you perhaps using either old revision of the owslave code, or
>>> perhaps old AVR-libc headers?
>>>
>>> Johan
>>>
 On 11/11/15 09:09, Colin Reese wrote:
 I get a number of errors on compile similar to:

 /moat.c:182: undefined reference to `pgm_read_ptr_near'

 C

> On 11/10/2015 1:07 PM, Johan Ström wrote:
> _include: world.cfg
> devices:
> _default:
>   _ref: defaults.target.m88
>   types:
> _ref: defaults.types
>   code: []
> m328test:
>   _ref: mcu.mega328
>   defs:
> f_cpu: 800
>   port:
> 1: B0~
> 2: B1~
 --
 ___
 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

Re: [Owfs-developers] Merging "moat" device specific code

[Colin Reese]

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

Re: [Owfs-developers] Merging "moat" device specific code

[Matthias Urlichs]

On 10.11.2015 20:32, Colin Reese wrote:
> I've been limping along with code for atmega328 from elsewhere and would love 
> if someone has time to help me port it.

The devices I'm using right now use atmega88/168/328 ICs.

My personal use for this is home automation (heating control / switches
/ temperature monitoring / cheap interface to wall switches), using a
couple of boards I designed myself (prototyping stage).

I have no plans to do this commercially; it's all open source though, so
conceivably somebody else could run with it. Or I could do some
consulting. Right now I'm very busy with my day job, for another three
months or so, then it's back mostly-full-time to MoaT and related issues.

My general "plan of attack" is here:
http://matthias.urlichs.de/en/wiring/goal/

-- 
-- Matthias Urlichs


--
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Merging "moat" device specific code

[Matthias Urlichs]

On 11.11.2015 13:42, Johan Ström wrote:
> Also try to search for pgm_read_ptr_near and/or pgm_read* in the include
> files which your avr-libc package installs (check with your package
> manager how to list installed files).

There seem to be some somewhat-incompatible and probably incompletely
updated/patched AVR libc packages floating around, and Ubuntu LTR14
appears to have caught one of them.

It's all in /usr/lib/avr/include/avr/pgmspace.h.

The complete code from that file, as far as pgm_read_ptr_near is
concerned, is this:

#define __LPM_word_classic__(addr)  \
(__extension__({\
uint16_t __addr16 = (uint16_t)(addr);   \
uint16_t __result;  \
__asm__ __volatile__\
(   \
"lpm"   "\n\t"  \
"mov %A0, r0"   "\n\t"  \
"adiw r30, 1"   "\n\t"  \
"lpm"   "\n\t"  \
"mov %B0, r0"   "\n\t"  \
: "=r" (__result), "=z" (__addr16)  \
: "1" (__addr16)\
: "r0"  \
);  \
__result;   \
}))

#define __LPM_word_tiny__(addr) \
(__extension__({\
uint16_t __addr16 = (uint16_t)(addr) + __AVR_TINY_PM_BASE_ADDRESS__; \
uint16_t __result;  \
__asm__ \
(   \
"ld %A0, z+" "\n\t" \
"ld %B0, z"  "\n\t" \
: "=r" (__result), "=z" (__addr16)  \
: "1" (__addr16)\
);  \
__result;   \
}))

#define __LPM_word_enhanced__(addr) \
(__extension__({\
uint16_t __addr16 = (uint16_t)(addr);   \
uint16_t __result;  \
__asm__ __volatile__\
(   \
"lpm %A0, Z+"   "\n\t"  \
"lpm %B0, Z""\n\t"  \
: "=r" (__result), "=z" (__addr16)  \
: "1" (__addr16)\
);  \
__result;   \
}))

#if defined (__AVR_HAVE_LPMX__)
#define __LPM_word(addr)__LPM_word_enhanced__(addr)
#elif defined (__AVR_TINY__)
#define __LPM_word(addr)__LPM_word_tiny__(addr)
#else
#define __LPM_word(addr)__LPM_word_classic__(addr)
#endif

#define pgm_read_ptr_near(address_short) \
(void*)__LPM_word((uint16_t)(address_short))

Thus if somebody could build a patch for MoaT that can work around
whatever is missing from your avr libc (preferably without duplicating
anything that _is_ there), please go ahead and submit a pull request.
Thank you.

-- 
-- Matthias Urlichs



--
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Merging "moat" device specific code

[Colin Reese]

In the meantime, getting an updated libc from elsewhere than the apt repos is 
an option?

C

> On Nov 11, 2015, at 11:40 AM, Matthias Urlichs  wrote:
> 
>> On 11.11.2015 13:42, Johan Ström wrote:
>> Also try to search for pgm_read_ptr_near and/or pgm_read* in the include
>> files which your avr-libc package installs (check with your package
>> manager how to list installed files).
> 
> There seem to be some somewhat-incompatible and probably incompletely
> updated/patched AVR libc packages floating around, and Ubuntu LTR14
> appears to have caught one of them.
> 
> It's all in /usr/lib/avr/include/avr/pgmspace.h.
> 
> The complete code from that file, as far as pgm_read_ptr_near is
> concerned, is this:
> 
> #define __LPM_word_classic__(addr)  \
> (__extension__({\
>uint16_t __addr16 = (uint16_t)(addr);   \
>uint16_t __result;  \
>__asm__ __volatile__\
>(   \
>"lpm"   "\n\t"  \
>"mov %A0, r0"   "\n\t"  \
>"adiw r30, 1"   "\n\t"  \
>"lpm"   "\n\t"  \
>"mov %B0, r0"   "\n\t"  \
>: "=r" (__result), "=z" (__addr16)  \
>: "1" (__addr16)\
>: "r0"  \
>);  \
>__result;   \
> }))
> 
> #define __LPM_word_tiny__(addr) \
> (__extension__({\
>uint16_t __addr16 = (uint16_t)(addr) + __AVR_TINY_PM_BASE_ADDRESS__; \
>uint16_t __result;  \
>__asm__ \
>(   \
>"ld %A0, z+" "\n\t" \
>"ld %B0, z"  "\n\t" \
>: "=r" (__result), "=z" (__addr16)  \
>: "1" (__addr16)\
>);  \
>__result;   \
> }))
> 
> #define __LPM_word_enhanced__(addr) \
> (__extension__({\
>uint16_t __addr16 = (uint16_t)(addr);   \
>uint16_t __result;  \
>__asm__ __volatile__\
>(   \
>"lpm %A0, Z+"   "\n\t"  \
>"lpm %B0, Z""\n\t"  \
>: "=r" (__result), "=z" (__addr16)  \
>: "1" (__addr16)\
>);  \
>__result;   \
> }))
> 
> #if defined (__AVR_HAVE_LPMX__)
> #define __LPM_word(addr)__LPM_word_enhanced__(addr)
> #elif defined (__AVR_TINY__)
> #define __LPM_word(addr)__LPM_word_tiny__(addr)
> #else
> #define __LPM_word(addr)__LPM_word_classic__(addr)
> #endif
> 
> #define pgm_read_ptr_near(address_short) \
>(void*)__LPM_word((uint16_t)(address_short))
> 
> Thus if somebody could build a patch for MoaT that can work around
> whatever is missing from your avr libc (preferably without duplicating
> anything that _is_ there), please go ahead and submit a pull request.
> Thank you.
> 
> -- 
> -- 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

Re: [Owfs-developers] Merging "moat" device specific code

[Matthias Urlichs]

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

Re: [Owfs-developers] Merging "moat" device specific code

[Colin Reese]

I get a number of errors on compile similar to:

/moat.c:182: undefined reference to `pgm_read_ptr_near'

C

On 11/10/2015 1:07 PM, Johan Ström wrote:
> _include: world.cfg
> devices:
> _default:
>   _ref: defaults.target.m88
>   types:
> _ref: defaults.types
>   code: []
> m328test:
>   _ref: mcu.mega328
>   defs:
> f_cpu: 800
>   port:
> 1: B0~
> 2: B1~


--
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

[Owfs-developers] Merging "moat" device specific code

[Johan Ström]

Hi,

a ticket was opened a few days ago regarding merging the "moat" device 
specific owfs code into master:

http://sourceforge.net/p/owfs/feature-requests/9/

Does anyone object that I merge this? I've run this code myself for 
months without any issues.
The only reason I can come to think of is that it uses the family code 
'F0' (re older discussion: 
http://sourceforge.net/p/owfs/mailman/message/33029728/).
Paul's last comment regarding type/version fields is almost fulfilled; 
there is no version field, but the device advertises which different 
data types (adc, counter etc) it has support for.

I don't know about Matthias Urlichs' ideas regarding any 
commercialization, for me it is for private use. But as he (I assume it 
his him) mentions in the ticket, it apparently has a few users now.

As this is a well-working and pretty easy-to-use open-source variant of 
a custom owslave, I'd love to see "official" support for it!

Regards
Johan

--
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Merging "moat" device specific code

[Johan Ström]

While I haven't tested it myself, there are specific code for mega328 
(and 168, 88 and 8), besides tiny84/85 (which is marked "untested for 
some time" though).
I've only used it on the mega8 and mega88 so far, running at 8Mhz with 
internal oscillator with great success.

On 10/11/15 20:32, Colin Reese wrote:
> Is this still only for attiny? I've been limping along with code for 
> atmega328 from elsewhere and would love if someone has time to help me port 
> it. I love the idea.
>
>> On Nov 10, 2015, at 11:10 AM, Johan Ström  wrote:
>>
>> Hi,
>>
>> a ticket was opened a few days ago regarding merging the "moat" device
>> specific owfs code into master:
>>
>> http://sourceforge.net/p/owfs/feature-requests/9/
>>
>> Does anyone object that I merge this? I've run this code myself for
>> months without any issues.
>> The only reason I can come to think of is that it uses the family code
>> 'F0' (re older discussion:
>> http://sourceforge.net/p/owfs/mailman/message/33029728/).
>> Paul's last comment regarding type/version fields is almost fulfilled;
>> there is no version field, but the device advertises which different
>> data types (adc, counter etc) it has support for.
>>
>> I don't know about Matthias Urlichs' ideas regarding any
>> commercialization, for me it is for private use. But as he (I assume it
>> his him) mentions in the ticket, it apparently has a few users now.
>>
>> As this is a well-working and pretty easy-to-use open-source variant of
>> a custom owslave, I'd love to see "official" support for it!
>>
>> Regards
>> Johan
>>
>> --
>> ___
>> 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

Re: [Owfs-developers] Merging "moat" device specific code

[Johan Ström]

I don't have a m328 to test with, but it builds fine:

I created this local.cfg (based on sample cfg):
--
_include: world.cfg
devices:
   _default:
 _ref: defaults.target.m88
 types:
   _ref: defaults.types
 code: []
   m328test:
 _ref: mcu.mega328
 defs:
   f_cpu: 800
 port:
   1: B0~
   2: B1~
--

and then built it using:

$ CFG=local.cfg make m328test

Resulting file:
$ avr-size device/m328test/image.elf
text   databssdechexfilename
4054 46 65   4165   1045 
device/m328test/image.elf

So at least it builds fine!

Johan

On 10/11/15 21:30, Colin Reese wrote:
> I will look again as I did not see this. I did not have success with the 
> attiny moat. Using another owslave (by youen) I needed to run at 16mhz to get 
> it working. Rather than rewrite to expose local IO (and other arbitrary 
> values like serial), my end goal, I'd much rather get moat working.
>
> C
>
>> On Nov 10, 2015, at 12:16 PM, Johan Ström  wrote:
>>
>> While I haven't tested it myself, there are specific code for mega328
>> (and 168, 88 and 8), besides tiny84/85 (which is marked "untested for
>> some time" though).
>> I've only used it on the mega8 and mega88 so far, running at 8Mhz with
>> internal oscillator with great success.
>>
>>> On 10/11/15 20:32, Colin Reese wrote:
>>> Is this still only for attiny? I've been limping along with code for 
>>> atmega328 from elsewhere and would love if someone has time to help me port 
>>> it. I love the idea.
>>>
 On Nov 10, 2015, at 11:10 AM, Johan Ström  wrote:

 Hi,

 a ticket was opened a few days ago regarding merging the "moat" device
 specific owfs code into master:

 http://sourceforge.net/p/owfs/feature-requests/9/

 Does anyone object that I merge this? I've run this code myself for
 months without any issues.
 The only reason I can come to think of is that it uses the family code
 'F0' (re older discussion:
 http://sourceforge.net/p/owfs/mailman/message/33029728/).
 Paul's last comment regarding type/version fields is almost fulfilled;
 there is no version field, but the device advertises which different
 data types (adc, counter etc) it has support for.

 I don't know about Matthias Urlichs' ideas regarding any
 commercialization, for me it is for private use. But as he (I assume it
 his him) mentions in the ticket, it apparently has a few users now.

 As this is a well-working and pretty easy-to-use open-source variant of
 a custom owslave, I'd love to see "official" support for it!

 Regards
 Johan

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

Re: [Owfs-developers] Merging "moat" device specific code

[Colin Reese]

I will look again as I did not see this. I did not have success with the attiny 
moat. Using another owslave (by youen) I needed to run at 16mhz to get it 
working. Rather than rewrite to expose local IO (and other arbitrary values 
like serial), my end goal, I'd much rather get moat working. 

C

> On Nov 10, 2015, at 12:16 PM, Johan Ström  wrote:
> 
> While I haven't tested it myself, there are specific code for mega328 
> (and 168, 88 and 8), besides tiny84/85 (which is marked "untested for 
> some time" though).
> I've only used it on the mega8 and mega88 so far, running at 8Mhz with 
> internal oscillator with great success.
> 
>> On 10/11/15 20:32, Colin Reese wrote:
>> Is this still only for attiny? I've been limping along with code for 
>> atmega328 from elsewhere and would love if someone has time to help me port 
>> it. I love the idea.
>> 
>>> On Nov 10, 2015, at 11:10 AM, Johan Ström  wrote:
>>> 
>>> Hi,
>>> 
>>> a ticket was opened a few days ago regarding merging the "moat" device
>>> specific owfs code into master:
>>> 
>>> http://sourceforge.net/p/owfs/feature-requests/9/
>>> 
>>> Does anyone object that I merge this? I've run this code myself for
>>> months without any issues.
>>> The only reason I can come to think of is that it uses the family code
>>> 'F0' (re older discussion:
>>> http://sourceforge.net/p/owfs/mailman/message/33029728/).
>>> Paul's last comment regarding type/version fields is almost fulfilled;
>>> there is no version field, but the device advertises which different
>>> data types (adc, counter etc) it has support for.
>>> 
>>> I don't know about Matthias Urlichs' ideas regarding any
>>> commercialization, for me it is for private use. But as he (I assume it
>>> his him) mentions in the ticket, it apparently has a few users now.
>>> 
>>> As this is a well-working and pretty easy-to-use open-source variant of
>>> a custom owslave, I'd love to see "official" support for it!
>>> 
>>> Regards
>>> Johan
>>> 
>>> --
>>> ___
>>> 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

Re: [Owfs-developers] Merging "moat" device specific code

[Colin Reese]

Is this still only for attiny? I've been limping along with code for atmega328 
from elsewhere and would love if someone has time to help me port it. I love 
the idea. 

> On Nov 10, 2015, at 11:10 AM, Johan Ström  wrote:
> 
> Hi,
> 
> a ticket was opened a few days ago regarding merging the "moat" device 
> specific owfs code into master:
> 
> http://sourceforge.net/p/owfs/feature-requests/9/
> 
> Does anyone object that I merge this? I've run this code myself for 
> months without any issues.
> The only reason I can come to think of is that it uses the family code 
> 'F0' (re older discussion: 
> http://sourceforge.net/p/owfs/mailman/message/33029728/).
> Paul's last comment regarding type/version fields is almost fulfilled; 
> there is no version field, but the device advertises which different 
> data types (adc, counter etc) it has support for.
> 
> I don't know about Matthias Urlichs' ideas regarding any 
> commercialization, for me it is for private use. But as he (I assume it 
> his him) mentions in the ticket, it apparently has a few users now.
> 
> As this is a well-working and pretty easy-to-use open-source variant of 
> a custom owslave, I'd love to see "official" support for it!
> 
> Regards
> Johan
> 
> --
> ___
> 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