µTasker Forum
µTasker Forum => LCD Graphics Library and Simulator => Topic started by: mark on July 22, 2009, 01:57:55 PM
-
Hi All
The uTasker project has long supported a character LCD simulator but from version V1.4 all projects contain monochrome graphical LCD support as well as a foundation for color LCD support. This includes simulation of the LCDs in the uTasker simulator to make development more efficient and more fun.
The following lists some of the history leading up to the decision to add this support and also some basic terminology:
• Graphical monochrome and colour LCDs have become very popular recently with processor evaluation board manufacturers typically adding such a device to their boards; sometimes connected to a dedicated interface such as the LCD controller in the LPC2478, an external memory interface such as the AVR32, via SPI such as some OLEDs on Luminary Micro evaluation boards, or more generally via GPIOs (bit-banging).
• In addition, the semiconductor manufacturers have identified the trend and promote the use of their own devices by supplying graphic libraries as part of demonstration code (Luminary Micro, Atmel, etc.). These graphic libraries are however generally restricted to use with particular microprocessors (licensing) and are not compatible.
• The result of these developments and research into real user requirements led to the decision to add processor-independent graphical LCD support to the µTasker project together with practical graphical LCD simulation support to accelerate project development.
• The first step in the process is the addition of monochrome LCD support including an accurate LCD simulator which can be simply added to all processors via GPIO connections. The initial support is restricted to text and bit-maps but this is generally adequate for most real project use, whereby library functions (such as line or shape drawing) will be added as the LCD project develops.
• In addition to the monochrome graphical LCD support as explained in this section various preparations have been made as foundation for extensions to colour support. The simulator, for example, is already capable of accurately simulating colour LCD controllers as well as processors with internal TFT LCD controller (like the LPC2478). The µTasker projects with such evaluation boards available for them also include a demonstration of this capability although it is not generally contained in the first release of the µTasker V1.4 project. See the following chapters for examples of these where applicable.
• To fully support LCD use various conversion utilities are required. A utility for converting bitmaps as generated with standards graphics programs (paint, etc.) is already included as detailed later in this section.
• Research and practical tests with various LCD types has shown that it is not practical to use a single low level interface. The main reason is due to the memory requirements – a monochrome graphical LCD requires about 1k of RAM in order to back-up the display memory contents, which is generally affordable and thus allows an efficient method of content manipulation and LCD updates based on changed pixels only.
A colour LCD may, on the other hand, require 230k RAM to do the same thing, which is generally not practical. There interfaces are also faster, especially when the display memory is in SDRAM used by an internal LCD controller to automatically refresh, and so there is in this case no advantage in trying to restrict accesses. These conflicting requirements led to the decision to optimise the low level interface to best suit each LCD type and so the monochrome graphical LCD interface was initially designed specifically to suit it’s inherent characteristics.
• Monochrome graphical displays often work very similarly but may have also some special commands to perform special tasks which are restricted to certain controllers. For this reason the first version of the graphical LCD driver concentrates on building a generic foundation based on standard commands. Specific advantages offered by certain display types may be used in the future to optimise operations should this be identified as being beneficial.
• The monochrome graphical LCD is identified from the character LCD in the µTasker project by the name GLCD (Graphical LCD). Colour graphical LCDs are further distinguished by the name CGLCD (Colour Graphical LCD).
The initial version is restricted to supporting fonts and bitmaps (including a useful utility for automatically creating all project widgets in a project file), which represents the fundamentals for the next step of developing the processor-independent uTasker graphics library. LCDs are fun to work with and you may already be quite amazed at what the first simple package can already do...! Get full details in the new LCD user's guide: http://www.utasker.com/docs/uTasker/uTaskerLCD.PDF
Have fun...
Regards
Mark
-
Hello Mark, just started playing with the uTasker, using the simulator. It is awesome.
I was successfully able to create a new task as per your instructions.
Able to to see the "hello world" on a telnet connection using PuTTY.
Next, I disabled the GLCD, and enabled the character LCD.
The telnet now outputs the "hello world" and LCD = 0xFF.
The display on the simulator is OK.
Question: Where is the LCD =0XFF coming from?
the code snippet:
#include "config.h"
extern void fnMyFirstTask(TTASKTABLE *ptrTaskTable)
{
static unsigned char ucCounter = 0;
fnDebugMsg("Hello, World! Test number ");
fnDebugDec(ucCounter++, sizeof(ucCounter));
fnDebugMsg("\r\n");
TOGGLE_LAV_OUT() ; // toggles portB bit 22
}
-
Hi
The LCD = 0xff is coming from the test (see application_lcd.h)
#define LCD_READ_TEST // test read of LCD content
This is requesting the value of the LCD data RAM at regular intervals using the following line:
fnDoLCD_com_text(E_LCD_READ_RAM, (unsigned char *)&ucAddress, sizeof(ucAddress));
The LCD task is then reading the LCD and returning the value for display.
You can disable this by removing LCD_READ_TEST.
In fact I think that the value from the simulator is probably not correct (I known that it is good with a real LCD - at least the last time I tried it) so it may need improving...
Since this is the first post on this particular board I will take the opportunity on reporting a bit on some progress in the mean time. This is all to do with graphical LCDs (GLCD)
1. The library has been developed a bit to include support for drawing lines between two points (easy when vertical or horizontal but a but trickier when diagonal).
2. Also a rectangle function has been added.
3. Both of these can be either drawn black, white or inverted (the pixels are the opposite of the background).
4. A full character LCD font has been added (useful for making a character LCD with a graphical LCD...)
5. A blink function has been added so lines or rectangles can be given their own blink speed. Multiple such objects can be blinking at the same time (each with different blink speeds if required). The blinking is fully coordinated by the LCD task so the application doesn't need to get involved. The objects blinking can also be individually disabled.
6. The GLCD is being ported to a Samsung controller (more or less working) with compatible application interface. This means that the two most popular controllers (as far as I am aware) are then supported.
7. An OLED GLCD compatible interface has been built in. The reason for this is that many Luminary Micro boards have an OLED (usually gray scale) - although many real projects will target a GLCD it is useful to be able to test and develop also on the OLED (which is probably about the same dimension in terms of X,Y). This mode doesn't utilise gray scales - it is just black/white - but it is very handy to play with if no GLCD is wired up or available. This may also allow a number of Luminary Micro users to make first steps with the library just because it is so practical with the on-board display...
8. The next step which is foreseen is an LCD document update with the new functions and a new Luminary Micro SP to allow an easy start with these kits. It is very easy to use and also great fun to play with!
Regards
Mark
-
Dear Mark
There is not CGLCD.c file in uTasker :(
Where can I find it?
-
Hi
CGLCD.c is only included in packages with color LCD on their development boards.
That is for
- AVR32 (the EVK1105 eval board)
- Luminary Micro (EK_LM3S3748)
TFT.c is only available in the LPC2XXX package (specifically for testing the TFT on the LPC2478 board).
The color LCD code is based on the evaluation board suppliers code but illustrates how existing code can also be simulated in the uTasker simulator (as shown by screen-shots at http://www.utasker.com/Demos/Simulations.html). The code is not yet a part of the uTasker graphical library, which is being developed initially for GLCD and then will advance to color once the ground work has been completed and the interfaces (as much compatibility as possible between different types) have been refined.
Regards
Mark
-
I have LPC2478STK from Olimex. When I try to compile uVision3_LPC23xx example I got error concerning CGLCD.C absence.
IAR example was compiled allmost OK last week, except GLCD which do not work on hardware and in simulator and strange garbadge:
?r? 8??G8µiF???(?? !A^ ??a? 8??G8µiF???(??!A^ ??P? 8??G0µ‹° ©?¦?(?di 4 ????? °? ??G?j"’’’’ ?R )???? M!?"
on the WEB page.
Today trying to compile last week project I got error message from IAR:
X ielftool error: Symbol not found __vector
X Error while running Linker
-
The only changes I did:
in application.c only network settings.
in config.h
// #define LPC2378FBD144
#define LPC2478FBD208
#define OLIMEX_LPC2378_STK
// #define KEIL_MCB2300
-
Hi
The CGLCD.c in the uVision project is a mistake - it can be deleted from the project (I probably tested with it still in the directory so didn't notice it).
When working with the LPC2478 and Olimex (your settings are correct) it will automatically activate the TFT test. This means that it is not possible to enable any other LCDs (like GLCD) without first deactivating SUPPORT_TFT. If the original V1.4 config.h is used, LPC2478FBD208 enabled and SUPPORT_GLCD disabled it should then default to the Olimex board with TFT.
Regards
Mark
-
OK. Report continued.
I forced //#define SUPPORT_GLCD
allthough
#if defined SUPPORT_GLCD && !defined SUPPORT_TFT
did the same.
TFT not working. Not in HW nor in simulator.
I could make WEB interface to work correctly by manual downloading all files via TotalCommander FTP client. If use bat file everything seems OK, but only 3 files were downloaded.
-
I put breakpoint to fnDisplayBitmap in Simulator. it never reached when I tried to sent image from the WEB.
-
Hi Mark,
In your post to this thread on 9 September you talk of further developments for Graphics LCDs.
Will this library work with TFT devices such as Olimex LPC2478-STK board, I will be over the moon if it does?
Thanks, Roger...
-
Hi Roger
Presently the development concentrates on monochrome LCDs, which have been the most popular to date.
As mentioned previously there are more functions available (lines, squares, blinking objects etc.) and this has also been extended to Samsung type controllers (that is, both Toshiba and Samsung based displays are compatible, even though the internal pixel/byte layouts are not). Where I am rather behind is in generating a new library package so that this is then actually generally available - it involves some more clean-up work and a document update, but a Samsung based commercial project has already been successfully implemented as test vehicle.
The design is based on a backup of the image in a pixel buffer the same size as the display. Pixel manipulation is performed there and writes to the display are only made when expressly commanded, and where a change is really detected.
In the case of the TFT there are several differences which make in not 100% compatible:
- first of all it doesn't have a single bit for a pixel but up to 4 bytes (depending on controller mode - eg. 24bit color). The present library is monochrome and so doesn't support the color part at the moment.
- the TFT (based on refresh directly from RAM as on the LPC2478) is in fact easier in that writing to the buffer already changes the image displayed. This means that the buffer method is similar (apart from the pixel size) but without the display write function being needed.
Also here I think that an intermediate step with monochrome content and compatible user interface would be a useful step, even when using a rather limited amount of the TFTs color capability. This is analogue to the OLED as described previously (although it supports gray scales, it is compatible in monochrome mode).
Finally note that routines supplied by other sources can be used and also will work in the simulator, which accelerates developments. Check the code supplied with the Olimex board.
In the meantime I will try to get a new library released - possible with the TFT monochrome mode, which may be interesting for some work and tests and will certainly be a useful stepping stone on the way to more color functionality too.
Regards
Mark
-
Hi Roger
Quick update: I have reworked the project to put the complete GLCD (monochrome) interface into the uGLCDLIB, supporting both Toshiba and Samsung based controllers and with emulation modes for OLED [on Luminary boards] and TFT [on LPC24XX]. This means that GLCD monochrome projects can be tested on OLED or TFT. This works successfully in the simulator and on the evaluation boards so a uGLCDLIB V1.1 is very close.
To round of this first session I also added scrolling support to the interface meaning that it is quite easy to use the displays for debug text output (as well as the other features discussed previously). A scroll is commanded and a line of text written to the coordinate of the start of the bottom text line in the display, causing the complete screen contents to be moved up one line (or as many pixels as specified) and the new text line written in the new blank space.
I may add the same for some other color based LCDs (AVR32 board and Luminary with SPI based TFT) to complete the packet. Then I will need to update the uGLCDLIB document and either release some complete project updates of just uGLCDLIB packet updates (to be decided).
Regards
Mark
-
Hi Mark,
Sounds fantastic, I look forward to trying the new uGLCDLIB.
Cheers, Roger...
-
hi,
congratulation for the best tool you have created,
after a long gap I am back on utasker ,
initial i just tested the simulator part in ver 1.3
good to see ver 1.4 beta release
so today did some hand-on testing with lm6965 kit ! worked great except oled !
was pulling my hairs why it not working , then i saw glcd and oled defines !
wanted to check out test oled lcd simulation ,
commented following in config.h
#define SUPPORT_GLCD
uncommented
#define SUPPORT_OLED
got error
"uTasker_root\Applications\uTaskerV1.4\OLED.c(27) : fatal error C1083: Cannot open include file: 'GLCD_Core.h': No such file or directory"
searched for it in 1.4 folder doesn't exist
I think it not yet supported !
looked around in LCD user guide chapter 4
didn't find any pointer to oled usage
In this post i read some thing of emulation of glcd on olcd
my mistake I had assumed glcd would support oled , then i read this post!
Is their any upcoming support for oled display on LM kits?
In the mean time i will try to find some char lcd 16x2 from old project
and wire then to LM kit
Thanks and regards
mrutyunjay
(LM3s6965 Eval board + cs-lite +eclipse+oocd )
-
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
-
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?
-
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
-
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.
-
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
-
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
-
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:
(http://home.comcast.net/~kmeaghermd/utasker/Trying_to_load_another_bmp_after_padded_bmp.jpg)
-Kevin
-
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