[Elphel-support] Documentation for RAW Images Requiered

[Andrey Filippov]

On Thu, Feb 10, 2011 at 12:55 PM, Marc Reichenbach  wrote:

> Dear Andrey,
>
> thank you very much for your anwser. The support ist great :)
>
> Please, let me ask one more question because, I think, I havn't
> understood the system architecture right. I thought the raw data goes
> trough sysinterface component to the CPU - but now, after your mail, I
> think, I get this wrong. Please tell me, if I got it right now:
>
> The data comes from the sensor (sensorpix353.v) and is raw stored in
> the memory (mcontr353.v).


 In 8-bit (normal) mode the data is still subject to optional scaling and
gamma-correction.



> Which memory is it in the Block Diagramm
> (http://wiki.elphel.com/index.php?title=File:10353bd.png) ? The memory
> on the top or the memory in the middel between the FPGA and the CPU?
> Get I it now right, that thats the memory in the middel, and after
> storing the raw image there, an acess is possible with the help of
> /dev/ccam_img and /dev/fsdram? If I get it now right, then I'm
> interestet in the memory in the top of the image. For which task is
> this memory used? For JPEG Compression?


No, that is a dedicated video memory, shown on top. Drivers access it
(normally - just for developing/testing) through the FPGA using memory
channel #3. The "second" (system, from the CPU point of view) only receives
compressed data over DMA. That memory buffer is accessible through
/dev/circbuf , currently ~19MB (of total 64) are used for circbuf



> And the second question is,
> which data is transmitted via the sysinterface?


sysinterface module (ther are some helper modules in the same file) is
designed to decode commands from the host access, process internal
addresses. In the 8.x software it combines the commands from the two sources
- directly from the CPU and from the command sequencer that has a 8-frame
buffer for up to 64 commands for each frame. These commands are executed
automatically after the frame sync from the sensor, this feature is used to
reduce real-time requirements to the software. Software can write some
registers ahead, the action will be performed at required frame. In this
mode only the lower 24 bits (of the 32) are available, so most registers do
not use the 8 MSB. It is so because when CPU writes to the sequencer, the 8
MSBs are used as the destination register address (retrieved when after the
appropriate frame sync pulse)

There is another 8 frames x 64 commands sequencer for the i2c commands that
are automatically sent to the sensor, that sequencer operates from the same
frame sync pulses.


First I though it is
> the raw image, but now I thing this interface is used for the
> compressed JPEG and other things for example sensor settings, color
> diagramms .... If this is right, is the JPEG image direct send to the
> CPU or is the image send to CPU via a memory. And you have spoken
> about DMA - from where to where is DMA used for which data?
>

DMA is used to send compressed JPEG/JP4 data from the FPGA to the system
memory. It is aligned to 32 byte pages (specifics of ETRAX operation),
additional 32 bytes are skipped between each frame (they are later used by
the software for some metadata used when sending the images from the circbuf
to the client (data structures are defined in c313a.h). FPGA provides the
complete bitstream and attach file size in bytes and timestamp data to it.



>
> I don't know, if more people have problems to get the system
> architecture right? Maybe you have a wiki page that I havn't found
> yet. If there is no wiki page for the system architecture it would be
> great to create one, because I think more people are interestet in. If
> I get the architecture completely, I can help to create, if you need
> it.
>
> Marc, that would be nice - we just do not have sufficient resources. The
top level description of the architecture (more features were added, but in
general it is similar) was in the old Xilinx Xcell article, it went offline,
but there is a copy at
http://www.linuxfordevices.com/files/misc/xc_freesw46.pdf

Marc, do you have 10359 board? It has exactly the same FPGA and memory as
the system board. It should be much easier to experiment with raw sensor
data with it than with the FPGA on the system board. The main board FPGA is
by now very interconnected with the software, it uses much of the FPGA
resources (esp. BRAMs), matching the timing constraints can be difficult,
re-running P&R takes long time. So if you need some major development I
would recommend to use teh 10359 board, possibly moving the result code to
the main FPGA when finished. If the code has universal application it may
make sense to include it into the code tree otherwise you'll have to rebuild
the code each time we update the FPGA.




> Thanks again for you efforts and the great camera,
>
> Marc Reichenbach
>

Thank you, Marc

Andrey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://support.elphel.com/pipermail/support-list_support.elphel.com/attachments/20110210/2d917584/attachment-0002.html>