ATMEGA128A LCD controller using FAST UTFT library

Go To Last Post
27 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi All,

I have been trying to port code based on the UTFT library: http://gizmogarage.net/fast-avr-...

 

I am using an ATMEGA128A with a 3.2" LCD from sainsmart (uses SSD1289) http://www.sainsmart.com/sainsma...

 

I have designed my own PCB and have been able to get about as far as blinking a status LED.

 

My problem is that I when I have tried to import the fast UTFT library I get loads of errors that I don't know how to resolve (I'm new to AVRs that aren't in arduino boards).

 

The error I am currently stuck on is "Number must be positive and less than 64" this occurs many times in my code but on firstly on the line:

/* this block sets up the TOGGLE_WR_FAST registers r30:r31 */
	in r26, _SFR_IO_ADDR(WR_PORT) //This line
	//lds r26, _SFR_IO_ADDR(WR_PORT) This line was suggested in/out to lds/sts	
	mov r27, r26
	set
	bld r26,WR_PIN
	clt
	bld r27,WR_PIN
	
	movw r30, r22

FB1BIT_LOOP:

	LPM r0, Z+

	PLOT_MONO_PIXEL r0,7
	PLOT_MONO_PIXEL r0,6
	PLOT_MONO_PIXEL r0,5
	PLOT_MONO_PIXEL r0,4
	PLOT_MONO_PIXEL r0,3
	PLOT_MONO_PIXEL r0,2
	PLOT_MONO_PIXEL r0,1
	PLOT_MONO_PIXEL r0,0

	SUB16 r24,r25,1

	cpi r24,0
	cpc r25,r1
	breq FB1BIT_DONE
	jmp FB1BIT_LOOP

WR_PORT = PORTG 

I have set the fuse to turn off compatibility mode in the ATMEGA128A (M103C) so I should be able to use this port like a standard IO port

 

I would really appreciate some help with this.

 

I have attached the Fast UTFT project as a .zip

 

Many thanks in advance

 

Gareth

 

Attachment(s): 

This topic has a solution.

Last Edited: Tue. Oct 13, 2015 - 09:39 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Oh,   I love this new website and lovely editor!

 

Ok,   starting again.    Your display should work just fine with the standard UTFT library code.     And it should work plenty fast enough for most people.

 

Note that UTFT is a lot more up to date than the link to the "fast-UTFT" site.

 

Yes,   you can certainly make UTFT run a lot faster than the standard distribution.     However your ZIP file appears to show an awful lot of hacks to the original.

 

I would start with Henning Karlsen's official distribution.     You only need to edit one file e.g. make your own "hardware/avr/HW_ATmega128.h" from the "hardware/avr/HW_ATmega1280.h"

 

If you want some help,   write down your wiring scheme.    And we can do it for you.

Once you are up and running,   by all means have another go with the "www.hacking" version.    I am sure that it works perfectly.    But it is not code that looks attractive for others to delve into.

 

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

I am using an ATMEGA128A

You have posted in the XMEGA forum, I'll move the thread.

 

Also please delete your post from the projects, that's only for COMPLETED projects you want to share.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

I had a look at the fast-avr-utft distribution ZIP.

THe AS6 project compiles and builds just fine.

 

However,   the project is written for a mega644 that has regular IN/OUT accessible ports.     The author is obsessed with saving every cycle.

 

Consequently,   it will require a bit of care to get it using PORTF/PORTG on a mega128.     It will be a little SLOWER.

 

If you say which pins / ports you want to use,    we could get the example working.

 

I have no intention of reading your project.     How do I know what you have altered from the original mega644?

It is your job to run diff on your files.

 

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for your replies guys,

I will try reverting to the original Henning Karlsen UTFT library.

As for the project I uploaded Ignore that, I posted that before I really understood how this site works.

 

As for the speed I will get it working first then time how long a full screen bitmap takes to display as this is the real test for me.

 

I have posted the schematics for the Interface board I have designed as well as the sainsmart adaptor shield for the LCD.

 

Thanks again guys I will work through your suggestions today and let you know how I get on.

 

Gareth

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

It looks as if your 16-bit LCD bus is using 'easy' ports on the mega128.

The 'control' lines are on PORTG.

 

Quite honestly,   the LCD driving is pretty straightforward.

However,   your SDCard is using mixed-up SPI lines.     This will really cripple any performance.

 

The mega128 has only got one SPI peripheral.    It has two UARTs but neither can do USART_MSPI.

It is very important to use hardware SPI if you want reasonable performance.

 

I would choose a more suitable AVR.    Perhaps the mega1280/1 ?

 

Or even put the LCD on the address bus.     (which I have never done)

 

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So the PB0-PB3 pins are not true hardware SPI?

I am using the two UART's for serial communication, the USB interface is really just for debug & test purposes.

The Other UART is for communication between this display and another embedded device.

 

Regards,

 

Gareth

ATMEGA128A

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Yes,   they are correct hardware SPI.

However,  you have connected SDDIN to SCK and SDSCK to MOSI !

 

I have not studied your module.     I a guessing that it has a Touchscreen controller that uses SPI.

So I would route DOUT, DDIN, DCS DCLK to the correct pins on the SPI bus.

 

If you want the best performance for your money,   choose an AVR with USART_MSPI.

 

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So the PB0-PB3 pins are not true hardware SPI?

What makes you say/ask that? Yes the PB0..PB3 are a full, properly implemented hardware SPi peripheral.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ah, I see my error now.

As it seems likely I will have to re-design the board I think I will follow your advice and choose a better AVR for the job.

Thanks for your input.

 

Gareth

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Oh  I am a wimp when it comes to wiring things up.    I always choose 8-bit over 16-bit.   Or SPI over 8-bit.

 

Yes,   the 16-bit can be written faster:   OUT / OUT / CBI / SBI (6 cycles)

8-bit requires OUT / CBI / SBI / OUT CBI / SBI (10 cycles)

 

In practice,   your app still has to generate the data.     So the raw GPIO time is not too significant.

 

Oh,   your Touchscreen,  SDCard,  other SPI peripherals should work just fine on a single SPI bus.

 

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have been searching for a similar Chip, my main requirement is to keep the component cost very low and even the ATMEGA1280 is twice as expensive (at least from Farnell) http://uk.farnell.com/atmel/atme...

Data sheet - http://www.farnell.com/datasheet...

 

I want to keep the MCU at 3.3v so that I don't have to mess around with changing logic levels to the LCD.

I have been looking at this:

http://www.farnell.com/datasheet...

 

IT's about the same money but from what I can tell from the datasheet it has potentially 3 Hardware SPI ports (though I would need one of those ports for the LCD databus)

Can you tell me if it is worth overhauling the PCB design to use this micro?

 

Regards,

 

Gareth

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

If it's 3.3V you might want to consider some models of Xmega - I have a feeling they may be cheaper for similar facilities. Xmega tend to have "one of everything per port". So you will probably find more UARt or SPI or whatever than you can shake a stick at. The downside of Xmega is that the peripherals tend to be more featured and hence more complex so instead of a GPIO having DDR/PORT/PIN you'll find about 10 registers and need to read deeper to understand which of those are the simple equivalent of DDR/PORT/PIN and which are the "extra bits" you can probably ignore for the time being.

 

Of course at 3.3V another option is Cortex ;-)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you are running at 3.3V there is a wide choice.    e.g. Xmega,  Cortex-M0, ...

 

First of all,   you have to decide what your design considerations are.

 

Generating graphics requires CPU power.

Displaying photos from an SD Card on an LCD involves transferring data from the memory card.    Possibly processing it.   Then displaying on the LCD.

Pre-processing data before it goes into disk files is always worthwhile.

 

An Xmega has got DMA,   works faster,   is relatively simple.

The Cortex chips vary greatly.     Possibly have DMA,   better SPI, ....    And they can process faster.

 

But some brands of Cortex have appalling peripherals.     Some have excellent peripherals.

 

David.
 

Last Edited: Wed. Oct 29, 2014 - 10:51 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

For the time being I am going to wire mod the PCBs I have to fix the SPI issues.

However, I am still trying to get the Hennign Karlsen UTFT project to work in Atmel Studio 6.1.

 

I will keep plodding on with the port and see where it gets me.

 

Thanks for all your input so far!

 

Gareth

 

FYI the library I am trying to port is attached

 

...ignore that attachment, it was the wrong one, I am trying to port the example from Hennign Karlsens site

Attachment(s): 

Last Edited: Wed. Oct 29, 2014 - 11:12 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have been struggling to spend as much time on this as I would have liked, my workload is mostly repair & testing of circuit boards, I'm not actually a programmer, though I am hoping to get there.

 

The current issue I have is that I am getting the error unkown type name 'class' from Atmel studio.

This happens when trying to compile UTFT.h I would assume because of the .cpp nature of UTFT, however the Fast UTFT example I had used before never had this compile error yet it used a near identical UTFT.cpp & UTFT.h albeit some of the "fat" was cut out from it.

 

Can you offer me some assistance to get me on my way?

 

Regards,

 

Gareth

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

If you confirm that your wiring in the schematic is truthful,    I will write a "HW_ATmega128.h" file for you.    Then all the current UTFT library should work for you.

 

Meanwhile,    I suggest that you install AS6.2 on your PC.

 

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

The current issue I have is that I am getting the error unkown type name 'class' from Atmel studio.

That's the classic error you get when you feed C++ code to a C compiler. I'm guessing that if the class declaration is in a .h file that you have #include'd that .h in a .c not a .cpp file.

 

In fact when you are working with C++ you might as well just name all files .cpp rather than just .c even if they still only contain plain ANSI C.

 

If you really must retain some files as C not C++ then don't include C++ headers in them and if the C needs to call anything in C++ make sure it is "extern "C"". See:

 

http://stackoverflow.com/questio...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi David,

Yes the schematic is correct, however I am going to wire mod the PCB at some point to swap the SPI lines round, I think I should probably connect the SD card SPI lines onto the same bus as well.

 

Regards,

 

Gareth

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My experience with writing code mostly derives from C code in the Code warrior IDE using a freescale (MS9S12XDT512MAL & MC9S12X256CAL) in my spare time I have fiddled with Arduino, Android (java), C# and Raspberry Pi (python) but I would like to get a lot better at writing for C as I think my mistake so far has been trying to learn a bit of everything before fully understanding any of them.

 

All your help is very much appreciated.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi David,

I've been busy repairing boards all day but I have just got round to looking at this again.

 

I am installing AS 6.2 now I will start fresh form the beginning, if you don't mind writing the header file for me I would be very grateful.

 

I'm still unsure of how I would get around the error with the UTFT.h cpp class error, or will that be fixed by using the latest atmel studio version?

 

Regards,

 

Gareth

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So having re-visited this I decided to re-write the entire project in C.

It has taken me a while but I now have the basics, I have ported most of the UTFT library into C and re-written a few functions to cut down on code space.

 

If anyone is interested in the source I am happy to provide the lcddriver.c &.h files.

Obviously you will need to initialize some of the ports differently unless you have the exact same schematic as me, there are a few hard coded references to port pins which would need to be changed but it could save you a lot of work.

 

David has been very helpful so I hope in turn I can be of some use...

 

Regards,

 

Gareth

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gjenkins87 wrote:

So having re-visited this I decided to re-write the entire project in C.

It has taken me a while but I now have the basics, I have ported most of the UTFT library into C and re-written a few functions to cut down on code space.

 

If anyone is interested in the source I am happy to provide the lcddriver.c &.h files.

Obviously you will need to initialize some of the ports differently unless you have the exact same schematic as me, there are a few hard coded references to port pins which would need to be changed but it could save you a lot of work.

 

David has been very helpful so I hope in turn I can be of some use...

 

Regards,

 

Gareth

 

Thanks a ton for your hard work and effort. im going to use this for my project :D :D 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gjenkins87 wrote:
I have ported most of the UTFT library into C and re-written

Good initiative and it can help understanding the code if it's stripped from the compatibility layers of all the different hardware.

 

It is not nice however to remove:

/*
  UTFT.cpp - Multi-Platform library support for Color TFT LCD Boards
  Copyright (C)2015 Rinky-Dink Electronics, Henning Karlsen. All right reserved

  This library is the continuation of my ITDB02_Graph, ITDB02_Graph16
  and RGB_GLCD libraries for Arduino and chipKit. As the number of
  supported display modules and controllers started to increase I felt
  it was time to make a single, universal library as it will be much
  easier to maintain in the future.

  Basic functionality of this library was origianlly based on the
  demo-code provided by ITead studio (for the ITDB02 modules) and
  NKC Electronics (for the RGB GLCD module/shield).

  This library supports a number of 8bit, 16bit and serial graphic
  displays, and will work with both Arduino, chipKit boards and select
  TI LaunchPads. For a full list of tested display modules and controllers,
  see the document UTFT_Supported_display_modules_&_controllers.pdf.

  When using 8bit and 16bit display modules there are some
  requirements you must adhere to. These requirements can be found
  in the document UTFT_Requirements.pdf.
  There are no special requirements when using serial displays.

  You can find the latest version of the library at
  http://www.RinkyDinkElectronics.com/

  This library is free software; you can redistribute it and/or
  modify it under the terms of the CC BY-NC-SA 3.0 license.
  Please see the included documents for further information.

  Commercial use of this library requires you to buy a license that
  will allow commercial use. This includes using the library,
  modified or not, as a tool to sell products.

  The license applies to all part of the library including the
  examples and tools supplied with the library.
*/

If for nothing else a link to your source helps people who stumble into your version, like it, but can't use it because they need a part of the code you stripped out.

If you really can't live with a big comment block then at least drop a hint about UTFT / Henning Karlsen / Rinky-Dink. Any of those three should be enough to easily trace it back to its origin.

Just as Henning, who drops a hint back to ITead studio.

Paul van der Hoeven.
Bunch of old projects with AVR's:
http://www.hoevendesign.com

Last Edited: Wed. Aug 2, 2017 - 04:28 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello again,

This library is very neat, i was able to study the initialization of my ili9481 tft screen.
After all the painfull experiments with the code, i successfully made my own function to start the lcd.

Making a rectangle is so simple :D

Thanks to avr freak dude's .

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Is it possible for me to get a copy of you initialization code for ili9481

Regards Jan

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

janus2008 wrote:
Is it possible for me to get a copy of you initialization code for ili9481

Who are you addressing?

 

Have you looked at the files provided in #22 ?