As most users might be aware, DLP LightCrafter4500 EVM and/or DLPC350 DLP controller supports pattern sequencing from either of the following input sources – 1) Images stored in flash memory 2) video port.
As documented in DLP LightCrafter4500 user’s guide section 4.1 on pattern sequences, when patterns are sourced from images stored in flash memory, the golden rule in order for the pattern sequence to work well is that sum_exposure must be greater than image_load_time
Where
Sum_exposure is the sum of exposure times of individual patterns contained in a given 24-bit image and
Image_load_time is the time it takes for the next 24-bit image to be loaded from flash to RAM.
DLP LightCrafter4500 GUI provides a control to measure the actual load time of each 24-bit image stored in flash under “Pattern Sequence” tab “Image Load timing” subtab (in version 3.0.0 of the tool). TI recommends that the actual load time of each image be measured using this tool in order to ensure that sum_exposure of each image is conforming to rule above.
Quite a number of Lightcrafter4500 users have expressed interest in knowing the various factors that influence the actual image load time. Some others are interested in being able to compute/predict the load time for an image without having to actually load it on the EVM and measuring it using the GUI tool. They like to use this information for getting a ball park estimate of the pattern rates that they can achieve for a given set of flash images.
This article discusses those factors that affect the compression of flash images and resultant load times.
Fastest pattern rate:-
A pattern sequence that uses a maximum of 2 24-bit images from flash can support the fastest pattern rate. Such a sequence can have use a total of <=48 bits. 48 1-bit patterns, or 6 8-bit patterns or any such combination of patterns that adds up to a total of <=48 bits. In this case, patterns are pre-loaded from flash to DLPC350 internal RAM upfront and once loaded individual patterns can be displayed at the fastest rate independent of the pattern load time (1-bit at 4225hz; 8-bit at 120hz; see datasheet for more).
When total number of bits > 48; and thus need to use more than 2 24-bit images from flash:-
1) If patterns used are like the one shown below, where intensity/bit/color varies in the X-direction, but the pattern is identical in the Y direction, that is row0, row1….., row1140 are all identical –
- In this case compression stores only row0 and decompression replicates row0 to form 1140 rows. (If you are using the GUI to create flash image, GUI automatically chooses this compression if all rows are identical).
- Compressed image size is very small and does not vary much based on the pattern content.
- For such images, load time is relatively constant and is about 100ms. The constant part of load time is very large compared to flash speed dependent variable part.
- When flash access time was increased from 100ns to 200ns, the typical load time only increased from 100ms to 110ms for such images.
- 100ms load time will translate to 30 8-bit patterns per second.
2) If patterns used are not made up of identical rows as shown below –
- In this case RLE compressed bitmaps are stored in flash. The size of compressed image will vary dependent on the pattern.
- Load time (of each 24-bit pattern from flash) will be directly proportional to the compressed image size.
- Load time will also be proportional to the flash access time.
If
B is the size of compressed image in bytes and
Tns is the flash read access time in nanoseconds,
A further note on Tns:- The read access time is different for different flash parts and is specified in their datasheet. Ideally, the DLPC350 firmware should be changed to program the flash read access to match with the flash part being used. However, until the latest release (v3.0) the DLPR350PROM or the firmware does not provide a command interface to configure the flash read wait states; instead it is fixed at 100ns. So one should assume Tns=100 for all practical purposes. But actual flash Tns will tell you the actual best case load time possible. Please approach TI with a request to optimize the flash access time if you think that will be huge for your project.
Then approximate load time of such an image from flash to RAM in milliseconds TLoadMs is
TLoadMs = 65 + ( (B/2) * (Tns + 13.334)) / (1000000 * 0.6) )
Here,
The constant factor 65ms is coming from the software overheads and set up times which is independent of flash access time,
B/2 because flash is read 16-bits (2 bytes) per access,
The constant 13.334 nanosecond needs to be added to the flash read access time due to a constant additional access overhead,
The factor of .6 is because 60% happens to be the slice of time that the flash DMA is getting access to the flash bus.
So the above equation will evaluate to a load time of approx. 360ms for a full uncompressed image of 912x1140x3 bytes (2.88 MB) on a 100ns flash, 310ms for a 2.4MB compressed image size, 150ms for a 1.18MB image and so on…
Please bear in mind that the actual load time for a given image (which can be measured using the GUI tool) may differ from the above estimate by 5-10%. The above equation may be used for a quick estimation of achievable pattern speeds, however it is recommended that the actual load time be measured using the GUI and the EVM before deciding the final pattern rates and exposure times.
The above equation is derived from a limited set of data points involving 10 different image sizes and 3 different flash access times. Below I have given the test images, their size, flash access times and corresponding measured and computed image load times..
Image |
Size (bytes) |
Measured Load Time (ms) |
Access time (ns) |
Computed load time |
LCr4500_splash |
483360 |
110 |
100 |
110.6509352 |
LCr_H |
138752 |
80 |
100 |
78.10443264 |
LCr_V |
46656 |
80 |
100 |
69.40642592 |
Emorro_35 |
1448288 |
215 |
100 |
201.7835602 |
color_ramp |
1245696 |
150 |
100 |
182.6497587 |
Emorro_15 |
442032 |
110 |
100 |
106.7477122 |
ElMorro |
3021184 |
360 |
100 |
350.3357229 |
ElMorro_25 |
1360432 |
200 |
100 |
193.4860002 |
ElMorro_half |
1988640 |
260 |
100 |
252.8171048 |
ElMorro_75 |
2517056 |
310 |
100 |
302.7233539 |
LCr4500_splash |
483360 |
100 |
70 |
98.5669352 |
LCr_H |
138752 |
80 |
70 |
74.63563264 |
LCr_V |
46656 |
80 |
70 |
68.24002592 |
Emorro_35 |
1448288 |
170 |
70 |
165.5763602 |
color_ramp |
1245696 |
115 |
70 |
151.5073587 |
Emorro_15 |
442032 |
105 |
70 |
95.69691224 |
ElMorro |
3021184 |
275 |
70 |
274.8061229 |
ElMorro_25 |
1360432 |
168 |
70 |
159.4752002 |
ElMorro_half |
1988640 |
200 |
70 |
203.1011048 |
ElMorro_75 |
2517056 |
240 |
70 |
239.7969539 |
LCr4500_splash |
483360 |
162 |
206 |
153.3477352 |
LCr_H |
138752 |
80 |
206 |
90.36085931 |
LCr_V |
46656 |
80 |
206 |
73.52770592 |
Emorro_35 |
1448288 |
374 |
206 |
329.7156668 |
color_ramp |
1245696 |
295 |
206 |
292.6862387 |
Emorro_15 |
442032 |
166 |
206 |
145.7938722 |
ElMorro |
3021184 |
700 |
206 |
617.2069762 |
ElMorro_25 |
1360432 |
360 |
206 |
313.6574936 |
ElMorro_half |
1988640 |
488 |
206 |
428.4803048 |
ElMorro_75 |
2517056 |
600 |
206 |
525.0633006 |