[prev in list] [next in list] [prev in thread] [next in thread] 

List:       owfs-developers
Subject:    Re: [Owfs-developers] a couple things
From:       Paul Alfille <palfille () earthlink ! net>
Date:       2005-05-02 1:14:31
Message-ID: 200505012114.32489.palfille () earthlink ! net
[Download RAW message or body]

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
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
[prev in list] [next in list] [prev in thread] [next in thread]