Ah, using the latest code is always a good start.. :) Yes, the 'moat' device uses custom ROM commands. To communicate with the moat from any other non-owfs master you'd need to implement the custom ROM commands there. See https://github.com/M-o-a-T/owfs/blob/moat/module/owlib/src/c/ow_moat.c for details.
And to get back where this thread started, this is the actual code which this thread revolves around, adding support for those special ROM commands to the official owfs branch. On 13/11/15 06:53, Colin Reese wrote: > First, I just noticed the HOWTO is much improved and has some details > about using the uart. Thanks Matthias. > > I assume all of the data appears somewhat transparently via owfs as > indicated in the HOWTO, which is how I plan to use it typically. Using > other code, e.g. through LabVIEW or otherwise, how would one read this > data? Is there a modified command set? > > Thanks, > C > > On 11/12/2015 9:06 PM, Colin Reese wrote: >> Understood. >> >> From what I can see, 1Wire should be on INT0 (D2) per 152 in >> world.cfg. With the world.cfg below, everything compiles fine and >> loads from my USBTiny. I verified my fuses are xFF, xDE, x05, which >> looks good. I still don't see anything on my DS9490R. >> >> One more thing -- anybody know what I need to do to select and enable >> the debug UART? I can see that the default baudrate is 38400; I just >> need to select a port, pin and enable it. I can't quite see what >> needs to be defined to do it. >> >> C >> >> _include: world.cfg >> devices: >> _default: >> _ref: defaults.target.m88 >> types: >> _ref: defaults.types >> code: [] >> m328test: >> _ref: mcu.mega328 >> defs: >> f_cpu: 16000000 >> port: >> 1: B0~ >> 2: B1~ >> onewire_id: x0f361b8bff8a >> >> >> On 11/12/2015 12:28 PM, Johan Ström wrote: >>> You'd have to step through the "_ref" in your def, and the "default" >>> section in world.cfg to found out any defaults. >>> >>> In my example, I only have specifically 'ref: mcu.mega328'. Checking >>> the mcu.mega328 section in world.cfg (included) we do not have a >>> f_cpu def. >>> So continue to global 'defaults' section, check defs. no f_cpu there >>> either. >>> So for this target, there is no "default". In my example, it was >>> explicitly set to 8Mhz though. >>> >>> If we would instead use 'ref: defaults.target.m88' we would find >>> _ref 'defaults.target.m8x_base' which contains the f_cpu def. >>> >>> The reason it is not in code is that world.cfg controls all >>> dynamic/configurable properties. During build, it will write a >>> device/$TARGET/dev_config.h which is then included in the actual code. >>> >>> >>> >>> On 12/11/15 18:17, Colin Reese wrote: >>>> I understand, but if not already defined, what is the default >>>> value? Or, why is this not defined in the code already? >>>> >>>> On Thu, Nov 12, 2015 at 9:13 AM, Johan Ström <jo...@stromnet.se >>>> <mailto:jo...@stromnet.se>> wrote: >>>> >>>> Yes, the f_cpu define only controls timing calculations, which >>>> must match the clock speed. If incorrectly configured, it won't >>>> be able to talk on the 1wire net. >>>> >>>> >>>> On 12/11/15 18:04, Colin Reese wrote: >>>>> I see this in main: >>>>> >>>>> #elif defined (__AVR_ATmega168__) || defined >>>>> (__AVR_ATmega88__) || defined(__AVR_ATmega328__) >>>>> >>>>> >>>>> >>>>> // Clock is set via fuse >>>>> >>>>> is the f_cpu definition necessary here? >>>>> >>>>> C >>>>> >>>>> On Thu, Nov 12, 2015 at 8:44 AM, Johan Ström >>>>> <jo...@stromnet.se> wrote: >>>>> >>>>> As long as your built it for 16MHz it should probably be >>>>> compatible (I'm >>>>> not familiar with any specific fuses the m328 might have). >>>>> >>>>> Thus, f_cpu: 16000000 >>>>> >>>>> On 12/11/15 03:39, Colin Reese wrote: >>>>> > So to avoid trying to get WinAVR to behave, on a windows >>>>> machine with >>>>> > avrdude I would do something like: >>>>> > >>>>> > avrdude -c usbtiny -p m328p -U flash:w:image.hex -U >>>>> eeprom:w:eprom.hex >>>>> > >>>>> > That should do the trick? Do I really need to set the >>>>> fuses? I have it >>>>> > set up as external 16Mhz. I assume this is compatible. >>>>> > >>>>> > C >>>>> > >>>>> > On 11/11/2015 12:34 PM, Matthias Urlichs wrote: >>>>> >> On 11.11.2015 20:45, Colin Reese wrote: >>>>> >>> In the meantime, getting an updated libc from >>>>> elsewhere than the apt repos is an option? >>>>> >> I'd be wary of compiler/libc or libc/header >>>>> incompatibilities when >>>>> >> upgrading partially. IMHO it'd be safer to examine your >>>>> existing >>>>> >> pgmspace.h and add a patch to MoaT that works around >>>>> not having the >>>>> >> current version of pgmspace.h. (I already tried that, >>>>> but apparently not >>>>> >> quite successfully.) >>>>> >> >>>>> >> In fact you might just email your version to me, I can >>>>> certainly take a >>>>> >> look. >>>>> >> >>>>> >> >>>>> >> -- Matthias Urlichs >>>>> >> >>>>> >> >>>>> >> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> >> _______________________________________________ >>>>> >> Owfs-developers mailing list >>>>> >> Owfs-developers@lists.sourceforge.net >>>>> <mailto:Owfs-developers@lists.sourceforge.net> >>>>> >> >>>>> https://lists.sourceforge.net/lists/listinfo/owfs-developers >>>>> > >>>>> > >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> > _______________________________________________ >>>>> > Owfs-developers mailing list >>>>> > Owfs-developers@lists.sourceforge.net >>>>> <mailto:Owfs-developers@lists.sourceforge.net> >>>>> > https://lists.sourceforge.net/lists/listinfo/owfs-developers >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> _______________________________________________ >>>>> Owfs-developers mailing list >>>>> Owfs-developers@lists.sourceforge.net >>>>> <mailto:Owfs-developers@lists.sourceforge.net> >>>>> https://lists.sourceforge.net/lists/listinfo/owfs-developers >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> >>>>> >>>>> _______________________________________________ >>>>> Owfs-developers mailing list >>>>> Owfs-developers@lists.sourceforge.net >>>>> <mailto:Owfs-developers@lists.sourceforge.net> >>>>> https://lists.sourceforge.net/lists/listinfo/owfs-developers >>>> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Owfs-developers mailing list >>>> Owfs-developers@lists.sourceforge.net >>>> <mailto:Owfs-developers@lists.sourceforge.net> >>>> https://lists.sourceforge.net/lists/listinfo/owfs-developers >>>> >>>> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> >>>> _______________________________________________ >>>> Owfs-developers mailing list >>>> Owfs-developers@lists.sourceforge.net >>>> https://lists.sourceforge.net/lists/listinfo/owfs-developers >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> >>> >>> _______________________________________________ >>> Owfs-developers mailing list >>> Owfs-developers@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/owfs-developers >> > > > > ------------------------------------------------------------------------------ > > > _______________________________________________ > Owfs-developers mailing list > Owfs-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/owfs-developers
------------------------------------------------------------------------------
_______________________________________________ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
