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

Go To Last Post
66 posts / 0 new

Pages

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

Oh wow it seems you're right, Pin#6 of JTAG is not connected at all. 

What's weird is that JTAG still does go offline when I set JTD twice, i.e. I get an error when I try to program the code over it, BUT the screen just still doesn't work. Using the checkbox I CAN restore programming ability, with PORTC functionality remaining the same - not there. 

If it's not connected, why can I use the external reset checkbox to regain access to JTAG programming?

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

We have never seen your code.   You must do JTD before DDRC is set up for the data bus.

 

JTAG normally works without the nSRST signal.   i.e. it use a JTAG_RESET command.

But this will only work if JTAGEN fuse is set and JTAG has not been disabled with JTD.

 

It is wise to allow a short delay at startup for any application.   This allows an external programmer to gain control of your AVR before you execute any CLKPR or JTD statements.

 

David.

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

Hmm, DDRC is set up in the config.h file that I #include. I guess that runs before main() so that may be the problem.

Will test this evening when I get back from work and upload the code too.

 

As I understood, the external reset checkbox uses the nSRST signal. I am wondering how can I successfully reset the MCU using the checkbox if the nSRST pin isn't even connected?

As far as the delay is concerned, I think I have that configured with the fuses. I use the "external crystal high frequency with startup time 16K CK and 64ms" setting, since I have the external crystal/resonator at 8MHz on my dev board.

Does that cover the small delay you are talking about?

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

Post the code.  Ideally by ZIP your AS7.0 project and attaching the ZIP.   (if you Clean first,  the ZIP is much smaller)

 

The only reliable way of programming an existing JTD-running device is with nSRST and checkbox.

 

However,   if you have nimble fingers,  you could hold the RESET button.  Release button and click on the AS7.0 "Apply" at the same time.

This might let the programmer catch the AVR by JTAG before JTD has been executed.

You do a similar trick with inappropriate CLKPR punters.

 

Much wiser to solder a thin wire to JTAG header.

 

David.

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

The code is pretty much a mess right now because I am testing a lot of stuff but I will upload it. 

I don't really have a soldering device but I can use the dupont cables to connect the JTAG pin#6 to the MCU RESET pin. My dev board has a nice MCU "holder" with contacts between the MCU and the board that can fit a male jumper cable. Also a lever to release the MCU from the board so I can fit the male cable end before I put it back together.

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

You can access the RESET pin.   It is on the ISP header.   You can not access pin #6 of the JTAG header when the ribbon is plugged in.

 

Since you have no soldering iron,  I would just use USBASP and the ISP header.    You still need the two JTD statements since the JTAGEN fuse is present.    And it is good practice to use JTD instead of removing JTAGEN.

 

Alternatively you would need individual Dupont wires instead of the ribbon to the JTAG header.   And route the nSRST wire to the ISP header.    I do not like Dupont wires for an important connection to a programmer.   They are often worn and loose.    Use new Duponts if you attempt this procedure.

 

David.

Last Edited: Wed. May 13, 2020 - 01:04 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Alright here is the complete project archived: https://workupload.com/file/Pft4...

 

Here is the data sample I am using:

4519.8081,01426.5819
4519.8081,01426.5818
4519.8082,01426.5815
4519.8083,01426.5812

 

Right now I am in a pretty good spot I think, except for a ridiculous completely illogical baffling issue concerning data parsing I am having. 

Here is the function:

 

void parse(){
	display.InitLCD(LANDSCAPE);
	display.setFont(BigFont);

	int i=0;
	while(1){
		int n_read = sscanf(msg2, "%f,%f", &y[i], &x[i]);
		display.clrScr();
		display.printNumI(n_read, 10, 10, 0, 0);
		_delay_ms(1000);
		if (n_read != 2) {
			display.clrScr();
			display.print("PARSE NOT OK!", 10,10,0);
			break;
		}
		i++;

		if(i>=4){
			break;
		}

		msg2 = strchr(msg2, '\n');
		if (msg2 == NULL) {
			break;
		}

		msg2++;
	}

	display.clrScr();
	display.print("PARSE OK!", 10,10,0);

	flag=0;
}

 

Basically, the parse function I've written works perfectly when I run it on my PC with the IDENTICAL string I input to parse. The data from the string gets separated nicely to two float arrays.

The IDENTICAL function when I run it on the MCU does not want to parse the data! 

 

I've literally printed out the data that is read from the SD card character by character on the screen and it is identical to the actual string on the SD card, no stray characters that could interfere with the parse.

Nevertheless, I still tried HARDCODING the string from the SD card without really reading it and then running the parse - SAME results! I can't parse it and my float arrays stay empty!

 

I am reading what sscanf is returning - it's 0 for some reason, meaning it didn't find the data in the format I specified. Something even more peculiar is that, the if (n_read !=2) does not get triggered and it never breaks with NOT OK message, although I printed the n_read value and IT IS ZERO!

 

One thing is that I compile the function on the PC as .c, while the MCU main is cpp. But it shouldn't make any difference.

 

Could someone look at the code or just the parse function? What am I missing here??

 

UPDATE: I've found the issue.  https://www.reddit.com/r/embedded/comments/6daguh/floating_point_support_in_sscanf/?utm_source=amp&utm_medium=&utm_content=post_body
Seems like sscanf does not like floating point. I am baffled, I don't know what to do if I can't convert the data from the SD into a workable format, my whole project literally breaks down.

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

Alright, just to give an update if anyone is interested. The project is done! The project is here if anyone wants to take a look and give any recommendations: https://workupload.com/file/7kFq...    (PWD is: OhYeahh1!)

Comments are in croatian so I guess they won't be of too much use to you :)

 

I've ended up with 95% flash memory usage (WITH the optimize for size toolchain option), around 31 of 32 total kilobytes :D The system is solidly robust, sometimes it does a memory overflow (I think?) and the screen goes white but it can be reset easily and you can come back to the main menu with just the RESET button. No data is ever lost because it's all on the SD card.

Otherwise, one can start tracking (INT0) and save the coordinates to the SD card, load that data (KEY2) and then visualize that data (KEY3). Or, my own presaved trip can be loaded (KEY1) and visualized (KEY3).

Also, you can delete the saved trip (KEY4) and then start a new track.

All in all it actually turned out nicer than I thought it would.

 

Now at last, I just wanted to give a big shout-out to a few freaks...

First of all mister @david.prentice who has guided me through the initial hardware setup and helped me set up the configuration and regain access when I almost started crying... The project really wouldn't have gone far without him! Big thanks!!!

Secondly, @DocJC who helped me tremendously with the general ideas about mapping the coordinates from the data I have. 

This line of code:

display.drawLine(220-(int)((maxlong-x[i])*ratioLon)+10, (int)((maxlati-y[i])*ratioLat)+10, 220-(int)((maxlong-x[i+1])*ratioLon)+10, (int)((maxlati-y[i+1])*ratioLat)+10);

...is all your words transfused into code! With a bit of my own adjustments of course... :) 

Last but not least, all the other freaks that chipped in with suggestions in this or the other thread -  @clawson, @awneil, @ki0bk and anyone else I may have forgotten to mention.

 

It's actually been a cool experience, I've learned the value every single kilobyte of memory and how important dynamic memory allocation is when you're working with these small units. 

I am used to gigahertzes and terabytes, but pretty cool stuff can be done in the kilobyte&megahertz range!

 

Again, thanks to everyone, wouldn't be a bachelor soon if it wasn't for everyone here. I am also definitely going to give a shout-out to the avrfreaks forum in my 'thanks' section of my official document! Cheers!

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

chiMa wrote:
The system is solidly robust, sometimes it does a memory overflow
Those are contradictory statements.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

Congratulations on both your project and your degree!

 

JC

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

chiMa wrote:

Seems like sscanf does not like floating point. I am baffled, I don't know what to do if I can't convert the data from the SD into a workable format, my whole project literally breaks down.

Default printf() and default scanf() omit floating point support.

You select the "full-fat" library versions for the linker.   They use quite a bit more Flash memory.

 

The good news is that you have 95% flash memory usage which means you still have 5% spare i.e. 1600 bytes.   Which might be enough for the bigger scanf().

However there are better ways than scanf().   Just ask.

 

chiMa wrote:
The system is solidly robust, sometimes it does a memory overflow (I think?) and the screen goes white but it can be reset easily and you can come back to the main menu with just the RESET button.

This is BAD news.   You should be more careful with your SRAM use.   e.g. keep anonymous strings in PROGMEM.   appropriate width of variables,  size of arrays, ...

 

What did you do with JTAG ?

 

David.

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

joeymorin wrote:

chiMa wrote:
The system is solidly robust, sometimes it does a memory overflow
Those are contradictory statements.

Well, the system definitely will not be used for army navigation, it's more a proof of concept. I believe a stray overflow here and there which can be remediated with just the press of a button is good enough.

DocJC wrote:

Congratulations on both your project and your degree!

 

JC

Thank you Doc!

 

david.prentice wrote:

chiMa wrote:

Seems like sscanf does not like floating point. I am baffled, I don't know what to do if I can't convert the data from the SD into a workable format, my whole project literally breaks down.

Default printf() and default scanf() omit floating point support.

You select the "full-fat" library versions for the linker.   They use quite a bit more Flash memory.

 

The good news is that you have 95% flash memory usage which means you still have 5% spare i.e. 1600 bytes.   Which might be enough for the bigger scanf().

However there are better ways than scanf().   Just ask.

 

chiMa wrote:
The system is solidly robust, sometimes it does a memory overflow (I think?) and the screen goes white but it can be reset easily and you can come back to the main menu with just the RESET button.

This is BAD news.   You should be more careful with your SRAM use.   e.g. keep anonymous strings in PROGMEM.   appropriate width of variables,  size of arrays, ...

 

What did you do with JTAG ?

 

David.

 

As far as printf and scanf are concerned, I managed to find a workaround. When reading the line for the values, I don't scan the variables as float, but as two integer numbers separated by the decimal dot. So I have 4 int buffer variables which I read, after which I do a calculation on them to bring them into the desired float format. i.e. after calculating them I save them in a float array (which I couldn't sscanf directly into). 

for(;;){
		f_read(&fil, &line, sizeof(line), &br);
		if (br < 19){
			y[i] = EOF;
			x[i] = EOF;
			break;
		}
		line[20] = '\0';
		line[21] = '\0';
		
		sscanf(line, "%d.%d,%d.%d", &y2, &y3, &x2, &x3);
		
		//pretvaranje int buffera u float vrijednosti i spremanje u array
		x[i] = x2 + (float)x3/10000;
		y[i] = y2 + (float)y3/10000;
		
		//pretvaranje koordinata u decimalni oblik
		x[i] = ((fmod(x[i], 100))/60)+(int)x[i]/100;
		y[i] = ((fmod(y[i], 100))/60)+(int)y[i]/100;
		
		//dinamicko alociranje dodatne memorije za sljedeci element
		y =(float*)realloc(y, (i+2)*sizeof(float));
		x =(float*)realloc(x, (i+2)*sizeof(float));
		i++;
	}

Also right after saving them, I turn them into decimal format. After that, thanks to Doc, it's quite simple. :)

 

I was very careful with the variables. I don't even declare any size of arrays (except when I exactly know how long it needs to be), but I do dynamic memory allocation. 

E.g. for the float arrays which store the coordinates, first I allocate space just for one variable in the array. After storing the coordinate in the array in the loop above, I reallocate space for one more and so on.

When I detect less than a complete line of coordinates read from the file, I put EOF into the array and break the loop. That's how I know where the array end is.

 

I am not sure if the occasional white screen actually IS due to memory overflow. After reading coordinates from different files a few times and visualizing them, sometimes the screen goes white and I have to reset the program, which just brings me back to the main menu.

I thought that maybe the file open (which takes 512 bytes?) causes it to crash after opening a few times, but then again I always do a file close after opening it so am not really sure what's going on. Memory overflow was just a guess actually. 

 

As far as JTAG is concerned, I disabled it with the JTAGEN fuse so it doesn't bother me anymore. PORTC works properly and I was programming the MCU over the SPI. Probably lost a few hours over the course of a few days since every code upload took ~30ish seconds. Multiply that by 100 for every day.... But I could work without interrupts and it was good enough.

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

I would definitely avoid malloc() and realloc() in an embedded program.

 

You generally know how many floats you might have in an array.   Or what you might use as local variables.

 

The scanf("%d.%d") will fail on "123".   And you need to remember the sign.

 

The good news is that you can create some test data.   Then parse with your PC or with the AVR to check everything is ok.

 

David.

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

chiMa wrote:
I believe a stray overflow here and there which can be remediated with just the press of a button is good enough.
We believe in very different things.  It's your project.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

The thing is that I generally don't know how many coordinate pairs will be generated when tracking. This way an indefinite amount can be stored, as long as there is enough memory on the MCU. 

The sscanf function will always scan input in the same format, i.e the data that the GPS stores on the SD is formatted as yyyy.yyyy,xxxxx.xxxx. Latitude has 4 digits before decimal point and 4 after, longitude 5 before and 4 after. Here it is detailed.

Even if the longitude is a single number, it will still log zeros before the single number. That is my saving grace, I know the data will always be formatted the same way.

 

I've already created multiple use cases using gpsvisualizer.com. :) Everything works pretty fine, although when the the path I draw is not in earth's first quadrant, the path get's mirrored against x or z lines depending on which quadrant it is. The screen labels are still good so although west and east are maybe on swapped sides of the screen, the labels do actually show that, so I guess it's alright.

 

joeymorin wrote:

chiMa wrote:
I believe a stray overflow here and there which can be remediated with just the press of a button is good enough.
We believe in very different things.  It's your project.

I would also very much like it to be 100% error-proof, but since I have 2 more days to finish my documentation before my deadline - this will work just fine ;)

Last Edited: Sun. May 17, 2020 - 06:17 PM

Pages