USART Komplikationen

[noNeed 4 aNick]

Hi zusammen,

nachdem ich nun nen funktionierenden LCD-Schirm habe *freu*
Hab ich mich direkt ans nächste Thema gewagt - dem USART... Ich hab vorhin alles fertig zusammengelötet und angeschlossen, basierend auf der Schaltung von http://www.mikrocontroller.net/tutorial/uart.htm

Als Terminal benutze ich dieses hier: http://bray.velenje.cx/avr/terminal/

Wenn ich das Programm starte erkennt es automatisch die Baudrate, daher gehe ich mal davon aus, das ich alles richtig zusammengelötet habe, da auch kein Teil heiß wurde und die Elkos noch heile sind :)
Natürlich kann das auch nur Zufall sein mit der Baudrate, wenn das Programm zB 9600 als Defaultwert hat...

Naja, jedenfalls passiert gar nix, weder receive noch transmit funktioniert... Nachdem ich erstmal selber versucht habe, dass zu coden und es nicht ging, hab ich die Lib von www.mc-project.de genommen, aber auch diese scheint nicht zu arbeiten:



#define F_CPU 8000000
#define USART_BAUD_RATE 9600
#define USART_BAUD_SELECT (F_CPU/(USART_BAUD_RATE*16l)-1)

void USART_Init(void) {
//UCSRB = (1<<RXCIE) | (1<<TXCIE) | (1<<RXEN) | (1<<TXEN);
UCSRB = (1<<RXEN) | (1<<TXEN);
UBRRL = (unsigned char) USART_BAUD_SELECT;
}

void USART_transmit (unsigned char c) {
while (!(UCSRA & (1<<UDRE))) {}
UDR = c;
}

unsigned char USART_receive (void) {
while(!(UCSRA & (1<<RXC))) {}
return UDR;
}

void USART_transmit_string (unsigned char *string) {
while (!(UCSRA & (1<<UDRE))) {}
while ( *string)
USART_transmit (*string++);
}

int main (void)
{
USART_Init();

while (1)
{
USART_transmit_string("Hello World");
}
}


Ich weiß jetzt nicht, ob ich anstatt F_CPU 8 * 10^6 nicht 1 * 10^6 nehmen müsste, weil ich nen ATmega16 habe und gelesen hab, dass man dort die Oszilatorfrequenz nehmen muss...

Außerdem kann ich mich noch dunkel an die Zeiten erinnern, als man noch mit seriellen Mäusen gearbeitet hat... Diese mussten doch immer vor dem Hochfahren des Systems angeschloßen sein - Kann das daran liegen?

Irgendwelche Vorschläge?

ThxInAdv
Alex

[PicNick]

Hi, nur ein Tip nebenbei: wenn das terminal ÜBERHAUPT nix zeigt, auch nicht wtlbrnft oder smileys, was bei Baudratenfehler vorkommt, versuch mal, auf der PC <> Boardverbindung RX u. TX (2 u.3) auszukreuzen.
Je nach Kabel u. Anschluß kann das schon mal verkehrt sein.
Is nur ein Versuch, denn solche Download-Beispiele funzen meist schon
mfg robert

[noNeed 4 aNick]

d'oh
Tatsächlich, ich hab mich gestern verzählt....

Naja jetzt empfang schon mal was, aber es kommt im Moment nur Müll an...

Wenn ich für F_CPU 8000000 wähle kommt bei dem oben geposteten Code sowas hier an:


ð<0><0>€€€<0>€<0>€€<0>€€€€€<0><0>€€€€€€€<0>
<0>€<0>€€<0><0>€<0><0>€€€<0>€<0>€€<0>€€€€€<0>
<0>€€€€€€€<0><0>€<0>€€<0><0>


Mit F_CPU 1000000 sowas:


‹K‘µ¶ÛZݲ¶i†ËÝ�å+Ñ´¤)ËÝ�å+Ñ´¤)ËÝ�å+Ñ´¤)ÃÝ�å+Ñ´¤)ÃÝ�å+Ñ´
¤)ËÝ�å+Ñ´¤)ËÝ�å+Ñ´¤)ËÝ�å+


(Zeilenumbrüche hab ich der "Übersicht" ;) wegen reingehauen)

Nun würd ich mal vermuten, das irgendwas mit der Baut-Rate noch nicht so ganz stimmt :)
Aber warum?
Ich hab nen ATmega16 mit 8Mhz... Der interne Oszi ist afaik 1Mhz, aber beide Zahlen arbeiten ja nicht so richtig gut :-/

[PicNick]

Na ja, F_CPU sollt' schon in die Nähe der Realität kommen.
Wie taktest du deinen Fuzzy nun wirklich ? mit 8 oder intern mit 1 MHz ?
mfg

[noNeed 4 aNick]

öhm...
Also ich hab nen Quarz mit 8.000 MHz an die xtals geschloßen.
Aber ich weiß net, ob ich irgend nen Fusebit ändern muss - bisher war mir das ja an sich auch egal, mit welchem Takt der gearbeitet hat, dass er gearbeitet hat, hat mir gereicht :)

edit:
Hab bissel rumgestöbert und diesen Beitrag gefunden:
https://www.roboternetz.de/phpBB2/zeigebeitrag.php?t=2576

Ich hab dann entsprechend die Fusebits umgelegt und jetzt reagiert der Mikrocontroller nicht mehr...

edit2:
*stöhn* War ne kalte Lötstelle ^^

edit3:
Yeah Baby


Hello WorldHello WorldHello WorldHello WorldHello WorldHello WorldHello WorldHello WorldHello WorldHello WorldHello WorldHello WorldHello WorldHello WorldHello WorldHello WorldHello WorldHello WorldHello WorldHello WorldHello WorldHello WorldHello WorldHello WorldHello WorldHello WorldHello WorldHello WorldHello WorldHello WorldHello WorldHello WorldHello WorldHello

[bluebrother]

Natürlich kann das auch nur Zufall sein mit der Baudrate, wenn das Programm zB 9600 als Defaultwert hat...
9600 ist ein Quasi-Standard und das von dir verwendete Terminal merkt sich die letzte Einstellung. Also nix mit automatisch erkennen ;-) Erkennen tut es nur welche seriellen Ports überhaupt verwendbar sind.

[noNeed 4 aNick]

Nun hab ich ein neues Problem - ein sehr seltsames, dass ich mir echt nicht erklären kann...

Das Ganze fing damit an, dass mein Pony angefangen hat zu streiken und nur etwa 5-6% aller Schreibversuche erfolgreich beendet wurden.
Daraufhin hab ich geradzu verzweifelt irgendwelche eher schlecht gelöteten Stellen neu gelötet und tausende von Stellen durchgegangen, ob sie gut gelötet sind etc.

Nun geht das Programmieren meist, jedoch muss ich ab und zu meinen LCD abklemmen - sehr seltsam :-?

Nun habe ich den oberen Code auf folgenden Code erweitert:


#include "../main.h"

volatile unsigned char data;

void USART_Init(void) {
UCSRB = (1<<RXCIE) | (1<<RXEN) | (1<<TXEN);
//UCSRB = (1<<RXEN) | (1<<TXEN);
UBRRL = (unsigned char) USART_BAUD_SELECT;
}

void USART_transmit (unsigned char c) {
while (!(UCSRA & (1<<UDRE))) {}
UDR = c;
}

unsigned char USART_receive (void) {
while(!(UCSRA & (1<<RXC))) {}
return UDR;
}

void USART_transmit_string (unsigned char *string) {
while (!(UCSRA & (1<<UDRE))) {}
while ( *string)
USART_transmit (*string++);
}

SIGNAL (SIG_UART_RECV) {
data = UDR;
lcd_write("muh");
}

int main (void)
{
USART_Init();
lcd_init();
data = ' ';
lcd_on(CURSOR + BLINK);

lcd_write("Ready 2 GO");
lcd_setPos(1,2); lcd_write("3"); lcd_delay(80);
lcd_setPos(1,2); lcd_write("2"); lcd_delay(80);
lcd_setPos(1,2); lcd_write("1"); lcd_delay(80);

USART_transmit_string("lets go :)");

lcd_cls();

sei();

while (1)
{
if (data == 'c') lcd_cls();
else if (data != ' ')
{
lcd_write(data);
USART_transmit(data);
data = ' ';
}
}
}

Alle Vordefinierten Eigenschaften sowie die Funktionen für die LCD werden über die main.h eingebunden.

Nunja, bewirken sollte der Code folgendes:
Wenn ich über mein Terminal etwas sende, sollte auf meinem LCD Bildschirm das zeichen angezeigt werden und als zweite Bestätigung nochmal zurück ans Terminal geschickt werden.

In der Praxis passierte folgendes:
Das LCD wurde initialisiert, der Countdown läuft ab, dann wurde der Bildschirm schwarz und wurde erneut initalisiert und der Countdown erschien wieder.
Daher hab ich in die SIGNAL die Ausgabe "muh" reingepackt. Nun wurde kurz bevor das LCD schwarz wird noch muh ausgegeben.
Danach fing der µC die main-Routine wieder von neu an. Als ob das Ganze nicht seltsam genug wäre, hier noch ne Kuriosität:
Wenn ich das RS-232 Kabel entferne, ändert sich nix, der µC empfängt trotzdem noch irgendetwas, gibt kurz "muh" aus und resetet.

Ich hab mir gedacht, das ich vllt irgendwie den Watchdog eingeschaltet haben könnte, jedoch weiß ich gar net, wie man den an kriegt und bezweifel auch, dass das sein kann.

Naja, zum testen habe ich wieder die alte File mit dem Hello World auf den µC gepackt, aber das Terminal empängt wieder nur Müll, ähnlich wie vorhin, als der Quarz net stimmte...

*Idee*
---------------------------Kurze Schreibpause-----------------

Nun, ich hab kurz geschaut, und die Fusebits haben sich irgendwie wieder so gesetzt, dass der interne Quarz verwendet wird.
Irgendwelche logischen Erklärungen dafür?

Nachdem ich die Fusebits nun umgestellt habe, arbeitet das Dongle wieder net sauber, ich kann nur coden, wenn ich die Platte mit LCD und USART abklemme...

Naja, nun hab ich das neue Programm wieder getestet, und beim ersten Mal gab der im Terminal "Lets go :))))))))))))))))))))))))))))[...]" und auf dem LCD "muh)muh)muh)[...]" aus.

Danach hab ich mal dies mal das wegkommentiert oder hinzugefügt und jetzt kommt schonwieder nur Müll im Terminal raus: "88ÿ8ð8ðxð8ðxpü
" Und dementsprechend auch auf dem LCD


Ich verstehs net...

[PicNick]

Hallo, Kollege, keep cool, don't panic !
Step by Step, back to the roots = "hello world"
Wenn das immer noch klappt, kann's ja nicht gleichzeitig falsch sein.
Also halte dir dieses Programm warm und unverändert und wenn irgendwas spinnt, lade es wieder und schau, ob's noch geht.
Wenn ja, hat's halt was mit dem aktuellen neuen Programm.
Wenn nicht, --> alles retour, bis das wieder klappt.
Wenn du OHNE Lcd und UART einwandfrei mit dem Pony coden kannst, ist da irgendwo dort der Wurm drin. ABER PONY MUSS GEHEN !
Stell die Geräte mal softwaremäßig einzeln in die Ecke, d.h. entweder NUR UART-Echo testen oder NUR LCD.

Dein Programm:
schau mal die Funktiondefinition "lcd-write" nach.
ist das ? void lcd_write(char* string) oder so ähnlich ?
wenn ja, und wenn du dann schreibst lcd_write(data) dann isser im Nirwana.

fürd erste mfg robert

[noNeed 4 aNick]

Zum Programm: Warum killt das den Controller?

Es is echt verückt, wenn ich LCD und USART am µC angeschloßen habe, dann kann ich ihn einfach nicht coden, das kann doch nicht sein...
Und das Hello World Programm gibt wieder Unsinn aus :(

[PicNick]

Ist von deinem PIC/LCD eigentlich ein Schaltplan da ?
KILLEN: wenn die Funktion lcd_write die Adresse eines strings erwartet, der mit einem \0 endet, und kriegt die Adresse von einem Einzelbyte, fängt er deine Memory zum displayen an, bis er eine Null findet. Das kann dauern und ein sehr langer String sein.
Noch schlimmer, wenn er "data" by Value kriegt, dann liest er überhaupt irgendwo.
Wenn's geht, schau dir den generierten Assembler an, vielleicht isser ja auch gescheiter als gedacht.
PS Wenn einer murkst, ist es eher der LCD. die MAXen sind normalerweise Büffeln, die keine Schwierigkeiten machen. Vielleicht laßt sich der LCD einzeln mal abhängen ?
mfg robert

[noNeed 4 aNick]

Zum Schaltplan:
Eigentlich gibt's keinen, ich hab mich durch Tutorials und ähnliches gewühlt und bissel kombiniert :)
Zwar hatte ich immer irgendwelche kleinen Probleme, aber bisher konnte ich das alles immer lösen und hab dementsprechend viel über die "Materie" gelernt.
Das woran ich bastel, soll nur ne Experimentierstation sein, für mein richtiges Projekt mach ich mir nen richtigen Schaltplan.

Naja zum Problem: Ich glaube es liegt irgendwie am Quarz, denn gerade eben habe ich wieder auf den Internen geschaltet und der klappt wunderbar. Da kann ich mit dem Pony auch dann coden, wenn LCD & USART dranhängen...

Letzens hab ich meinen µC mit nem Kurzschluss gef***t, vllt is der Quarz auch hinüber?
Ich denk egtl nicht, denn auch damals hatte ich die Fusebits net auf externen Quarz gestellt...

[PicNick]

Würde mich auch wundern, wenn man einen Quarz so meucheln könnte, aber nix is fix.
Was du erzählst, klingt mir schon sehr elektrisch und weniger softwarig
Ein Unterschied extern /intern is natürlich schon : 8 Mhz stellen an Leitungskapazitäten, Überspruch etc. ganz andere Anforderungen als 1 Mhz.
Hast du alle Chips, speziell den AVR, mit Kondensatoren versehen ?
Ideal wär ja, einen externen mit ca 1 MHZ zu probieren, ob's am Externen oder an der Taktrate liegt. *leichtratlos* mfg robert

[noNeed 4 aNick]

hmm, dann muss ich mir heute noch nen Externen 1Mhz Takt kaufen :-/

Also am AVR hab ich nen Kondensator, auf meinem Dongle auch.
Im Schaltplan vom USART wird das mit nem Elko gelöst, nur am LCD hab ich keinen, hab aber auch keinen Plan gesehn, auf dem das gezeigt wurde...

Kann man die denn zu weit weg platzieren oder so?

[PicNick]

Kann man schon, im Prinzip zählt jeder Zentimeter. mfg

[noNeed 4 aNick]

Hmm, ich hab gerad mal das Datasheet vom ATmega16 durchstöbert und folgendes gefunden:


The Calibrated Internal RC Oscillator provides a fixed 1.0, 2.0, 4.0, or 8.0 MHz clock. [...]
Table 9. Internal Calibrated RC Oscillator Operating Modes
<pre>
CKSEL3..0 Nominal Frequency (MHz)
0001 1.0
0010 2.0
0011 4.0
0100 8.0
</pre>


Also hab ich mal CLSET3..1 auf 0100 (Wobei 0 = programmed und 1 = unprogrammed) gestellt.

Resultat: Der µC scheint stabil zu laufen, lässt sich bisher programmieren und mein Terminal empfängt wieder fleißig "Hello World" :D

Scheinbar lag es doch am externen Quarz und nicht an der Taktrate...
(Hoffentlich) eine letzte abschließende Frage:
Warum benutzt man denn nen externen Quarz, wenn der interne bis auf 8 MHz kommt? (Es sei denn man will mit 16MHz arbeiten)

Und die Frage zu gestern: Kann sich jmd erklären, wie es der µC geschafft hat, von selbst die Fusebits wieder zurückzustellen?

MfG
Alex

[noNeed 4 aNick]

Hi zusammen,
so richtig will's immernoch nicht klappen...
Das Schreiben scheint zu klappen, aber ich hab echt das Gefühl, dass der µC nicht mit dem Lesen klar kommt.

Folgender Code:


#include <inttypes.h>
#include <avr/io.h>
#include <avr/interrupt.h>
#include <avr/signal.h>

#define Pin1 0
#define Pin2 1
#define Pin3 2
#define Pin4 3
#define Pin5 4
#define Pin6 5
#define Pin7 6
#define Pin8 7

#define READ 1
#define WRITE 2

#define F_CPU 8000000
#define USART_BAUD_RATE 9600
#define USART_BAUD_SELECT (F_CPU/(USART_BAUD_RATE*16l)-1)

volatile unsigned char data;

void usart_init(int Enable, int Interupts) {
if (Enable == READ) UCSRB = (1<<RXEN);
if (Enable == WRITE) UCSRB = (1<<TXEN);
if (Enable == READ + WRITE) UCSRB = ( (1<<RXEN) | (1<<TXEN) );

if (Interupts == READ) UCSRB |= (1<<RXCIE);
if (Interupts == WRITE) UCSRB |= (1<<TXCIE);
if (Interupts == READ + WRITE) UCSRB |= ( (1<<RXCIE) | (1<<TXCIE) );

UBRRL = (unsigned char) USART_BAUD_SELECT;
}

void usart_writeChar(unsigned char c) {
while (!(UCSRA & (1<<UDRE))) {}
UDR = c;
}

unsigned char usart_readChar(void) {
while(!(UCSRA & (1<<RXC))) {}
return UDR;
}

void usart_writeString(unsigned char *string) {
while (!(UCSRA & (1<<UDRE))) {}
while ( *string)
usart_writeChar(*string++);
}

SIGNAL (SIG_UART_RECV) {
data = UDR;
}

int main (void)
{
usart_init(READ + WRITE, READ);
DDRD = 0xFF;
PORTD = 0x00;
usart_writeString("Hello World");
sei();

while (1)
{
if (data == 'l')
{
PORTD = (1 << Pin6);
usart_writeString("[Motor left]");
}
else if (data == 'r')
{
PORTD = (1 << Pin7);
usart_writeString("[Motor right]");
}
else if (data == 's')
{
PORTD = 0x00;
usart_writeString("[Motor stop]");
}
else usart_writeChar(data);
}
}


Folgende Ausgabe auf dem Terminal:


Hello World[Motor right]ht]ht]ht]ht]ht]ht]ht]ht]ht]ht]ht]ht]ht]ht]ht]ht]ht]ht]ht]ht]ht]ht]ht]
...

Das seltsame ist, dass ich über das Terminal gar nichts schicke, was das USART empfangen könnte.
Trotzdem wird die IF Schleife (data == 'r') ausgelöst, dabei kann data gar nicht 'r' sein :-s

[PicNick]

Kollege, es is ja keiner da, der "data" zurücksetzt, wenn kein UDR kommt.

Beim senden tät ich
warten, bis register leer (machst du)
reinschreiben
warten, bis senden fertig (TXC) sicherheitshalber
mfg robert

[noNeed 4 aNick]

Das stimmt zwar, aber data wird ja nie ein Wert zugewiesen, daher sollte der ja nicht in die if schleife springen, daran kann's also nicht liegen...

Nun habe ich den Code erweitert:


//...
volatile unsigned char data;
volatile int changed;

//...

void usart_writeChar(unsigned char c) {
while (!(UCSRA & (1<<UDRE))) {}
UDR = c;
while(!(UCSRA & (1<<TXC))) {}
}

//...

SIGNAL (SIG_UART_RECV) {
data = UDR;
changed = 1;
}

//...

int main (void)
{
//...
changed = 0;
sei();
//...
while (1)
{
if (changed == 1)
{
if (data == 'l')
{
//...
}
else usart_writeChar(data);
changed = 0;
}
}
}


Trotzdem wird der Motor eingeschaltet und das Terminal empfängt dasselbe wie oben. Dabei schicke ich doch gar nichts ab...

[PicNick]

Seltsam. Es sind immer die drei zeichen "ht]" die er wiederholt ?
Oder ist "ft]", wenn du "l" schickst ? mfg

[noNeed 4 aNick]

kA, denn er reagiert nicht, wenn ich ihm was schicke...
Das hab ich vergessen zu erwähnen:

Wenn ich was sende wird die SIGNAL - Routine gar nicht aufgerufen...

[PicNick]

Hopperla, mit deinem Init hat's was
wenn du usart_init aufrufst mit (READ + WRITE, ...
kannst du nicht auf Enable == READ abfragen
du mußt if(Enable & READ) fragen
mfg robert

[noNeed 4 aNick]

Ok, nun hab ich die init umgeschrieben:


void usart_init(int Enable, int Interupts) {
if (Enable & READ) UCSRB = (1<<RXEN);
if (Enable & WRITE) UCSRB |= (1<<TXEN);
if (Enable & (READ + WRITE) ) UCSRB = ( (1<<RXEN) | (1<<TXEN) );

if (Interupts & READ) UCSRB |= (1<<RXCIE);
if (Interupts & WRITE) UCSRB |= (1<<TXCIE);
if (Interupts & (READ + WRITE) ) UCSRB |= ( (1<<RXCIE) | (1<<TXCIE) );

UBRRL = (unsigned char) USART_BAUD_SELECT;
}


Aber das Resultat war noch nicht zufriedenstellend, daher hab ich in die SIGNAL noch folgendes reingepackt:


usart_writeChar('[');
usart_writeChar(data);
usart_writeChar(']');

Man soll zwar net im Interupt wieder schreiben, aber naja....

Resultat is jedenfalls folgendes:


Hello World[H][e][r][[][[][[][[][[][[][[][[][[][[][[][[][[][[][[][[]...

Hmm :-s

Warum muss man das egtl mit & verbinden und kann net mit == vergleichen?
Und muss ich dann vllt in der 3ten iif (Enable & WRITE & READ) schreiben?

[PicNick]

Hi, den jeweils dritten "if" soltest du entfernen.
Unterschied & und ==
Beim Aufruf init (READ + WRITE
steht bei enable offensichtlich "3" drin
das ist weder == 1 (READ) noch == 2 (WRITE) also nix.
Mittels "&" fragst du das bit ab, also 00000001 oder 00000010

Schaut fast so aus, als würde dein Senden den receive interrupt auslösen.
und im EMpfangsregister steht, so scheint's, immer "[" drin
Kannst du mal dein komplettes Programm im jetzigen Zustand posten ?
mfg robert

[noNeed 4 aNick]

Wenn aber Enable == 3 wäre, sollte doch die dritte if (Enable = READ + WRITE) anspringen oder?

Hier der momentane Code (Die ifs hab ich erstmal drin gelassen)


#include <inttypes.h>
#include <avr/io.h>
#include <avr/interrupt.h>
#include <avr/signal.h>

#define Pin1 0
#define Pin2 1
#define Pin3 2
#define Pin4 3
#define Pin5 4
#define Pin6 5
#define Pin7 6
#define Pin8 7

#define READ 1
#define WRITE 2

#define F_CPU 8000000
#define USART_BAUD_RATE 9600
#define USART_BAUD_SELECT (F_CPU/(USART_BAUD_RATE*16l)-1)

volatile unsigned char data;
volatile int changed;

void usart_init(int Enable, int Interupts) {
if (Enable & READ) UCSRB = (1<<RXEN);
if (Enable & WRITE) UCSRB |= (1<<TXEN);
if (Enable & (READ + WRITE) ) UCSRB = ( (1<<RXEN) | (1<<TXEN) );

if (Interupts & READ) UCSRB |= (1<<RXCIE);
if (Interupts & WRITE) UCSRB |= (1<<TXCIE);
if (Interupts & (READ + WRITE) ) UCSRB |= ( (1<<RXCIE) | (1<<TXCIE) );

UBRRL = (unsigned char) USART_BAUD_SELECT;
}

void usart_writeChar(unsigned char c) {
while (!(UCSRA & (1<<UDRE))) {}
UDR = c;
while(!(UCSRA & (1<<TXC))) {}
}

unsigned char usart_readChar(void) {
while(!(UCSRA & (1<<RXC))) {}
return UDR;
}

void usart_writeString(unsigned char *string) {
while (!(UCSRA & (1<<UDRE))) {}
while ( *string)
usart_writeChar(*string++);
}

SIGNAL (SIG_UART_RECV) {
data = UDR;
changed = 1;
usart_writeChar('[');
usart_writeChar(data);
usart_writeChar(']');
}

int main (void)
{
usart_init( (READ + WRITE) , READ);
DDRD = 0xFF;
PORTD = 0x00;
changed = 0;
usart_writeString("Hello World");
sei();


while (1)
{
if (changed == 1)
{
if (data == 'l')
{
PORTD = (1 << Pin6);
usart_writeString("[Motor left]");
}
else if (data == 'r')
{
PORTD = (1 << Pin7);
usart_writeString("[Motor right]");
}
else if (data == 's')
{
PORTD = 0x00;
usart_writeString("[Motor stop]");
}
else usart_writeChar(data);
changed = 0;
}
}
}

[PicNick]

Ich zieh mir mal den Code rein.
Mit deinem dritten "if" hast du nicht ganz unrecht, aber auf diese art mußt du 4 Möglichkeiten "ifen"
1Nix
2Read
3Write
4Read + Write
Stell die mal vor, du hättest 3 Parameter, dann hast du 8 if's.
Also, ich laß mal nachdenken mfg derweil robert

[PicNick]

Also Kollege, da ist mal der Code zurück, als Attachment.
Bei mir auf einem RNBFRA 1.2 läuft das Zeugs pipifein, keine Loops
Ein Input --> Ein Output
allerdings extern 8MHZ, das wollt ich mir nicht antun

1 den berühmten dritten "if" hab ich geschmissen,
2 volatile auf static (das ist aber wurst, geht beides)
3 changed auf Byte (das reicht, is aber egal )
4 Daten vor dem vergleich auf kleinbuchstaben (damit man "R"/"r"
gleichermaßen eingeben kann)
5 eine paar "newlines" eingefügt, besser zum Lesen

aber im Prinzip ist es völlig dein Programm.

Also wenn was nicht geht, liegt der Fehler NICHT im Programm, sondern irgendwo drumherum.
Halte dir die Version warm und arbeite auf einer Kopie weiter.
Laß hören ! mfg robert

[noNeed 4 aNick]

](*,) ](*,) ](*,) ](*,) ](*,) ](*,)

Dein Code ging nun auch nicht und dann hab bin ich nochmal alles mit dem Multimeter durchgegangen...
Ergebnis:
Von einem Litz - ich glaube TX - am µC war ein einzelner Strang außen geblieben und hat sich beim reinschieben umgebogen. Und irgendwie is der dann an den entsprechenden RX Pin gekommen.

](*,) ](*,) ](*,) ](*,) ](*,) ](*,)


Wie blöd -.-

Auf jeden Fall vielen Dank, Robert...
Hast mir sehr geholfen

MfG
Alex

[PicNick]

Is immer wieder toll, wenn man nach ein paar verzweifelten Tagen auf solche banalen Fehler draufkommt. Was man sich da denkt, sollte besser keiner wissen. Also, auf zum Nächsten ! mfg robert