This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

DLP2000: structured light code continues to run, but the evm doesn't update with new images?

Part Number: DLP2000
Other Parts Discussed in Thread: DLPC2607

Hello, 

In the continuing string of questions I have related structured light code here is another one. 

I'm still using the structured light code with the dlp2607 controller and dlp2000 DMD. I"m utilizing 24bit  black and white images, that project a single bar, being utilized as a mask. The current code that I'm using. 

for (; i < num_images; i++)
		{

			if(!not_finished)
				break; 

	        // Transfer image structure to the buffer
			for (y = 0; y < y_max; y++) {
				for (x = 0; x < x_max; x++) {
					location = (x + var_info->xoffset) * (var_info->bits_per_pixel / 8) + (y + var_info->yoffset) * fix_info->line_length; // offset where we write pixel value
					pix = pixel_color (img[i][y][x].r, img[i][y][x].g, img[i][y][x].b, var_info); // get pixel in correct format
					*((uint32_t*)(bbp + location)) = pix; // write pixel to buffer
				}
			}
			
			// Freeze update buffer. this is so it won't display garbage data as we update the framebuffer
			i2c_write(handle, freeze, 5);
			
			// Display image
			memcpy (fbp, bbp, screensize); // load framebuffer from buffered location
			
			usleep (35500); // allow framebuffer to finish loading
			
			i2c_write(handle, unfreeze, 5);
			
			usleep (24000); // allow DLP2000 to update

the sleep time for the load bufferframe and the sleep time for the DLP2000 update are the minimum wait times I can use before I start seeing splits issues with the images I'm displaying. 

The next part of the software uses gpio pins to determine when to move to the next frame. 

if( is_high(9, 23))
			{

				printf("Single Frame Mode\n");
				while (is_low(9, 25)){ 
					if(is_low(9, 23))
						break;
				}
				usleep(10000);
			}	
			else
			{

				if( is_high( 9, 25 ) & not_finished) // check if tx2 acquisition enable signal
				{

					sync = 0;

					if(DEBUG)
						printf("SYNC = %d\n", sync);

					toggle_gpio(1, 8, 8);  //toggle UTC camera trigger high then low
					
					while ( (sync < 3) && is_high(9, 25) ) // keep going while sync < 3 and TX2 is still enabling acquisition 
					{

						if ( is_high( 8, 10) & not_finished )
						{

							while( is_high(8, 10) ){}
							sync++;

							if(DEBUG)
								printf("SYNC = %d\n", sync);

							if( sync < 3)
								toggle_gpio(1, 8, 8);  //toggle UTC camera trigger high then low
						}
						else
						{
							break;
						}
						
					}

					if (DEBUG)
						printf("^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n");
				}
				else
				{
					break;
				}
			}

if I run the software roughly 10min or longer, the frames stop updating on the dmd. The loops and triggers continue to run just fine. I have a timer in the code, that tracks how long it takes to go through 40 frames. This way I can estimate the fps. Well the timer continues to update with no issues, but the image is locked on one frame and doesn't update as it is suppose to do. 

Does the device have a timeout or other such functionality that would cause the DMD or Controller to fail to load a new image? It is the same 40 images every time nothing changes. 

  • Hello Michael,

    The Beaglbone will consistently be sending data to the DLPC2607 at a given nominal frame rate. The program itself is just updating what the actual BeagelBone frame buffer. The frame buffer is updated at a slower, asynchronous rate. The freeze commands are used to essentially make it appear as if the actual DMD is updating at the program's frame rate. 

    Therefore, I don't expect any timeout to be related to the DLPC2607 as long as the Beagle is consistently sending periodic video. This could be confirmed by probing VSYNC between the two boards. As long as the VSYNC is consistent, the source of the freeze would be on the program's side.

    Thanks,

    Kyle

  • Kyle, 

    Hi hope you had a nice holiday season. Thanks for getting back to me. How would I go about looking at VSYNC to see if there is an issue there. 

    One thing I want to add is, as soon as I reset the software I'm able to pick up where I left off. part of that is re-enabling lightmd services. 

    My next step is to put a break in about the 10 min mark, and do some tests like re-enable lightmd and disable it again. See if I see any changes there. Of course I would do this across the board with different processes of the code. To see if there's a specific point where I get a success after the changes. 

    there's obviously a lot more happening before I get to this point in the software, such as memory mapping the buffers and what not. So I would probably address those as well. To see if any of those clear things up. 

    Michael

  • Kyle, 

    So I did the reset of the lighdm service, I shutdown the desktop manager and then start it back up. My hunch was correct, something that occurs in the process of turning the DM back on, and shutting it back down allows the software to run continuously. Previously the software would fail about the 9min mark. Currently I've been running the software for roughly an hour. 

    So if its a time issue, could it be that something else is looking for the DM, and causing issues cause its shutdown?

    Or is it more likely, I'm causing a memory overflow on a buffer somewhere, that gets cleared with the reset of the DM? 

    Any ideas?

    Michael

  • Hi Michael,

    I am unsure. It is possible there's a memory leak but you may want to try checking with a BeagleBone or Linux forum. Unfortunately we are unable to provide additional assistance on this aspect.

    Thanks,

    Kyle