spess53 schrieb:> Was sagt das Datenblatt?
Was hat das Datenblatt damit zu tun? Die Bezeichnungen für die Register
werden einzig und alleine in den devicespezifischen Headerfiles des
Compilers festgelegt. Wenn die - mehr oder weniger zufällig - mit den
Bezeichnungen im Datenblatt übereinstimmen, ist das glückliche Fügung
und dient einzig der Arbeitserleichterung ;-)
Thomas W. schrieb:> Was hat das Datenblatt damit zu tun? Die Bezeichnungen für die Register> werden einzig und alleine in den devicespezifischen Headerfiles des> Compilers festgelegt. Wenn die - mehr oder weniger zufällig - mit den> Bezeichnungen im Datenblatt übereinstimmen, ist das glückliche Fügung> und dient einzig der Arbeitserleichterung ;-)
Und der Ersteller der Library wäre ein Idiot.
A. K. schrieb:> Faule Leute hätten in der Schleife einfach nur uart_putc aufgerufen.
Ich denke, wenn man zwei Funktionen in einer vereinen kann, sollte man
es tun :)
Max M. schrieb:> Ich denke, wenn man zwei Funktionen in einer vereinen kann, sollte man> es tun :)
Erstens: Nein, auf vorhandenem aufbauen ist im Prinzip besser.
Zweitens hätte der Compiler das auch selbst getan (inlining).
Drittens: Es bringt nix, Wartezeiten auf Zeit zu optimieren. ;-)
STK500-Besitzer schrieb:> Und der Ersteller der Library wäre ein Idiot.
ähm, so würde ich das nicht sagen, weil sich die Namen öfter mal
geändert haben ist es oft nicht möglich irgendeine Lib zu nehmen die
genau nicht für alle AVR passt.
Ich habe in meinem Beispiel zwar 2 -Punkte gesammelt ändert aber nix.
Ich benutze heute lieber Pseudo Defines in "StandardLIBs" und setze die
echten Namen aus dem Datenblatt ein, zumal es ja wie schon geschieben
heute UART0 und UART1 gibt, die Interrupt- Bits -register auch gerne mal
wechseln.
Geduldsfaden Ende erreicht..
..mach's halt richtig, so wie's im Datenblatt (für Schreibfaule) steht:
void USART_Init( unsigned int ubrr)
{
/*Set baud rate */
UBRR0H = (unsigned char)(ubrr>>8);
UBRR0L = (unsigned char)ubrr;
Enable receiver and transmitter */
// *****************************************************
UCSR0B = (1<<RXEN0)|(1<<TXEN0); // <<-- DING DING DING *
// *****************************************************
/* Set frame format: 8data, 2stop bit */
UCSR0C = (1<<USBS0)|(3<<UCSZ00);
}
aber so nicht
UCSR0B = (1<<TXEN0); // Im Controlregister wir nur Bit TXEN0 gesetzt
UCSR0B = (1<<RXEN0); // Im Controlregister wir nur Bit RXEN0 gesetzt,
// TXEN0 und alle anderen Bits werden auf 0
gesetzt
UCSR0B |= (1<<RXEN0); // so werden einzelne Bits gesetzt, ohne die
anderen wieder auf 0 zu löschen..
Jetzt aber..
BirgerT schrieb:> Geduldsfaden Ende erreicht..>> ..mach's halt richtig, so wie's im Datenblatt (für Schreibfaule) stehtBirgerT schrieb:> ..PALMFACE..
Nur mal als kurzer Hinweis: Wenn Du weder LUST noch GEDULD aufbringst,
etwas zu erklären, dann LASS ES EINFACH.
SCNR
Kai M. schrieb:> BirgerT schrieb:> Nur mal als kurzer Hinweis: Wenn Du weder LUST noch GEDULD aufbringst,> etwas zu erklären, dann LASS ES EINFACH.
Mach ich auch..
Meine Philosophie ist "Hilfe zur Selbsthilfe" und "Beratungsresistenz
ignorieren".
Bei der Problematik hier handelt es sich um eine der vielen gut
dokumentierten Aufgabenstellungen. Also habe ich erst versucht, den OT
selber eine Lösung finden und das Erfolgserlebnis haben zu lassen..
..um dann doch die Katze aus dem Sack zu lassen.
Also Max_MMM probier bitte nochmal folgendes:
1
voiduart_putc(unsignedcharc)
2
{
3
while(!(UCSR0A&(1<<UDRE0)))/* warten bis Senden moeglich */
4
{;// hier noch ein Semikolon einfügen
5
}
6
UDR0=c;/* sende Zeichen */
7
}
8
9
uint8_tuart_getc(void){
10
while(!(UCSR0A&(1<<RXC0))){
11
;// und hier auch eine "leere Anweisung"
12
}
13
returnUDR0;
14
}
Wenn das auch noch nicht geht, probier nochmal das Senden:
1
charstr[]="Hallo Max_MMM\n-";
2
3
intmain(void){
4
uart_init();
5
6
_delay_ms(100);
7
uart_puts(str);
8
9
while(1){
10
uint8_tval=uart_getc();
11
itoa(val,str,10);
12
uart_puts(str);
13
_delay_ms(100);
14
}
15
}
und wenn's dann noch immer nicht klappt - bin ich zugegebenermaßen
erstmal ratlos. Liegt es vielleicht an dem C# Programm?
Versuch doch mal ein normales Terminalprogramm (puTTYtel, Hterm..)
Danke!
P.S. Warum 49 als Ergebnis ausgegeben wird obwohl ich "1" sende,
verstehe ich aber nicht...
Edit: okay, anscheinend braucht man C#-Programm ein Ende-Zeichen, so
gehts:
BirgerT schrieb:> und wenn's dann noch immer nicht klappt - bin ich zugegebenermaßen> erstmal ratlos. Liegt es vielleicht an dem C# Programm?
Augenscheinlich liegt es am C# Programm..
Console.WriteLine(sp.ReadLine());
..heisst bestimmt, dass der empfangene String ebenfalls mit einem
"return" abgeschlossen sein muss.
> Versuch doch mal ein normales Terminalprogramm (puTTYtel, Hterm..)
Max M. schrieb:> Yeah, es geht :)
das ist schön..
> P.S. Warum 49 als Ergebnis ausgegeben wird obwohl ich "1" sende,> verstehe ich aber nicht...
Weil Du das Zeichen mit itoa in einen Zahlstring konvtertierst, der dem
Zeichencode in dez entspricht. Nimmste als Radix 16, wird hex 31
zurückgegeben.. 'A' ist 65 dez und 41 hex
>> Edit: okay, anscheinend braucht man C#-Programm ein Ende-Zeichen, so> gehts:
Da haben sich unsere Posts überschnitten..
Ist das eigentlich normal, dass der Arduino den Code verliert, wenn man
ihn vom Strom trennt?
Edit: Hm, ein anderes Programm funktioniert nach dem Strom trennen
einwandfrei...