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

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

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

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

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

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

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

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

Re: [Owfs-developers] 'strange' value reading /sensed.BYTE of a DS2408 (Stefano Miccoli)

On Tue, 10 Nov 2015 13:19:56 +0100 Stefano Miccoli mo...@icloud.com wrote: > Do you experience slow dir times only on the root / or also on the > sensors? say something like ?/system/? that should not require any bus > activity? So I've learned how to use the timing test program more

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

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

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

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 /

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

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

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

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

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

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

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

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: [] >