DCMI description

The DCMI comprises up to 17 inputs. Depending on the number of data lines enabled by the user (8, 10, 12, or 14), the number of the DCMI inputs varies (11, 13, 15, or 17 signals).

If less than 14-bit data width is used, the unused pins must not be assigned to the DCMI through GPIO alternate functions. The unused input pins can be assigned to other peripherals.

In the case of embedded synchronization, the DCMI needs only nine inputs (eight data lines and DCMI_PIXCLK) to operate properly. The eight unused pins can be used for GPIO or other functions.

Figure 16 DCMI signals shows the DCMI signals.

If x-bit data width is chosen (x data lines are enabled, x = 8, 10, 12, or 14), x bits of image (or video) data are transferred each DCMI_PIXCLK cycle, and packed into a 32-bit register.

Figure 17 DCMI block diagram: example of 12-bit data width shows the four main DCMI components.

• The DCMI synchronizer ensures the control of the ordered sequencing of the data flow through the DCMI. It controls the data extractor, the FIFO, and the 32-bit register.
• The data extractor ensures the extraction of the data received by the DCMI.
• The 4-word FIFO is implemented to adapt the data rate transfers to the AHB. There is no overrun protection to prevent data from being overwritten if the AHB does not sustain the data transfer rate. In case of overrun or errors in the synchronization signals, the FIFO is reset, and the DCMI waits for a new start of frame.
• A 32-bit data register where the data bits are packed for transfer through a general-purpose DMA channel. The placement of the captured data in the 32-bit register depends on the data width:
  • For an 8-bit data width, the DCMI captures the eight LSBs (the six other inputs D[13:8] are ignored). The first captured data byte is placed in the LSB position in the 32-bit word, and the fourth captured data byte is placed in the MSB position. In this case, a 32-bit data word is made up every four pixel clock cycles. For more details, see Data formats and storage.

    

  • For a 10-bit data width, the DCMI captures the 10 LSBs (the four other inputs D[13:10] are ignored). The first 10 bits captured are placed as the 10 LSBs of a 16-bit word. The remaining MSBs in the 16-bit word of the DCMI_DR register (bits 10 to 15) are cleared. In this case, a 32-bit data word is made up every two pixel clock cycles.

    

  • For a 12-bit data width, the DCMI captures the 12-bit LSBs (the two other inputs D[13:12] are ignored). The first 12 bits captured are placed as the 12 LSBs of a 16-bit word. The remaining MSBs in the 16-bit word of the DCMI_DR register (bits 12 to 15) are cleared. In this case, a 32-bit data word is made up every two pixel clock cycles.

    

  • For a 14-bit data width, the DCMI captures all the received bits. The first 14 bits captured are placed as the 14 LSBs of a 16-bit word. The remaining MSBs in the 16-bit word of the DCMI_DR register (bits 14 and 15) are cleared. In this case, a 32-bit data word is made up every two pixel clock cycles.

    

The DCMI_PIXCLK and AHB clocks must respect the minimum ratio AHB/DCMI_PIXCLK of 2.5.

Some camera modules support the two types of synchronization, while others support either the hardware or the embedded synchronization.

The polarities of the DCMI_PIXCLK and the synchronization signals (DCMI_HSYNC and DCMI_VSYNC) are programmable.

Data are synchronized with DCMI_PIXCLK, and change on the rising or falling edge of the pixel clock, depending on the configured polarity.

If the DCMI_VSYNC and DCMI_HSYNC signals are programmed active level (active high or active low), the data is not valid in the parallel interface when VSYNC or HSYNC is at that level (high or low).

The DCMI_HSYNC and DCMI_VSYNC signals act like blanking signals, since all data received during DCMI_HSYNC/DCMI_VSYNC active periods are ignored.

Figure 23 Frame structure in hardware synchronization mode shows an example of data transfer when DCMI_VSYNC and DCMI_HSYNC are active high, and when the capture edge for DCMI_PIXCLK is the rising edge.

In this case, delimiter codes are used for synchronization. These codes are embedded within the data flow to indicate the start/end of line or the start/end of frame.

The codes eliminate the need for DCMI_HSYNC and DCMI_VSYNC to signal the end/start of the line or the frame. When this synchronization mode is used, there are two values that must not be used for data: 0 and 255 (0x00 and 0xFF). These two values are reserved for data identification purposes. It is up to the camera module to control the data values. Image data can then have only 254 possible values (0x00 < image data value < 0xFF).

Each synchronization code consists of 4-byte sequence 0xFF 00 00 XY (as shown in Figure 24 Embedded code bytes), where all delimiter codes have the same first 3-byte sequence 0xFF 00 00. Only the final one 0xXY is programmed to indicate the corresponding event.

This mode is ITU656 compatible (ITU656 is the digital video protocol ITU-R BT.656).

Figure 25 Frame structure in embedded synchronization mode 1 illustrates the frame structure using this mode.

A 0xFF value programmed as a frame-end (FE) means that all the unused codes (the possible values of codes other than FS, LS, LE) are interpreted as valid FE codes.

In this mode, once the camera interface has been enabled, the frame capture starts after the first occurrence of an FE code followed by an FS code.

Figure 26 Frame structure in embedded synchronization mode 2 illustrates the frame structure when using this mode.

These codes are also used to signal start/end of a line or a frame. Thanks to these codes, instead of comparing all the received code with the programmed one to set the corresponding event, the user can select only some unmasked bits to compare with the bits of the programmed code having the same position.

There can be different codes for each event (line-start, line-end, frame-start, or frame-end) but all of them (the different codes corresponding to one event) have the unmasked bits in the same position (same unmask code).

Example: FSC = 0xA5 and unmask code FSU = 0x10 (as shown in Figure 27 Embedded code unmasking). In this case the frame-start information is embedded in the bit number 4 of the FS code. The user must compare only the bit number 4 of the received code with the bit number 4 of the programmed code, to know if it is a frame-start event or not.