On Sunday 01 May 2005 09:02 pm, jerry scharf wrote: > --On 05/01/2005 04:12:27 PM -0400 Paul Alfille wrote: > > On Sunday 01 May 2005 01:36 pm, jerry scharf wrote: > >> Well, > >> > >> I got my link serial interfaces, and started playing with things. > >> > >> Things came up in a couple areas: > >> > >> First, the programs seem to ignore --foreground and go to the background > >> no > > > > Hmm.. works for me. /opt/owfs/bin/owfs --foreground -u /mnt/1wire stays > > in foreground. > > I'm running fedora fc3, no option on configure or build. > > joke: How does a wordperfect (or whatever) customer support person change a > lightbulb? "We have an exact copy of your lightbulb, and ours is working > perfectly." > Perhaps it's a quantum lightbulb?
--foreground really goes into background? Gives up the console? I just tested several combinations, 1. owfs(fg) 2. owserver(fg)/owfs(fg) 3 owserver(fg)/owfs(bg) 4 owserver(bg)/owfs(fg) 5 owserver(bg)/owfs(bg) all work. > >> matter what. Second, there is no debugging output for owfs or owserver. > >> This seems quite wrong to me. I would like to do the classic multiple > >> levels of d or v switches to be able to run the program with different > >> levels of output and see what it's doing. For example, I had the > >> protection set wrong on the tty, and the program silently exited. I have > >> another one where I'm trying to get it onto an arm system with a cross > >> compiled environment. Again the program exits silently, and I have no > >> idea what's wrong. I may end up making one of the SBCs into a devel > >> system and scrap the cross compiler (makes configure a mess...), but I > >> should be able to debug the program to a limited degree with just > >> itself. I am happy to discuss this more, but I am not up to adding this. > > > > I just checked. There should be syslog messages about opening the com > > port. > > > > You're right about the debug messages, though with a working foreground, > > it's easy to trace problems (I use printfs myself). Actually, there are > > no end of printfs scatered around that can be uncommented. I know it's > > not elegant, what kind of debugging output would you like, specifically? > > Let's say you have 3 levels of debugging. One -v sets it to level 1, 2 to > level 2 and 3 or more to level 3. Here are kind of what I was thinking of > for the levels. Since there is no general stdin/stdout/stderr usage, you > can just use stdout for all the messages. > > In level one, major section entry and exit is printed: > Initializing data structures > opening each bus > setting up fuse > got a read/write > printout of all exception events > > Level two adds > steps for opening each bus > initial bus scan > details of each read/write request > caching hits > copious detail on each exception > > level 3 adds the data sent to and from the serial bus or tcp port, cache > checking details, etc. > I like it. I guess it's time to add proper error/debug functions with levels and output to stdio/syslog depending on calling mode. > >> The other major area is that I wanted to try to compile the program > >> without pthreads for the sbc, figuring that I didn't need it. There were > >> a number of problems in files from owlib, clearly this hasn't been tried > >> in a while. I'm not a great coder, but the changes are minimal. I'll > >> attach diffs in a separate message for what I found. > > I tried without pthreads just to make the porting to the SBC as simple as > possible. There may be some speed improvements, but debugging is why I did > it. I always turn off threading if possible when I start these kind of > things. 1 copy of owserver with 1 remote owserver talking to it is probably > 30% of the total load on a 200MHz ARM9 computer, so I don't think cycles > will be in short supply. > > >> I haven't gotten to the simultaneous reads yet. I would like to make > >> sure that the cache invalidation has been added when simultaneous is > >> set. My first tests for that will be calibration, which included adding > >> groups of sensors on the net in the same conditions and getting offsets > >> from a precise measurement. It's a pretty simple strategy for handling a > >> large number of common sensors. > >> > >> thanks, > >> jerry > >> > >> Jerry Scharf > >> laguna way consulting > >> > >> ------------------------------------------------------- This SF.Net email is sponsored by: NEC IT Guy Games. Get your fingers limbered up and give it your best shot. 4 great events, 4 opportunities to win big! Highest score wins.NEC IT Guy Games. Play to win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 _______________________________________________ Owfs-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/owfs-developers
