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

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

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

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.

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

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

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

On 22.11.2015 17:03, Matthias Urlichs wrote: > bah. Sorry about that. Will fix ASAP. Fix pushed. -- Matthias -- ___ Owfs-developers mailing list

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

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

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

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

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

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

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

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

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

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]

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

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,

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

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

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

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,

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

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

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

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;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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,

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

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:

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

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

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

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