memory position of numpy arrays
david at ar.media.kyoto-u.ac.jp
Thu Oct 26 05:08:05 CDT 2006
Lars Friedrich wrote:
> thanks for your comments.
> Am Mittwoch, den 25.10.2006, 11:28 +0900 schrieb David Cournapeau:
>> Andrew Straw wrote:
>>> David Cournapeau wrote:
>>>> I don't know anything about your device, but a driver directly accessing
>>>> a memory buffer from a userland program sounds like a bug to me.
>>> David, DMA memory (yes, I know thats an example of RAS Syndrome,
>>> apologies) allows hardware to fill a chunk of RAM and then hand it over
>>> to a userspace program. In my experience, RAM used for this purpose must
>>> be pre-allocated, usually in a ring-buffer type arrangement. So this is
>>> normal operating procedure for something like a frame grabber and not a
>>> bug at all.
>> What I understood from former emails was that the user is allocating a
>> memory buffer, and that it gives this memory buffer to the hardware. In
>> this sense, I don't see how it is possible to avoid kernel panic or
>> equivalents. If on the contrary, the driver gives you the memory buffer,
>> then, ok, by eg a mmap-like call, you can access directly the device
>> memory, but within a range fixed by the driver, which is valid if the
>> driver is not buggy.
> The API of the camera provides a function
> pl_exp_start_cont(hCam, buffer, size)
> The usage is to pass a Camera-Identifier "hCam", a pointer "buffer" and
> a size "size" in bytes. The camera will then start to acquire frames and
> put them to the buffer, which has to be size-bytes long. When the
> function reaches the end of the buffer, it will start at the beginning
> again (circular buffer mode). There is also a function available to ask
> for the last buffer position that is written to. The buffer has to be
> allocated by the caller of this API-function, so I guess it will be in
In this case, I think the data are copied from the device to your buffer.
> To have enough time to read a frame, the buffer has to be sufficiently
> big. I don't know what is sufficient, but I made it 50 frames big. With
> an acquisition time of lets say 10ms I have about 0.5seconds to get a
> frame, that was recently written to the buffer.
You have no way to check if the ringbuffer is full or not ? In audio
programming under linux, what happens normally is that you have a ring
buffer locked in memory (that is cannot be paged out), and you need to
check if your read/write pointers overlap to detect a buffer overrun.
> I know, these things are not numpy and even not Python-questions, but
> C-questions, and I think I should go and read something about it. Does
> anyone have a recommendation where to find information on this
> memory-locking things? How is this kind of programming called?
> Driver-Programming? Hardware-Programming? System-Programming?
Real time programming, maybe ? Without a knowledge of the API of your
device, it is hard to know what the problem is for me.
By the way, I found the information about locking pages into memory for
It may not work as expected, though, as it happens quite often with
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
More information about the Numpy-discussion