ATMega8 an Serieller SS sendet Müll

[Studiologe .. (studiologe)]

Hallo zusammen,
ich habe aus dem UART-Teil des AVGCC-Tutorials mal die Routine für das 
senden eines einzelnen Zeichens auf die Serielle Schnittstelle 
ausgeliehen und versucht mittels diesen Codes meinen ATMega8 dazu zu 
bringen, P (0x50) an meinen Computer zu senden.... Das ganze in einer 
Endlosschleife, der PC empfängt auch tatsächlich jede menge 
(gleiche)zeichen, jedoch nicht P.
anstelle des P empfängt er § (0x15). wenn ich nun hingehe und versuche O 
(großes o = 0x4F) zu senden kommt wider erwarten nicht das Zeichen 
(0x14) welches einen vor §(0x15) ist, sondern aus der ganz anderen Ecke 
der ASCII Tabelle das X (0x58)....

Hier der code

#include "avr/io.h"


/* USART-Init beim ATmega16 */
#ifndef F_CPU
#define F_CPU 16000000           /* Oszillator-Frequenz in Hz */
#endif
 
// Hilfsmakro zur UBRR-Berechnung ("Formel" laut Datenblatt)
#define UART_UBRR_CALC(BAUD_,FREQ_) ((FREQ_)/((BAUD_)*16L)-1)
 
#define UART_BAUD_RATE 19200


int main(void)
{
  /*        I/O Settings      */
  UCSRB |= (1<<TXEN);                 // UART TX einschalten
    UCSRC |= (1<<URSEL)|(3<<UCSZ0);     // Asynchron 8N1 
  UBRRH = (uint8_t)( UART_UBRR_CALC( UART_BAUD_RATE, F_CPU ) >> 8 );
  UBRRL = (uint8_t)UART_UBRR_CALC( UART_BAUD_RATE, F_CPU );
  
  unsigned int i=0;
  

  
  while(1)
  {    
    // bei neueren AVRs steht der Status in UCSRA/UCSR0A/UCSR1A, hier z.B. fuer ATmega16:
    while (!(UCSRA & (1<<UDRE)))  /* warten bis Senden moeglich                   */
    {
      
    }
    
    UDR = 0x50;    // P
  }
}

kann es vll daran liegen, das in dem Tutorial der Code für einen 
ATMega16/32 ist und ich ihn auf einen ATMega8 anwende ? normal 
unterscheiden die 3 sich doch abgesehen vom Speicher nicht wirklich oder 
??


Danke

[Johannes M. (johnny-m)]

Das übliche: Welche Taktquelle? Und versuchs mal mit

#define F_CPU 16000000UL

Und check mal, wenn Du mit AVRStudio arbeitest, ob in den Configuration 
Options auch 16000000Hz stehen. Wenn nicht, dann eingeben.

[Studiologe .. (studiologe)]

Hallo und danke für die rasche Antwort....

leider macht er immer noch das gleiche wie vorher, also das $ anstelle 
des P Senden. naja zumindest empfängt der PC das §, weiß nicht ob der µC 
das P sendet oder doch tatsächlich das §... aber ich denke das liegt am 
µC, das der mist sendet :)

Also ich arbeite mit Programmers Notepad und werfe die Programme dann 
per PonyProg rein. Als Taktquelle habe ich einen externen 16MHz Quarz.
Bei den Fuses habe ich alle Häckchen bei CKSEL entfernt, also sollte auf 
externen Takt umgestellt sein.

Hat sonst noch jemand eine Idee ??

[Johannes M. (johnny-m)]

> Als Taktquelle habe ich einen externen 16MHz Quarz.
> Bei den Fuses habe ich alle Häckchen bei CKSEL entfernt, also sollte auf
> externen Takt umgestellt sein.
Für einen Quarz darfst Du aber KEINEN externen Takt einstellen. Du 
musst auf "external Crystal/Resonator" (high Frequency, > 8 MHz) fusen. 
Sonst klappt gar nichts.

EDIT:
"Externer Takt" (external clock) bedeutet, dass ein externer Taktgeber 
(z.B. ein QuarzOSZILLATOR oder eine andere externe Taktquelle) 
dranhängt, die bereits ein "fertiges" Taktsignal liefert. Dabei wird 
durch die Fuses der im µC eingebaute Oszillator komplett abgeschaltet.

Da die Fuses in PonyProg allerdings invertiert sind, müssten die 
Einstellungen bei Dir passen (CKSEL3..0 = 1111). Der Fehler muss dann 
woanders liegen.

Aber verwechsle nie "externer Takt" mit "externer Quarz"! Steht im 
Datenblatt allerdings an einigen Stellen auch ein bisschen verwirrend 
drin...

[Studiologe .. (studiologe)]

Ja sorry meinte ja chrystal....
ist auch richtig eingestellt:
External Crystal/Ceramic Resonator 1111 - 1010
da ich einen Crystal habe also auf 1111, d.h. bei Ponyprog alle Häckchen 
bei CKSEL weg, so habe ich das auch....

[Johannes M. (johnny-m)]

Ach ja, die CKOPT-Fuse sollte für so hohe Frequenzen programmiert sein 
(Häkchen rein).

[Johannes M. (johnny-m)]

...und im Terminal ist auch das richtige Frame-Format und die Baudrate 
eingestellt?

[Studiologe .. (studiologe)]

Jo CKOPT ist natürlich auch ein Häckchen,
die Einstellungen bei HyperTerminal sind wie auf dem Bild im
Dateianhang zu sehen richtig eingestellt. aber es geht leider nicht...
Empfangen wird ja die ganze zeit etwas, aber leider das falsche Zeichen

§ statt P

[Auch einer (Gast)]

Lade dir mal

http://www.docklight.de/

runter.
 Benutze nur noch das, ist um Welten besser
als das der Firma Winzigweich.

Es zeigt dir auch Steuerzeichen an.

[Studiologe .. (studiologe)]

Hi, also ich habe mir das mal runtergeldan, gefällt mir ehrlich gesagt 
auch schon besse als das von M$

jedoch empfange ich damit auch nur Mist....
Ich sende laut source-code ein 0x50, empfangen wird
ASCII: }
HEX  :7D
Dec  :125


also liegt es auch nicht am Hyperterminal, obwohl ich da auch was 
anderes empfange (§ statt 0x50)

[Studiologe .. (studiologe)]

hmm also komischer Effekt ist nun, das wenn ich auf stopp klicke, kurz 
darauf auf start, das dann unterschiedliche daten empfangen werden.....

beim ersten mal war es:
ASCII: }
HEX  :7D
Dec  :125
dann plötzlich
ASCII: -
HEX  :5F
Dec  :095

dann wieder
ASCII: }
HEX  :7D
Dec  :125


????? was ist los mit der verrückten Computerwelt ?

[Auch einer (Gast)]

Mit was Prog. du?
AVR Studio & WinAVR?
Bei mir funktioniert der code einwandfrei.

[Thilo M. (Gast)]

>das dann unterschiedliche daten empfangen werden.....

Kann passieren wenn die Zeichen ununterbrochen kommen, dann kann es 
passieren, dass der PC das Startbit nicht mehr korrekt finden kann.

Hast du einen USB/Seriell-Adapter dran? Dual-Core CPU? Das kann auch 
Probleme machen, besonders wenn mehrere Adapter gleichzeitig laufen.

[Matthias (Gast)]

Das liegt an baudrate/stoppbit/paritätseinstellungen!
Irgendwo gleichen die sich nicht!
vielleicht stimmt auch nur die quartzfreuqenz nicht

[Auch einer (Gast)]

Wenn du WinAVR benutzt, welche Quarzfrequenz ist in der
Project Option eingestellt?
Diese Einstellung überschreibt dir die Einstellung in deinem Code.

[Studiologe .. (studiologe)]

Also ich arbeite mit Programmers Notepad und werfe die Programme dann
per PonyProg rein, wie oben schon erwähnt.

wo finde ich denn die Project Option  ???

[Karl H. (kbuchegg)]

Mach da

/* USART-Init beim ATmega16 */
#ifndef F_CPU
#define F_CPU 16000000           /* Oszillator-Frequenz in Hz */
#endif

mal

/* USART-Init beim ATmega16 */
#define F_CPU 16000000           /* Oszillator-Frequenz in Hz */

draus.
Also ohne das #ifndef / #endif.
Wer weiss, welche CPU Frequenz dem Compiler über das Makefile
vorgegeben wird.

[Auch einer (Gast)]

Ändere das UCSRC |= (1<<URSEL)|(3<<UCSZ0);     // Asynchron 8N1
in das UCSRC |= (1<<URSEL)|(1<<UCSZ0))|(1<<UCSZ1);     // Asynchron 8N1
mal.

[Thilo M. (Gast)]

@  Karl heinz:
Ich habe seinen Code schon getestet, UBRRL stimmt (51), UBRRH braucht's 
normalerweise nicht, da bei 16MHz und Baudraten > 3922 sowieso immer 0 
drinsteht.

[Johannes M. (johnny-m)]

Studiologe .-. wrote:
> wo finde ich denn die Project Option  ???
Lass Dir nix erzählen. Die Configuration Options gibts nur im AVRStudio, 
mit dem Du ja nicht arbeitest. Du müsstest, wenn überhaupt, dann im 
Makefile die Änderungen direkt machen. Aber die Methode von Karl Heinz 
ist für Deine Einstellungen sicher die sicherste.

[Johannes M. (johnny-m)]

Auch einer wrote:
> Ändere das UCSRC |= (1<<URSEL)|(3<<UCSZ0);     // Asynchron 8N1
> in das UCSRC |= (1<<URSEL)|(1<<UCSZ0))|(1<<UCSZ1);     // Asynchron 8N1
> mal.
Das ist beide Male exakt dasselbe...

[Thilo M. (Gast)]

Schätze auch mal dass es am Makefile liegt, wenn's mit Mfile erstellt 
wurde dürften da 8MHz drinstehen (default).

[Johannes M. (johnny-m)]

Thilo M. wrote:
> Schätze auch mal dass es am Makefile liegt, wenn's mit Mfile erstellt
> wurde dürften da 8MHz drinstehen (default).
In dem Falle müsste ja die Lösung von Karl Heinz den gewünschten Erfolg 
bringen. Wir werden sehen...

[Studiologe .. (studiologe)]

hmm also zu F_CPU finde ich garnichts im Makefile, sollte also daher 
egal sein oder ?
Hat auf jeden Fall auch nicht den gewünschten Effekt gebracht :(

[Studiologe .. (studiologe)]

Hier mal das Makefile, vll habe ich ja auch irgendwas anderes darin 
falsch gestellt....

[Johannes M. (johnny-m)]

BTW:
Wenn bei solchen Sachen irgendwas nicht klappt, ist es IMMER sinnvoll, 
als erstes alle Makros, die irgendwelche kritischen Werte berechnen oder 
angeben (in diesem Falle gilt das besonders für UART_UBRR_CALC und 
F_CPU), rauszuschmeißen und die Register zumindest probeweise von Hand 
zu setzen. Also in diesem Falle alle #defines weg und ins UBRR den 
errechneten Wert (also hier 51, wie ja oben irgendwo schon mal erwähnt) 
reinschreiben.

[ozo (Gast)]

Ich denk, du benutzt einen Mega8?
Im Makefile ist noch Mega16 gewünscht...

[Johannes M. (johnny-m)]

Studiologe .-. wrote:
> hmm also zu F_CPU finde ich garnichts im Makefile, sollte also daher
> egal sein oder ?
Den Fall hatten wir neulich schon mal. Da war es zwar ein vom AVRStudio 
erstelltes Makefile, in dem ohne eine explizite Angabe bei den 
Configuration Options auch kein F_CPU-Wert zu finden war (ansonsten 
gleicher Aufbau wie bei Dir mit #ifndef F_CPU...). Klappen tat es aber 
nur mit einer Eingabe des korrekten Frequenzwertes in den Configuration 
Options vom AVRStudio (und damit im Makefile).

> Hat auf jeden Fall auch nicht den gewünschten Effekt gebracht :(
Wie gesagt, schmeiß das #ifndef...#endif raus. Dann muss der Compiler 
auf jeden Fall den angegebenen Wert nehmen. Oder, wie oben gesagt, alles 
direkt eingeben. Oder dem F_CPU für Code-interne Anwendungen einen 
anderen Namen verpassen...

[Johannes M. (johnny-m)]

ozo wrote:
> Ich denk, du benutzt einen Mega8?
> Im Makefile ist noch Mega16 gewünscht...
Oha! Ich hab mir das Makefile jetzt nicht angeschaut, aber wenn das so 
ist, dann wundert mich gar nichts...

[ozo (Gast)]

Jetzt hab ich extra nochmal nachgeguckt, ich habe nicht phantasiert:
---
# MCU name
MCU = atmega16
---

[Thilo M. (Gast)]

>UCSRC |= (1<<URSEL)|(3<<UCSZ0);

URSEL sollte low sein. Mit high schreibst du in UCSRC, nicht in UBRRH.
Kommentiere diese Zeile einfach mal aus.

[Studiologe .. (studiologe)]

Also gut habe jetzt mal alles ins folgende geändert, was leider auch 
nicht geholfen hat....
im Makefile habe cih auch ATMega8 reingeschrieben statt ATMega16, half 
auch nicht :(

#include "avr/signal.h"
#include "avr/io.h"

int main(void)
{
  /*        I/O Settings      */
  UCSRB |= (1<<TXEN);                 // UART TX einschalten
    UCSRC |= (1<<URSEL)|(1<<UCSZ0)|(1<<UCSZ1);     // Asynchron 8N1

  
  unsigned int i=0;
  

  
  while(1)
  {    
    // bei neueren AVRs steht der Status in UCSRA/UCSR0A/UCSR1A, hier z.B. fuer ATmega16:
    while (!(UCSRA & (1<<UDRE)))  /* warten bis Senden moeglich                   */
    {
      
    }
    
    UDR = 0x50;    // P
    
  }
}

[Johannes M. (johnny-m)]

Thilo M. wrote:
>>UCSRC |= (1<<URSEL)|(3<<UCSZ0);
>
> URSEL sollte low sein. Mit high schreibst du in UCSRC, nicht in UBRRH.
> Kommentiere diese Zeile einfach mal aus.
Hallo? Genau das will er doch! Da steht explizit, dass UCSRC geschrieben 
werden soll!

Es kann eigentlich tatsächlich nur am Makefile liegen. Wenn da der 
falsche µC-Typ drinsteht, ist die Wahrscheinlichkeit für ein 
Nicht-Funktionieren sehr groß.

[Johannes M. (johnny-m)]

Studiologe .-. wrote:
> Also gut habe jetzt mal alles ins folgende geändert, was leider auch
> nicht geholfen hat....
Du darfst das Setzen des UBRRL auch nicht wegschmeißen! Woher soll der 
denn jetzt wissen, mit welcher Baudrate er arbeiten soll?

[ozo (Gast)]

Okay, so bringt das nix.
Schick doch bitte mal die Ausgabe von make.

[Studiologe .. (studiologe)]

habe aber Makefile wie gesagt angepasst...
siehe anhang

[Thilo M. (Gast)]

>Genau das will er doch!
Hab's gerade gesehen. Ich habe diese Bits noch nicht verwendet, lief bis 
jetzt immer prima mit xx,n,8,1.

[Johannes M. (johnny-m)]

...Nur damit wir uns richtig verstehen: Die Zeile

UBRRL = 51;

ist WICHTICH. Die muss da irgendwo bei der Initialisierung stehen 
bleiben.

[ozo (Gast)]

Okay, nach erstem Augenschein sieht Makefile sinnig aus.
Und was bekommst du als Ausgebe bei "make all" ?

[Thilo M. (Gast)]

Kannst es ja mal mit dem Malefile versuchen.

[Studiologe .. (studiologe)]

Hmm vll liegt es ja auch daran, wie ich das miteinander verkabelt habe?!
Also
µC   -- PC
TxD   RxD
RxD   TxD
GND   GND
VCC   CD (Carrier Detect)

sollte doch soweit richtig sein, vor allem da der PC ja auch was 
empfängt

[ozo (Gast)]

#include "avr/signal.h"
ist übriges veraltet, sollte nicht mehr benutzt werden.
Und da du ja sowieso keine Interrupts benutzt -> raus damit

[ozo (Gast)]

Pegewandler ist schon dazwischen?

[Thilo M. (Gast)]

Wie jetzt, direkt oder über MAX232 (oder sonstigen Pegelwandler)?

[Auch einer (Gast)]

Habe aus deinem Code mit AVR Studio mal ein Hex-File gemacht.

Teste das einfach mal.

[Studiologe .. (studiologe)]

Pegelwandler ? ähhh hmmm also ich glaube daran liegts, ist nämlich 
keiner dran....

wie sieht denn sowas aus ? also bisher gehe ich noch direkt dran, wird 
auch der fehler sein.... oder ?

[Johannes M. (johnny-m)]

Studiologe .-. wrote:
> Pegelwandler ? ähhh hmmm also ich glaube daran liegts, ist nämlich
> keiner dran....
Autsch! Das erklärt einiges. Man sollte Dich...

> wie sieht denn sowas aus ? also bisher gehe ich noch direkt dran, wird
> auch der fehler sein.... oder ?
Google mal nach MAX232. Im AVR-GCC-Tutorial steht übrigens an der 
entsprechenden Stelle auch etwas über die Pegel!

[Thilo M. (Gast)]

Kannst auch Testweise mal das UCPOL-Bit setzen, das invertiert die 
Pegel. Manche Schnittstellen kommen mit 0 und 5V aus.

[Studiologe .. (studiologe)]

hehe jo den absatz habe ich gan übersehen :)
tut mir leid, das ich eure zeit so "verschwendet habe"...
ich bin mal eben bei reichelt was bestellen

[Studiologe .. (studiologe)]

wo kann ich denn das UCPOL bit setzten ?
UCSRC |= (1<<URSEL)|(1<<UCSZ0)|(1<<UCSZ1)|(1<<UCPOL);     // Asynchron 
8N1

oder ??

[Thilo M. (Gast)]

UCSRC |= (1<<URSEL)|(1<<UCPOL);

zum Beispiel?

[Matthias (Gast)]

ich vermute einen MAX232 ;-)

[Johannes M. (johnny-m)]

Studiologe .-. wrote:
> wo kann ich denn das UCPOL bit setzten ?
> einfach über UCPOL = 1; ??
> steht so zumindest im datenblatt
Ich frage mich langsam, ob Du Dich überhaupt ernsthaft mit der Materie 
beschäftigt hast, oder ob Du einfach nur hirnlos Code kopiert hast, ohne 
ihn zu verstehen.

Wie setzt Du denn in "Deinem" Code oben die Bits in den Steuerregistern? 
Aha! Und genau so wird auch das UCPOL behandelt...

[Studiologe .. (studiologe)]

ja habs gesetzt über
UCSRC |= (1<<URSEL)|(1<<UCSZ0)|(1<<UCSZ1)|(1<<UCPOL);     // Asynchron 
8N1

hat aber auch nicht den gewünschten effekt gebracht, mus nen 
pegelwandler her...

[ozo (Gast)]

Nur noch eine ganz peinliche Frage, wie hast du denn RX und TX 
verbunden?

[Auch einer (Gast)]

Hier eine Schaltung ohne MAX232

[Auch einer (Gast)]

Lochraster Bild von oben im Anhang

[Falk (Gast)]

@ Thilo M. (power)

>Hast du einen USB/Seriell-Adapter dran? Dual-Core CPU? Das kann auch
>Probleme machen, besonders wenn mehrere Adapter gleichzeitig laufen.

???
Schon wieder 1. April? Duo-Core CPU von USB-RS232 Adaptern überlastet? 
Ist die Software für Duo-core Unterstützung soooo schlecht?

MfG
Falk

[Thilo M. (Gast)]

Hi Falk,
nee, wir hatten auf Arbeit neue Laptops angeschafft (Dualcore), mit 
denen konnten wir unsere Messumformer per RS232 nicht mehr 
parametrieren. Laut Softwareprogrammiere liegt's am Dualcore, warum auch 
immer.
Mit den Adaptern hatte ich selbst schon Probleme, wenn zwei Adapter sich 
einen Treiber teilten gab es schwere Timingprobleme, mehrere Bytes 
wurden 'verschluckt' und beim nächsten Ansprechen kamen die auf einmal.
Das Problem ist nicht aus der Luft gegriffen, hat schon seinen Grund 
warum ich gefragt habe.

[Andreas K. (a-k)]

Sowas gibt's wirklich. Dass Device-Driver an einem Multiprozessorsystem 
scheitern. Auch schon auf einem alten P4 mit Hyperthreading oder einem 
Pentium-Pro Doppelprozessorsystem. Weil der Programmierer zu blöd war 
das zu berücksichtigen, oder dessen Arbeitgeber zu knauserig ihm eine 
entsprechende Kiste hinzustellen. Konnte einem auch vor 2 Jahren noch 
bei einer USB-Adapterkarte von Adaptec(!) passieren.

[Simon K. (simon)]

Thilo M. wrote:
> Kannst auch Testweise mal das UCPOL-Bit setzen, das invertiert die
> Pegel. Manche Schnittstellen kommen mit 0 und 5V aus.

Zitat ATmega8 Datenblatt(10/06) Seite 157:

> UCPOL
> This bit is used for Synchronous mode only. Write this bit to zero when
> Asynchronous mode is used.

[Thilo M. (Gast)]

Danke, hatte ich übersehen! ;)

[Falk (Gast)]

@ Thilo M. (power)

>nee, wir hatten auf Arbeit neue Laptops angeschafft (Dualcore), mit
>denen konnten wir unsere Messumformer per RS232 nicht mehr
>parametrieren. Laut Softwareprogrammiere liegt's am Dualcore, warum auch
>immer.

Das ist ein Witz. Wenn gleich ein schlechter. :-(
So ein lausiges 1200 Baud Protokoll scheitert an High-Tec? Und warum. 
Weil garantiert mal wieder jemand irgendwelche Zählschleifen zur 
"Timinganpassung" verwendet.

>Mit den Adaptern hatte ich selbst schon Probleme, wenn zwei Adapter sich
>einen Treiber teilten gab es schwere Timingprobleme, mehrere Bytes
>wurden 'verschluckt' und beim nächsten Ansprechen kamen die auf einmal.

Schnittstelle entweder schlecht geschrieben oder verwendet.
Naja, thats life.

MfG
Falk

[Thilo M. (Gast)]

>Das ist ein Witz. Wenn gleich ein schlechter. :-(

Wir fanden's nicht soo witzig! :(
Da kommste ganz schön in's Schleudern, gottseidank waren die alten 
Laptops noch da.

[Andreas K. (a-k)]

> Weil garantiert mal wieder jemand irgendwelche Zählschleifen zur
> "Timinganpassung" verwendet.

Das dürfte aus der Mode sein. Eher schon weil er übersehen hat, dass bei 
einem Multiprozessorsystem der Code des Treibers in mehreren 
Prozessen/Threads gleichzeitig laufen kann.

[Falk (Gast)]

@ Andreas Kaiser (a-k)

>> Weil garantiert mal wieder jemand irgendwelche Zählschleifen zur
>> "Timinganpassung" verwendet.

>Das dürfte aus der Mode sein.

1.) Darauf würde ich nciht wetten.
2.) War die Software wahrscheinlich schon älter.

> Eher schon weil er übersehen hat, dass bei
>einem Multiprozessorsystem der Code des Treibers in mehreren
>Prozessen/Threads gleichzeitig laufen kann.

Und? Was änders sich da aus Sicht des Programmierers einer Anwendung? 
Ich würde erstmal sagen GAR NCIHTS! Die LOGISCHE Abfolge MUSS 100% 
identisch sein. Und wenn das Timing sauber über Timer, Flags etc. 
gemacht ist darf da auch GAR NICHTS anbrennen. Wenn, ja wenn . . .

MfG
Falk