Hallo zusammen,
ich habe ein Programm geschrieben, dass Bytes über die serielle
Schnittstelle an den ATtiny13 sendet, und empfangene Bytes anzeigt. Wenn
ich jetzt mit Bascom programmiere, dass der Tiny13 mir einen Text
ausgeben soll, kommt der richtig an, die Baudrate habe ich sowohl im
Bascom als auch in meinem Programm auf 1000 gestellt. Wenn ich jetzt
z.B. das Byte 126 an den Tiny13 sende, verarbeitet es dies irgendwie
nicht.
Weiß jemand warum?
Das Byte kommt richtig an, das sehe ich, wenn ich den Ausgang vom
Computer an den Eingang vom Computer schließe.
Code ist folgender:
$regfile = "attiny13.dat"
$crystal = 1200000
Open "comb.0:1000, 8,n,1,Inverted" For Output As #2
Open "comb.1:1000, 8,n,1,Inverted" For Input As #1
Dim B As Byte
Do
B = Inkey(#1)
Loop Until B = 126
Print #2 , "126"
End
Vielen Dank!
F. J. schrieb:
> z.B. das Byte 126 an den Tiny13 sende, verarbeitet es dies irgendwie> nicht.
Wie wäre es, wenn du dir einfach mal den Wert von B ausgeben lässt?
Dann brauchst du nicht raten, sondern siehst direkt welche Bytes der
Tiny empfängt.
> die Baudrate habe ich sowohl im> Bascom als auch in meinem Programm auf 1000 gestellt.
1000 ist aber eine sehr unübliche Baudrate.
Kannst du die wirklich an deinem PC einstellen?
F. J. schrieb:
> Bei 9600 gab es Übertragungsfehler, bei der Ausgabe von Text, deswegen> 1000.
Aha. Lass mich raten.
Kein Quarz, interner Oszillator?
(Geh deinen Übertragungsfehlern auf den Grund. Bei 9600 darf es keine
Fehler geben.)
Karl heinz Buchegger schrieb:
> Aha. Lass mich raten.> Kein Quarz, interner Oszillator?
Ja.
Wieso geht es aber bei der Ausgabe, und wieso funktioniert der Eingang
nicht?
Mist. Das ist schlecht. Ein Quarz einbauen geht überhaupt nicht. Kann
ich Softwaremäßig was machen? Ich müsste 60 Bytes übertragen. Wieso
funktioniert der serielle ISP-Programmer dann eigentlich?
F. J. schrieb:
> Mist. Das ist schlecht. Ein Quarz einbauen geht überhaupt nicht.
Dann hast Du auch keinen Anspruch auf wirklich zuverlässig
funktionierendes RS232.
> Kann> ich Softwaremäßig was machen?
Es kann am Schreibtisch funktionieren, es muss aber nicht.
> Ich müsste 60 Bytes übertragen.
RS232 geht nunmal nur zuverlässig, wenn die Baudrate stimmt. Es wird
schließlich bei jedem Byte nur einmal synchronisiert (Startbit).
> Wieso> funktioniert der serielle ISP-Programmer dann eigentlich?
Der arbeitet nach einem anderen Protokoll (SPI, synchron, wie bei
Schieberegistern) und nutzt eine separate Taktleitung zur
Synchronisation.
...
Das das mit dem RC nicht zuverlässig wird, wurde ja schon erwähnt. Und
du solltest das ernst nehmen.
Nichts desto trotz. Wenn deine Schaltung in etwa immer in derselben
Umgebungstemperatur arbeitet, wird auch der RC sich nicht allzuviel
verstellen.
Daher sollte man jetzt als allererstes
$crystal = 1200000
abklären, wie genau diese Angabe wirklich ist.
Sprich: du musst die Taktfrequenz deines µC herausfinden.
Karl heinz Buchegger schrieb:
> Das das mit dem RC nicht zuverlässig wird, wurde ja schon erwähnt. Und> du solltest das ernst nehmen.>> Nichts desto trotz. Wenn deine Schaltung in etwa immer in derselben> Umgebungstemperatur arbeitet, wird auch der RC sich nicht allzuviel> verstellen.
Dann lohnt es sich, mit Baudratenangaben zu experimentieren, die dicht
neben der gewünschten Baudrate liegen. Bei Änderung von
Versorgungsspannung und/oder Temperatur muss das aber nicht mehr
funktionieren, ebenso bei einem anderen Exemplar.
Bei einem Mega8 funktionierte RS232 ohne Quarz z.B. überhaupt nicht. Da
ein GLCD im 8-Bit-Mode angeschlossen war, konnte ich auch keinen Quarz
anschließen, denn ich wollte den Datenport nicht teilen. Beim Tiny2313
meines Pollin-IR8-Bausatzes funktioniert RS232 (Hardware-USRT) mit 19200
Baud auch ohne Quarz. Mir ist aber bewusst, dass es nicht funktionieren
muss.
>>> Daher sollte man jetzt als allererstes>> $crystal = 1200000>> abklären, wie genau diese Angabe wirklich ist.> Sprich: du musst die Taktfrequenz deines µC herausfinden.
Naja, für einen neuen Tiny13 vom Markenhändler stimmt das schon, solange
die Fuses nicht angerührt wurden. Sollte das Ding aber anderer Herkunft
sein (Pollin, Lernprogramm, Bausatz), dann muss man die
Fusebiteinstellungen eben nochmal überprüfen.
...
F. J. schrieb:
> Karl heinz Buchegger schrieb:>> Sprich: du musst die Taktfrequenz deines µC herausfinden.>> Gut. Aber wie kann ich das machen?
Z.B. durch Auslesen der Fusebits und Vergleich mit den Angaben im
Datenblatt des Tiny13.
...
Hannes Lux schrieb:
>> abklären, wie genau diese Angabe wirklich ist.>> Sprich: du musst die Taktfrequenz deines µC herausfinden.>> Naja, für einen neuen Tiny13 vom Markenhändler stimmt das schon, solange> die Fuses nicht angerührt wurden.
Echt?
Einen Tiny13 hatte ich noch nie in den Fingern. Einen Tiny11. Gut das
ist zwar eine andere Baustelle, aber ohne den OSCAL war der sowas von
daneben.
Ich werd mal gucken, ob ich damit weiterkomme.
Ansonsten würd ich es kompliziert machen, und sowas programmieren:
Senden "a"
Warten 2 MS
Auslesen Zustand an Pin, entscheiden ob 1 oder 0
das 5 mal
und dann zu Byte konvertieren.
Wäre das vom verfügbarem Speicher möglich?
Vielen Dank für eure Hilfe!
Karl heinz Buchegger schrieb u.A.:
> Hannes Lux schrieb u.A.:>> Naja, für einen neuen Tiny13 vom Markenhändler stimmt das schon, solange>> die Fuses nicht angerührt wurden.>> Echt?> Einen Tiny13 hatte ich noch nie in den Fingern. Einen Tiny11. Gut das> ist zwar eine andere Baustelle, aber ohne den OSCAL war der sowas von> daneben.
Ja, der läuft ab Werk mit internem RC mit 9,6 MHz und aktivem Vorteiler
1 zu 8 und ist damit halbwegs kompatibel zum Vorgänger Tiny12. Ich nutze
der Tiny13 ganz gern, allerdings nicht mit UART. Da bevorzuge ich
bitsynchronisierende serielle Übertragung.
...
Hallo zusammen,
ich hab mal weiter rumexperimentiert, und bei kleinerer Baudrate
funktioniert das ganze auch.
Es kommen wieder die Bytes zurück, die ich gesendet habe.
Allerdings ganz richtig ist es immer noch nicht, ich sende ca. 10 Bytes,
nach dreien oder vieren mache ich 1 sec. Pause, aber es kommen immer nur
die ersten drei Bytes zurück.
Woran kann das liegen?
Vielen Dank!
F. J. schrieb:
> Woran kann das liegen?
Der Takt wird mit der Zeit weglaufen.
Es gibt noch die Möglichkeit mit dem OSCCAL-Register den Takt anhand der
empfangenen Zeichen zu korrigieren. Gibt es hier auch Threads dazu.
Allerdings muss dazu der Empfangsinterrupt selbst geschrieben werden.
Weiss nicht ob das in BASCOM geht.
Grrrr schrieb:
> F. J. schrieb:>> Woran kann das liegen?>> Der Takt wird mit der Zeit weglaufen.>> Es gibt noch die Möglichkeit mit dem OSCCAL-Register den Takt anhand der> empfangenen Zeichen zu korrigieren. Gibt es hier auch Threads dazu.> Allerdings muss dazu der Empfangsinterrupt selbst geschrieben werden.> Weiss nicht ob das in BASCOM geht.
Z.B. so:
1
$baud = 19200 'Baudrate UART
2
...
3
On Urxc Onrxd 'UART-Empfangs-Interrupt
4
Enable Interrupts 'Interrupts global freigeben
5
...
6
7
Onrxd: 'ISR, UART-Byte eingetroffen
8
Incr Rix 'Schreibposition im Array erhöhen
9
Rx_buf(rix) = Udr 'Empfangsbyte in Buffer legen
10
Return 'fertig, zurück...
Wobei Rx_buf() ein Array zum Einsammeln der empfangenen Bytes ist und
Rix der Index zu diesem Array. Erreicht Rix den vereinbarten Wert
(entspricht len(string)), dann kopiert sich die Mainloop den Inhalt
woandershin und löscht Rix.
Dies diente zum Empfang von Bytekolonnen fester Länge, man kann es aber
auch als Ringbuffer organisieren.
...
Erstmal vielen Dank für eure Antworten!
Grrrr schrieb:
> Der Takt wird mit der Zeit weglaufen.
Also umso langsamer ich den Tiny13 Takte, umso länger funktioniert es?
F. J. schrieb:
> Erstmal vielen Dank für eure Antworten!>> Grrrr schrieb:>> Der Takt wird mit der Zeit weglaufen.
RS232 synchronisiert sich bei jedem Startbit (1 mal pro Byte) neu. Wenn
die ersten drei Bytes durchkommen, so sollten die anderen auch
durchkommen. Oder Du liegst dermaßen grenzwertig daneben, dass es Zufall
ist, ob es klappt oder nicht.
Vielleicht liegt der Fehler aber auch auf der PC-Seite. Ich hatte auch
mal ähnliche Probleme (mit Terminal und auch VB6), da spuckte der
RS232-FIFO im PC die Daten nicht zur rechten Zeit aus, sondern erst,
wenn weitere Daten eintrafen. Das muss hier aber nicht unbedingt der
Fall sein.
>> Also umso langsamer ich den Tiny13 Takte, umso länger funktioniert es?
Nööö, wenn es Baudratenfehler aufgrund von Frequenzabweichungen sind,
dann sind die bei jeder Baudrate und jeder Sollfrequenz (Takt) gleich.
Das einzige Argument, warum kleinere Baudraten weniger Fehler
verursachen, ist das, dass der Teilerfaktor größer und damit
ganzzahliger wird, also dass der Nachkommawert, der ja unterschlagen
wird, sich geringer auswirkt.
Wenn Du wirklich ohne Baudratenquarz eine RS232-Verbindung vom und zum
PC realisieren willst, dann lass den Tiny13 mit hoher Taktfrequenz
laufen (9M6) und experimentiere mit Baud-Angaben dicht um den Sollwert
herum. Also bei 9600 Baud mit Werten im Bereich von 9200 bis 10000.
Allerdings halte ich es für möglich, dass Bascom die Baudangaben auf
genormte Werte rundet, dass diese Maßnahme also nichts bringt.
Dann bleibt nur noch die Manipulation von OSCCAL. Hierbei sollte
beachtet werden, dass jedes Exemplar einen anderen Calibrationswert
haben kann. Die "magische Zahl", die Du ermitteln kannst, gilt also nur
für dieses eine Exemplar. Für eine Serie ist das also auch Murks.
Unterm Strich halte ich es deshalb für sinnvoller, einen AVR mit mehr
Pins und Hardware-UART zu benutzen, dem einen Baudratenquarz zu
spendieren und damit eine zuverlässige serielle Kommunikation zu
erreichen.
...
