TFT Display - TFT 320QVT (SSD1289) - help needed

Go To Last Post
66 posts / 0 new

Pages

Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi all, 

 

this is a continuation of THIS project, but as the problem is something completely else (and the old thread is cluttered and dead), I opened a new one here. Hope that is okay with the admins.

Anyways, I am trying to connect a LCD display to my MCU - ATmega32. 

 

This is the display:

 

So the documentation I got on it was scarce but I am pretty sure the display controller is the SSD1289. THIS ( https://gizmogarage.net/fast-avr-utft/ ) modified UTFT library was also uploaded for us to use, it's made for the SSD1289 controller.

 

This is how I connected the display:

 

And this is my config.h file from the library:

#ifndef __CONFIG_H__
#define __CONFIG_H__


#include <avr/io.h>

	
/* Configure your hardware pins here */
#define WR_PORT PORTA
#define WR_PIN	4
#define WR_PORT_DDR DDRA

#define DATA_PORT_LOW PORTD
#define DATA_PORT_HIGH PORTC
#define DATA_PORT_LOW_DDR DDRD
#define DATA_PORT_HIGH_DDR DDRC

#define RS_PORT PORTA
#define RS_PIN 2
#define RS_PORT_DDR DDRA

#define CS_PORT PORTA
#define CS_PIN 5
#define CS_PORT_DDR DDRA

#define RD_PORT PORTA
#define RD_PIN 3
#define RD_PORT_DDR DDRA

#define RESET_PORT PORTA
#define RESET_PIN 1
#define RESET_PORT_DDR DDRA

#define BACK_LIGHT_PORT PORTA
#define BACK_LIGHT_PIN 0
#define BACK_LIGHT_DDR DDRA

#define HAVE_STATUS_LED 0
#define STATUS_LED_PORT 0
#define STATUS_LED_PIN 0
#define STATUS_LED_DDR 0
	
#define F_CPU 8000000	
	
/* No touch zone follows */	
#define DPLIO _SFR_IO_ADDR(DATA_PORT_LOW)
#define DPHIO _SFR_IO_ADDR(DATA_PORT_HIGH)

#ifdef HAVE_STATUS_LED

#define status_led_on()\
STATUS_LED_PORT&=~_BV(STATUS_LED_PIN);

#define status_led_off()\
STATUS_LED_PORT|=_BV(STATUS_LED_PIN);

#define status_led_toggle()\
STATUS_LED_PORT^=_BV(STATUS_LED_PIN);

#define status_led_init()\
STATUS_LED_DDR|=_BV(STATUS_LED_PIN);

#else

#define status_led_on() {}
#define status_led_off() {}
#define status_led_toggle() {}
#define status_led_init() {}
	
#endif


#endif /* __CONFIG_H__ */

Only thing I changed was the reset and backlight pins, which were on PORTB and I set them to PORTA now. Also disabled status LED.

 

First question - can someone check out if everything is connected properly and is config.h set up correctly?

 

Second question - I noticed something weird with the library.

Part of the library code was written in assembly (.s files). When I included all what was necessary, I was still getting errors with missing functions, the ones that were written in assembly. When I tried including the .s files, it was giving me compilation errors (I think the compiler tried to compile it as C, not as assembly). What I did was click "Show all files" in solution explorer in Atmel Studio and then clicked on the .S files that appeared and selected "Include in project". 

After that, the compilation errors went away and I could run the code.

 

Example:

#include <avr/io.h>
#include "UTFT.cpp"
#include "color.c"
#include "had.c"
#include "DefaultFonts.c"
#include "ssd1289.c"

int main()
{
	UTFT display;
	
	display.InitLCD(LANDSCAPE);
	display.setFont(BigFont);
	display.clrScr();
	//status_led_init();
	
	while(1)
	{
		
	display.print("Hello world!", 10, 10, 0);
		
		
	}
	
}

This gives no compilation errors but after running this code, the display is just lighting up a bit and flickering, nothing else.

I am running the whole system on 3.3V since I've read that the SSD1289 controller works with 3.3V. 

 

I'd really appreciate it if someone could take a look at the code and tell me what I am doing wrong here. I got a lot of help for my SD card integration and now it works great.

Thanks in advance!

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

Yes,  it is SSD1289 and yes,  you need 3.3V logic.

 

ATmega32 has JTAG on PORTC.     Disable with JTD or JTAGEN.

You are using PORTD, PORTC as the data bus.  PORTA for control signals.

 

Yes,  UTFT will run on a 32kB MCU but you will only be able to run simple programs.

 

I am horrified by the program "structure" e.g. #include-ing C files in a C++ program.

I presume that it "worked" for the Author.   So I would copy exactly.  i.e. use exactly the same GPIO port pins.

 

Seriously,   a MEGA2560 clone is cheap.   An Arduino 40-pin Adapter shield is cheap.

You would be able to run every UTFT program without worries.    And use up to date Arduino UTFT library.

 

David.

Last Edited: Sat. May 9, 2020 - 07:59 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thing is, this is a student project for which I am given the hardware. If I could just order (and had time to do that) Arduino board which have finished code for them, I would've done that a long time ago.

I started with ATmega16 but it turned out impossible to implement all that I need on so little memory. So I got the ATmega32 from my mentor. :)

 

But, I disabled JTAG with the JTD bit in MCUCSR and now it worked, I got my hello world! Thing is, my MCU is not reachable anymore since I disabled JTAG but I use it for connecting the MCU and uploading code. 

How to use PORTC and still be able to upload code over JTAG?

Last Edited: Sat. May 9, 2020 - 08:14 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hmm I realized I may have a problem here. I've read in a thread and someone said that in order to reset JTAG I need to:

" You have to connect the RESET-pin of your microcontroller to the RESET-pin in the JTAG header. You should then be able to use JTAG again. "

 

Does that mean physically touching the RESET pin (pin 9 in my case) to the reset pin of the JTAG header? I really don't want to fry anything here :|

                      

 

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

You can upload your HEX file via SPI or via JTAG.

What programmer do you have?

 

The JTAG header has nSRST (pin#6).   The 10-way ribbon from your programmer will have this signal.   Your dev board header will connect this to the AVR Reset pin.    

You don't need to alter any hardware.   However there will be a checkbox in your programming software.    You need to tick this box to enable the nSRST signal.

 

You can program via JTAG

Your program sets JTD twice at the beginning of main().

You can not debug the program.

 

Since you can't debug (after JTD),  there is no advantage in using JTAG.

I would choose whichever inteface has the convenient header and matching ribbon.

 

David.

 

Edit.   Ouch.  You have the ARM JTAG/SWD pinout in #4.   AVR JTAG pinout is different.    It is very important to use the correct programmer, ribbon, header pinout.

You will struggle to do FatFs and UTFT on a 32kB AVR.    It should be possible if you are careful with memory.

Last Edited: Sat. May 9, 2020 - 09:02 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

I am using the JTAGICE mkII-CN programmer like THIS one.

 

What I did was alter my code for my display by setting the JTD bit twice at the beginning of main(). After that the display started working, which is great.

However, I can't communicate with my device anymore over JTAG. 

What are the exact steps I need to do with ATmel Studio 7 to reset the MCUCSR register, that is set the JTD bit to 0 again? How to exactly use the nSRST pin to do that?

Don't think I quite understood what you mean with this below.

 

david.prentice wrote:

The JTAG header has nSRST (pin#6).   The 10-way ribbon from your programmer will have this signal.   Your dev board header will connect this to the AVR Reset pin.    

You don't need to alter any hardware.   However there will be a checkbox in your programming software.    You need to tick this box to enable the nSRST signal.

 

This is the dev board I am using:

 

 

EDIT: I am aware of the memory constraints, but right now getting JTAG communication back up is a priority. I live in a small town in Croatia and I don't think I can find the ISP interface for communication anywhere locally, and with my deadline approaching I don't have time to order online. 

 

Last Edited: Sat. May 9, 2020 - 09:12 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Personally,   I would use PORTA, PORTD for the data bus.   PC0, PC1, PC6, PC7 for control signals.  LED and RD connect to 3.3V.  LED needs a series resistor e.g. 10R.

 

This would release PC2-PC5 for JTAG.   If you ever use the LCD_RD pin,  connect it to PORTB somewhere.

 

Your programmer and dev board have correct JTAG sockets (and 10-way ribbon)

But you could use your programmer ISP10PIN header and dev board ISP header for programming if you wanted.

 

As I said in #2,  it is safer to copy the exact wiring used by the Tutorial project.    But this does prevent you debugging with JTAG.

 

David.

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

Thanks for the tips, but that does not help me resolve the crucial issue I am currently having. I need to re-establish communication with my microcontroller, is there any way to do the reset externally?

THIS thread talks about the issue, post #2 says :

" You have to connect the RESET-pin of your microcontroller to the RESET-pin in the JTAG header. You should then be able to use JTAG again. "

 

I am hoping that can help me but I need confirmation on this, if it's doable!

 

EDIT: Did I understand correctly that I can use the same programmer and same cable to connect to ISP instead of JTAG and program my device that way? What do I need to change to do that? 

Last Edited: Sat. May 9, 2020 - 10:03 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What software do you use?   AS4.xx or AS7.0 ?

These both have a checkbox for "enabling nSRST".

 

Your dev board pcb will already have nSRST on JTAG header connected to /RESET on the PDIP40.

 

The MCUZONE programmer will have everything present on its ISP10PIN and JTAG headers.

You do nothing more than plug in the 10-way ribbon.

 

David.

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

I use Atmel Studio 7.0. I don't know where to find the nSRST option to be honest, the checkbox you are mentioning. 

The programmer has one 10PIN socket on it, looks like this:

 

When I connect the ribbon that I usually connect to JTAG header on the board, to the ISP header, the board won't turn on.

When I pull out the ribbon from ISP, it turns on. So it's definitely not liking me plugging it into the ISP header. 

 

Don't know what to make of it really!

Last Edited: Sat. May 9, 2020 - 10:39 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In AS7.0 "Device Programming"

1. Tool = JTAGICE-2

2. Device = ATmega32

3. Interface = JTAG

4. Read Signature

5. Interface settings:  [x] Use external reset

6. Memories:  Program, Verify, ...

 

(5) enables the nSRST pin.   (marked SRST in your photo)

 

Regarding ISP10PIN header.   You would need to read the MCUZONE docs.

Since you are using JTAG ok,  this does not really matter.

 

David.

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

My friend... If you ever find yourself in Rijeka, Croatia, you have a bloody case of beer waiting for you!

Thank you so much for the patience, it worked and I regained control of the device!

 

david.prentice wrote:
Personally,   I would use PORTA, PORTD for the data bus.   PC0, PC1, PC6, PC7 for control signals.  LED and RD connect to 3.3V.  LED needs a series resistor e.g. 10R.

 

What you said here - I need to connect the LED_A and RD pins of the display to VCC, that is 3.3V? Thing is, my board has 4 VCC pins, since I already have an SD card and GPS connected, I have 2 left free.

Can I use one VCC pin on my board for the VCC and RD pins on my display together using a breadboard and one remaining VCC pin for the LED_A pin through a resistor then? Would that work?

Since the display started working after I set the JTD bit, I am wondering why is this necessary?

 

Also, I need USART for my GPS so I need PD0 and PD1 pins. I basically don't have two completely free ports to connect the high and low data ports for the LCD... Not sure how I am going to go around this problem right now. 

We have a saying that morning is more clever than evening, hoping for that to work. :)

Last Edited: Sat. May 9, 2020 - 11:47 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Your photo shows J6 (System Power Select) is set for 5V.   You must use 3.3V

 

The "Power Header" (to the left of the power LED) has 4 VCC and 4 GND pins.

So there are plenty of 3.3V pins to attach Dupont jumper cables.

 

If everything works first time,  you don't need JTAG debugging.

But if you want JTAG debugging,  you must choose different pins for the data bus.

 

Yes, driving a data bus with two 8-bit PORTs is simple.   But it should not be too hard to rearrange a few pins.

Life is much easier with an 8-bit parallel TFT.   Unfortunately your display is 16-bit only.

 

I don't know what impresses your Professor.   Driving a bare mega32 or "usable commercial product" based on Arduino hardware.

i.e. spending time and effort on low-level AVR hardware or using that "time and effort" on the high-level C++ software.

 

Whichever style of project,   your Professor will pay a lot of attention to your documentation.   e.g. a well written project description,  design, operation, user manual ... is just as important as whether it "works"

 

David.

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

The photo is an old one I took before, I am running the system on 3.3V, no worries. 

 

Yep, I have 4xVCC pins but I need to connect a GPS, an SD card and the display. That takes up 3 of the 4 VCC pins.

 

Question: How can I connect the LED_A and RD pins to the last VCC pin I have left free?

 

 

 

As far as rearranging a few pins, I need to look in the code but I am not sure I can do it. This is how the pins are defined right now:

#define DATA_PORT_LOW PORTD
#define DATA_PORT_HIGH PORTC
#define DATA_PORT_LOW_DDR DDRD
#define DATA_PORT_HIGH_DDR DDRC

So I need to split up DATA_PORT_LOW on PORTD and make 2 pins from there (which are used up by USART) connect to PORTB for example. 

 

Regarding the documentation - I am perfectly aware of that, I've already begun writing the documentation for the project so it will definitely be there.

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

There is a VCC pin on the ISP header.   If J5 is for active-low LEDs,   one of the J5 pins will be 3.3V

 

I suggest that you either post a link to the dev board schematic or test these pins with a DMM first.

 

If you are really stuck for spare VCC pins,  just solder two Dupont cables together at one end.

 

Regarding split PORTs for the data bus.   You use & and | operators to write to individual bits on the split ports.

 

David,

 

p.s. do a pin budget e.g. data = 16, ctrl = 5, usart = 2, SD card = 4, JTAG = 4 

So you even have a spare pin.   But it means splitting the data bus over 3 ports e.g. PORTA, PC0-PC1, PD2-PD7.   Ctrl on PC6-PC7,  PB0-PB2

Last Edited: Sun. May 10, 2020 - 10:53 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Here is the dev board schematic:

 

Seems you were right, pin 2 of J5 (led_enable) is VCC, so I can use that for VCC? That is, connect that to a resistor and then to LED_A pin? 

 

Regarding the pin budget, I did that last night actually. Turned out something like this:

 

GPS 2 pins : PD0, PD1 (USART)

SD card 4 pins : PB4 -> PB7 (SPI)

Buttons 2 pins (connected on PORTB, plan on using two of them) : PB0, PB1

Display data 16 pins : (PA0 -> PA7) + (PD2 -> PD7) + (PC0, PC1) 

Display control RESET, CS pins : PB2, PB3

Display control RS, WR pins: PC6, PC7

JTAG 4 pins : PC2->PC5

 

This is with LED_A and RD pins connected to VCC (not to the I/O pins) as you said it should be. This way I am using literally every single pin on the MCU :)

Does this seem right?

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

Yes,  that seems fine.   Most TFT projects never read the TFT.   So LCD_RD pin is never used.

 

Your first job is to write a suitable function for writing 16 bits to the data bus.

And configuring all the port pins.

 

I am horrified by the "gizmogarage style" e.g. 'included C in C++ file

The use of S files.

The website name even worries me.

 

If the author had a regular name and followed worldwide conventions,   I would read his code.

As it stands,   I wash my hands of it.

What will your Professor think?

 

We can help you with individual functions.   Just ask.

 

David.

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

I won't be reading from the LCD, so can I just leave the RD pin unconnected?

 

I am aware that the library from gizmo garage may not be standard convention style but it's the most complete implementation of UTFT made for non-Arduino boards. I am not that worried what will my mentor think because he uploaded that very library for us to use.

I tried using the standard UTFT library but it was made for Arduino and it seems a lot more complicated to use it than this already made library, which works out of the box. Although it may not be adhering to certain conventions (mixing C/C++/ASM).

 

I just need to somehow alter the config.h file to split up the data bits over the ports. This is how it looks now:

#define DATA_PORT_LOW PORTD
#define DATA_PORT_HIGH PORTC
#define DATA_PORT_LOW_DDR DDRD
#define DATA_PORT_HIGH_DDR DDRC

I tried to do this for DATA_PORT_HIGH:

#define DATA_PORT_HIGH ((1<<PC0) | (1<<PC1) | (1<<PD2) | (1<<PD3) | (1<<PD4) | (1<<PD5) | (1<<PD6) | (1<<PD7))

But it doesn't work really, gives me a bunch of compilation errors. Not sure how I am supposed to proceed with this logic. 

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

Find all the DATA_PORT_HIGH statements.

 

I suspect that you have something like this:

void write_data16(uint16_t x)
{
    DATA_PORT_HIGH = x >> 8;
    DATA_PORT_LOW = x & 0xFF;
}
//assuming that you have PORTA for DATA_PORT_LOW and PD2-PD7, PC0-PC1 for HIGH
void write_data16(uint16_t x)
{
    uint8_t hi = (x >> 8);
    uint8_t lo = x & 0xFF;    
    PORTD = (PORTD & 0x03) | (hi & 0xFC);
    PORTC = (PORTC & 0xFC) | (hi & 0x03); 
    PORTA = lo;
}

Likewise,  the DDR statement will be similar.

 

First off.   You need to see how Mr Gizmo has accessed the data bus.

 

It looks as if I created a UTFT project in Atmel Studio in 2014.   For mega328P and mega128 targets.

So it would be a similar vintage to Mr Gizmo.

 

David.

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

Alright, so I've edited the code to not use the RD pin anymore. I connected the LED_A pin through an 330ohm resistor (when I connect it through a 10K you can barely see anything on the screen) to VCC and commented out the back light pin configuration from config.h so it's not using the I/O pin anymore.

 

Last thing I need is help with splitting up this definition of DATA_PORT_LOW/HIGH from a single PORTx to individual bits from different PORTs, e.g. PC0, PC1, PD2, PD3, PD4, PD5, PD6, PD7. 

Same thing with DATA_PORT_LOW/HIGH_DDR. 

 

How can this be accomplished?

 

EDIT: Posted at the same time, need to look at what you written now, thanks!

Last Edited: Sun. May 10, 2020 - 12:56 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok so after defining:

#define DATA_PORT_LOW PORTx
#define DATA_PORT_HIGH PORTx
#define DATA_PORT_LOW_DDR DDRx
#define DATA_PORT_HIGH_DDR DDRx

Gizmo defines DPLIO and DPHIO for use in the .asm functions like this in config.h:

#define DPLIO _SFR_IO_ADDR(DATA_PORT_LOW)
#define DPHIO _SFR_IO_ADDR(DATA_PORT_HIGH)

 

Does this mean I have to edit every function that uses DPHIO and DPLIO in the assembler functions?

Or can I edit the definitions somehow in config.h so it gets carried over to the assembler functions without editing them? 

 

In my mind it means somehow mapping DATA_PORT_LOW/HIGH to individual bits (PC0, PC1, PD2, PD3, PD4, PD5, PD6, PD7), instead of whole PORTD.

Is that somehow feasible?

Last Edited: Sun. May 10, 2020 - 01:20 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I suggested 10R.  330R would be fairly dim.   10k would be dark.

 

The genuine UTFT has

void UTFT::LCD_Writ_Bus(char VH,char VL, byte mode)

which can be tidied up easily.

 

David.

 

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

Right now I only have 330ohm and 10K ohm so I'll need to check my hardware store tomorrow to get a 10ohm one, it is fairly dim right now with the 330 one.

 

OK, I am thinking about transitioning to the genuine UTFT library. I created a new project which includes the standard UTFT library but the first compilation error I am getting is that I am missing arduino.h. 

 

Besides that, I should use the HW_ATmega1280.h file for my project because you said it's almost the same as my ATmega32?

I see that I need to edit the 'void UTFT::_hw_special_init()' function to suit my hardware but I am not sure what I need to add here. If we take into consideration that I leave the hardware connected as it is (described in post #16).

Also, what to do with the missing arduino.h library? Since I am not really using arduino.

 

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

As a temporary fix, put multiple 330 in parallel to reduce the value... this will give you an idea as to your final required value.

 

Neil

Last Edited: Sun. May 10, 2020 - 01:55 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for the tip, but currently I am way more worried about porting this UTFT library to my ATmega32. So much is missing since I don't have arduino.h library...

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

Most TFT projects never read the TFT.   So LCD_RD pin is never used.

But if you need a BIG sample buffer etc. The display is a very nice big RAM.  

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

So basically the whole project is about tracking, storing and displaying a traveled path. The GPS stores coordinates on the SD card which I use to draw the points on the display and connect those points with lines... and I have the traveled path. 

That is the idea, so my display will only be used to display static data.

 

What I need right now is either a way to edit the Gizmo garage library (which works fine for me currently) to split up the HIGH and LOW bits to different PORTs, instead of just one because my JTAG is preventing me from using the whole PORTC.

 

It's either that, or using the obviously better and up to date UTFT library. Thing is, I don't have Arduino but just an ATmega32 on a Chinese dev board and the UTFT library is missing A LOT of stuff for my case. I am still pretty green as far as AVR is concerned and I don't know where and how to start filling in these parts for the UTFT library. 

 

And nope, I can't just order an Arduino and use it, I have to use the hardware provided. :(

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

If your professor wants you to use the Gizmo code,  stick with it.    Professors like you to agree with them.

 

There will be some initialisation function where the DDR is set for data bus and ctrl pins.   Adapt for the split data bus.

There will be some LCD_Writ_Bus() function.   Adapt for the split data bus.

 

Since you have the display working with PORTC and PORTD I would start by just moving some control pins.

I suspect that the #defines will cope with different pins and different ports.

Test that your display still works.

 

Then move the data bus.

Test that your display still works.

 

Only you know your Professor's mind.

I suggest that you get the Gizmo code working 100% with your chosen wiring scheme.

 

If you choose to be "arduino-style" post your successful Gizmo adapted functions.

Then we can show you how to make a dummy Arduino.h

 

David.

Last Edited: Sun. May 10, 2020 - 02:28 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I can easily move the control pins around different ports, since every single control pin has it's own define. That part is easy.

The problem are the data pins since their defined with two ports which I really don't understand how to split up.

 

I really don't understand how to do this.

 

david.prentice wrote:

There will be some initialisation function where the DDR is set for data bus and ctrl pins.   Adapt for the split data bus.

There will be some LCD_Writ_Bus() function.   Adapt for the split data bus.

 

There is a LCD_Write_Bus function, but it's written in assembler which I barely understand. 

I have 9 days til my deadline and I am pretty overwhelmed with everything right now, don't think I can tinker this deep with assembler and editing these functions.

Last Edited: Sun. May 10, 2020 - 02:53 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Go on.   The C functions are pretty straightforward.  Especially when there only two bits to move.   And they go to the same bit-positions in another port.

 

If you have located the LCD_Writ_Bus() function in an S file,   just say what you don't understand.

Show your attempts.   And we can explain.

 

It would not be appropriate for us to write your thesis.    But we can certainly review your LCD_Writ_Bus() code.

 

David.

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

The little three pin IC named IC1 (on the back of the TFT board next to DB0) is a 5V-to-3.3 voltage regulator.  If you are putting 3.3V into the VCC pin of the TFT board, then you should put a dot of solder on J1.  This ensures that the 3.3V Vcc goes to the the TFT circuitry instead of into the 5-to3.3 regulator.

 

If this individual TFT unit has been operational before (if someone was able to get it working from a previous year of your school class) and you are certain that both the pin-out is correct and that the TFT controller is SSD1289,  then you are well advanced in getting this TFT to work.  If the screen flickers at power-up, then either the TFT initialization code is not correct, the wiring is not correct, the lowest-level of linkage between the AVR and the TFT in the TFT library is not correct, or the AVR is not sending the right commands needed to light up the individual pixels of the display.

 

I have been using TFTs for about seven years; using both SPI and 8-bit Parallel interfaces.  I use David Prentice's MCUFRIEND code and Adafruit libraries.  I have never been able to get a TFT working with UTFT code.  I believe that this is because the linkage between general-purpose UTFT code and the many types of TFT-controllers is so poorly documented and that the UTFT designers don't have the sense to post working versions of their code specifically for the one of the top five or ten most-commonly-used TFT controllers that the user has.

 

You may have to write your own code to control this TFT with Mega32.  Basically you write the list 30 or so commands that initialize the TFT, and then write or use a function that writes an individual pixel to a specific color.  Usually you send commands to define the X and Y co-ordinates of the area of the screen where the pixels will be lighted.  Then write the command to set the exact X-Y location of the first pixel.  Then  write as data the 16-bit color in 5-bits-red/6-bits-green/5 bits-blue format.  The TFT controller will advance the pixel pointer to the next internal mem location.  This will be either up/down/left/right of the first pixel according to the initialization parameters that you sent.

 

Once you have control of one pixel, then you can use/adapt all the other graphics library functions to call the draw-pixel function.

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

The little three pin IC named IC1 (on the back of the TFT board next to DB0) is a 5V-to-3.3 voltage regulator.  If you are putting 3.3V into the VCC pin of the TFT board, then you should put a dot of solder on J1.  This ensures that the 3.3V Vcc goes to the the TFT circuitry instead of into the 5-to3.3 regulator.

Yes,  the regulator takes 5V.   If you have a 3.3V supply,  you short J1.    The display will still work with 3.3V and open J1.  

 

I have never been able to get a TFT working with UTFT code.

Rubbish.  UTFT is incredibly easy to adapt for different controllers and for different interfaces.    The source code is public.

Henning Karlsen supports several well known makes of display.   He does not support makes that he does not like.

 

The OP has only got to configure some #defines and adapt two functions.

 

David.

Last Edited: Sun. May 10, 2020 - 04:27 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@Simonetta

 

Thanks for the tips, but the screen is initialized and works properly right now with the modified UTFT library for AVR by GizmoGarage. The problem is the implementation of the code, with the high and low parts of the 16 bit data bus being divided onto two whole PORTx. While I want to connect them partially over 3 different ports.

 

@david.prentice

Thank you so much for the patience and help but as I see it, going too deep into this will take too much time from me, which I don't have. If I had a month to figure this out I would do it, but with 9 days left - I am starting to feel too much pressure.

That's why I decided to just use whole PORTC for the high part of the data bus.

 

What I am going to do is to develop the rest of the project without connecting USART, that is use PORTA and PORTD do drive the display while I figure out the rest of the code. 
When I have everything logically programmed, I will connect the display to PORTC and just change the definitions to use PORTC instead of PORTD (and set the JTD bit to disable JTAG). If any changes are necessary I can always use the external reset to change the code.

 



 

SO, with that said I am shifting my focus on actually displaying the data on my display.

Right now, I got the coordinates on my SD card and I am trying to figure out how to display it on the screen in a logical way. 

 

Thing is, since I have a limited number of pixels (320x240) I have to somehow figure out what is the best way to map the actual coordinates to the pixels on the screen.

So for example: if I was moving 11 Km/h (~3 m/s) and mapping my coordinates every 2 seconds how much would my recorded coordinates change and how should I map that change on the display.

The case is very much different if I was moving 150 Km/h. 

 

I am basically looking to do something like @DocJC mentioned doing in my old thread HERE.

 

 

Thank you @DocJC for providing a visual example of what I want also!

 

I need to work out how I am going to deal with this. I'd appreciate any input on how I should handle this mapping of movement on the display!

Last Edited: Sun. May 10, 2020 - 05:05 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My apologies.    I had refused to look at the Gizmo S files from prejudice/snobbery.

After I had claimed "The OP has only got to configure some #defines and adapt two functions."   I thought that I had better read the S files.

 

In fact they would be a nightmare to adapt.

 

So you are wise to stick with PORTC, PORTA.

 

Incidentally,   my assertion would apply to the original UTFT library code.  i.e. very simple.

 

David.

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

No worries my friend, no need to apologize! You still helped me tremendously with setting up Gizmos library and working out the JTAG issues. 

I'll do it with PORTA+PORTD for now  then just swap to PORTC+PORTA when I have all the needed code to display the data.

 

Right now I am having headaches with displaying the data, will need some time to figure out how to map the GPS data to my display. 

Any advice is greatly appreciated!

Last Edited: Sun. May 10, 2020 - 06:08 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Nemanja,

It is good to hear that you project is coming together.

 

Mapping the data, once you can plot pixels, is the easy part!

 

Do you have the ability to plot pixels?

Do you have the ability to plot (display) text?

 

The "easiest" way to display text is to simply map the display into a grid, (rows and columns).

You "plot" each character in a box on the grid, this is a "fixed font", so a character "i" takes the same width on the display as a "W" or an "M". 

Have an array of 8 x 8 (or whatever) pixels for each character.

The array holds Bytes of data for each row of pixels, top to bottom, for the pixels that make up the character to be displayed.  0 = pixel is off, 1 = display that pixel.

You write a routine that takes a character, reads in that character's pixel data, row by row, and plots the required pixels.  It can plot them directly on the display, or into a memory map for the display, which is then updated.

It can all be slow, you don't need speed for your project as you are not trying to display real time video.

 

Next, to display the traveled path:

Mapping programs typically work in Decimal Degrees, not Degrees, Minutes, Seconds, for the Latitude and Longitude of the geographic coordinates.

Wiki is your friend here, and can explain it with images much better than I can.

Decimal degrees: https://en.wikipedia.org/wiki/De...

This site, Wiki Latitude, has LOTS of math.  Fortunately you can ignore 90% of it!

https://en.wikipedia.org/wiki/La...

 

Another good term is Wiki "Great Circle Navigation":

https://en.wikipedia.org/wiki/Gr...

That has more math, and some good links to look through.  You, fortunately, can skip the math once you understand the assumptions and simplifications you are making for your project.

 

The overall concept is that for accurate plotting on the surface of a sphere it is easiest to use spherical coordinates for the calculations.  You should read up on this to develop an understanding of it, and then SKIP IT.  You don't need it.

 

For "short" distances",  just ASSUME a rectilinear grid and coordinate system, (i.e. an X and Y axis that are perpendicular to each other).

The image I showed does just that.  The horizontal axis is 81.8 W to 81.4 W Longitude.  Technically, on a sphere, the top edge of the graph should be a little bit closer together than the bottom edge. 

 

If you want to aim a directional antenna to a specific country, or fly an airplane a long distance, then spherical trig is required.  For plotting your short distance trips, on foot, bike, or car, use a rectilinear grid (graph, plot...).

 

Understanding that approximation is important, and you should discuss it a little bit in your project report.

 

Next, if you want to test or demonstrate your project, the scale for you walking around your neighborhood is very different from a scale for you driving +/- 10 KM from home. 

 

For any given trip one might scan the GPS data and convert the Lat and Long data into a floating point number, eg. 81.76234 Degrees W Longitude, and ... Degrees North Latitude.

Now scan the data and find the range for the Lat and Long.  The range will be small for a short walking trip, long for a car trip.

 

It is easiest if you keep the display "square", at least for starters.  So the display will show X KM range vertically and the same X KM horizontally.

From your scan pick the larger range, and use that for your map scaling.

Perhaps you drive a car and the range of the Longitude (max - min), is 6 KM, while the range of the Lat, (max - min), is 3.6 KM.  This means you drove E/W more than you drove N/S.  

 

Pick a nice number, perhaps 8 KM for the full screen range.

 

Look at the lowest, (smallest), Lat and Long values.  Then pick the starting point for your display.  If the smallest Longitude was 81.54321 Degrees, then set your Longitude origin to 81.4 Deg, or 81.0 Degrees. some nice number less than your lowest data point.

Do the same for the Latitude.  On the graph shown, the Latitude ranged from 41.0 to 41.4 Degrees (N).

 

I think you mentioned the display's pixel size, but I don't recall the numbers.  But perhaps you want to use  400 x 40 pixels for your trip plot, and the remaining part of the display for data, (distance traveled, average speed, date and time of trip, etc.).

 

400 pixels / 0.4 degrees latitude range = 1000 pixels / Degree latitude.

 

Take any given data point, in decimal degrees, and subtract the offset for the origin of you graph.  For example your data point has Lat = 41.2 degrees.  You set the lower edge of the plot to 41.0 Degrees, so this data point is 41.2 - 41.0 = 0.2 Degrees above (N) of the lower edge of the graph.

0.2 Degrees x 1000 pixels / Degree -> 200 pixels up from the lower edge of the graph.

 

When you plot the actual data point, you have yet one more set of coordinates to keep track off.  That is the pixel location (x,y) for the origin of the graph being displayed.  If the graph starts 75 pixels above the bottom of the display, the you have to add that extra vertical offset to the data found above.

 

You do the same calc's for both the Lat and the Longitude, and you end up "mapping" the GPS coordinates to an X/Y grid on the display.

 

For short distances, and a low resolution display, using rectilinear approximations are fine. 

 

Finally, have all of that working?

Then add another array of your known / favorite locations.  Go there and record the coordinates, or pull them up on Google maps/Earth.

 

Now plot those points, (House, School, Work, Major road intersection, etc.).  Now you will have a few known locations on your display to help you "visualize" where your trip covered.  With a colored display, those can obviously be plotted in different colors that the trip data.

 

You might wish to make the above calculations on the fly, with the real data.

 

You might, for version 1 of your software, chose to fix the coordinates for the display, based upon where you live, and then have three scales, (essentially zoom factors), for displaying the data, to make it easier to code for a first approach.  For walking trips the axis cover +/- 1 KM, for driving trips they cover +/- 10 KM, etc.  The software can easily select the graph axis range based upon the distance travels range limits.

 

It goes without saying, but I'll say it anyway, you can create a fake data base with known coordinates, e.g. Long goes 41.00, 41.05, 41.10, 41.15, 41.20; and likewise for Latitude, so you can (hopefully) see a straight line plotted on the middle of your display, or a "box" for your fake trip, etc.

 

You might also want to have a User Interface that lets you select between one of several "trips".  If you had lots of time and memory, the display could show the trip's data and time.  For now just calling them trip 1, 2, 3,and 4 might be easier.  Your User Interface might ask the user to select which "map" to write / overwrite the  to.  That way you can have several stored trips on the SD card to pull up and demo your project to your Instructor.  One of the stored trips can be your test / fake / canned data while you are debugging your system.

 

Remember, one step at a time! 

Once you have your hardware platform up and running, it is now just a matter of starting simple and slowing expanding upon your program.

 

JC  

 

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

Alright, I need some concrete advice on data parsing.

 

So my idea for displaying the data is the following. I have the data on my SD card in a txt file in the following format:

4519.8241,01426.5621
4519.8101,01426.5757
4519.7930,01426.5906
4519.7809,01426.6019
4519.7698,01426.6067
4519.7594,01426.6128
4519.7517,01426.6046

 

Which actually means : 

45°19.8241',14°26.5621'

45°19.8101',14°26.5757'

.

.

.

 

These are the coordinates of every point that the GPS logged.
 

What I plan on doing is transform these coordinates to coordinates I can use on the 240x320 screen. 

Step-by-step plan:

1) Transform the coordinates to 7 digit numbers, like this:

 

4519824,1426562
4519810,1426575
4519793,1426590
4519780,1426601
4519769,1426606
4519759,1426612
4519751,1426604

 

2) Take the first point and make it center of the screen at coordinates 120, 160. I do that by taking away from the numbers how much is necessary to get to 120 and 160 (middle of the screen) respectively. This value is important in the next steps, lets call it modulatorX and modulatorY.

3) From every other coordinate pair, take away the same respective values for latitude and longitude (y and x). Latitude minus modulatorY and longitude minus modulatorX. This way I transform the coordinates from the 7 digit format to a format that I can put into the drawing functions of the display.

4) Store the new coordinate pairs in two arrays and use the drawLine function with these values to draw the crossed path. 

 

That would basically map over the crossed path to a same shape on the screen. I would also label the center of the edge of the screen with the starting coordinates so the user roughly know where he is.

 

I tested this by creating the arrays manually with values and it works quite nicely.

My problem is that I don't know how to do the data parsing and transforming to integer values from the text file that looks like the starting:

4519.8241,01426.5621
4519.8101,01426.5757
4519.7930,01426.5906
4519.7809,01426.6019
4519.7698,01426.6067
4519.7594,01426.6128
4519.7517,01426.6046

 

I need to remove the decimal dot and remove the unnecessary 0 from the longitude coordinate at the beginning (01426.5621).

Seems really complicated to do all this math and parsing on the MCU. Is this feasible? 

How do I start with doing this? 

 

EDIT: Thanks for the input Doc! Just saw it so I'll give it a read tomorrow, got work in the morning. Whenever you get the chance to take a look at my idea - feel free to drop a comment on it!

Last Edited: Sun. May 10, 2020 - 11:07 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Step 1:

There are 60 Minutes in a Degree.

 

So 19.8241 Minutes = 19.8241 / 60.0 = 0.3304 Degrees.

 

So 45Deg 19.8241 Mins = 45.03304 Degrees.

 

Minutes is 1/60th of a Degree, not 1/100th of a Degree.

 

JC

 

 

 

 

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

Yep, I am aware of the conversion. I don't know why but I went with this kind of mapping, where I just remove the decimal dot from the data that the GPS gives me. I don't really transform it to degrees, I just transform it to 7digit number that represent the original degrees and use the change in those numbers to plot the path on the display.

Don't know why but it seemed easier to do it like this for me. Will have to work out what is the easiest way to get my data (e.g.  4519.8241,01426.5621 ) in a format that I can put into the 320x240 display.

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

A technical question about ATmega32. I got an USB->ISP programmer so I don't have to use JTAG anymore and take up my PORTC by doing so. Thing is, I see that ISP uses SCK, MISO and MOSI pins on it's 10 pin header

 

Does this mean my ATmega pins PB5, PB6 and PB7 on PORTB will be disabled since they are MISO, MOSI and SCK pins? And I use those for the SPI communication for my SD reader. 

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

chiMa wrote:
Does this mean my ATmega pins PB5, PB6 and PB7 on PORTB will be disabled since they are MISO, MOSI and SCK pins? And I use those for the SPI communication for my SD reader. 
Read AVR datasheet. AVR040 and AVR042 that collectively have info about "sharing" SPI device pins with both your own SPI device(s) and also the ISP programmer. (it basically involves some resistors).

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

OK, so if I understood correctly - I need to put 330ohm resistors between my SPI connected device (SD card in this case) and the PB5, PB6 and PB7 pins, if I am using the USB to ISP programmer to program my code to the MCU? 

My USB->ISP programmer:

Last Edited: Tue. May 12, 2020 - 01:47 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ouch.   Your USBASP is set for 5V.   It will fight your existing 3V system.    A University student should know basic electricity.

 

Your MCUZONE programmer only senses voltage.   The USBASP will supply voltage on pin#2.

 

I would be pretty certain that the MCUZONE programmer can do ISP10PIN.   Read the documents.

But there is no harm in using the JTAG header just like you always do.   (And disable with JTD at runtime)

 

Regarding your other questions.   You can draw circles, crosses, squares, text, ... wherever you want on the screen.   All the UTFT methods are available.

You calculate the positions just like you would when plotting a graph on paper.

You scale just like on any map.   e.g. cm per km.   pixels per km.

 

David.

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

I haven't yet connected the programmer because I am at work, and yes I saw the jumper for voltage selection. You presume that I don't know basic electricity just by looking at a picture I posted?

I'll switch it to 3.3V and use it to program the board because it is a lot more practical to do it that way than by setting JTD at runtime. Because regaining access to the MCU over external reset every time is a bit of unneeded pain. :)

 

As for the JTAGICE and ISP10PIN, I tried multiple times to set  it up but the board just doesn't want to power up at all when I connect the 10pin cable to the ISP header on the board. That is why I am getting this ISP programmer. 

So if the USBASP supplies voltage on pin 2, does that mean it also acts as a power supply to the board?

Last Edited: Tue. May 12, 2020 - 02:51 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

chiMa wrote:
You presume that I don't know basic electricity just by looking at a picture I posted?

 

We have to "presume" as you have not told us otherwise, but can infer from the questions you ask as well...  (see next question)

 

chiMa wrote:
So if the USBASP supplies voltage on pin 2, does that mean it also acts as a power supply to the board?

 

Yes, but you knew that!

 

Jim

 

 

 

 

 

Last Edited: Tue. May 12, 2020 - 03:00 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I really don't want to argue here but all I said was "here is my programmer" and BOOM. I get put down like I was implying something stupid (that I wasn't).

 

Don't know what comments about my presumed level of knowledge/ignorance are supposed to accomplish really. I am here. I am working. I am asking. I am trying to learn. If electrics weren't my forte (and they are not), does that need pointing out so badly?

I am really thankful for all the help because it really was tremendous but am still really baffled by these comments. Does that make people feel superior or something?

Nevertheless, I still thank everyone for helping and everyone that helped me still has a beer from me if they ever visit Croatia. Never mind the mean-ness :)

Last Edited: Tue. May 12, 2020 - 03:23 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

chiMa wrote:

I'll switch it to 3.3V and use it to program the board because it is a lot more practical to do it that way than by setting JTD at runtime. Because regaining access to the MCU over external reset every time is a bit of unneeded pain. :)

You need the two JTD statements at runtime whatever way you program the board.

We showed you the checkbox in the AS7.0 Device Programming dialog.   AS7.0 should remember your setting.

JTAG programming is painless.

 

There is no harm in programming via USBASP with 3V jumper.

You don't need any series resistors for SD card.

You don't need to disconnect USBASP ribbon.

Likewise,  you don't need to disconnect JTAG ribbon.

 

However,  if you leave ribbon in place the programmer must be powered e.g. programmer USB cable plugged in.

Of course this is the most convenient arrangement for program-test-debug development cycle.

 

No,  I don't know how the MCUZONE programmer does ISP10PIN.  Only you have the manual.

I suspect that there is either another header inside the case or an adapter that plugs into the JTAG 10 pin.

 

It is wise to use whichever programmer has the correct ribbon.   Random floating wires are a bad idea (tm).

 

David.

 

Edit.   Please don't take offence.   We have all wired pins wrong.   We have all set jumpers incorrectly.   

Pictures are better than a thousand words.    But if you change a jumper from the picture,  you should explain the difference in writing.

Last Edited: Tue. May 12, 2020 - 03:39 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

No one is arguing, or putting you down, you posted a picture, and a freak warned you about how it was setup, again, we can only go on what you show us!

Details matter, parts can be damaged if ignored, not saying you ignored the advice, again, we can only go on what you show us, we can not see what you have done, nor can we know what your doing, unless you tell/show us.

So don't get upset with the help you receive, its based on what you tell/show us.

 

Jim

 

 

 

 

 

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

Ah I guess I was a bit too sensitive, after all I am forgetting that I am talking with freaks (meant in a good way) laugh

 

Just came home and set up the USBASP. Had to tinker with zadig tool to get the right drivers and set the tool up with "External tools" option in AStudio, but all in all the tool now works. I am programming the MCU over ISP, although it does need like 10 seconds to upload the code. Which is about 23Kb right now. And as you pointed out, the other power supply really is redundant now.

Gonna go work on getting my data in the right format to display it on the screen now, thanks a bunch again!

Last Edited: Tue. May 12, 2020 - 04:09 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok, so I've been experimenting with the ISP programmer and it works good, only thing is that it's pretty slow as I mentioned. Takes about 30 secs to upload and verify the code.

So I was trying to get JTAG to work again, I would use it with external resets checkbox when needed to rewrite the memory.

 

I set JTD at the beginning of main twice but my screen (which is now on PORTC) doesn't want to work. Then I've tried disabling the JTAGEN fuse which made the screen work, but then, I COMPLETELY cut off JTAG access.

After that I used avrdude and ISP to write the fuses and set (that is clear actually) JTAGEN. With that I regained access to JTAG.

 

But the problem still remains. With JTAGEN enabled and JTD set twice at the beginning of main, the screen on PORTC doesn't want to work. I also tried both disabling and enabling OCDEN but same result - screen flickering and not working.

What's peculiar is that the first time I set JTD twice the screen started working, after which I lost access to JTAG and that lead me to learn about fuses. Now, by doing the same thing I can't get the screen to work! 

 

What else could be the issue with PORTC? Does JTAGEN HAVE to be disabled if I want to use PORTC?

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

Oops.  Just looked at your schematic.   Pin #6 of the JTAG header is not connected to RESET.   I suggest that you solder a fine wire.

 

My apologies.   The checkbox will not work without the nSRST signal being connected to RESET.

 

When you have made the hardware mod,   everything should work nicely.   i.e. JTAG programming and JTD disabling.

I strongly advise you to keep JTAGEN fuse.   JTD works fine.   (do not use -O0 optimisation.  it makes JTD fail timing)

 

David.

Pages