Re: [Owfs-developers] Adding another means of accessing devices(ie not serial, USB, etc)...
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. > > > I notice that you "write" then "read", but the string can be of uncertain > length. The DS9097U buffers one byte in hardware, and the kernel allows > something like 100 bytes of buffer (the combuffer string is sized for this). > The existing code will break long communication into write/reads of this > length or less. There is a balance between buffer length and the cost of > read/write setup. Unfortunately, the search algorithm uses a very short > read/write string (3 bits at best) so tends to be slow. We had a major > speedup of the DS9097 code when we did some loop regrouping to join the 1 bit > direction selection with the next two bit query. The way it is currently written, my kernel driver would not support something like that --- indeed, it would not even give you a chance to try it. That may be something worth considering in future, though in this case I am not sure there would be a significant change in performance. When I have been testing things out, I have had an oscilloscope connected to the bus, and it already seems to be going about as fast as the bus allows. > > > 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. > > > You don't. I'm just trying to find ways to reduce errors and > misconfigurations. It would be nice to have a positive test that the OMAP > adapter is actually there. That is more or less done when the open() command is called in ow_opt.c::OW_ArgOMAP(). Firstly, if you do not have the device file or the driver, this will obviously fail. Secondly, if the bus is not there (ie not an OMAP board), the driver should pick up on this when you try to load it --- before owfs is even run. > > > 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/ > > > Looks interesting. I don't see a 1-wire port, however. All the OMAP boards I know of come with on-board support for 1-Wire, however it is poorly advertised: some pages will have at best one line mentioning it, but most skip over the feature. That has been one of my biggest problems here: there was absolutely nothing available for me. That is why I have written the driver and the documentation, and now begun adding it to owlib. It firstly gives me what I need, but it also means that others wanting to do similar things will have a base to begin from. -- 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=7477&alloc_id=16492&op=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)...
On Sunday 17 July 2005 08:45 pm, Matthew Percival wrote: > 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. > I would like to include support with the mainline code, once you finished your testing. We would probably make in a compile-time option, since it won't be sued that often. > > 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. > I notice that you "write" then "read", but the string can be of uncertain length. The DS9097U buffers one byte in hardware, and the kernel allows something like 100 bytes of buffer (the combuffer string is sized for this). The existing code will break long communication into write/reads of this length or less. There is a balance between buffer length and the cost of read/write setup. Unfortunately, the search algorithm uses a very short read/write string (3 bits at best) so tends to be slow. We had a major speedup of the DS9097 code when we did some loop regrouping to join the 1 bit direction selection with the next two bit query. > > 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. > You don't. I'm just trying to find ways to reduce errors and misconfigurations. It would be nice to have a positive test that the OMAP adapter is actually there. > > 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/ > Looks interesting. I don't see a 1-wire port, however. > -- 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=7477&alloc_id=16492&op=click > ___ > Owfs-developers mailing list > Owfs-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/owfs-developers --- 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=7477&alloc_id=16492&op=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=7477&alloc_id=16492&op=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)...
Nice work. I've been going through your code. One basic question: What exactly is this "adapter" and which architecture supports it? Specific comments: 1. in ow_omap.c : OMAP_reset, are we missing something? I see a loop, with fsync, but no body. 2. How big a send/recieve buffer does the adapter have? 3. Is there a characteristic major/minot device number to test for in OMAP_detect 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. 5. Do you have a picture of the adapter for the web site? Paul --- 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=7477&alloc_id=16492&op=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,
> No, you got it all correct. There are a set of bit-level commands, and then
> some
> higher level composite commands (byte or more).
Thanks for checking those out for me: I believe everything is just
about right now. I was also having some trouble with support for the
DS2431, but have now worked out that problem --- you also need to list
the device in ow_tree.c. That is not mentioned on the webpage: it may
be a good idea to add it to the list of files that needs to be edited.
I can now see my device, as well as the specific files related to it.
I do not seem to be able to use it though. I tried to read the EPROM,
and received the following errors:
# ls /mnt/1wire/bus.0/2D.A9AA1100/
address crc8 family id memory pagespresent type
# cat /mnt/1wire/bus.0/2D.A9AA1100/memory
cat: Read error: Invalid argument
# more /mnt/1wire/bus.0/2D.A9AA1100/memory
fuse: writing device: Invalid argument
(system hung here)
I can cat `address', `crc8', etc, but not the device specific files. I
tried other places, and found a similar problem with catting `BUS_*' in
statistics/errors/ --- and once even on simply `ls statistics/errors/'!
What would you suggest may be the problem here? I am testing with the
2.1.0 release. I also used CVS to get the latest code, but had a lot
of trouble with it: when I eventually managed to get it to compile and
link, it would cause the system to hang after only a few simple
operations.
Because at least the bulk of the work is done, I have attached a patch
with the OMAP additions I have made: it is a diff with the latest CVS
source, rather than the last release. That should make it more
compatible with the next release. I shall share any changes I make as a
patch over this patch, to make things simple.
-- Matthew
--- aaa/module/owlib/src/c/ow_connect.c 2005-07-13 14:32:16.0 +1000
+++ bbb/module/owlib/src/c/ow_connect.c 2005-07-13 14:34:16.0 +1000
@@ -133,6 +133,13 @@
DS9490_close(now) ;
break ;
#endif /* OW_USB */
+case bus_omap:
+ if (now->fd > 0)
+ {
+ close(&(now->fd));
+ now->fd = -1;
+ }
+break;
default:
//printf("FreeIn: unknown busmode %d on index=%d\n", get_busmode(now), now->index);
break ;
--- aaa/module/owlib/src/c/owlib.c 2005-07-13 14:34:30.0 +1000
+++ bbb/module/owlib/src/c/owlib.c 2005-07-13 14:36:18.0 +1000
@@ -246,6 +246,20 @@
// in->name should be set to something, even if DS9490_detect fails
if(!in->name) in->name = strdup("-1/-1") ;
break ;
+ case bus_omap:
+ if ((in->fd = open(in->name, O_RDWR | O_NONBLOCK)) < 0)
+ {
+ ret = errno;
+ syslog(LOG_ERR, "Cannot open port: %s error=%s\n",
+ in->name, strerror(ret));
+}
+ else if (OMAP_detect(in))
+ {
+ syslog(LOG_WARNING, "Cannot detect OMAP bug on %s.\n", in->name);
+ ret = -ENODEV;
+ }
+
+break;
default:
ret = 1 ;
break ;
--- aaa/module/owlib/src/c/ow_omap.c 2005-07-13 14:39:01.0 +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 Paul H Alfille <[EMAIL PROTECTED]>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation.
+ */
+
+#include "owfs_config.h"
+#include "ow.h"
+#include "ow_omap.h"
+
+/* public functions */
+
+int OMAP_detect(struct connection_in *in)
+{
+ struct stateinfo si;
+ struct parsedname pn;
+ int error;
+
+ memset(&pn, 0, sizeof(struct parsedname));
+ pn.si = &si;
+ OMAP_setroutines(&(in->iroutines));
+
+ in->Adapter = adapter_OMAP;
+ in->adapter_name = "OMAP";
+ in->busmode = bus_omap;
+
+ if ((error = FS_ParsedName(NULL, &pn)))
+ {
+STATLOCK;
+OMAP_detect_errors++;
+STATUNLOCK;
+return error;
+ }
+
+ pn.in = in;
+
+ if((error = OMAP_reset(&pn)))
+ {
+STATLOCK;
+OMAP_detect_errors++;
+STATUNLOCK;
+ }
+
+ return error;
+}
+
+static void OMAP_setroutines(struct interface_routines* const f)
+{
+ f->write = OMAP_write;
+ f->read = OMAP_read;
+ f->reset = OMAP_reset;
+ f->next_both = OMAP_next_both;
+ f->level = OMAP_level;
+ f->PowerByte = OMAP_PowerByte;
+ f->ProgramPulse = OMAP_ProgramPulse;
+ f->sendback_data = OMAP_sendback_data;
+ f->select= OMAP_select;
+ f->overdrive = NULL;
+ f->testoverdrive = NULL;
+}
+
+/* protected functions */
+
+static int OMAP_write(const unsigned char* const buffer, const size_t length,
+ const struct parsedname* const pn)
+{
+ int error;
RE: [Owfs-developers] Adding another means of accessing devices(ie not serial, USB, etc)...
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Matthew Percival Sent: Tuesday, July 12, 2005 11:11 PM To: owfs-developers@lists.sourceforge.net Subject: 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. Sounds good. If the adapter presence can be tested, or there is some firmware information, this is where it would be tested. OMAP_setroutines: simply assigns the functions that would be called by external routines; no overdrive functions provided. Correct. This allows the rest of OWFS to access the low-level functions of your adapter. 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? The 1-wire bus transfers data 1 bit at a time. Some adapters have hardware support for transporting bytes or longer data segments. The main advantage is that the CPU does not have to wait for each bit, which can be very inefficient. OMAP_read: effectively the same as OMAP_write(), only reading. Again, should I really be expecting bits, or can I assume byte returns? This sends "1" bits and reads the bus to see if a device is driving it low. 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. Correct. The algorithm listed has a bit of loop unrolling to send/read three bits at a time. Some devices, (the LINK and the USB adapter) do this entirely in hardware. OMAP_level: does not seem to do much of anything; more or less copied from the serial adaptor. Right. The DS2480B has a complicated state machine that cares about "level". This is effectively bypassed for all the other adapters. OMAP_PowerByte: sounds fancy, but I cannot work out the purpose of it. Calls OMAP_send_data(), switches level, waits, then calls OMAP_level(). Again, some adapters have a specific software sequence to send a bit and leave the bus in the high state. For the passive adapter, this is the natural process. OMAP_ProgramPulse: does not do anything right now; neither the DS9097 nor DS9490 seem to support it. Correct. It needs to switch to 12V. 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? This is a higher level command. Some adapters can use this level, others have to bit-bang the interface. 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. pn->sn is the serial number pn->dev is a pointer to the device type (DS2401 or whatever). 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. Right. Most writing to the bus will use this. The check is to confirm the bus is not noisy. 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 any
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)...
On Tue, 2005-07-12 at 09:32 +1000, Matthew Percival wrote: > 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. > I suggest you start it with --foreground anyway... and put in in the background with & just to keep the error messages to your terminal. Or why not using owhttpd?? Then you could make some experiments without having fuse as an error source. > owhttpd --foreground --error_level=9 --error_print=2 -p -o /dev/wire & > lynx -source http://192.168.1.2:/text/uncached/ 10.A2284800 DS18S20 "1-wire chip" 10.E2C746000800 DS18S20 "1-wire chip" 1F.CCF20100 DS2409 "1-wire chip" 10.1A9246000800 DS18S20 "1-wire chip" 10.061847000800 DS18S20 "1-wire chip" 10.E54347000800 DS18S20 "1-wire chip" 10.4D8746000800 DS18S20 "1-wire chip" 10.6D015800 DS18S20 "1-wire chip" 10.5D1947000800 DS18S20 "1-wire chip" 10.233B4800 DS18S20 "1-wire chip" 10.B3E166000800 DS18S20 "1-wire chip" 10.2BD346000800 DS18S20 "1-wire chip" FF.72020100 LCD "1-wire chip" alarm alarm "directory" simultaneous simultaneous "1-wire chip" > lynx -source http://192.168.1.2:/text/uncached/10.A2284800/temperature temperature 21.375 (Or using telnet locally from your board) > telnet 127.0.0.1 Trying 127.0.0.1... Connected to 127.0.0.1. Escape character is '^]'. GET /text/uncached/10.A2284800/temperature HTTP/1.0 200 OK Date: Tue, 12 Jul 2005 05:27:49 GMT Server: owhttpd Last-Modified: Tue, 12 Jul 2005 05:27:49 GMT Content-Type: text/plain temperature 21.375 Connection closed by foreign host. > > 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 -- Christian Magnusson <[EMAIL PROTECTED]> --- This SF.Net email is sponsored by the 'Do More With Dual!' webinar happ
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
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)...
On Mon, 2005-07-11 at 16:19 +1000, Matthew Percival wrote: > G'Day, > > 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. > Try "ls -l /mnt/1wire/uncached/" to force scanning the 1-wire bus every time. 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) If you start: owfs --foreground --error_level=9 --error_print=2 -o /dev/wire /mnt/1wire You should get lots of other debug-messages, and try accessing the /mnt/1wire/uncached/ directory and tell us how it looks like. 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. /Christian > 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 -- Christian Magnusson <[EMAIL PROTECTED]> --- 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)...
On Sunday 10 July 2005 10:52 pm, Matthew Percival wrote: > G'Day, > > Thanks for the suggestions: it has made things a lot easier to work > through! I had actually skipped those files (ow_ds9097.c, etc) assuming > they were 1-Wire devices, rather than adaptors --- I did not think I > would find anything useful in them. Was I ever wrong! > > I have written ow_omap.c as well as made a variety of additions to > other files here and there, and am now able to add `-o /dev/wire' to the > command line when I load owfs. When I mount owfs, I get bus.0/, and > when I cat the files in system/adapter/ I now get the information I > would expect to see. I do not, however, get any devices in bus.0/ --- > obviously I am still lacking something. I assume you've altered ow_opt for special parameters and configuration for your adapter type, and added the adapter type to the enum. > > My first, key, question is this: where does the actual polling for > devices occur, and what do I have to ensure I do/have to be able to get > it to at least recognise the existence of the device? Polling uses the 1-wire protocol search routine. Some devices do it in hardware, others (like the 9097) set the bus powered and unpowered for the requisite time. The 9097 is a little tricky, the baud rate is changed for the reset command, and then changed back so that individual bits are at the right speed for 1-wire. I'm afraid you're going to have to read the 1-wire Application Notes. Suggestions: Look at code for the PIC microprocessor (it's sufficiently low-level, I think) http://www.maxim-ix.com/appnots.cfm/appnote_number/2420 Using a serial port: http://www.maxim-ix.com/appnots.cfm/appnote_number/214 And the search algorithm: http://www.maxim-ix.com/appnots.cfm/appnote_number/187 The reset command is essential, it effectively resets the bus and starts the next transaction. Reset and bit write/read (read is writing a "1" and reading if the bus actually stays high) are the essential commands. The search/select command can be made from these smaller parts (though accelerated by hardware in some adapters). > > Secondly, I currently have `f->reset' set to a dummy function, as I was > not sure what the purpose of this was, and if it really applied to my > device at all. If someone could just tell be the basic purpose of this > function, I will be able to work out what to do with it. > > Thanks for the help again: I feel I am on the verge of being able to > see my device, and it is entirely due to the assistance here! > > -- 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 --- 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)...
On Mon, 2005-07-11 at 04:52, Matthew Percival wrote: > 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 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. > > Sounds great. > > > > > > 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. > > Pretty easy. You are right, the adapter support is quite well encapsulated. > > > > Basically all adapter support is in owlib, and transparent to higher levels. > > > > The type of adapter is determined mainly from the command line (though the > > serial adapters are distinguished by their response to a query). > > > > Unique support is in the files > > > > module/owlib/src/c/* > > > > where * is ow_ds1410.c > > ow_ds9097.c > > ow_ds9097U.c > > ow_ds9490.c > > > > (also ow_server.c and ow_badadapter.c) > > > > I would base my support on ow_9097.c which is a bit-banging passive serial > > support. > > Thanks for the suggestions: it has made things a lot easier to work > through! I had actually skipped those files (ow_ds9097.c, etc) assuming > they were 1-Wire devices, rather than adaptors --- I did not think I > would find anything useful in them. Was I ever wrong! > > I have written ow_omap.c as well as made a variety of additions to > other files here and there, and am now able to add `-o /dev/wire' to the > command line when I load owfs. When I mount owfs, I get bus.0/, and > when I cat the files in system/adapter/ I now get the information I > would expect to see. I do not, however, get any devices in bus.0/ --- > obviously I am still lacking something. > > My first, key, question is this: where does the actual polling for > devices occur, and what do I have to ensure I do/have to be able to get > it to at least recognise the existence of the device? 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. 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) 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. /Christian > > Secondly, I currently have `f->reset' set to a dummy function, as I was > not sure what the purpose of this was, and if it really applied to my > device at all. If someone could just tell be the basic purpose of this > function, I will be able to work out what to do with it. > > Thanks for the help again: I feel I am on the verge of being able to > see my device, and it is entirely due to the assistance here! > > -- 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 --- 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 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. > Sounds great. > > > > 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. > Pretty easy. You are right, the adapter support is quite well encapsulated. > > Basically all adapter support is in owlib, and transparent to higher levels. > > The type of adapter is determined mainly from the command line (though the > serial adapters are distinguished by their response to a query). > > Unique support is in the files > > module/owlib/src/c/* > > where * is ow_ds1410.c > ow_ds9097.c > ow_ds9097U.c > ow_ds9490.c > > (also ow_server.c and ow_badadapter.c) > > I would base my support on ow_9097.c which is a bit-banging passive serial > support. Thanks for the suggestions: it has made things a lot easier to work through! I had actually skipped those files (ow_ds9097.c, etc) assuming they were 1-Wire devices, rather than adaptors --- I did not think I would find anything useful in them. Was I ever wrong! I have written ow_omap.c as well as made a variety of additions to other files here and there, and am now able to add `-o /dev/wire' to the command line when I load owfs. When I mount owfs, I get bus.0/, and when I cat the files in system/adapter/ I now get the information I would expect to see. I do not, however, get any devices in bus.0/ --- obviously I am still lacking something. My first, key, question is this: where does the actual polling for devices occur, and what do I have to ensure I do/have to be able to get it to at least recognise the existence of the device? Secondly, I currently have `f->reset' set to a dummy function, as I was not sure what the purpose of this was, and if it really applied to my device at all. If someone could just tell be the basic purpose of this function, I will be able to work out what to do with it. Thanks for the help again: I feel I am on the verge of being able to see my device, and it is entirely due to the assistance here! -- 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)...
On Thursday 07 July 2005 09:50 pm, Matthew Percival wrote: > 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. > Since I don't have a DS2431 device, you will have to tell me if it works with OWFS in a more traditional environment. OWFS should see all devices, even if explicit support hadn't been added. You would get only a minimal functionality, however (serial number, essentially), so I wonder if there isn't a electrical problem. > 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. Ok. > > 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. Sounds great. > > 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. Pretty easy. You are right, the adapter support is quite well encapsulated. Basically all adapter support is in owlib, and transparent to higher levels. The type of adapter is determined mainly from the command line (though the serial adapters are distinguished by their response to a query). Unique support is in the files module/owlib/src/c/* where * is ow_ds1410.c ow_ds9097.c ow_ds9097U.c ow_ds9490.c (also ow_server.c and ow_badadapter.c) I would base my support on ow_9097.c which is a bit-banging passive serial support. You'll notice that one of the first commands is DS9097_setroutines which sets pointers to adapter-specific functions like read, write, reset, next_both (search routine), and sendback_data (which sends bits and returns the response). > > 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. > so can you send a bit and see the response? Can you reset? can you set power-on (for conversion?) That's enough! > 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? Glad to help you and include 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
[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
