From MAILER-DAEMON@midway.uchicago.edu  Mon Jun  2 02:39:07 2003
From: MAILER-DAEMON@midway.uchicago.edu (Mail Delivery Subsystem)
Date: Sun, 1 Jun 2003 20:39:07 -0500 (CDT)
Subject: [pxc] Returned mail: see transcript for details
Message-ID: <200306020139.h521d7uY008077@midway.uchicago.edu>

This is a MIME-encapsulated message

--h521d7uY008077.1054517947/midway.uchicago.edu

The original message was received at Sun, 1 Jun 2003 20:39:07 -0500 (CDT)
from palevsky-221-007.rh.uchicago.edu [128.135.221.7]

   ----- The following addresses had permanent fatal errors -----
<lory@midway.uchicago.edu>
    (reason: 550 5.1.1 <lory@plaisance.uchicago.edu>... User unknown)
    (expanded from: <lory@midway.uchicago.edu>)

   ----- Transcript of session follows -----
... while talking to plaisance.uchicago.edu.:
>>> DATA
<<< 550 5.1.1 <lory@plaisance.uchicago.edu>... User unknown
550 5.1.1 <lory@midway.uchicago.edu>... User unknown
<<< 503 5.0.0 Need RCPT (recipient)

--h521d7uY008077.1054517947/midway.uchicago.edu
Content-Type: message/delivery-status

Reporting-MTA: dns; midway.uchicago.edu
Received-From-MTA: DNS; palevsky-221-007.rh.uchicago.edu
Arrival-Date: Sun, 1 Jun 2003 20:39:07 -0500 (CDT)

Final-Recipient: RFC822; lory@midway.uchicago.edu
X-Actual-Recipient: RFC822; lory@plaisance.uchicago.edu
Action: failed
Status: 5.1.1
Remote-MTA: DNS; plaisance.uchicago.edu
Diagnostic-Code: SMTP; 550 5.1.1 <lory@plaisance.uchicago.edu>... User unknown
Last-Attempt-Date: Sun, 1 Jun 2003 20:39:07 -0500 (CDT)

--h521d7uY008077.1054517947/midway.uchicago.edu
Content-Type: message/rfc822

Return-Path: <Pxc@lists.prosa.it>
Received: from COURTNEY (palevsky-221-007.rh.uchicago.edu [128.135.221.7])
	by midway.uchicago.edu (8.12.9/8.12.9) with ESMTP id h521d1ua007966
	for <lory@midway.uchicago.edu>; Sun, 1 Jun 2003 20:39:07 -0500 (CDT)
Message-Id: <200306020139.h521d1ua007966@midway.uchicago.edu>
From: <Pxc@lists.prosa.it>
To: <lory@midway.uchicago.edu>
Subject: Re: 45443-343556
Date: Sun, 1 Jun 2003 20:39:01 --0500
Importance: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MSMail-Priority: Normal
X-Priority: 3 (Normal)
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="CSmtpMsgPart123X456_000_00098D96"

This is a multipart message in MIME format

--CSmtpMsgPart123X456_000_00098D96
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Please see the attached file.
--CSmtpMsgPart123X456_000_00098D96--



--h521d7uY008077.1054517947/midway.uchicago.edu--


From lmejias@etsii.upm.es  Tue Jun  3 17:00:51 2003
From: lmejias@etsii.upm.es (Luis Mejias)
Date: Tue, 03 Jun 2003 12:00:51 -0400
Subject: [pxc] pxc reading frames
Message-ID: <3EDCC633.5F81E461@etsii.upm.es>

Hi i'm using two frame grabbers PC104+, stacked in a embedded system.
And my question is if possible to  acquire images in 20fps? i have a
simple loop reading PAL images and I can't read it below 40 ms (low
resolution images).

Thanks !!


From lmejias@etsii.upm.es  Tue Jun  3 12:34:28 2003
From: lmejias@etsii.upm.es (Luis Mejias)
Date: Tue, 03 Jun 2003 13:34:28 +0200
Subject: [pxc] pxc reading frames- correction
References: <3EDCC633.5F81E461@etsii.upm.es>
Message-ID: <3EDC87C4.7E0C85E1@etsii.upm.es>

Sorry!!!  i have to give excuse for the last email: is clear to read PAL
frames in 25fps, so 1 frame in 40ms

I really want to know if there are any possibility of grab the images in
a non-interlaced manner in the frame buffer,  of way,   of read just 1
field in 20 ms (without wait for the second one), instead of read the
entire frame and spent 40 ms to read it.

Thanks!!!!


Luis Mejias escribió:

> Hi i'm using two frame grabbers PC104+, stacked in a embedded system.
> And my question is if possible to  acquire images in 20fps? i have a
> simple loop reading PAL images and I can't read it below 40 ms (low
> resolution images).
>
> Thanks !!
>
> _______________________________________________
> pxc mailing list
> pxc@lists.linux.it
> http://lists.linux.it/listinfo/pxc


From rubini@ar.linux.it  Tue Jun  3 16:01:14 2003
From: rubini@ar.linux.it (Alessandro Rubini)
Date: Tue, 3 Jun 2003 17:01:14 +0200
Subject: [pxc] pxc reading frames- correction
In-Reply-To: <3EDC87C4.7E0C85E1@etsii.upm.es>
References: <3EDC87C4.7E0C85E1@etsii.upm.es>
Message-ID: <20030603150114.GA6206@gnudd.com>

Hello.

> I really want to know if there are any possibility of grab the images in
> a non-interlaced manner in the frame buffer,  of way,   of read just 1
> field in 20 ms (without wait for the second one), instead of read the
> entire frame and spent 40 ms to read it.

Early versions of the driver delivered whatever field was available at
time of reading. Then I fixed this misbehaviour, and now you always
get the same field (always even, or always odd, I don't
remember). This feature is required for many motion detection
applications, to avoid the half-pixel flickering.

>From comments in dma.c::px_write_dma_program it looks like this fix
was contributed by Chanop Silpa-Anan.

Please note that you can change the behaviour, but it's not completely
trivial. With the redesigned (and much better) buffer-management
introduced some time ago, each and every buffer has the same DMA
program, and the next buffer to be used is selected on an
image-by-image basis. If you want both even end odd buffers, you need
slightly different DMA programs for the two of them, thus making it
difficult the run-time selection of the next buffer.

Every problem is solvable, but this is not a trivial one, actually.

/alessandro
-- 
Alessandro Rubini, free software specialist.
Device drivers, embedded systems, courses.
http://ar.linux.it/

