Re: [Owfs-developers] Creating owlua...
G'Day,
If by path you mean something like /10.23AD234523/temperature the
answer is simple:
You use get for the root path (/ or actually just ) and build
from there.
I had actually tried that before, curious to what would happen rather
than expecting it to be the answer to my question. That it did not
accept / meant nothing to me before, but has now allowed me to spot a
bug in my code. It now accepts /, but I am getting a segmentation
fault in owlib instead. I have tried to trace it as best I can, but can
only get as far as the `BUS_select(pn2)' call in FS_realdir()
(ow_dir.c:459). I am not sure if it is crashing on that line, or within
the function it calls, but I cannot trace any further.
I believe this is where it calls the adaptor-specific X_select()
function. It should be calling OMAP_select() for me, but I do not
believe it is. I am calling `owopt('o', optarg, opt_server)' in my
init() function, which should set it to the OMAP adaptor. Unless there
is another step I have missed along the way.
-- Matthew
The explanations 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 returned as straight ascii characters.)
Paul Alfille
On 1/31/07, Matthew Percival [EMAIL PROTECTED] wrote:
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 without any trouble, but I cannot for the life of me
work out
how to use put/get. In both cases I need to provide a path,
and this is
where it feels like I am missing a function or two.
How does a person writing their Lua script know what
path is needed?
Presumably they would need to call a function that tells them
the
relevant paths or something. For that matter, what devices
are
available and what can we do with them?
I have been trying to work these things out from the
source code, but I
am just going around in circles. I have a C library written
similar to
owcapi that allows people to access the 1-Wire net from Lua,
but no idea
how to make any practical application of this. Can anyone
direct me on
where to find the answers to this?
Thanks,
Matthew
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance
to share your
opinions on IT business topics through brief surveys - and
earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___ Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Creating owlua...
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 without any trouble, but I cannot for the life of me work out how to use put/get. In both cases I need to provide a path, and this is where it feels like I am missing a function or two. How does a person writing their Lua script know what path is needed? Presumably they would need to call a function that tells them the relevant paths or something. For that matter, what devices are available and what can we do with them? I have been trying to work these things out from the source code, but I am just going around in circles. I have a C library written similar to owcapi that allows people to access the 1-Wire net from Lua, but no idea how to make any practical application of this. Can anyone direct me on where to find the answers to this? Thanks, Matthew - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
[Owfs-developers] Creating owlua...
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 to what I would need to do, so would I be able to use this as a basis/guide to make owlua, or would that be a bad idea (incomplete, out of date, etc)? If owcapi is fine, I assume the key functions owlua needs are init(), get(), put() and finish(). I see owcapi also has OW_init_string(), but I am unsure as to what its purpose is, or if I would need an equivilent function for owlua. If owcapi is insufficient, is there anywhere I could get find a guide to what would be necessary, or perhaps a owlib API summary? -- Matthew - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
RE: [Owfs-developers] DS2431 memory woes, and BUS_send_data()bug...
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 writes to the DS2431
ultimately happen in ow_2433.c::OW_w_mem2D(), and this function exits
right on the first line:
static int OW_w_mem2D( const unsigned char * data , const size_t size ,
const size_t offset, const struct parsedname * pn ) {
unsigned char p[3+8+3] = { 0x0F, offset0xFF , offset8, } ;
int ret = 0 ;
size_t start = offset 0x07 ; /* place within EPROM row */
/* if incomplete row (8 bytes) read existing into buffer to fill it
up */
if ( start || (size0x07) || OW_r_mem( p[3], 8, offset-start,
pn ) ) return 1 ;
(snip)
Because `start' is true, this function will automatically exit, and so
the write will never begin. The rest of the function should work, if
the BUS_send_data() calls are replaced with something else; the
BUS_readin_data() calls would work, but seem like they perform more
steps than necessary.
-- Matthew
---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] DS2431 memory woes, and BUS_send_data() bug...
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 them. If I am correctly understanding the way this device
works, are the bits you read back there not the contents of the
memory? I could very well be wrong here, as I am finding the
documentation for the device a little hard to follow at times, but
that is just how it seems to me: I need to send 0xF0, some sort of
reference address, then start reading back data stored in that
address.
Never properly documented, but:
BUS_send_data sends and compares data (the data is specific to
DS2480B/DS9097U syntax that uses in-band commands to the adapter,
hence data and command modes).
BUS_sendback_data sends data and returns what it reads.
BUS_readin_data sends dummy data and returns what it reads.
Clearly these are all slight variations of the underlying send bits
and look at what the bus does to them, but that's the essence of
1-wire communication.
I understand that BUS_sendback_/readin_data() relate to the protocol
used by those adaptors then? They may not be completely compatible with
the OMAP boards, so I may need to add an option which skips aspects if
it is using the OMAP hardware support.
Tell me specifically where you are looking, please.
I have been using the Dallas documentation for the DS2431 as my
reference on how things work on the device:
http://www.maxim-ic.com/getds.cfm?qv_pk=4272ln=en
I have been watching what happens when I cat `memory' with an
oscilloscope, and noted some rather unusual behaviour. For some reason,
when I cat this file the `Match ROM' command (effectively, BUS_select()
for the purposes of owfs), is being performed twice, then nothing else.
The OW_r_mem() function in ow_2433.c, however, lists a BUS_select() call
followed by BUS_send_data() and BUS_readin_data(), so I am not sure why
nothing is getting called after BUS_select(), nor why that function is
being called twice.
Sounds like a problem with the select.
The routine is as follows:
static int OW_r_mem( unsigned char * data , const size_t size , const size_t
offset, const struct parsedname * pn) {
unsigned char p[] = { 0xF0, offset0xFF, offset8, } ;
int ret ;
//printf(reading offset=%d size=%d bytes\n, offset, size);
BUSLOCK(pn);
ret = BUS_select(pn) || BUS_send_data( p, 3,pn ) ||
BUS_readin_data( data,size,pn );
BUSUNLOCK(pn);
if ( ret ) return 1;
return 0 ;
}
I am still not sure why it is doing the double BUS_select() (perhaps it
is from another function called shortly before this?), but I have
identified the problems. Firstly, there was an excess return still
hanging in OMAP_select() (I thought I had already removed all of them,
but obviously not): this is why it was never calling BUS_send_data().
As for BUS_send_data(), on the OMAP it writes the three bits in p, then
reads back three bits --- which are the first three bits of memory ---
and compares them. If they ever match up, it will be an amazing
coincidence.
I have tested it with the following:
ret = BUS_select(pn) || write(pn-in-fd, p, 3) ||
read(pn-in-fd, data, size);
With those changes I am now able to read from memory. I have also tried
reading from pages/page.X (they use the same function, so they should
work): they *seem* to `work' (there are no errors, and the oscilloscope
shows the values coming in), but I receive an empty set with them, while
memory returns a lot of 0xFFs. Perhaps that is intentional though?
I tried writing to memory, however OW_write_paged() exits early --- I
have not yet identified why. I am also trying to write to pages/page.X,
however, they fail right at the start of the code:
if ( start || (size0x07) ||
OW_r_mem( p[3], 8, offset-start, pn ) ) return 1 ;
The value of start (and size0x07 for that matter) is true, therefore
the function never gets a chance. The comment above the line (this is
in ow_2433.c::OW_w_mem2D() by the way) reads as if it should be
something more like this:
if (start (size07))
if (OW_r_mem(p[3], 8, offset-start, pn))
return 1;
Am I understanding that correctly? If not, is there something else
wrong with that line? It seems to me that it is impossible to write to
the device, given it fails without even getting started.
-- Matthew
---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click
[Owfs-developers] DS2431 memory woes, and BUS_send_data() bug...
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_errors was 1, however, when I checked `cat statistics/errors/OMAP_*', everything was 0! The only logical explanation is that the error being generated by BUS_send_data() was not due to OMAP_sendback_data() returning a non-zero value, rather that memcmp() was coming back non-zero. When I checked the code for this section, I noticed a small mistake. The line is as follows: (ret=BUS_sendback_data( data, resp, len,pn )) || ((ret=memcmp(data, resp, (size_t) len))?-EPROTO:0) ; Which, if I assume BUS_sendback_data() is returning `0' and memcmp is returning `unknown', evaluates to: 0 || (unknown ? -EPROTO : 0) In other words, that *line* evaluates to either 0 or -EPROTO, but the value or ret will be the value of unknown. You can fix this by moving the bracket like so: (ret = BUS_sendback_data( data, resp, len,pn )) || ((ret = memcmp(data, resp, (size_t) len) ? -EPROTO : 0)); Now, if memcmp returns a non-zero value, ret will equal -EPROTO. I have also noticed that owfs seems to fall asleep on me at times: sometimes when I give a command (ls, cat, etc), it will just hang on that. If I background the ls/cat and `killall owfs' it will finally act on the command (with a predictable `No such file or directory' error). I have tried disabling multithreading, but that did not seem to be the problem. Has anyone else experienced anything like this before? 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 them. If I am correctly understanding the way this device works, are the bits you read back there not the contents of the memory? I could very well be wrong here, as I am finding the documentation for the device a little hard to follow at times, but that is just how it seems to me: I need to send 0xF0, some sort of reference address, then start reading back data stored in that address. -- Matthew --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Adding another means of accessing devices(ie not serial, USB, etc)...
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 recently wrote a kernel driver for this, and needed to add support for my driver to owfs. I am just finishing off some documentation on the hardware support and my driver, if you are interested --- though I would not imagine it would be particularly interesting to anyone not using OMAP boards. Specific comments: 1. in ow_omap.c : OMAP_reset, are we missing something? I see a loop, with fsync, but no body. That would be a typo I had not noticed: it should have a semi-colon at the end. fsync() could return -EBUSY if the bus were currently in use, which meant you needed to wait a moment before you could use it (at the time I felt that was a cleaner solution than blocking). Due to a hardware bug, if you try to do anything while another operation is completing, you risk corrupting data (`anything' includes even reading status registers!). That will not be relevant soon, however, as my next version of the driver will be blocking when performing operations, and as such there is no -EBUSY signal. 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. 3. Is there a characteristic major/minot device number to test for in OMAP_detect ow_ds9097.c had no such thing, so I did not realise I needed to test anything like that. Because there is no device assigned to this (and, really, there probably never will be), this may need to change, but currently /dev/owire is set to 232/0. 4. It's a matter of style. Your ow_omap.h has only static function prototypes. I've been putting them at the start of the source module and using the *.h files for externally visible definitions. That is simple enough to change --- I mainly do it like that for my own reference early on anyway. Once I get to a certain point, it works just as well for me either way. 5. Do you have a picture of the adapter for the web site? Since it is not really an real adaptor, there are no pictures of the relevant aspect, however if you want a picture of an OMAP development board there is one of the board I am using here: http://omap.spectrumdigital.com/osk5912/ -- Matthew --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Adding another means of accessing devices (ie not serial, USB, etc)...
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; these were the cause of much of the trouble. I also had to make my driver more intelligent, as it needs to work differently when an Search ROM command has been issued compared to normal. There also seemed to be aspects of the DS9097 driver that differed from the algorithm somewhat, but that was probably because of the way the adaptor works. I now have the basics working, but have not been able to test all the functions yet. There are also a few functions I am still not sure of the use of, and as such they may need to be rewritten a little. All-in-all, it is almost complete: I would just like to say what I have so far, so as to verify that I am doing what is expected. OMAP_detect: almost identical to the serial device, it does a little setting up, then resets the bus. OMAP_setroutines: simply assigns the functions that would be called by external routines; no overdrive functions provided. OMAP_write: one I am not sure of. It splits the write buffer up into bits, and calls OMAP_send_and_get(). Do they really have to be sent as individual bits, or can I just leave them as bytes and send it all together? OMAP_read: effectively the same as OMAP_write(), only reading. Again, should I really be expecting bits, or can I assume byte returns? OMAP_reset: sends a reset pulse, and verifies there are devices present. OMAP_next_both: the Search ROM routine. Sends a Search ROM command, reads two bits, writes a bit, and continues until either an error or it is complete. Checks the serial at the end. OMAP_level: does not seem to do much of anything; more or less copied from the serial adaptor. OMAP_PowerByte: sounds fancy, but I cannot work out the purpose of it. Calls OMAP_send_data(), switches level, waits, then calls OMAP_level(). OMAP_ProgramPulse: does not do anything right now; neither the DS9097 nor DS9490 seem to support it. OMAP_sendback_data: seems to be OMAP_write() and OMAP_read() combined; as with the other two, is it really necessary to do this in bits, or can I assume bytes? OMAP_select: seems to be a Match ROM command; currently taken almost directly from the DS9097. If if is Match ROM, I may need to make a few, small, changes. I guess pn-sn is the serial number, and pn-dev has something to do with devices, but am not positive. OMAP_send_data(): fairly similar to BUS_send_data(). It calls OMAP_sendback_data, and checks that it received back the same data it sent. I am guessing there is some kind of device that requires this. OMAP_readin_data(): replacement for BUS_readin_data(), it is basically a front to OMAP_sendback_data, but does a memset() in the first argument rather than a variable; not sure of the purpose yet. OMAP_send_and_get(): replaces BUS_send_and_get(), and seems to work fine. If there's anything to send, it does; if there's anything to read, it does. If there is anything there I am wrong about, of if anyone can answer any of the questions, I would really appreciate it. -- Matthew --- This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual core and dual graphics technology at this free one hour event hosted by HP, AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Adding another means of accessing devices (ie not serial, USB, etc)...
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. If you look for a directory listing, there is a loop in ow_dir.c:FS_real_dir() which starts with BUS_select() and BUS_first(). BUS_select() calls BUS_select_low() in ow_bus.c and it will reset the 1-wire bus and eventually select the main or aux branch on a DS2409, or address a specific 1-wire device. BUS_first() initiate some structs and calls BUS_next() (which is translated to DS9490_next_both() (or the other *_next_both for other adapters). *_next_both is called until there are no more devices on the 1-wire bus. ow_.c:CheckPresence_low() will check if a device exists on any connected adapter. It calls ow_verify.c:BUS_normalverify(). As you can see that function reset the 1-wire bus and address the wanted device via BUS_select(), and then send presence check to the device. I have added some fprintf()s to the code, and noticed that OMAP_select() and OMAP_next_both() are never called; nor is CheckPresence_low(). No errors are recorded anywhere, however, and pn-si-AnyDevices is being set to true. I added some more fprintf()s to see exactly what was going on, and there do not seem to be many calls to my code at all. When I first run owfs, I get the following output: OMAP_detect() OMAP_reset() OMAP_send_and_get() OMAP_reset(): AnyDevices = 1 owfs is activated! Looking at the oscilloscope, I see a little activity (a clear presence pulse at the correct time, followed by some other transfers). When I ls 1wire/, there are no calls to my functions, but the oscilloscope shows some activity; likewise, ls 1wire/bus.0/ has activity, but my functions are not called. The most likely explanation is that something is failing before it calls my functions, but it is also not calling the functions that are supposed to be called at this time. I half tempted to add fprintf()s everywhere, so I can see every function call: it may help track down what is going on a little faster. I assume you've altered ow_opt for special parameters and configuration for your adapter type, and added the adapter type to the enum. I do not need to do much here, but I have made some additions. I'm afraid you're going to have to read the 1-wire Application Notes. The website seems to be down at the moment, but I shall check them out later: thanks for the links! -- Matthew --- This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual core and dual graphics technology at this free one hour event hosted by HP, AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Adding another means of accessing devices (ie not serial, USB, etc)...
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. If received byte is 0, the 1-wire bus has a short circuit. Otherwise there seem to be devices 1-wire devices to use. I guess you get a result !=0 and !=0xF0 since you make a debug output like: OMAP_reset(): AnyDevices = 1 (and I suppose you return 0 from OMAP_reset() to indicate reset was successful) That is correct: I have maintained that aspect as-is. If you start: owfs --foreground --error_level=9 --error_print=2 -o /dev/wire /mnt/1wire I have now tried that. --error_level and --error_print were not recognised (they must have been added since the last release), and if I use --foreground I end up stuck because I can only have one terminal: I did not think about that aspect until after I tried it. Add debugging in ow_dir.c:FS_realdir() just after BUS_select(pn2) and BUS_first(sn,pn2) and make sure they both return 0, otherwise it will never enter the loop and list the devices on the 1-wire bus. I added a couple of messages to that function, and it never even gets called, let alone BUS_select()/BUS_first() getting called. Indeed, none of the BUS_*() functions seem to get called at any time. `ls /mnt/1wire/uncached/' does not appear to help either. 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 in FS_getdir(), which also never seems to be called. From what I can gather, I would have to go into FUSE to find where that is called... so I turned my attention to where owfs gets FUSE started. I took the following line: if ( LibStart() ) ow_exit(1) ; and turned it into: testing = LibStart(); fprintf(stderr, LibStart() returned %d, testing); if ( testing ) ow_exit(1) ; Interestingly enough, I never saw that output. It got to the line before calling LibStart(), but never printed `testing', yet I could still access parts of the file system. I know nothing about how FUSE works, but I would have thought it would be a case of all-or-nothing. I am rather stuck now: I had not expected to find anything like this. Is the problem likely with FUSE as I suspect, or may it perhaps be somewhere else? Thanks for the assistance so far, Matthew --- This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual core and dual graphics technology at this free one hour event hosted by HP, AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Adding another means of accessing devices (ie not serial, USB, etc)...
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 in FS_getdir(), which also never seems to be called. From what I can gather, I would have to go into FUSE to find where that is called... so I turned my attention to where owfs gets FUSE started. I took the following line: if ( LibStart() ) ow_exit(1) ; and turned it into: testing = LibStart(); fprintf(stderr, LibStart() returned %d, testing); if ( testing ) ow_exit(1) ; Interestingly enough, I never saw that output. It got to the line before calling LibStart(), but never printed `testing', yet I could still access parts of the file system. I know nothing about how FUSE works, but I would have thought it would be a case of all-or-nothing. I just realised LibStart() was starting owlib, not FUSE, and when I looked through that I realised that the call to daemon was with the arguments (1,0): all output is sent to /dev/null! I have now changed that to (1,1) and now see things closer to what I would have expected: # ls /mnt/1wire/ FS_dir() FS_realdir() OMAP_reset() OMAP_send_and_get() OMAP_reset(): AnyDevices = 1 OMAP_sendback_data() OMAP_send_and_get() OMAP_select() OMAP_reset() OMAP_send_and_get() OMAP_reset(): AnyDevices = 1 OMAP_next_both() OMAP_send_data() OMAP_sendback_data() OMAP_send_and_get() OMAP_send_data_errors Further investigation shows that the problem is that the memcmp() in OMAP_send_data() is returning a non-zero value (which means it should be OMAP_send_data_memcmp_errors rather than OMAP_send_data_errors, but I will work out what is wrong there later). I am sending of 0xF0 (Search ROM) and receiving 0xAD... which, to be honest, I do not know how to interpret! From my understanding, 0xF0 is used to identify all the devices on the bus (in this case, there is only one). I would imagine the link provided yesterday would explain this, but the site seems to be still down; hopefully it will come back soon, and I will be able to work out what is going wrong. Thanks, Matthew --- This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual core and dual graphics technology at this free one hour event hosted by HP, AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
[Owfs-developers] Adding another means of accessing devices (ie not serial, USB, etc)...
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 assumption seems fairly likely. This board has hardware support for 1-Wire, so I decided that taking advantage of that would be the best way to go. By directly accessing registers, I was able to confirm that I could use this to access the device where owfs failed, but due to a hardware bug you *have* to use interrupt driven I/O. 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 of 1-Wire device. Since one happens to be available here, I figured the best approach would be to add in support for my driver to owlib. I am reading through the source to try and work out how this would best be done, but I thought it would be a good idea to ask the developers how they would suggest going about it: after all, you have a much better idea of how this all works than I am likely to figure out in the next few days. I figure that since you already support (or, in some cases, plan to support) different protocols (serial, USB, etc), you would have designed the program in such a way that a new one can be added without having to pull your hair out: I want to add the omap-on-board-using-kernel-driver method. I have made the driver pretty simple (being my first driver, it could not be anything *but* simple), and as such you only have to open() a /dev/ file (eg /dev/owire) then write() and read() as needed. Would it be much work for me to add support for this? Assuming this is not something only a person out of his mind would attempt, does anyone have any suggestions about how best to go about this? -- Matthew --- This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual core and dual graphics technology at this free one hour event hosted by HP, AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] RE: 1-wire on Linux...
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 device I am going to use is not yet supported, but it sounds like I should be able to add it easily enough --- at least, the website makes it sound easy! 5. Access to the data is via filesystem, web server, or perl/python/tcl/php 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 for perl, php, python and tcl); if I use touch to fake these (as I do not plan on compiling them at the moment), I still cannot get it to compile because at least one header file is missing (I say `at least' because it would be not so quick and easy to write a placeholder file and see if I can compile any further). I tried using a few different daily builds, and had other problems with them, though I did manage to at least compile a (probably out of date) version of owlib. I tried downloading 2.1.0 from a different mirror too, and still had the same problems. Does anyone have a quick and easy solution for this? Thanks, Matthew --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] RE: 1-wire on Linux...
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-wire, but I shall not be worrying about that just at the moment; later on, I shall likely try to make use of this though. We shall be adding a DS2431 to the board, which is where the 1-wire will come into play. This is perhaps sliding a little off topic, but would it be possible to share the fuse.ko line in modules.dep? I have to build this file manually (depmod is not available), but have not been able to find out what the line should look like for that module. -- Matthew --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] RE: 1-wire on Linux...
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 *.h files it should work. That gets a compile, but that is how I get up to the other problems (modules.dep so I can use FUSE, and thus owfs, and it not finding libow.0, which keeps osfs AND owhttpd from working) Thanks, Matthew --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] RE: 1-wire on Linux...
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 onto the build machine, then moving it to the target, I was able to get things to work. Using --prefix to install it to the NFS root or manually installing both caused a variety of problems. I am now able to mount owfs without any troubles --- at the moment, that does not do much good, but it is reassuring to know that this much works fine. owhttpd does not seem to work though: when I run it on the ARM machine, I cannot access it from a browser on this one (the build machine). The ARM has thttpd running on port 80, which I can access, so I know that the problem is not network or anything like that. One point of note is that when I execute the command (owhttpd -p 3001 -d /dev/ttyS1), it just hangs there: I never get the prompt back. That is probably a pretty fair indication as to why I cannot access it with the browser. Not a major concern though, as owfs was the the component I was most interested in. I now just have to add support for the DS2431. I would imagine that you would be interested in having that once I have it working: how would I best go about getting that to the project? Thanks for the help: it has been exceptional! Matthew --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
