Octal,
Thank you for your reply. I would like to develop applications for different sizes (such as 122x32, 128x64, 192x64, 240x64, 240x128 etc.,) of GLCD's using just a single 240x128 T6963C. SF allows me to do this as they use a separate driver for each GLCD controller type with common graphics/control routines. And of course, your font generator is a great help. Here is an example of applications for the 128x64 and 240x128 sizes using the big GLCD.
Octal's driver for T6963C GLCD
Moderators: David Barker, Jerry Messina
Hello rmteo
nice work
You must be carefull about one thing:
SF Provide needed common code and the drivers. This is really very fine cause it let you work on any kind of display without reworking your app logic and code.
For big displays you must be carefull at modifiying the TXY type used in SF Drivers (and take care to RAM consumption). For displays having more than 255 pixels width or height, you need to switch TXY from Bytes to Word (Byte is <= 255).
SF Does not offer a TX and TY alone, so if you have a display with 257x120 pixels for example, both X and Y will become WORD vars, so you must be careful cause WORD calculations (inside the GLCD Lib for Lines and circle algorithms for example) will be switched to do double bytes calculations, and this can be cpu intensive and RAM hungry
Regards
octal
nice work
You must be carefull about one thing:
SF Provide needed common code and the drivers. This is really very fine cause it let you work on any kind of display without reworking your app logic and code.
For big displays you must be carefull at modifiying the TXY type used in SF Drivers (and take care to RAM consumption). For displays having more than 255 pixels width or height, you need to switch TXY from Bytes to Word (Byte is <= 255).
SF Does not offer a TX and TY alone, so if you have a display with 257x120 pixels for example, both X and Y will become WORD vars, so you must be careful cause WORD calculations (inside the GLCD Lib for Lines and circle algorithms for example) will be switched to do double bytes calculations, and this can be cpu intensive and RAM hungry
Regards
octal