Merging "moat" device specific code

classic Classic list List threaded Threaded
47 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Merging "moat" device specific code

Johan Ström-3
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: Merging "moat" device specific code

CReese
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 <[hidden email]> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

------------------------------------------------------------------------------
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: Merging "moat" device specific code

Johan Ström-3
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 <[hidden email]> 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
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
> ------------------------------------------------------------------------------
> _______________________________________________
> Owfs-developers mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/owfs-developers


------------------------------------------------------------------------------
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: Merging "moat" device specific code

CReese
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 <[hidden email]> 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 <[hidden email]> 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
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Owfs-developers mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Owfs-developers mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

------------------------------------------------------------------------------
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: Merging "moat" device specific code

Johan Ström-3
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: 8000000
     port:
       1: B0~
       2: B1~
------

and then built it using:

$ CFG=local.cfg make m328test

Resulting file:
$ avr-size device/m328test/image.elf
    text       data        bss        dec        hex    filename
    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 <[hidden email]> 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 <[hidden email]> 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
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> Owfs-developers mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Owfs-developers mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
> ------------------------------------------------------------------------------
> _______________________________________________
> Owfs-developers mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/owfs-developers


------------------------------------------------------------------------------
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: Merging "moat" device specific code

CReese
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: 8000000
>       port:
>         1: B0~
>         2: B1~


------------------------------------------------------------------------------
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: Merging "moat" device specific code

Johan Ström-3
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: 8000000
>>       port:
>>         1: B0~
>>         2: B1~
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Owfs-developers mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/owfs-developers


------------------------------------------------------------------------------
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: Merging "moat" device specific code

CReese
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 <[hidden email]> 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: 8000000
>>>      port:
>>>        1: B0~
>>>        2: B1~
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Owfs-developers mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Owfs-developers mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

------------------------------------------------------------------------------
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: Merging "moat" device specific code

Johan Ström-3
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 <[hidden email]> 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: 8000000
>>>>      port:
>>>>        1: B0~
>>>>        2: B1~
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> Owfs-developers mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Owfs-developers mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
> ------------------------------------------------------------------------------
> _______________________________________________
> Owfs-developers mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/owfs-developers


------------------------------------------------------------------------------
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: Merging "moat" device specific code

Matthias Urlichs-3
In reply to this post by CReese
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: Merging "moat" device specific code

Matthias Urlichs-3
In reply to this post by Johan Ström-3
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: Merging "moat" device specific code

CReese
In reply to this post by Matthias Urlichs-3
Thanks for the update.

If i can get these working I'll be using them all over for io port expanders in controls panels. I use ds2408s with optos, but they're expensive and don't have analog (among other things). I will help wherever I can, but I'm certainly a stronger integrator and coder in JS and Python than C.

C

> On Nov 11, 2015, at 11:31 AM, Matthias Urlichs <[hidden email]> wrote:
>
>> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

------------------------------------------------------------------------------
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: Merging "moat" device specific code

CReese
In reply to this post by Matthias Urlichs-3
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 <[hidden email]> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

------------------------------------------------------------------------------
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: Merging "moat" device specific code

Matthias Urlichs-3
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: Merging "moat" device specific code

CReese
In reply to this post by Johan Ström-3
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 <avr/pgmspace.h>
#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 <[hidden email]> 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: 8000000
>>>>>       port:
>>>>>         1: B0~
>>>>>         2: B1~
>>>> ------------------------------------------------------------------------------
>>>> _______________________________________________
>>>> Owfs-developers mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> Owfs-developers mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Owfs-developers mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Owfs-developers mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/owfs-developers


------------------------------------------------------------------------------
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: Merging "moat" device specific code

CReese
In reply to this post by Matthias Urlichs-3
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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/owfs-developers


------------------------------------------------------------------------------
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: Merging "moat" device specific code

Johan Ström-3
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
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Owfs-developers mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/owfs-developers


------------------------------------------------------------------------------
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: Merging "moat" device specific code

CReese
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 <[hidden email]> 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
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Owfs-developers mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/owfs-developers


------------------------------------------------------------------------------
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers


------------------------------------------------------------------------------

_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: Merging "moat" device specific code

Johan Ström-3
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 <[hidden email]> 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
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Owfs-developers mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/owfs-developers


------------------------------------------------------------------------------
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers



------------------------------------------------------------------------------


_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers


------------------------------------------------------------------------------

_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: Merging "moat" device specific code

CReese
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 <[hidden email]> 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 <[hidden email]> 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
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Owfs-developers mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/owfs-developers


------------------------------------------------------------------------------
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers



------------------------------------------------------------------------------


_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers


------------------------------------------------------------------------------

_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers



------------------------------------------------------------------------------

_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
123