ATMega8 an Serieller SS sendet Müll

Das übliche: Welche Taktquelle? Und versuchs mal mit

1

#define F_CPU 16000000UL

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

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 ??

> 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...

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....

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

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

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

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)

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 ?

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  ???

Mach da

1

/* USART-Init beim ATmega16 */

2

#ifndef F_CPU

3

#define F_CPU 16000000           /* Oszillator-Frequenz in Hz */

4

#endif

mal

1

/* USART-Init beim ATmega16 */

2

#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.

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.

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. 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...

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 :(

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

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.

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...

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...

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 :(

1

#include "avr/signal.h"

2

#include "avr/io.h"

3

4

int main(void)

5

{

6

  /*        I/O Settings      */

7

  UCSRB |= (1<<TXEN);                 // UART TX einschalten

8

    UCSRC |= (1<<URSEL)|(1<<UCSZ0)|(1<<UCSZ1);     // Asynchron 8N1

9

10

11

  unsigned int i=0;

12

13

14

15

  while(1)

16

  {    

17

    // bei neueren AVRs steht der Status in UCSRA/UCSR0A/UCSR1A, hier z.B. fuer ATmega16:

18

    while (!(UCSRA & (1<<UDRE)))  /* warten bis Senden moeglich                   */

19

    {

20

21

    }

22

23

    UDR = 0x50;    // P

24

25

  }

26

}

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ß.

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?

habe aber Makefile wie gesagt angepasst...
siehe anhang

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

1

UBRRL = 51;

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

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

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 ?

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!

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

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

oder ??

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...

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...

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.

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.

> 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.