www.mikrocontroller.net

Forum: Compiler & IDEs USART ATMega 168


Autor: Christian Beuge (christianbeuge)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen!

Ich bins mal wieder...

Ich würde gerne etwas über die UART schicken. Diesmal verwende ich den 
168er, einen externen Quarz (4MHz). Das komische daran (ich arbeite mit 
Docklight): das Terminalprogramm empfängt etwas... aber immer nur 3F 00 
00. Immer das gleiche (hin und wieder schleicht sich ein C0 rein, wenn 
ich aber UDR0 = 'x' "sende" bekomme ich ich immer 3F 00 00). An was kann 
es liegen???? Muss ich noch eine Frequenz umstellen????

Danke!!!

Gruß Christian

Folgenden Code habe ich verwendet (ist nicht von mir):

#define F_CPU 4000000
#define USART_BAUD_RATE 9600
#define USART_BAUD_SELECT (F_CPU/(USART_BAUD_RATE*16L)-1)

#include <avr/io.h>
#include <avr/interrupt.h>

void sendUart(char* cmd)
{
  do
  {
    while (!(UCSR0A & (1<<UDRE0)))  {}              // Warten bis 
mansenden kann
    UDR0 = *cmd++;                                  // senden und 
zumnächsten zeichen wechseln
  }
  while(*cmd);                                      // so lange bis 
dasende erreicht ist
}

unsigned char USART_Receive( void )
{
  /* Wait for data to be received */
  while ( !(UCSR0A & (1<<RXC0)) )
    ;
  /* Get and return received data from buffer */
  return UDR0;
}

void USART_Init( unsigned int baud )
{
  /* Set baud rate */
  UBRR0H = (unsigned char)(baud>>8);
  UBRR0L = (unsigned char)baud;
  /* Enable receiver and transmitter */
  UCSR0B = (1<<RXEN0)|(1<<TXEN0) | (1<<RXCIE0);
  /* Set frame format: 8data, 2stop bit */
  UCSR0C = (1<<USBS0)|(3<<UCSZ00);
}

ISR(USART_RX_vect)
{
  PORTC = 0xFF;
}

int main(void)
{
  USART_Init(USART_BAUD_SELECT);
  sei();
  DDRC = 0xFF;
  sendUart("Programm gestartet\n");
  PORTC = 0x00;
  //USART_Receive();
  //PORTC = 0xFF;
  for(;;){}
}

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian Beuge wrote:

> Ich würde gerne etwas über die UART schicken. Diesmal verwende ich den
> 168er, einen externen Quarz (4MHz). ...

Ja, hast du den auch wirklich in Betrieb genommen (per fuse bit)?

Autor: Christian Beuge (christianbeuge)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Jörg!

Ich hoffe doch.
Eingestellt ist der ATMega 8, da der 168 der Nachfolger sein soll. Den 
168 direkt angeben konnte ich nicht (ich hoffe nicht, das dies der 
Hacken ist!). Bei den Fuse Bits ist der Hacken bei SPI Enable gesetzt, 
sonst bei keinem weiteren Punkt. Als Oszilator ist "Ext STAL, Medium 
frequency" angegeben (Was ist der Unterschied zwischen: High - Medium - 
Low - es geht bei keinem...). Startup: 1K CK; No BOD function (was ist 
das??) und Boot block ist 128 Words angegeben.

Ich hoffe das stimmt alles.

Gruß Christian

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Uff, was hast du denn fürn altmodischen Programmer?

Nein, die ATmegax8 sind zwar aufwärtskompatibel zum ATmega8, aber
alles andere als fusebit-kompatibel.  Das fängt schon damit an, dass
die neue Serie debugWire kann (und damit eine DWEN-Fuse braucht).
Außerdem besitzt sie nur noch einen einzigen (mit 8 MHz laufenden)
RC-Oszillator statt 4 davon sowie eine CKDIV8-Fuse, die den clock
prescaler auf 1:8 voreinstellt, sodass die CPU wieder im
Auslieferungszustand mit 1 MHz getaktet wird und damit im gesamten
Betriebsspannungsbereich nutzbar ist.

Nein, ohne einen Programmer, der deinen ATmega168 unterstützt, wirst
du da nicht weit kommen.

Übrigens, Haken und Hacken sind im Deutschen zwei sehr verschiedene
Dinge.  Ich nörgele ungern an der Rechtschreibung, aber hier haben
einfach beide Worte eine Bedeutung.

Autor: markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

Kommen immer nur diese 3 Bytes (auch wenn du einen ganzen String senden 
willst??)
Ansonsten:
hast du bei deinem Terminalprogramm auch 2 Stoppbits eingestellt (vl 
liegts ja daran)
wie sieht der Hardwareaufbau aus (Störeinflüsse => dieses Problem hatte 
ich letztens mit dem RS485 Bus... ) vl. kannst du dir das ganze mal mit 
nem Oszi anschauen

mfg Markus

Autor: Christian Beuge (christianbeuge)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mein "Hardwareprogrammer" ist der mysmartUSB 
(http://www.myavr.de/shop/artikel.php?artID=42) von www.myavr.de .

In der Beschreibung steht, das man einen 168er damit programmieren kann. 
Als Software verwende ich AVR-Studio. Und laut AVR habe ich auch die 
aktuellste Version.

Hm.... ist schon etwas komisch. Soll ich mir dann (extra...) einen neuen 
kaufen? Welchen empfiehlst Du mir? Ich hätte zwar gerne einen mit JTAG, 
aber die sind sehr teuer und leider sind meine (studentischen) Mittel 
begrenzt.

Gruß Christian

Autor: Christian Beuge (christianbeuge)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@markus:

ich habe gerade mit den stopbits "gespielt". Außerdem habe ich ein 
programm geflasht, das nur ein 'x' schreibt (siehe Tutorial / Forum). 
Leider schreibt er bei mir nur 0xE8. Das komische daran ist, egal wie 
viele Stopbits ich beim Terminalprogramm einstelle. Das kommt mir auch 
etwas komisch vor.
Kann es wirklich am Programmer liegen, wie Jörg meinte? Wäre sehr schade 
(und kostenaufwendig).

Gruß Christian

P.S.: Welchen µC verwendest Du? Und welchen Programmer?

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian Beuge wrote:

> Mein "Hardwareprogrammer" ist der mysmartUSB
> (http://www.myavr.de/shop/artikel.php?artID=42) von www.myavr.de .

Hmm, AVR910-Style.  AVR910 ist ein uraltes und ziemlich dummes
Protokoll, und die entsprechenden device IDs sind einfach mal nicht
mehr gepflegt worden.

Ggf. liefert der Hersteller ja auch Firmware-Upgrades.

> Als Software verwende ich AVR-Studio.

Hmm, AVR Studio kann mit AVR910 aber nicht selbst umgehen.  Was wählst
du denn dort genau aus?

> Welchen empfiehlst Du mir? Ich hätte zwar gerne einen mit JTAG, aber
> die sind sehr teuer und leider sind meine (studentischen) Mittel
> begrenzt.

AVR Dragon.  Kostet bei Sander Electronic in Berlin EUR 68.  Weiß
nicht, wer ihn sonst noch hat, bei dem man auch privat und mit mäßigen
Versandkosten bestellen kann.  Der kann ISP, JTAG, debugWire, und
high-voltage programming.  Die JTAG-Emulation ist dabei limitiert auf
AVRs mit <= 32 KiB ROM.

> Das komische daran ist, egal wie viele Stopbits ich beim
> Terminalprogramm einstelle. Das kommt mir auch etwas komisch vor.

Dann hast du die Asynchronübertragung einfach nicht verstanden.  Das
ist alles andere als komisch: der Empfänger hört sowieso beim ersten
Stopbit auf zu empfangen.  Die folgenden Stopbits ignoriert er dann
einfach, da sie ja keine Startbits sein können.

1,5 oder 2 Stopbits mag in Zeit klappriger mechanisch abtastender
Fernschreiber einen Zweck gehabt haben (Zwangssynchronisation des
Empfängers auch bei geringfügig abweichender Empfängerdrehzahl),
heutzutage ist es eigentlich nur noch Verschwendung einer Bitzeit pro
Symbol.

Der einfachste Weg herauszufinden, ob deine Oszillatorfrequenz stimmt
ist, dass du damit erstmal einen Timer programmierst.  Entweder mit
Oszillograph oder Zählfrequenzmesser messen, oder halt so weit
runterteilen, dass du im 1-s-Takt eine LED blinken lässt und dann mit
der Uhr nachmessen kannst.  Ach, noch einfacher wäre es natürlich, die
CKOUT-Fuse zu programmieren und die Oszillatorfrequenz an port B0
nachzumessen...

Autor: Christian Beuge (christianbeuge)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Jörg (und auch Hi Rest!!)

Also... ich stelle bei AVR-Studio nichts besonderes ein. Jedoch sind 
Deine Einwände, bezüglich der Einstellung des Prozessors (8er / 168er) 
durch aus nachvollziehbar. Daher habe ich jetzt das Programm Burn-o-mat 
(siehe Forum) sowie myAVR workpad installiert. Damit kann ich (lt. 
Anleitung) direkt auf die FUSE Bits des 168er zugreifen. Der Prozessor 
wird sogar automatisch erkannt. Folgedes habe ich eingestellt:

Ext. Crystal Osc.; Frequency 3.0-8.0 MHz; Start-up time PWRDWN/RESET: 
16K CK/14 CK + 65 ms; [CKSEL=1101 SUT=11]

Also, ich hoffe, das passt für einen 4 MHz Quarz Leider weiß ich nicht 
ob ich das richtige eingestellt habe. Besonders mit den" Start-up und 
16k CK/14...." ... ich weiß nicht was das heißt. Wäre super, wenn mir 
das jemand erklären könnte. Ich werde auch gleich noch mal im tutorial 
nachsehen. Außerdem habe ich jetzt folgendes Programm "draufgebrannt":

#include <avr/interrupt.h>
#include <avr/io.h>
#include <avr/iom168.h>
#include <avr/portpins.h>
#include <avr/sfr_defs.h>
#include <stdint.h>
#define BAUD 9600
#define FOSC 4000000  //Taktgeschwindigkeit 4 Mhz
#define MYUBRR FOSC/16L/BAUD-1  //Formel....

// Receive Interrupt
ISR(USART_RX_vect ) // veraltet: SIGNAL(SIG_OVERFLOW0)

{
  // ISR: Zeichen wurde empfangen
  while ( !( UCSR0A & (0x20)) ); //Warten bis UART Data empty
    UDR0 = UDR0 + 1; // Gesendet: 0xFF Antwort: 3F 7F 00
//  UDR0 = 0xe8;   // Antwort: Endlosschleife E1 warum???
}

//Zeichen wurde komplett gesendet
ISR(USART_TX_vect ) // veraltet: SIGNAL(SIG_OVERFLOW0)
{

}

void USART_Init (unsigned int ubrr)
{
  // zuerst Baudrate setzen
  UBRR0H = (unsigned char) (ubrr>>8);
  UBRR0L = (unsigned char) (ubrr);
  //nun Sender und Empfänger initialisieren
  UCSR0A = 0x00;
  UCSR0B = 0xF8;

  //Frameformat setzen: 8 Datenbits, 1 Stopbits
  UCSR0C = 0x86;
}

int main(void)
{
  DDRD = 0xff;    //enable PortD as output
  sei();        //enable Interrupt
  USART_Init (MYUBRR);

  while (1)
  {

  };

}

Mein Hardwareaufbau ist folgender: Verwende XP-Laptop (DELL) der keinen 
Seriellen Port hat. Dafür habe ich einen USB Adapter. Wenn ich RX und TX 
am Adapter "kurzschließe" kommt das Gesendete auch an (erste 
Fehlerquelle beseitigt?). Den Adapter habe ich mit einer RS232 Buchse 
und 3 "freirumliegenden", ca. 22 cm langen Drähten (0,2mm²?) verbunden 
(TX,RX,GND). Das Störungen auftreten können, ist mir klar, aber ich habe 
mein Handy draufgelegt und es angerufen... dabei änderte sich bei der 
Übertragung nichts. Die Spannungsversorgung übernimmt mein 
"Programmmierboard".
Was evtl. noch wichtig wäre: Mir ist absolut klar, das ich meinen 
Hardwareaufbau nicht sehr Störungsfrei gestaltet habe. Auch möchte ich 
kein Bild von dem "Board" ins Netz stellen... das sieht beschämend aus. 
Aber: Ich habe (in der Arbeit: Praxissemester) einen Aufbau mit einem 
Xc164 Evaluation Board (CM?). Eingestellt habe ich das mit DAVE. Das 
funktioniert einwandfrei! Daher denke ich, es kann doch nicht so schwer 
sein, einem Atmel Prozessor beizubringen anständige Info's via UART zu 
senden (ok, kann auch sein, das ich es nicht verstehe....).
Ich werde morgen mal das "Board" mit in die Arbeit nehmen und am Oszi 
ansehen, was genau ausgegeben wird. Vielleicht ändere ich das Programm 
noch ein wenig ab, so das er "automatisch" alle x-sec einen Wert sendet.
Was mir jedoch nicht ganz klar ist, warum ich bei 0x08 (nach dem senden 
eines beliebigen Wertes) eine Endlosschleife bekomme.... schließlich 
sende ich ja nur was im "Receive-Interrupt..." ?!
So, mehr fällt mir leider nicht dazu ein... Aber wie gesagt... ich bin 
dankbar für jeden TIP!!!!

Gruß Christian

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian Beuge wrote:

> Also... ich stelle bei AVR-Studio nichts besonderes ein.

Naja, irgendwas musst du doch als Plattform auswählen, mit der du
arbeiten willst.  Ist das ein STK500?

> Folgedes habe ich eingestellt:

> Ext. Crystal Osc.; Frequency 3.0-8.0 MHz; Start-up time
> PWRDWN/RESET: 16K CK/14 CK + 65 ms; [CKSEL=1101 SUT=11]

Klingt erstmal OK.

> Also, ich hoffe, das passt für einen 4 MHz Quarz

Ja.

> Leider weiß ich nicht ob ich das richtige eingestellt
> habe. Besonders mit den" Start-up und 16k CK/14...." ... ich weiß
> nicht was das heißt.

Der Prozessor wartet nach einem Power-down sleep 16K (= 16384) Zyklen,
damit sich der Oszillator stabilisieren kann, nach einem Reset noch
zusätzlich weitere 14 Zyklen plus 65 ms.  Das ist die konservativste
Variante, in der auch der gemütlichste Quarz auf Touren gekommen sein
sollte.

Diese Werte möchte man vor allem dann optimieren (d. h. auf den
wirklichen Quarz anpassen), wenn man mit Power-down oder Power-save
sleep arbeitet, da der Controller während der Anlaufphase halt schon
Strom zieht, ohne was machen zu können.

> #include <avr/iom168.h>
> #include <avr/portpins.h>
> #include <avr/sfr_defs.h>

Die drei sind überflüssig.

> #define FOSC 4000000  //Taktgeschwindigkeit 4 Mhz

Ist nicht falsch, aber mittlerweile hat sich als Konvention hier der
Name F_CPU durchgesetzt.  Solltest dich vielleicht einfach dran
gewöhnen.

> // Receive Interrupt
> ISR(USART_RX_vect ) // veraltet: SIGNAL(SIG_OVERFLOW0)

Der Kommentar passt nicht zum Vektornamen...

> {
>   // ISR: Zeichen wurde empfangen
>   while ( !( UCSR0A & (0x20)) ); //Warten bis UART Data empty

Im Prinzip musst du das nicht tun: du kannst ja sowieso maximal so
schnell empfangen, wie du auch senden kannst.

> //Zeichen wurde komplett gesendet
> ISR(USART_TX_vect ) // veraltet: SIGNAL(SIG_OVERFLOW0)
> {
>
> }

Wofür hast du diesen IRQ überhaupt aktiviert?

Wenn man schon interruptgesteuert senden will, ist übrigens der
UDRE-Interrupt sinnvoller: damit kann man das nächste Zeichen bereits
vorbereiten, während das aktuelle Zeichen gerade rausgeschoben wird.
Wenn keine Zeichen mehr zu senden sind, muss man diesen Interrupt
allerdings abschalten.

>   UCSR0A = 0x00;

Das ist ein NOP.  Die Interruptflags werden dadurch nicht angefasst,
und der Rest des Registers bleibt auch auf Voreinstellung.

>   UCSR0B = 0xF8;

Das ist tödlich und ist möglicherweise dein tatsächlicher Fehler.
Gewöhn dich lieber an die symbolische Schreibweise, dann steht da:
UCSR0B = _BV(RXCIE0) | _BV(TXCIE0) | _BV(UDRIE0) | _BV(RXEN0) | _BV(TXEN0);

Du aktivierst den UDRE-Interrupt, für den du aber keinen Handler
definiert hast!  Dieser Interrupt triggert in diesem Moment dann
sofort (da das TX-Datenregister natürlich leer ist), und springt in
den __vector_default, der auf Adresse 0 springt.

>   //Frameformat setzen: 8 Datenbits, 1 Stopbits
>   UCSR0C = 0x86;

0x06 übrigens die Voreinstellung.  Bit 7/6 = 0x80 wählen als
Betriebsmodus einen aus, der ausdrücklich als reserviert markiert ist.
Ich denke, hier hast du etwas gedankenlos das 0x80-Bit von einem AVR
übernommen, bei dem UBRRHn mit UCSRnC zusammenfällt und dann das Bit 7
zur Unterscheidung beider Register benutzt wird.

Nach meiner Erfahrung fasst man das Steuerregister C der USART am
Besten einfach gar nicht an, wenn man sowieso nur das Standardframing
8N1 haben will, da dieses bei AVR immer voreingestellt ist.

Einen ATmega168 habe ich nicht, aber ich hab' das Ganze mal mit einem
ATmega48 auf einem STK500 nachgestellt.  Dort muss man zwar statt des
externen Quarzes in den Fuses einen Externoszillator einstellen (low
fuse also 0xe0), aber danach konnte ich das mit 4 MHz einwandfrei so
benutzen, nachdem ich das UDRIE0 rausgeschmissen hatte.

Autor: Christian Beuge (christianbeuge)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hey Jörg!

vielen Dank, für Deinen Einsatz. Könntest Du bitte Dein Programm posten, 
oder mir per E-Mail schicken (ChristianBeuge@gmx.de) ? Ich bekomme es 
einfach nicht hin. Ich habe das Programm nun folgendermaßen geändert:

#include <avr/interrupt.h>
#include <avr/io.h>
#include <stdint.h>
#define BAUD 9600
#define F_CPU 8000000  //Taktgeschwindigkeit 4 Mhz
#define MYUBRR F_CPU/16L/BAUD-1  //Formel....

// Receive Interrupt
ISR(USART_RX_vect ) // veraltet: SIGNAL(SIG_OVERFLOW0)
{
  // ISR: Zeichen wurde empfangen
  while ( !( UCSR0A & (0x20)) ); //Warten bis UART Data empty
  UDR0 = 0xFF;   // Immer noch Endlosschleife
}

void USART_Init (unsigned int ubrr)
{
  // zuerst Baudrate setzen
  UBRR0H = (unsigned char) (ubrr>>8);
  UBRR0L = (unsigned char) (ubrr);
  UCSR0B = _BV(RXCIE0) | _BV(TXCIE0) | _BV(RXEN0) | _BV(TXEN0);
}

int main(void)
{
  DDRD = 0xff;    //enable PortD as output
  sei();        //enable Interrupt
  USART_Init (MYUBRR);

  while (1)
  {

  };

}

Ich hoffe, ich habe nichts übersehen. Ich werde auf jedenfall morgen das 
Ding in die Arbeit mitnehmen und mir mal ansehen, was es sendet.... 
vielleicht werde ich ja schlauer...

Gruß Christian

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian Beuge wrote:

> vielen Dank, für Deinen Einsatz. Könntest Du bitte Dein Programm
> posten, oder mir per E-Mail schicken

Sorry, dürfte schon dem Schredder anheim gefallen sein.

>   UCSR0B = _BV(RXCIE0) | _BV(TXCIE0) | _BV(RXEN0) | _BV(TXEN0);

Du hast zwar den USART_TX_vect entsorgt aber das TXCIE0-Bit trotzdem
noch gesetzt.  Damit knallt's dann genauso wie vorher mit dem UDRIE0.

>   UDR0 = 0xFF;   // Immer noch Endlosschleife

Bist du dir sicher, dass dein Terminalprogramm dieses Zeichen
überhaupt anzeigen kann?

Ich hatte deine Version
UDR0 = UDR0 + 1
 übernommen.  Sinnvoller
wäre jedoch:
  uint8_t c = UDR0;
  if (c >= 'A' && c <= 'z')
    c = c + 1;
  UDR0 = c;

Damit würden wenigstens Steuerzeichen wie CR und LF einfach nur als
Echo ausgegeben und lediglich bei den Buchstaben die +1-Magie
vorgenommen.

Autor: Christian Beuge (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Guten Morgen Jörg!

So, in der Arbeit angekommen habe ich mich sofort daran gemacht, zu 
messen was da raus kommt, aus meiner UART. Dummerweise sendet die 
wirklich 00. Ich werde Deine Änderungen auf jedenfall berücksichtigen 
und heute abend das Ding neu flashen.

Melde mich spätestens heute abend wieder!!!

Gruß Christian

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian Beuge wrote:

> So, in der Arbeit angekommen habe ich mich sofort daran gemacht, zu
> messen was da raus kommt, aus meiner UART. Dummerweise sendet die
> wirklich 00.

"Gemessen" klingt ja nicht nach Terminalprogramm.  Womit misst du
denn?  Dein 0xFF müsste so aussehen:

----+  +---------------------------
    |  |
    +--+  .  .  .  .  .  .  .  .  .

Bit: S   0  1  2  3  4  5  6  7  T

S - Startbit, T - Stopbit

Das zeigt den TTL-Pegel am AVR.  Der V.28-Pegel am Stecker ist dazu
negiert.

Autor: Christian Beuge (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Jörg....


Also, ich möchte mal ganz schwer behaupten: Shame on me!!!!!

Aber der Reihe nach:

Ich bin in der Arbeit und messe mit einem Tektronix DPo 4034 
Speicheroszi. Außerdem bekomme ich genau das Bild, welches Du oben 
"gezeichnet" hast. Dabei dauert das "Startbit" 208µsec (müssten das 
nicht 104µsec sein - bei 9600 Baud). Also genau das, was es soll. Was 
ich an der ganzen Sache natürlich nicht bedacht habe ist, das der AVR 
"nur" einen TTL Pegel verwendet und RS232 +/- 12 V. Das es hier zu 
"komplikationen" kommen kann... ich denke, das wäre vorprogammiert.

Kann es sein, wenn ich einen UART Treiber "zwischenschalte" das ich die 
richtigen Daten an meinem Rechner bekomme? Leider kann ich meinen Atmel 
hier nicht programmieren, da wir hier Infineon µCs verwenden. Aber ich 
werde versuchen, von meinem Kollegen einen Treiberbaustein (evtl. heute 
noch) zu bekommen und dann das ganze zu testen.

Deshalb: Shame on me... habe zwar was gelernt, brauchte dazu aber knapp 
2Wochen und habe dabei einige µCs verfused.... (und viele Leute 
wahrscheinlich in den Wahnsinn getrieben...)

Gruß Christian

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Kann es sein, wenn ich einen UART Treiber "zwischenschalte" das
> ich die richtigen Daten an meinem Rechner bekomme?

Wenn mit "UART Treiber" so etwas wie ein MAX232 oder ein 
SN75188/SN75189-Pärchen gemeint ist, dann besteht eine realistische 
Chance.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian Beuge wrote:

> Außerdem bekomme ich genau das Bild, welches Du oben "gezeichnet"
> hast. Dabei dauert das "Startbit" 208µsec (müssten das nicht 104µsec
> sein - bei 9600 Baud).

Ja, das klingt noch nach falschem Takt irgendwie.  Warum, das musst du
selbst analysieren.  Denk an die CKOUT-Fuse, zusammen mit einem Oszi
kann die Dir gut helfen.  Kann ja auch sein, dass du den Quarz zu sehr
(kapazitiv) belastet hast und er dann ,,irgendwie'' wild schwingt.

> Was ich an der ganzen Sache natürlich nicht bedacht habe ist, das
> der AVR "nur" einen TTL Pegel verwendet und RS232 +/- 12 V. Das es
> hier zu "komplikationen" kommen kann... ich denke, das wäre
> vorprogammiert.

Nu ja, wenn's denn nur die Pegelunterschiede wären...  Insbesondere
sind die Signale aber negiert, d. h. logisch 1 (das auch TTL high
entspricht) ist auf der V.28-Seite die negative Spannung, während
logisch 0 die positive Spannung ist.  Die meisten PC-Schnittstellen
kommen heutzutage sogar mit TTL-Pegel zurecht, aber du musst das
Signal eben noch negieren.

> Leider kann ich meinen Atmel hier nicht programmieren, da wir hier
> Infineon µCs verwenden.

Naja, wenn du noch irgendwo eine stinknormale Parallelschnittstelle
hast und 'nen DB25-Stecker dafür, kannst du dem abhelfen. ;-)

Autor: Christian Beuge (christianbeuge)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Jörg!

Ok... shame on me, Teil 2....

Gerade eben habe ich den Unterschied zwischen 4MHz und 8 MHz entdeckt...

Ähm... bis jetzt funzt es, also, mit MAXIM 232 Baustein... an dem UART 
Ausgang liefert er weiterhin Mist.... also, zumindest zeigt das das 
Terminalprogramm an. So, jetzt bin ich gespannt, wie lange das so weiter 
geht und wie das nächste Problem sich darstellt.

Ich danke Euch, besonders Dir Jörg, für Deine Hilfe und hoffe, das ich 
Euch auch mal mir Rat und Tat zur Seite stehen kann. Wie gesagt, ich 
hoffe, es klappt jetzt.... wenn nicht, würde ich mich nochmal per Mail 
melden... wenn ich darf....

Gruß Christian

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Gerade eben habe ich den Unterschied zwischen 4MHz und 8 MHz entdeckt...

:-)

Ja, den MAX232 o. ä. brauchst du natürlich wirklich, oder wie
geschrieben, zumindest einen simplen Inverter.

Naja, hast ja auch einiges gelernt dabei (z. B. hilft eben ein Oszi
doch manchmal ein gutes Stück weiter).

Na dann mal noch beste Erfolge!

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.