aptor
(presumably a bug in my owlua code).
-- Matthew
> Paul Alfille
>
> On 1/31/07, Matthew Percival <[EMAIL PROTECTED]> wrote:
> G'Day,
>
> > If by path you mean something like
> "/10.23AD234523/temperature
ons for what devices support what properties, their
> format, function, measurement units, etc is in the man files. That is
> domain-specific information that the user must know indep[endently
> (though we'endeavored to make function pretty transparent, and must
> data is
G'Day,
I have been trying to create a owlua using owcapi as a basis. As far
as this is concerned, it has been a success --- I have an exact
equivalent to owcapi that can now be used from Lua. I just cannot make
any use of it! I can use the OW_init() and OW_finish() equivalent
functions
G'Day,
I am looking to create a Lua interface to owlib --- effectively owlua.
I would need to do this as a simple C library that makes the appropriate
calls, however, I have not been able to find any documentation that
would help with this. owcapi seems like it would be something similar
G'Day,
> owfs.o(.text+0x20e): In function `main':
> /usr/local/owfs/module/owfs/src/c/owfs.c:152: undefined reference to
> `fuse_new_compat2'
> collect2: ld returned 1 exit status
> make[4]: *** [owfs] Error 1
> make[4]: Leaving directory `/usr/local/owfs/module/owfs/src/c'
> make[3]: *** [all-re
G'Day,
I have just about managed to work out all the bugs in
ow_2433.c::OW_w_mem2D() --- there is a potential bug which I have
introduced myself, and one I could not work out, but they should both be
simple enough to solve. I shall begin from the start...
> if ( start || (size&0x07) || O
G'Day,
> I'll have to look closely at your code, but it sounds like the code for the
> OMAP
> is flushing the bus after writing and not reading the bus response to writing.
That could not be the case: it never gets up to writing. I have
followed the code, and now identified that any wri
G'Day,
> > As to the specifics of the function called when catting
> > 2D.serial/memory/, perhaps it is just my misunderstanding, but it
> > seems to me like calling BUS_send_data() is not the best thing to
> > do. BUS_send_data(x,3,y) sends three bits, then reads three bits and
> > compares
G'Day,
> When I `cat 2D.serial/memory', it does not work, so I checked `cat
> statistics/errors/BUS_*' and noticed that BUS_send_data_errors was 1,
I may have been looking at the wrong thing with that: that error is
probably being flagged at some earlier time, and as such not relate
G'Day,
I am currently trying to weed out why I still cannot read from my
DS2431 device, and in my testing I stumbled across a minor bug in
BUS_send_data().
When I `cat 2D.serial/memory', it does not work, so I checked `cat
statistics/errors/BUS_*' and noticed that BUS_send_data_er
G'Day,
> > > 2. How big a send/recieve buffer does the adapter have?
> >
> > At the moment, I am buffering everything in kernel, and sending it one
> > byte (or bit, if performing Search ROM) at a time. I am considering
> > changing that in future, but at the moment there is no hard limit.
>
G'Day,
> Nice work. I've been going through your code.
Thanks: I appreciate it!
> One basic question: What exactly is this "adapter" and which architecture
> supports it?
It is not a true adaptor: Texas Instruments' OMAP development boards
have hardware support for 1-Wire. I r
00 +1000
+++ bbb/module/owlib/src/c/ow_omap.c 2005-07-14 09:34:08.712946016 +1000
@@ -0,0 +1,454 @@
+/*
+ * ow_omap.c
+ *
+ * OMAP Support for owlib v0.0 --- 08/07/2005
+ *
+ * Copyright (C) 2005 Capgo
+ *
+ * Written by Matthew Percival <[EMAIL PROTECTED]>
+ * Based on ow_ds9097.c v1.20 by P
G'Day,
> And the search algorithm:
> http://www.maxim-ix.com/appnots.cfm/appnote_number/187
Thanks to this document, I was able to eventually sort out the problem.
There were lots of small differences here and there between the way the
serial device works, and the way the OMAP bus works;
I seem to have completely missed something very important.
> I decided to trace back, and it seems FS_realdir() is called by
> FS_dir_seek(), however that function is never called either; nor is
> FS_dir(). If I continue to follow the path, FS_dir() seems to only
> called from owfs
G'Day,
> As I understand you have copied ow_ds9097.c and made your changes to it.
> DS9097_reset() send a resetbyte 0xF0 and read a byte. If received byte
> is 0xF0, no devices where found on the bus and it's therefor no use
> to search for more devices in DS9097_next_both() where it exits later.
G'Day,
> I doubt that you could skip the omap_reset() function since it's used
> to address a specific device or the branch on the DS2490. (and reset the
> 1-wire bus which more devices need)
I have added an OMAP_reset() now; it is fairly simple, but there does
not seem to be much to do.
G'Day,
> > I have now just finished writing a kernel module which handles the
> > OMAP's hardware support for 1-Wire, and have used a test program to
> > interact with the DS2431. All that remains to do is have a nice, user
> > program that can handle interactions with any number of any kind
G'Day,
I tried using owfs on my OMAP board, but even after I added basic
support for the DS2431, it did not list the device in /mnt/1wire --- I
am assuming that this is largely because of the unusual environment that
I am operating under. Given the report that I had a bad adaptor, this
as
G'Day,
> > config.status: creating module/swig/Makefile
> > config.status: creating module/swig/perl5/Makefile
> > config.status: error: cannot find input file: module/swig/perl5/Makefile.in
> >
> >
> My Makefile.am is at the end.
That is the same problem I had: there will be more than ju
G'Day,
Thanks for all the help: I now seem to have the basics sorted out!
Firstly, with FUSE, I never would have guessed it was just a blank
line: I was sure there would be at least one other module to be loaded.
Secondly, to paths, by making --prefix=/usr/local and installing it
G'Day,
> So your download doesn't include relevant files like
> modules/owlib/src/include/*.h ?
Not all of them, but several; module/swig/ is mostly empty too.
> Perhaps a CVS pull?
I used CVS to make the difference: I figured the rest should be right,
so by adding the missing
G'Day,
> It shouldn't be this difficult.
>
> What platform are you running?
I am not using a particularly standard environment. Well, I am
building it on standard desktop, but the target machine is an OMAP5912
--- owfs/owhttpd will run on an ARM. The board has hardware support for
1-wi
G'Day,
> > I have tried to compile the 2.1.0 version available for download, but
> > there seems to be some problems with the tarball. Namely, there are an
> > awful lot of files missing! I cannot get configure to complete because
> > many of the files used by automake are missing (the ones
G'Day,
Thanks for your replies: they are extremely helpful!
> 4. Almost all the devices are supported, you don't need anything extra. This
> includes temperature, memory, switches, voltage, current, timers, counters and
> some LCD and humidity 3rd party devices.
The particular de
25 matches
Mail list logo
