RGB888 pixel data: disable zero-byte padding?

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

RGB888 pixel data: disable zero-byte padding?

2,725 Views
john_obendorfer
Contributor III

I am trying to capture RGB888 data via the MIPI-CSI2 link on an IMX8M.

I had to modify the mx6s_capture.c driver to set the PARALLEL24_EN bit in register CSIRC18 (otherwise all I got was bits 2-9 of each 24-bit pixel).  Setting the PARALLEL24_EN bit got me all 24 bits of the RGB888 pixels, but unfortunately it looks as though the CSI bridge is padding a zero byte onto each pixel, so that the pixels go from 24 bits wide to 32 bits wide.  That is, each 32-bit word in the bridge fifo contains a 24-bit RGB pixel with a zero byte added as padding.

The IMX7 reference manual states -- section 13.3.6.1.3 -- (for some bizarre reason, the CSI bridge is completely undocumented in the IMX8M manual, you *really* need to fix that)

...

An optional scheme to pack a dummy byte is provided. For every group of 3 bytes data, a

dummy zero is packed to form a 32-bit word as shown in the figure below. The dummy

zero can be packed at the LSB position or MSB position. Using

RGB888A_FORMAT_SEL in CSI_CSICR18[18] to determine to put the dummy bytes

packed at LSB or MSB position.

...

I see the bit in CSICR18 that controls *where* the zero byte gets added (lsb v msb), but I don't see any bit that stops the zero-byte padding altogether, as the first sentence in the above quote suggests. 

Is there a way to disable the zero-byte padding for RGB888 data?

Alternatively, is there any way to make the zero pad byte drop away when transferring data out of the bridge fifo?  (Other than software repacking the image data?)

Thanks,

John

0 Kudos
7 Replies

1,776 Views
Skeef
Contributor I

Hello All
Does the way exist to fill "dummy zero" by 0xFF while packing?
Thanks in advance for response

0 Kudos

2,299 Views
johncairns
Contributor I

I've run into the same issue with an i.MX6ULL.  So no MIPI, but same 24-bit CSI interface.  PARALLEL24_EN in CSI_CSICR18 is set, and TWO_8BIT_SENSOR in CSI_CSICR3 is unset.  I get exactly what john.obendorfer@cognex.com‌ reported:  the (correct) 3 bytes of RGB24 image data, with with a 0-byte added to pad every pixel out to 32 bits.  Most frustratingly, CSI_CSICR3 has a ZERO_PACK_EN bit that purports to enable/disable this exact feature, but does not:
pastedImage_1.png

Just for the sake of trying everything, I attempted to set that bit as well, but with no change in behavior.  The throughput advantage of the 24-bit input is useless if the resulting image data needs to be software-unpacked to remove the zero bytes.  Certainly there must be a way around this?

i.mx 6ull imx 6ull 6ull csi imx6 24-bit rgb888 rgb24 zero_pack_en #parallel24_en

0 Kudos

2,299 Views
1603354597
Contributor II

hi John

   Do you figure out this question? I have come across the same problem, and I did what you did before, but it does not work, is there some detials to pay attention to?

thanks,

wang

0 Kudos

2,299 Views
andreasgustafss
Contributor III

For anyone stumbling upon this thread.

You cannot receive packed RGB888 (RGB24) from the CSI-reciever on the IMX6/IMX7/IMX8.

See: https://community.nxp.com/message/1290681#comment-1300322 

What you have to do is enabling PARALLEL24_EN in CSIRC18 and receive the data as XBGR32.

1,532 Views
ilyakosharov
Contributor II

great thanks for this comment

0 Kudos

2,299 Views
john_obendorfer
Contributor III

Hi Wang,

Sorry, no.  We worked around the issue by going to an 8-bit pixel mode.

Regards,

John

0 Kudos

2,299 Views
joanxie
NXP TechSupport
NXP TechSupport

 if you use bsp 4.14.78, try to set CSICR3_TWO_8BIT_SESNSOR=0 and CSICR18.PARALLEL24_EN=1(you should set it already)

0 Kudos