uTasker graphic LCD support and graphic library

[mark]

Hi mrutyunjay

This is unfortunately true. The OLED.c contained in the original uTaskerV1.4 [Luminary package] can not presently be used.

The development version focuses on GLCD (monochrome LCD) but allows various display types to be used to test and develop this (as previously discussed in this thread). The development is going quite well but there is still some work to be completed before this is ready - basically the list of LCDs to be supported has grown longer (the NOKIA 6100, available on Olimex boards has now been added and is in the final stage for completion; the TFTs as found on AVR32 EVK1105 and Luminary LM3S3748 are also in progress) - the reasoning behind this was that if the emulation mode is to be added for the Luminary OLEDs then why should it not be generally added so that all standard evaluation boards (at least the ones used for testing the project on) can be used.

This means that it will be a few days before it gets that far but various packages will then allow the same level of functionality to be used, irrespective of the GLCD type actually found on the board!

Regards

Mark

[paulk]

Does this mean that the EK-LM3S6965 eval board OLED should work now?  When I have SUPPORT_GLCD and OLED_GLCD_MODE defined, the simulator shows a black box where the LCD usually is.  Also, the OLED is bank on the eval board.

Any tricks to get this working?

[mark]

Hi Paul

The project was tested on the LM3S8962 evaluation board prior to the last release. This has a larger black OLED in comparison to the LM3S6965 evaluation board, who's OLED is also yellow(ish).

So I just checked the release in the simulator on these boards and also found that the display remains blank - although the reference project is OK.

The reason for this - as I found - was that there are a lot of interrupt generated when the IRQ test is enabled (as it is in the release project - see the file Port_Interrupts.h and the define IRQ_TEST).
If I disable this the simulator works correctly.

The reason (at least in the simulator but possibly also on the target - assuming the simulator is accurate) is that the IRQ test configures the port C-7 as interrupt input (edges cause interrupts to be generated, which send events to the application task, which will then display this occurrence on the debug output). But the OLED interface used this pin as an output to drive the Date/Command line. This means the each time data/commands are sent to the OLED (which is taking place) it is also generating IRQs. There are in fact so many IRQs that the input queue to the application task gets full and can not accept any more. When the OLED initialisation has completed it will have a dark screen and sends an event E_LCD_INITIALISED to the application task so that it can start with its demonstration - as seen on the GLCD. Unfortunately the application's input queue is completely full with the waiting IRQ events that this E_LCD_INITIALISED event has to be discarded and the application never starts using the OLED...

Therefore, disable the IRQ test and it works in the simulator and hopefully on the target too!

You will however see that the OLED on your board is quite small in comparison (in app_hw_lm3sxxxx.h you may like to remove the #undef BIG_PIXEL in the LM3S6965 case since this will make it larger..).

Furthermore, the simulator shows that the image is overflowing on this display - it expected it should be clipped... I am not sure whether this is due to an inaccuracy in the simulator (or in the project setup) or simply due to the small size of the OLED in comparison to the test images(?) To my embarrassment I can't find my LM3S6965 board at the moment...only the LM3S8962 one. Perhaps you could report back with results - I will keep searching for mine...

Regards

Mark

[paulk]

Mark,

Thanks for the excellent support!

Your suggestion to comment out the "#define IRQ_TEST" worked!  My LM3S6965 board has a white OLED display (It is a revision "D" board that I purchased about 3 months ago).

The display seems to work well, although it clips on the dev board (but appears to "wrap" around on the simulator).  Regardless, it is working.

[mhoneywill]

Hi paul,

I've been following your posts too, as I use the LM6965, LM1968 and uTasker in two different products. I've made the changes Mark suggested and can confirm the display wraps on the simulator, for the LM6965 EK.

Cheers

Martin

[mark]

Hi

I looked into the wrapping problem in the simulator and it turned out to be a configuration issue:

In app_hw_LM3Sxxxx.h there is a setup for the LM3S96965's OLED where the dimensions are adjusted:

    #define OLED_Y 64

However the GLCD code doesn't work with OLED_Y, only the simulator does in this mode. In fact too many lines are written to the OLED, which clips on the target. The simulator doesn't clip. This means that there in fact 2 issues - the correct setting and clipping of the OLED in the simulator, although the operation of the simulator was in fact not really a simulator error but also more a configuration error.

Therefore, to avoid confusion the best solution seemed to be to consolidate the dimensions and simply use always GLCD_X and GLCD_Y for the display dimension irrespective of whether it is an LCD or an OLED.

After replacing all occurrences of OLED_X with GLCD_X and OLED_Y with GLCD_Y everything was synchronised and both target and simulator do the correct thing.

Regards

Mark

[Kevin]

I'm not sure if this belongs in this topic or not...

Loadnig BMP files to the TFT can make the simulator and target non-responsive.

I first noticed it with the LPC2478-STK demo file and confirmed it with the simulator.

The two BMP files supply by utasker, work fine, but one I created myself from photoshop resulted in the issue:
File loads (HTTP POST) and displays with no problems, board and simulator appear to be working. From HTTP I can then browse to one of the original uTasker images, but once I hit upload, I loose all contact with the board and with the simulator.

I tracked it down to a two byte pad in my file utasker BMP length field is 0x36, 0x84, 0x03, 0x00 in my image it was 0x38, 0x84, 0x03, 0x00.  My file had two extra 0x00 bytes at the end of the file that were not needed.

When I changed the length field in my BMP to match the utasker BMP, everything worked well.  Removing the two extra bytes at the end of the file had no effect. 

It looks like loading a good BMP after the bad BMP causes the issue.  When I issue a break all from the debug window the stack frame value turns red as you can see in the screen capture:




-Kevin

[mark]

Hi Kevin

I know that the POST that is used to transfer the file is OK as long as the file contains the correct format.

If a file with an incorrect format is sent, the POST fails. This is not a problem in itself but the interface will then not respond to further attempts.
This is in fact a bug in the POST interface (at the application level and not the HTTP post) but I never got to look into it.
As long as you stick to valid formats it should be OK for an many (valid) posts. as you can send to it (format should be 24 bit color, 320 x 240 bit map without compression. Smaller pictures work (it will appear smaller and leave any previous background displaying) - larger images will fail and block further attempts until reset).

Note that the upload to the display is in fact not such a serious application. In fact it is very easy to do and so is useful for testing images (rather than having to compile them into code and download code to see what it really looks like) but probably less interesting for real project work.

Regards

Mark