Ansonsten habe ich im Programm noch nichts. PinB2 als Ausgang, PinB3 als
Eingang gepullt. Auf HTerm bekomme ich nur 255, 1 Zeichen obwohl ich
einen String sende "Hallo", wenn ich nur ein Zeichen sende kommt nichts
an.
Mr. AVR schrieb im Beitrag #5450757:
> Ansonsten habe ich im Programm noch nichts. PinB2 als Ausgang, PinB3 als> Eingang gepullt. Auf HTerm bekomme ich nur 255, 1 Zeichen obwohl ich> einen String sende "Hallo", wenn ich nur ein Zeichen sende kommt nichts> an.
Was meinst du mit "bekomme ich nur 255, 1 Zeichen"?
Wie ist der AVR mit HTerm verbunden? Ist HTerm auf "ohne Flusskontrolle"
eingestellt? Funktioniert das Echo, wenn du RXD und TXD am AVR
verbindest und von HTerm aus sendest?
Stimmt F_CPU? Stimmen die Fuse-Bits, so dass der wirklich mit 20MHz
läuft?
Ich weiß nun auch nicht, wie diese Register- und Bit-Definitionen zu
verstehen sind, daher die Frage: Was ist der Unterschied zwischen _bm,
_gc und _bp? Kann man die so miteinander verwursten, wie du das tust?
MfG, Arno
Arno schrieb:> Mr. AVR schrieb im Beitrag #5450757:>> Ansonsten habe ich im Programm noch nichts. PinB2 als Ausgang, PinB3 als>> Eingang gepullt. Auf HTerm bekomme ich nur 255, 1 Zeichen obwohl ich>> einen String sende "Hallo", wenn ich nur ein Zeichen sende kommt nichts>> an.>> Was meinst du mit "bekomme ich nur 255, 1 Zeichen"?>> Wie ist der AVR mit HTerm verbunden? Ist HTerm auf "ohne Flusskontrolle"> eingestellt? Funktioniert das Echo, wenn du RXD und TXD am AVR> verbindest und von HTerm aus sendest?>> Stimmt F_CPU? Stimmen die Fuse-Bits, so dass der wirklich mit 20MHz> läuft?>> Ich weiß nun auch nicht, wie diese Register- und Bit-Definitionen zu> verstehen sind, daher die Frage: Was ist der Unterschied zwischen _bm,> _gc und _bp? Kann man die so miteinander verwursten, wie du das tust?>> MfG, Arno
Moby schrieb im Beitrag #5450813:
> und>> lds YL,T0BPL> lds YH,T0BPH> cpi YL,low(T0BPL)> breq txint1>> ld XL,Y+> sts USART0_TXDATAL,XL ;OUTPUT (BUFFERADR)> rjmp txint2>> txint1: ldi XL,$80 ;DISABLE> sts USART0_CTRLA,XL ;TRANSMITTER-INT> cbi GPIO_GPIOR0,T0IP ;TRANSMISSION FINISHED> ldi YL,low(T0BUF)> ldi YH,high(T0BUF)> txint2: sts T0BPL,YL ;SAVE (NEXT BUFFERADR)> sts T0BPH,YH>> geben sie im DataRegisterEmpty Interrupt aus einem Puffer aus!
Die Assemblertexte kannst du vergessen. Die bringen mir nichts!
Ich habe oben auch keinen verwursteten Text, es ist die init und die
putc Funtkion - standard-zeug eigentlich.
Hier nochmal das ganze:
Das Programm des Controllers:
1
rs232_init(38400,0,0);
2
_delay_ms(100);
3
4
while(1)
5
{
6
usart_puts("HALLO\r\n");
7
PORTA.OUTTGL|=(1<<PIN4_bp);
8
_delay_ms(550);
9
}
Die Funktionen sind ja oben schon gezeigt (das eine die init, das andere
die putc.
Die Puts sieht so aus:
Arno schrieb:> Mr. AVR schrieb im Beitrag #5450757:>> Ansonsten habe ich im Programm noch nichts. PinB2 als Ausgang, PinB3 als>> Eingang gepullt. Auf HTerm bekomme ich nur 255, 1 Zeichen obwohl ich>> einen String sende "Hallo", wenn ich nur ein Zeichen sende kommt nichts>> an.>> Was meinst du mit "bekomme ich nur 255, 1 Zeichen"?>> Wie ist der AVR mit HTerm verbunden? Ist HTerm auf "ohne Flusskontrolle"> eingestellt? Funktioniert das Echo, wenn du RXD und TXD am AVR> verbindest und von HTerm aus sendest?>> Stimmt F_CPU? Stimmen die Fuse-Bits, so dass der wirklich mit 20MHz> läuft?>> Ich weiß nun auch nicht, wie diese Register- und Bit-Definitionen zu> verstehen sind, daher die Frage: Was ist der Unterschied zwischen _bm,> _gc und _bp? Kann man die so miteinander verwursten, wie du das tust?>> MfG, Arno
Hallo Arno,
guck oben meinen Quelltext an, die While mit "Hallo" etc..
Wenn ich das so mache, bekomme ich jede Sekunde 1 Zeichen (255) also
eher 1 Byte gesendet. Das war's. Mache ich aus dem String ein Putc (also
1 Zeichen senden), kommt gar nichts mehr an.
CPU Takt passt, Fueses auch. Ich nutze den oft den Prozessor, jedoch das
erste mal jetzt mit Uart Er läuft mit 20 Mhz int. Osc.
Die Register- und Bitdefinitionen sind Makros von Atmel, ist genau das
gleiche wie bei den Xmega. Das kann man machen. _bp ist einfach die
Bitposition (bspw. 7) _bm ist Bitmask also bspw. 0x80.
HTerm ohne Flusskontrolle etc.
Das läuzft über einen 0/815 USB-Serial Wandler (CP irgendwas, den nutze
ich immer dafür, sonst bei den Mega/Xmegas). Das läuft auch alles.
Daniel schrieb:> brauchte man beim AVR nicht sowas wie pgm_read_byte, um auf> Stringkonstanten im Flash zugreifen zu können?
Ja wenn es im Flash liegt schon. Tut es ja bei mir nicht
Mr. AVR schrieb im Beitrag #5450841:
> Daniel schrieb:>> brauchte man beim AVR nicht sowas wie pgm_read_byte, um auf>> Stringkonstanten im Flash zugreifen zu können?>> Ja wenn es im Flash liegt schon. Tut es ja bei mir nicht
Na da bin ich aber froh ;-)
Probier's doch trotzdem mal, ich bin ziemlich sicher, Dein Compiler ist
anderer Meinung.
Daniel schrieb:> Mr. AVR schrieb im Beitrag #5450841:>> Daniel schrieb:>>> brauchte man beim AVR nicht sowas wie pgm_read_byte, um auf>>> Stringkonstanten im Flash zugreifen zu können?>>>> Ja wenn es im Flash liegt schon. Tut es ja bei mir nicht>> Na da bin ich aber froh ;-)> Probier's doch trotzdem mal, ich bin ziemlich sicher, Dein Compiler ist> anderer Meinung.
Na da muss ich dich wohl enttäuschen.
Ich habe 7 Byte mehr SRAM Verbrauch wenn ich es so mache - das liegt
nicht im Flash - warum auch? Wenn müsste ich das dazu explizit mit
PROGMEM = ... ablegen. Sowas das der Compiler das macht hatte ich auch
noch nie.
Moby schrieb im Beitrag #5450852:
> Mr. AVR schrieb im Beitrag #5450843:>> Tue ich ja oben, spreche die Register direkt an.>> Nö tust Du nicht. Nämlich die Dinge lt. Datenblatt ansprechen.> Lies Dir dazu mal die entsprechende Passage zur UART-Initialisierung> beim Tiny1614 durch und vergleiche, ob Du das erforderliche mit Deinem> Code tust!
Was ist dein Problem? Die Init etc. läuft nach Datenblatt wie ich es
verstanden habe. Wenn ich was falsch gesetzt habe sag es mir, vll. ist
dort der entsprechende Fehler.
Andernfalls weiß ich nicht was du willst. Es sind alles Makros vom Atmel
Studio direkt.
Beispiel: PORTA.OUTTGL entspricht #define PORTA (*(PORT_t *) 0x0400)
Das ist von Atmel vordefiniert. Ich plage mich nicht mit ASM rum bei dem
Programm - das macht kein Mensch. Man kann mal ein Inline ASM machen
wenn es sein muss, ansonsten C oder C++.
Mr. AVR schrieb im Beitrag #5450856:
> Wenn müsste ich das dazu explizit mit> PROGMEM = ... ablegen.
Ok sorry, das hat bei mir immer ein Makro gemacht, darum habe ich das
nicht gesehen.
Moby schrieb im Beitrag #5450859:
> Mr. AVR schrieb im Beitrag #5450857:>> Ich plage mich nicht mit ASM rum bei dem>> Programm - das macht kein Mensch.>> Das ist im Vergleich zu Krypto-C keine Plage sondern eine Wohltat, glaub> mir. Ansonsten nimm Dir das Datenblatt zur Hand und schau endlich nach> was Du vergessen hast- und handle nicht bloß>>> wie ich es>> verstanden habe
Ich würde mich nicht ans Forum wenden, wenn ich nicht den Teil der Uart
mittlerweile auswendig kann und nicht mehr weiß, was ich machen soll.
Hast du bei deinem Krypto-ASM denn die Register entsprechend gleich
gesetzt wie ich?
Mr. AVR schrieb im Beitrag #5450822:
> Arno schrieb:>> Mr. AVR schrieb im Beitrag #5450757:>>> Ansonsten habe ich im Programm noch nichts. PinB2 als Ausgang, PinB3 als>>> Eingang gepullt. Auf HTerm bekomme ich nur 255, 1 Zeichen obwohl ich>>> einen String sende "Hallo", wenn ich nur ein Zeichen sende kommt nichts>>> an.>>>> Was meinst du mit "bekomme ich nur 255, 1 Zeichen"?>> guck oben meinen Quelltext an, die While mit "Hallo" etc..> Wenn ich das so mache, bekomme ich jede Sekunde 1 Zeichen (255) also> eher 1 Byte gesendet. Das war's. Mache ich aus dem String ein Putc (also> 1 Zeichen senden), kommt gar nichts mehr an.
Das sieht sehr nach falscher, viel zu hoher Baudrate aus. Wenn du den
String sendest, ist irgendwo dazwischen (im Zweifelsfall im 0-Byte am
Ende) ein relativ langer Bereich 0, der als Start-Bit erkannt wird. Die
Datenbits, die anschließend erkannt werden, sind dann alle 1 (-> 255)
oder das erste noch 0, der Rest 1 (->127). Wenn du nur ein einzelnes
Zeichen sendest, erkennt der PC gar kein Start-Bit. Kannst ja mal
versuchen, 0 zu senden...
Oder der TX-Pin muss noch auf Ausgang gesetzt werden - keine Ahnung, ob
das bei dem Chip automatisch mit aktivieren der UART passiert oder
nicht.
Mit der Info und nach acht Stunden Schlaf würde ich als nächstes deine
UBR-Berechnung durch einen festen Wert aus der Tabelle ersetzen.
MfG, Arno