• State TI Thinks Resolved
  • Locked Locked
  • Replies 19 replies
  • Answers 3 answers
  • Subscribers 29 subscribers
  • Views 640 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

DLPNIRNANOEVM: Self generated pattern

Cedrick
Expert 8270 points
Part Number: DLPNIRNANOEVM
Other Parts Discussed in Thread: DLPC150

Hi,

Good day.

Our customer is using the DLPNIRNANOEVM and they have the following questions:

1. About the NIRscanNano. My main goal is to upload self-generated patterns onto the DMD using this system.
I followed the compiling procedures on your user manual with the right versions: CCS v6.0.1, ARM 5.2.4,.... and at last I should be compiling the 'SPECTROSCOPY Tiva EVM' project with the 'dlpspeclib' project and the final .bin file generated ended up in the Release folder 'C:\ti\DLPNIRscanNanoSoftware_2.1.0\Sources\Release\NIRscanNano.bin'.
Would that be the file I should be using for the Tiva Firmware update in the GUI utilities?

2. And another question about the code itself. In this function: dlpspec_scan_col_genPatterns, for line 76 to 83, am I able to just change the the rect.height = frameBuffer.height to rect.height = frameBuffer.height/2 so that the whole column height would be half of what it is previously generating? (The original code is shown below)

//Guard against rectangles drawn out of the left bound of the frame
if((patDefCol->colMidPix[i] - patDefCol->colWidth/2) < 0)
rect.startX = 0;
else
rect.startX = patDefCol->colMidPix[i] - patDefCol->colWidth/2;
rect.startY = 0;
rect.height = frameBuffer.height;

3. Another question would be about the internal timer inside this code. I realized that whenever I click the scan button in the GUI software, the DMD first produces a checkboard like pattern and then produce the column scan of the Hardamard scan depending on the options, but I wanted to know what is the function that is producing that checkboard like pattern, and how can I adjust the time it stays like a checkboard pattern (make this pattern hold longer). Where would be a good way to start my goal?

We would appreciate your inputs regarding this matter. Thank you.


Regards,
Cedrick

  • 0
    TI__Mastermind 28005 points

    Cedrick,

    I believe there is information about uploading new TIVA source code here:

    https://e2e.ti.com/support/dlp/f/dlp-products-forum/955922/dlpnirnanoevm-nirscannano-library

    What sort of application is this for that the customer wants to override the patterns manually? That might help us better understand how to support.

    Regards,

    Philippe Dollo

  • 0 in reply to Philippe Dollo
    Prodigy 165 points

    Hi Philippe, I think Cedrick was asking the questions for me. 

    So our main goal is to upload our own patterns, like circular rings, and make the DMD continuously display at that pattern for 5 to 10 s. 

    So we really wanted to know some basics of where we could change the source code so that the DMD would work as we wanted to.

    Based on that,

    1. our first main question would be as Cedrick had mentioned in questions 2: If we only alter the function: dlpspec_scan_col_genPatterns   as described in Cedrick's post, and then compile it as asked in the manual, we are able to get a new compiled file in the Release folder (have checked the date stamp), but after we updated the firmware in the GUI, the patterns on the DMD still looked the same, but not half the height.

    Would there be somewhere else we needed to change in any of the projects, or is it that we didn't compile the source code correctly?

    2. Our second question would be to find a fast method (a method that don't have to alter the source code that much) to 'slow' down the pattern generation process, or just make the 'column' scan stop at each point for a longer time?

    Thank you!

  • 0 in reply to Haoran Zhang
    Prodigy 165 points

    What I also wanted to ask was that if I am just altering the function dlpspec_scan_col_genPatterns in dlpspeclib, and then finished the compiling in CCS, and updated the firmware using that .bin file. Do I still need to compile the GUI using Qt Creator and MInGW as asked in the manual? I am little confused of the steps.

    Just for info, I finished the steps as asked in for compiling the library and the source code in CCS version 6.0.1, and I am using spectrum library 2.0.3, and NanoSoftware 2.1.0.

  • 0 in reply to Haoran Zhang
    TI__Mastermind 28005 points

    Haoran,

    I believe what you are referring to is recompiling the GUI, which shouldn't be necessary if you don't need to modify its particular functions. However, you will need a way to interface with the system if you are not modifying the GUI and you are changing the TIVA functionality.

    Based on the above it may be easier for you to modify the source code of the TIVA system directly to execute commands on the DLPC150 to execute the behavior you are looking for. It sounds radically different than what the nirScan Nano is designed for originally.

    Have you looked at the commands available in the DLCP150 programmer's guide?

    https://www.ti.com/lit/ug/dlpu031a/dlpu031a.pdf

    Regards,

    Philippe

  • 0 in reply to Philippe Dollo
    Prodigy 165 points

    Thanks for your reply and confirming that we don't need to recompile the GUI.

    So we are currently just trying to understand the functions in the dlpspeclib library better, and thought that recompiling this project with the Spectrometer TIVA EVM project in the CCS (and updating the firmware in the GUI) would work, so that is why we are only changing and compiling the dlpspec_scan_col_genPatterns function. 

    Right now, we just wanted to make changes in the source code, and actually see the changes display on the DMD (like make the columns height lower, make the column thicker, make the vertical lines move slower etc.) so that we could better understand the code. If you could point out where we should look at first, it would be great.

    According to what you are mentioning, are you suggesting that changing the dlpspec_scan_col_genPatterns alone won't make a difference in the DMD's final pattern display? What I thought was that we could change the patterns in the dlpspec_scan_col_genPatterns function, and the column scan mode in the GUI would be different based on the changes we make in this function.

    We have checked DLCP150 programmer guide, but not sure which part would be helpful for our goal right now. We understand that there are serial commands for different default patterns for the DLCP150, but I was wondering how would that help with our goal.

  • 0 in reply to Philippe Dollo
    Prodigy 165 points

    Just for info, right now, we don't have to worry about disabling the light source or the spectrometer part, because the microcontroller is still connected to the light source and the detector, so after pressing the scan button on the GUI, the light source opens, and the DMD performs a 'column scan' pattern perfectly, and we do get a spectrum intensity plot on the GUI. But these don't matter for now, as we only care about the patterns on the DMD. Even if we change the height the way we did as described above, we still see the same 'column scan' pattern as previously.

  • 0 in reply to Haoran Zhang
    TI__Mastermind 28005 points

    Haoran,

    Thanks for the summary. We will need a few days but I or someone will the team will reach out once we have more information sometime this week.

    Regards,

    Philippe

  • 0 in reply to Philippe Dollo
    TI__Mastermind 28005 points

    Haoran,

    Thanks for your patience. Let me provide some guidance where I can.

    The TIVA controller, being an ARM processor, has a parallel interface (PDATA) which outputs the pattern data to the DLPC150. Given that the nirScan Nano is built for spectroscopy applications, the Spectrum Library source code is designed for this purpose. Because of that, there's probably a lot of code in there that is counter-productive to what you are trying to do (which is, namely, to send specific patterns on their own through the PDATA bus).

    From the Spectrum Library code, you would need to find the part of the code that generates the frame buffer data to send out over the PDATA bus. This is essentially what you will ultimately see on the DMD.

    From the DLPC150 Programmer's Guide, you should note that the system can technically be configured without the use of the TIVA controller (though it sounds like you may be using parts of that code untouched for the time being). In particular, if you look at command 0xF5 of the DLPC150 programmer's guide you will see that you can configure the system for pattern streaming over the RGB888 parallel port interface (which is what you are indirectly doing with the TIVA controller).

    You have multiple options in how you approach this issue. Ultimately, what matters is that you ensure that the DLPC150 gets configured with the right I2C commands, and following that the desired data gets sent over the PDATA bus (whether it's by the TIVA controller or a different source). This is because the actual processing of the input patterns and subsequent display on the DMD is handled by the DLPC150, not the TIVA controller.

    I hope this helps. Let me know where I can elaborate.

    Best Regards,

    Philippe Dollo

  • 0 in reply to Philippe Dollo
    TI__Expert 8270 points

    Hi Philippe,

    Haoran seems to have some trouble on replying to the thread. Kindly see his response below.

    Thanks Philippe for the guidance. We managed to overcome that in the past week by disabling the bend_function in the source code, and by doing that, we are able to produce different sized rectangles at different positions using the Draw_Rectangle function.
    Based on that, we have some questions about some of the details in the code.
    1. Is the value for the original internal framebuffer 24? Would that mean that the DMD has it's own memory of 24 frames? Would it matter if we change this internal framebuffer to 32 or 16 (for the goal to produce circular patterns)?
    2. Is there an maximum value for the number of patterns per scan? I saw the number defined in the dlpspec_setup.h file that the number for MAX_PATTERNS_PER_SCAN is 624. And originally, the patterns per scan is set to 228? What if we change this number to above 624?
    Thank you.


    Regards,

    Cedrick

  • 0 in reply to Cedrick
    TI__Mastermind 28005 points

    Cedrick,

    The DLPC150 (controller) has its own internal frame buffer to store video information that is streamed to the DMD. What do you mean by a frame buffer of "24"?

    Your question about the maximum number of patterns per scan sounds confusing to me. In your particular application as I understand you are not trying to perform scans but display custom patterns (since you aren't performing spectroscopy in this case). In this case the maximum binary pattern rate is limited by the DLPC150's maximum input rate of 2880 Hz. 

    I'm not sure if I answered your question though. Feel free to elaborate so we can discuss further.

    Best Regards,

    Philippe Dollo

  • 0 in reply to Philippe Dollo
    TI__Expert 8270 points

    Thanks Phillipe for your quick response.
    1. So I saw this in the 'display.c' file

    #ifdef INTERNAL_FRAMEBUFFER
    fb.bpp = 32;
    #else
    #ifdef SIXTEEN_BPP
    fb.bpp = 16;
    #else
    fb.bpp = 24;
    #endif
    #endif

    So basically I wanted to confirm the number for the fb.bpp, and if it is allowed to changed to the other two cases?
    2. I am aware that I am not trying to perform scans but display custom patterns. But right now, I am still modifying the column scan function and not disabling any spectrometer acquisition process, and I noticed there is a defined number for the MAX_PATTERNS_PER_SCAN in the 'dlpspec_setup.h' file, and it is defined to 624.
    I just wanted to check that if I change the num_patterns per scan and this number to a larger number, and re-compile it, would that 'break' the DLP firmware?
    Thanks!


  • 0 in reply to Cedrick
    TI__Mastermind 28005 points

    Cedrick,

    Will need some time to investigate on our end. Let me see if the team can get a response on this sometime this week.

    Best Regards,

    Philippe Dollo

  • 0 in reply to Philippe Dollo
    TI__Expert 8270 points

    Hello Philippe,

    Thank you for checking this for us.

    We appreciate your help.


    Regards,

    Cedrick

  • 0 in reply to Cedrick
    TI__Mastermind 28005 points

    Cedrick,

    Appreciate your patience. The team hasn't been able to address your issue yet but we are working to do so as soon as possible. I'll keep you up to date when we have more information to share.

    Regards,

    Philippe

  • 0 in reply to Philippe Dollo
    TI__Expert 8270 points

    Hi Philippe,

    Alright. We will be waiting for the update.

    Thank you and have a good day.


    Regards,

    Cedrick

  • 0 in reply to Cedrick
    TI__Mastermind 28005 points

    Cedrick,

    Thanks ahead for your patience. I still need a few more days before we can post back.

    Best Regards,

    Philippe

  • 0 in reply to Philippe Dollo
    TI__Expert 8270 points

    Hi Philippe,

    Good day.

    Just checking, is there an update on this? Thank you.


    Regards,

    Cedrick

  • 0 in reply to Cedrick
    TI__Genius 12575 points

    Hello Cedrick,

    Thank you for bearing with us with the delay on the response to your question. Our team is looking into your issue and will respond when we have more information.

    Regards,

    Austin

  • 0 in reply to Austin Snyder
    TI__Mastermind 28005 points

    Cedrick,

    Thanks for your patience. Here's some feedback for you on your current issue:

    /**
    * @brief Describes a multi-frame wide frame buffer in memory
    *
    * This structure contains descriptive information relating to a display frame
    * buffer such as the start pointer, the size of the palette, and its dimensions.
    */
    typedef struct
    {
    uint32_t *frameBuffer; /**< pointer to start of frame buffer memory */
    uint32_t numFBs; /**< number of consecutive buffers available to be filled with patterns */
    uint32_t width; /**< number of horizontal pixels in frame memory */
    uint32_t height; /**< number of vertical pixels in frame memory */
    uint32_t bpp; /**< number of bits per pixel */
    }FrameBufferDescriptor;

    The framebuffer descriptor struct you are referring to above is using fb.bpp to define the number of bits per pixel in the patterns. This information is being sent to the SpectrumLibrary to generate frame data in the form of patterns.

    You could change the number of bits per pixel, but as a consequence you will need to ensure that the DLPC150 is actually configured via I2C to handle video data with the width that you are generating. See the DLPC150 Programmer's Guide for more info: https://www.ti.com/lit/ug/dlpu031a/dlpu031a.pdf 

    As for your other question, you can think of the patterns per scan as frames (which may be bigger or smaller depending on your configuration). The size you can use will depend on the frame buffer size of the device you are using (in the case of the nirScan Nano, it is the Tiva TM4C1297 http://www.ti.com/product/tm4c1297nczad.

    You will need to calculate the "max patterns" value based on the pattern resolution (likely 854x480), bits per pixel, and LCD frame buffer memory size of the Tiva controller.

    I hope this helps.
    Regards,

    Philippe