• Locked Locked
  • Replies 4 replies
  • Subscribers 98 subscribers
  • Views 304 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Need help with hardware-programming

SabineKäß
Prodigy 95 points


Hello,

I start working with the OMAP35x Evaluation Module and try to drive the lcd to display images. This has to be done as a native program directly on the hardware.

The documentation of the OMAP35x is very voluminous and it is not very obviously recognisable to me which components and registers are needed for that purpose. Actually, the program contains following steps:
     - enable all power domains
     - enable needed (functional & interface) clocks (DSS/DPLL)
     - enabled gpio's and programmed them as output
     - initialized the display subsystem (DSS) registers
     - change the background color as a first test

Unfortunately, nothing happens... even the lcd backlight remains in that state which was active while processing the warm reset before loading my application. The register values read to control the initialisation implies that softreset of the display subsystem and the adaption of the dss shadow registers have been completed successfully.

Do I understand correct, that the given basic programming models of chapter 15 in "Omap35x Applications processor - Technical Reference Manual" are alternatives?

So I'd like to ask you, is anyone able to give me some advice writing omap35xx applications WITHOUT using the delivered linux, just by direct access to the hardware? Or do you have any compact documentation how to control the display or any small (native) example program?

Thanks & Best regards,

Sabine

  • TI__Mastermind 41665 points

    Unfortunately almost all of the collateral TI provides for the OMAP3 will be based on some high level OS like Linux or Windows CE, the device is complex to the point that it is not practical to try to offer a software solution with no OS out of the box, much like if you were to buy a PC it would not be practical to write your own software directly for it, you have to leverage existing software structures in the form of an operating system or you could spend a massive amount of time just getting it to power up. This being said I would definately advise against using the OMAP3 without some high level OS support.

    The closest I could suggest for an example that does the basic initialization would be the U-Boot sources that are included with the SDK install. U-Boot is a Linux boot loader that would normally be used to start up the Linux kernel, though it is technically not Linux by itself. Since it is not a full high level OS you could use it as a starting point for your own development as it has code in it to do the sort of initialization you are looking for.

  • in reply to Bernie Thompson TI
    Prodigy 95 points

    some weeks later: again, I am trying to solve my OMAP problem...  [:P]

    By the way, I tried to analyse the delivered Linux drivers to get the needed information. But it is very difficult for me, since I am not trained in Linux programming.

     

    Project background:   We want to run a virtualisation software on the board (what is already working) to run several operating systems in parallel. Therefore, we need to program a frame buffer driver that runs quasi directly on the hardware. As a first step we just want to start getting conversant with the display subsystem.

    Since my last request, I got another TI-contact and would like to make the actual discussion public:

     

    I started to configure the neccessary registers listed in the document "OMAP technical reference manual", chapter 15.5 "Display Subsystem Basic Programming Model" and set the "LCD GO"-command as last action to let the changes in the shadow registers be adopted. The problem is, the changes are not adopted. The system is always waiting for the "VFP start period" and I have to confess, that I don't know what that should be and how to enforce it. I searched but did not found any more detailed information in the reference manual.

    It seems to me, that I have to use/programm some more components than only the display subsystem, but the documentation is not clear enough for me.

    Moreover, since I am not conform with programming displays, the documentation makes not clear enough for me, which components of the display subsystem have to be used together or as alternatives (i.e. RFBI / DSI / SDI ...).

     

    I would be thankful for a piece of advice or a more compact (beginner-)manual how to control the display.

     

    When you say the system is waiting for “VFP start period”, what bit of equipment is telling you this?

     

    I’m not aware of a more compact guide at this point, as most people rely on either the Linux or WinCE drivers to understand how to program the module.  In your request to the community site, can you be specific about the outline of such a compact guide?  Otherwise, we will continue to think the existing documentation is sufficient.  We understand it is complex, but the module is complex.

     

     
    It seems to me that the system waits for VFP start period, because the bit DSS.DISPC_CONTROL[5] GOLCD - which I set after programming all the shadow registers - is never reset. The documentation says the hardware would reset it when update is complete. And those update should be initiated by the VFP start period...
     
    In the documentation I mainly miss an explanation of a usable minimal configuration: I mean, if I want to use the display subsystem and use chapter 15 with its basic programming model, it seems to me, that everything is described HOW to programm, but not WHAT of those possibilities are essentially needed.
    Moreover, to use the display, I need to use some other components like the GPIOs  for example, right? I miss some references to those necessary components...
  • in reply to SabineKäß
    TI__Mastermind 41665 points

    The mimimal configuration will vary based on your display, different output methods such as various DVI chips and various LCD displays will have different settings even thoguh they follow the same basic initialization process described by the basic programming model, since everything can be different there is not an actual example of settings in the TRM. For an example of what needs to be set in the case of the LCD on the OMAP3 EVM you could reference the U-Boot code from Mistral which initializes the LCD, or the ITBOK (Is The Board OK) code from OMAP35x_SDK_1.0.2\board_utilities\EVM3530_ITBOK\ which also sets up the LCD.

    SabineKäß said:
    Moreover, to use the display, I need to use some other components like the GPIOs  for example, right?

    In the case of the EVM you do need to assert some GPIOs to power on the display and such, for an example see lcd_utils.c in the ITBOK.

  • in reply to Bernie Thompson TI
    Prodigy 95 points

    Thank you for the tip. I'll try to exploit ITBOK for my purposes :-)