Neujahrsprobleme ATMEGA64

[surfer]

Hallo zusammen

Erstens möchte ich euch allen einen guten Start ins neue Jahr 2006 wünschen!

Meins hat im uC-Bereich leider nicht so gut angefangen

Ich arbeite an einem Projekt, bei dem ich ein Serielles Grafikdisplay mit Touchscreen und ein GPS-Empfänger habe.
Ich benutze einen ATMEGA64 wobei das Display am UART0 und das GPS am UART1 hängt.

Vor ein paar Tagen arbeitete ich noch mit einem ATMEGA162, jedoch reichte der Programmspeicher nicht aus und ich wechselte auf einen 64er.
Doch jetzt kommen die Probleme:
Nachdem ich das Makefile und den Code am 64er angepasst habe, hat dieser Mühe mit dem UART vom Display!

Wenn ich folgenden Code verarbeiten möchte, bleibt der Controller in der Schleife hängen:

volatile char buffer0;

SIGNAL(SIG_UART0_RECV)
{
	buffer0=UDR0;
}

int main(void)
{
     UART0_init(9600);
     sei();
     while(buffer0!=99)      //Touchscreen liefert bei Taste x das ASCII-Zeichen 99
    {
          disp_text('h','l',20,20,"Das ist ein TEST"); // Text auf Display (geht über UART0)
    }
}

Das komische ist, dass wenn ich in der Schleife die Textanweisung weglasse, dann geht es ohne Probleme. Also wenn nichts über den UART gesendet wird...

Ich verstehe vollkommen nicht, warum das auf dem 162er geklappt hat und auf dem 64 nicht!!!
Könnte es auch an der Verkabelung liegen (64er passt nicht auf 162er Footprint == Kabelwirrwarr)

Es gibt für mich einfach keinen Grund, warum er in der Schleife hängenbleiben soll

Hoffentlich könnt ihr mir einen Tipp geben...

[askazo]

Hm, wenn ich Dein Programm richtig deute, gibt Dein Controller solange den Test-Text auf dem Display aus, bis Du eine 'Taste' am Touchscreen drückst, richtig?
Was ist jetzt Dein Problem? Bleibt der Controller auch noch in der Schleife, nachdem Du die Taste gedrückt hast?

askazo

[surfer]

genau! Wenn ich in der Schleife den Text nicht ausgebe, dann klappt das auch.... Aber mit Text hats beim 162er geklappt...

[PicNick]

der ungeliebte Text taucht aber schon dort auf, wo er soll, und sieht auch normal aus ?

[surfer]

jep. eigentlich funktioniert alles, eben bis auf das empfangen während dem senden...

es ist ja ein interrupt... der ist doch höhere prioritäten als eine normale anweisung... oder? darum verstehe ich überhaupt nicht, warum er hängen bleibt!!

[PicNick]

Sieht für mich so aus, als hätte der disp_text() irgendwelche side-effects.
Rückst du den raus ?

[surfer]

es spielt eigentlich keine rolle ob disp_text() oder sonst eine Sendeaufgabe...
hier der disp_text() code und die UART initialisierung und senderoutine:

void UART0_init(long int baudrate, long int quarzfrequenz)
{
	int baudwert;
	baudwert = (quarzfrequenz/(baudrate*16))-1;
	UBRR0H = (baudwert>>8);
	UBRR0L = baudwert;
	
	UCSR0B = (1<<RXCIE0)|(1<<RXEN0)|(1<<TXEN0);
	UCSR0C = (1<<UCSZ01)|(1<<UCSZ00);
}


void UART0_send_char(char c0)
{
	if(c0=='ü'||'ä'||'ö'||'Ü'||'Ä'||'Ö')  // Falls das zu sendende Zeichen ein Umlaut		
	{										// wird der richtige Charaker zugeordnet	
		switch(c0)
		{
			case 'ü': c0=129; break;
			case 'ä': c0=132; break;
			case 'ö': c0=148; break;
			case 'Ü': c0=154; break;
			case 'Ä': c0=142; break;
			case 'Ö': c0=153; break;
			default: break;
		}
	}
	while((PIND&0x02)==0x02);				// Warten bis das Display bereit ist
	while ( !( UCSR0A & (1<<UDRE0)) );	// Warten bis der Sender bereit ist
	UDR0=c0;								// Zeichen senden
}


/****************************************************************************************
* orientation: h=horizontal, v=vertikal													*
* position: l=linksbündig, c=zentriert, r=rechtsbündig 									*
****************************************************************************************/

void disp_text(char orientation, char position, int x, int y, char *text)
{
	UART0_send_char(27);
	UART0_send_char('z');
	if(orientation=='v')
	{
		switch(position)
		{
			case 'l': UART0_send_char('o'); break;
			case 'c': UART0_send_char('m'); break;
			case 'r': UART0_send_char('u'); break;
			default: UART0_send_char('o'); break;
		}
	}
	else
	{
		switch(position)
		{
			case 'l': UART0_send_char('l'); break;
			case 'c': UART0_send_char('z'); break;
			case 'r': UART0_send_char('r'); break;
			default: UART0_send_char('l'); break;
		}
	}
	UART0_send_char(x);
	UART0_send_char(y);
	UART0_send_string(text);
	UART0_send_char(0);
}

[darwin.nuernberg]

Da das Programm mit der "alten" Harddware funktioniert hat
aber jetzt mit der "neuen" Hardware nicht mehr kontrolliere doch
erst mal folgendes:

Compiler: Wurde das Programm auch richtig und komplett neu parametriert und neu Compiliert?

CPU: hast Du einen "Satten" HI/LOW Pegel am Taster? ggf. mit 10k PullUp (nach VCC).

Wenn Dein LCD sauber funktioniert, kommen die (HI) Pegel vermutlich von diesen.

[surfer]

Es ist eben kein Taster, sondern das Display sendet ein vorher definiertes Zeichen als RS232...
Ich werde sehrwahrscheinlich die Hardware nochmals durchchecken und neu verdrahten... man weiss ja nie...

[surfer]

Hurra!! Ich habs gelöst! Wie schon gedacht, lag es nicht am Code...

Der 162er hatte MISO/MOSI und RX0/TX0 an verschiedenen Pins.
Der 64er teilt sich je ein Pin für 2 Funktionen. Nun haben meine Status LED´s vom MISO immer Strom geliefert bekommen, wobei diese dann gleichzeitig das UART-Signal herunterzogen... LED-raus === alles läuft!!! Juhuiii

Danke trotzdem für die Unterstützung!