mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Kommunikationsprobleme mit UART


Autor: Florian dielman (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo meine Lieben,

Ich bin total verzweifelt mit  meinem Problem hier.

ich möchte eine Kommunikation zwischen einem  Master und Empfänger über 
UART auf RS485-Basis aufbauen. Der Master ist ein  AVR ATMEGA32  und der 
Empfänger ein PSOC-µC.
Der Baudrate ist auf 9600 eingestellt beidseitig   und geprüft.  alles 
I.O.
Der  Master sendet ein Paket  mit 8 Bit einem Start-  und Stop-bit. 
Die kommen beim Eingang Rx_Psoc-µC   ganz gut  an.   In  einem Programm 
möchte ich die Daten zurücksenden  an dem Master.
Nun funktioniert der echo nicht ganz gut. Ich weiß  nicht,  ob der 
Psoc_Rx ordnungsgemäß  die Daten aufnimmt. Denn sporadisch sendet er den 
richtigen Wert  und manchmal was falsches.

Kann  mir jemand checken  was  ich in meinem  Code falsch mache?
Uart-Einstellung in Psoc:

Parameters
Parameters    Value
Clock         Row_0_Output_1
ClockSync     Sync to SysClk
CommandTerminator  13
Enable_BackSpace   Disable
IgnoreCharsBelow   32
IntDispatchMode    ActiveStatus
InterruptAPI       Enable
InvertRX Input     Normal
Param_Delimiter    32
RX Clock Out       None
RX Input           Row_0_Input_1
RX Output          None
RxBufferSize       16
RxCmdBuffer        Enable
TX Clock Out       None
TX Interrupt       Mode  TXComplete
TX Output          Row_0_Output_0

Code:

While(1)
{
DigBuf_RS_Stop(); Driver - Empfang
while(!(UART_1_bReadRxStatus()& UART_1_RX_COMPLETE));
x=UART_1_bReadRxData();

DigBuf_RS_Start(); Driver- Senden
while(!(UART_1_bReadTxStatus()&UART_1_TX_BUFFER_EMPTY));
UART_1_SendData(x);
while(!(bUART_1_ReadTxStatus()&UART_1_TX_COMPLETE ));
DigBuf_RS_Stop();

}


wäre sehr dankbar für jede Hilfe.

lg

Florian dielman

Autor: ttl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
externen Quarz verwenden

Autor: Florian dielman (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ja  das   problem ist das ich schon eine  fertige platine uaf dem ich 
keine Quarz mehr einbauen   kann. Zum anderen  meine Ressource(Pins) 
sind schon alle besetzt.
Nun kann ich nur Machen mit was ich in den Händen habe.

Ist der Code  so korrekt ?

Danke

Autor: Florian dielman (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
please  help.

ich sitze schon Tagelang drauf

lg

Florian

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Man kann den internen RC-Oszillator kalibrieren, das ist dann 
einigermassen genau genug für UART, wenn die Temperatur nicht zuviel 
schwankt (sagen wir +/-20K). Das Register OSCAL ist dein Freund.

MFG
Falk

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Man kann anhand eines empfangenen Bytes den Reloadwert für das 
Zählerregister errechnen. Das wäre dann so eine Art 
Auto-Baud-Funktion...

Aber einfacher ist die Methode von Falk  ;-)

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Lothar Miller (lkmiller)

>Man kann anhand eines empfangenen Bytes den Reloadwert für das
>Zählerregister errechnen.

Reloadwert und UART? Ahhhh, der alte 8051 Schrott.

Hey, wir leben im 21. Jahrhundert. AVR rulez!

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk Brunner schrieb:
> Hey, wir leben im 21. Jahrhundert. AVR rulez!
Und da geht das nicht mehr? Schade, schade   :-/
Aber wenn ich mir das Datenblatt ansehe
The USART Baud Rate Register (UBRR) and the down-counter connected to it 
function as a programmable prescaler or baud rate generator. The 
down-counter, running at system clock (fosc), is loaded with the UBRR value 
each time the counter has counted down to zero or when the UBRRL Register is 
written. 
dann hört sich das für mich nach einem Reloadwert an  ;-)

Andere Prozessorarchitekturen wie ST10 haben das sogar im Bootloader 
drin...

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Lothar Miller (lkmiller)

>dann hört sich das für mich nach einem Reloadwert an  ;-)

Lässt sich ja prinzipiell kaum vermeiden. Aber das Reloaden macht die 
Hardware allein, für so einen Schnulli die CPU zu belästigen ist ja fast 
strafbar. . .

MFG
Falk

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Aber das Reloaden macht die Hardware allein,
Wie beim 8051, womit sich der Kreis wieder schliesst  ;-)

Autor: Florian dielman (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke schön für Anregungen

ich sehe dass es vielleicht mein Problem sein kann. Denn  die Factory 
Calibrated Frequency   ist für ein Betrieb mit 3V und hat eine 
Abweichung von +-10%.

Ich habe auch gelesen, dass die vom User kalibrierte Frequenz zwischen 
7.3Mh und 8.1MH abweicht.(ATMEGA328P Seite 317)

Ist es dann damit möglichst eine genauere 8Mhz zu erzielen?
zum anderem muss man nur den OSCALL am Anfang vor dem main() schreiben 
und ist dann alles erledigt oder?.

Entschuldigung für die Fragen ich habe noch nicht ein Internen RC 
kalibriert.

Danke

Autor: Florian dielman (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bitte Um hilfe ich bien schon verzweifelt.

lg
Florian

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Florian dielman (Gast)

>Ich habe auch gelesen, dass die vom User kalibrierte Frequenz zwischen
>7.3Mh und 8.1MH abweicht.(ATMEGA328P Seite 317)

Ist auch so.

>Ist es dann damit möglichst eine genauere 8Mhz zu erzielen?

Definiere genau. Man bekommt das ganze in etwa auf 0,5% kalibriert.

>zum anderem muss man nur den OSCALL am Anfang vor dem main() schreiben
>und ist dann alles erledigt oder?.

Ja.

>Entschuldigung für die Fragen ich habe noch nicht ein Internen RC
>kalibriert.

Ach du Ärmster.

> Bitte Um hilfe ich bien schon verzweifelt.

Weil du innerhalb von 2 Stunden keine Antwort bekommt? Bleib mal locker.
In der Zeit hätte man es dreimal selber ausprobieren können.

MFG
Falk

Autor: R. Max (rmax)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Florian:

Bei Atmel gibt es mehrere AppNotes, die sich mit der Kalibrierung des 
internen Oszillators befassen (AVR351, AVR053, AVR054, AVR140).

Falls Du beim Übertragungsprotokoll nicht festgelegt bist, dürfte AVR054 
für Dich am interessantesten sein. Die beschreibt, wie sich ein Slave zu 
Beginn eines jeden Übertragungsblocks anhand eines vom Master gesendeten 
Bitmusters auf dessen Takt kalibrieren kann.

Autor: Hc Zimmerer (mizch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei serieller Übertragung musst Du deine Baudrate auf 1,5 bis 2,5% genau 
einhalten (je nach Begleitumständen).  Bei zwei Geräten gilt das für die 
Summe der Abweichungen beider.  Kannst Du das nicht einhalten, erreichst 
Du keine zuverlässige Verbindung -- keine Arme -> keine Kekse, in der 
Technik ist das so einfach.

Es ist nun Deine Aufgabe, das sicherzustellen; Verzweiflungsäußerungen 
bringen Dich dem Ziel nicht näher.  Da Du Deine Hardware am besten 
kennst, ist es nun an Dir, die Möglichkeiten abzuklopfen.

Hast Du irgendwo eine hinreichend genaue Frequenz, auf die Du 
ei^H^Hkalibrieren kannst?

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Es ist nun Deine Aufgabe, das sicherzustellen; Verzweiflungsäußerungen
> bringen Dich dem Ziel nicht näher.  Da Du Deine Hardware am besten
> kennst, ist es nun an Dir, die Möglichkeiten abzuklopfen.

Wobei der erste Schritt immer darin besteht, eine Fehleranalyse zu 
machen. Wenn du 2 Geräte hast, von denen du nicht weißt, welches Schuld 
ist, dann ist eine gute Strategie zb. eines der Geräte durch ein anderes 
zu ersetzen, welches garantiert richtiges Verhalten aufweist.

Garantie richtig gibt es selten, aber in diesem Fall kann man wohl davon 
ausgehen, dass die UART eines PC keinen allzugroßen Fehler haben wird.

Also wird man wohl jedes der unbekannten Geräte mit einem PC verbinden 
und nachsehen, ob sich dort bei einem der beiden (oder bei beiden) 
Fehler in der UART-Kommunikation zeigen.

Findet sich da etwas, hat man schon viel gewonnen. Immerhin ist das 
Problem dadurch schon um 50% leichter geworden.

Wie Hazeh schon so richtig sagte:
Verzweifeln bringt nichts. Systematisch überlegt vorgehen!
Überlegen "Was könnte es sein" und daraus sofort eine Strategie 
ableiten, wie man diesen möglichen Fehler testen oder ausschliessen 
kann.

Autor: Florian dielman (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für Hilfestellung und aufmunterung.

ich mache mich am Werk und lass euch  berichten.

Danke an alle
Lg
Flo

Autor: Florian dielman (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Leute,


ich habe die mögliche Quelle meines  Problem gefunden. aber weiß noch 
nicht wieso und warum es auftritt.
Die Übetragung läuft perfekt. Der master sendet, der Slave empfängt und 
sendet zurück. Das  Problem liegt bei der ATmel _µC  und  nicht beim 
PSOC.

Die TX und RX leitung  von dem ATMEGA32  sind direct auf dem Treiber 
MAX487 angeschlossen.
Sobald ich die RX einschalte  "UCSR0B |=(1<<RXEN0);"  die gesamte 
Übertragungsweg geht nicht mehr.  schalte ich RX ab  läuft alles wierder 
wunderbar.  D.h. ich kann nichts empfangen am Master.

Ich habe versucht ein  Verbraucher (Widerstand, Diode)  zwischen RX und 
Eingang Treiber zu schalten , es klappt aber nicht.

es wäre als ob er würde dauern die leitung auf low oder high  oder weiß 
nicht genau ziehen und die Gesamte Übertragung komplet stören.

Weißt jemand woran es liegen kann ?

Danke

Autor: Stefan B. (stefan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bemühe dich doch mal um einen Schaltplan. Laut Datenblatt MAX487 würde 
ich erwarten, dass vier oder drei Leitungen zum Atmega32 gehen: DI, 
RO als Datenleitungen plus DE und /RE als Enable-Leitungen (#1). DE und 
/RE können zusammengefasst werden (#2). Daten zur Busterminierung gibt 
es im Beitrag "Re: RS485 mit MAX487" und im 
Datenblatt sind 120 Ohm in den Diagrammen eingezeichnet.

#1 MAX487
http://ecee.colorado.edu/~mcclurel/max485ds.pdf

#2
http://www.circuitcellar.com/avr2006/winners/DE/DE...

Autor: Florian dielman (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Verdrahtung ist genau so gleich wie auf dem gelinkten Forumbeitrag.

120 Ohm habe ich auch dran. Variert +-30  habe ich auch schon. Trotzdem.

Enable-Eingänge(DE, /RE) werden zusammen angesteuert. R0 an RX  und DI 
an TX .

Autor: Florian dielman (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe auch versucht den Pin als Eingang zu schalten, die Übertragung 
ist immer gestört. Enferne  ich den Master Tx leitung bekomme  ich das 
gleiche Bild  als  wäre RX ein .
Ich vermute es wenn RX ein ist zusätzlich zu TX . collidieren die beide 
intern, sodass die Wirkung von Tx   nicht mehr zu sehen ist.
Andere  Treiber holen.   Klar habe ich schon gemacht .  Bei dem auch das 
gleiche Verhalten.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ich vermute...
Das ist m.E. nicht die richtige Vorgehensweise.

> Die Verdrahtung ist genau so gleich wie auf dem gelinkten Forumbeitrag.
Jaja. Welchem Teil des Beitrags?

Machs doch einfach so: zeichne genau deine Beschaltung ab und poste 
den Plan hier. Aber bitte nicht irgendwo was herkopieren und sagen "fast 
genauso ähnlich".

BTW:
> ich mache mich am Werk und lass euch  berichten.
Hast du das Thema mit der Baudrate (interner Takt) inzwischen behoben?

Autor: Florian dielman (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
>> Ich vermute...
>Das ist m.E. nicht die richtige Vorgehensweise.

Solange ich etwas   nicht aufklären kann, kann ich nur Vermutungen 
äussern und keine feste Ursache , da ich selber  nicht weiß.

hier  habe ich meine  plan  gezeichnet.


> ich mache mich am Werk und lass euch  berichten.
>Hast du das Thema mit der Baudrate (interner Takt) inzwischen behoben?

ja  ich habe es gelöst. Ich habe die interne Takt so getrimmt(mit 
osscal-register )bis eine gesamte Übertragung von 1 Byte 833µs erreicht.
Dies kommt dann beim Empfänger gut an und der Echo   klappt auch gut.

Nur der Master auf dem receive-Eingang macht mir nun probleme.

Autor: jakob (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
also wenn es bei deinem Master RX ist solltes es beim Client schon am TX 
angeschlossen sein. bei deinem Schaltplan ist das aber nicht so. ;)

Autor: Florian dielman (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>also wenn es bei deinem Master RX ist solltes es beim Client schon am TX
>angeschlossen sein. bei deinem Schaltplan ist das aber nicht so. ;)


Nein  vielleicht ist eine  Verwirrung.
Der MAX487  hat als Bedienpin von µC  aus die DI für Tx und R0  für RX. 
und geben auf dem  Bus die invertierende  Signal A und B.
 Es ist  auf dem Bild   nicht auf die lineare Anordnung von Tx bzw. A 
oder B aufzupassen.  Dies zeigt nur den Prinzip

Autor: Florian dielman (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Keine Idee voran es liegen kann?

Autor: Stefan B. (stefan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nö, der "Plan" ist ja im Prinzip richtig.

Es fehlen halt "lediglich" die Enable-Leitungen. Von anderen Problemen, 
die sich im Schaltplan oder auf der Platine befinden können nicht zu 
reden.

Den Wert "1 Byte 833µs" kann man auch schlecht einschätzen - ist das für 
2 Protokollbits plus 8 Datenbits gerechnet oder für ein Byte (8-Bit)? 
Ist das ein gemessener Wert für den AVR Sender und ist der Wert 
vergleichbar mit dem gemessenen Wert für den PSoC Sender?

Die AVR UART hat einen Fehlerdetektor, was meldet der beim Empfang? 
Wieviel % der Zeichen sind fehlerhaft? Ändert sich die Fehlerrate mit 
der Art oder der Geschwindigkeit der zeichen oder mit Pausen zwischen 
den Zeichen oder mit der Menge der Zeichen pro Block? Wie sehen die 
Bitmuster der Zeichen auf dem Bus und der empfangenen, fehlerhaften 
Zeichen aus; Versatz? Fehlendes Anfangsbits?

Wie ist die Software beim Empfänger AVR geschrieben? Ist die Umschaltung 
TX-Betrieb zu RX-Betrieb schnell genug?

Im Plan sind noch zwei weitere "Slaves" eingezeichnet. Sind die fiktiv 
oder real da? Sehen die auch verstümmelte Daten oder sehen die korrekte 
Daten?

BTW. AVR2006 Contest... Ich würde mir wahrscheinlich zum Debuggen eine 
solche RS232-nach-RS485 Bridge aufbauen. Mit Quarz ;-)

Autor: Florian dielman (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Den Wert "1 Byte 833µs" kann man auch schlecht einschätzen - ist das für
>2 Protokollbits plus 8 Datenbits gerechnet oder für ein Byte (8-Bit)?
>Ist das ein gemessener Wert für den AVR Sender und ist der Wert
>vergleichbar mit dem gemessenen Wert für den PSoC Sender?


Der Wert steht für 8 Bit ohne start und Stop-Bit. und Mit kontrolbit 
1ms.
 Diese  Wert sinid vergleichbar mit dem Psoc sender.


>Im Plan sind noch zwei weitere "Slaves" eingezeichnet. Sind die fiktiv
>oder real da? Sehen die auch verstümmelte Daten oder sehen die korrekte
>Daten?

sie sind nur fiktiv da. Nun ist nur ein in meinem Aufbau vorhanden

>Wie ist die Software beim Empfänger AVR geschrieben? Ist die Umschaltung
>TX-Betrieb zu RX-Betrieb schnell genug?

Momentan es soll zuerst  mal ankommen  ohne gelesen zu werden.  Erst 
dann kann ich die entprechende While einbauen.
UCSR0B |=(1<<TXEN0)|(1<<RXEN0);;
while(1)
{
  PORTB |= (1 << DDB0);                       //Max485 auf Senden

     while ( !(UCSR0A & (1<<UDRE0)));            
     UDR0 = 0x0F;                               

  while ( !(UCSR0A & (1<<TXC0)));            //Warten bis Übertragung fertig 
  UCSR0A |= (1<<UDRE0);            //Register leeren

     PORTB &= ~(1 <<DDB0);            //Max485 auf Empfang


  _delay_ms(4);
}

>Wie sehen die
>Bitmuster der Zeichen auf dem Bus und der empfangenen, fehlerhaften
>Zeichen aus; Versatz? Fehlendes Anfangsbits?

 wenn RX-enable (MAster )
Am EMpfang:fehlendes Bits, unperiodisches auftritt (nur einmal).
Am Sender : kontinuerliches unregelmäsiges Bitfolges unabhängig von 
RS485 enable-Leitung.

ich suche immer wo der Hase liegt.

Autor: Stefan B. (stefan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> wenn RX-enable (MAster )
> Am EMpfang:fehlendes Bits, unperiodisches auftritt (nur einmal).

Das ist seltsam. Werden die Bits mit dem obigen Codefetzen detektiert? 
da sollte man garnix sehen, denn in obigem Codefetzen ist keine 
Empfangsanweisung enthalten. Hast du Messequipment zum Überwachen des 
Bitstroms?

BTW. Warum hast du diese Zeile drin?
  UCSR0A |= (1<<UDRE0);            //Register leeren

> Am Sender : kontinuerliches unregelmäsiges Bitfolges unabhängig von
> RS485 enable-Leitung.

Das ist seltsam. Der Bitstrom muss von den Enable-Leitung abhängig 
sein. Die gesendeten Daten dürfen nur auf dem Bus (A/B Leitungspaar) 
sein, wenn der Sender seinen MAX487 per DE enabled hat. Und der 
Empfänger kann den Bitstrom nur empfangen, wenn er seinem MAX487 die 
/RE-Leitung enabled hat.

Ich würde Nägel mit Köpfen machen:

0. 8-Spur Logikanalyzer beschaffen

1. Einfaches Senderprogramm für PSoC schreiben. Einfaches 
Empfangsprogramm für AVR schreiben. Laufenlassen.

2. 8-Spur Logikanalyzer an die vier Digitalleitungen der beiden MAX487 
hängen. Mitschnitt zeigen.

3. Einfaches Senderprogramm für AVR schreiben. Einfaches 
Empfangsprogramm für PSoC schreiben. Laufenlassen.

4. Schritt 2 wiederholen.

Autor: Florian dielman (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Stefan B.


Danke für deine Hilfbereitschaft.

>BTW. Warum hast du diese Zeile drin?
>  UCSR0A |= (1<<UDRE0);            //Register leeren

das problem ist, dass ich keine IMpuls am PORTB bekomme  solange  ich 
diese  Zeile nicht hinzugefügt habe. Und das signal kommt periodisch 
alle 4 ms.
Kommentiere ich diese Zeile kommt das Signal nach reset einmal sauber( 
ca. 1ms) und dann nur als Spitze von paar pikrosekunde.

>Das ist seltsam. Werden die Bits mit dem obigen Codefetzen detektiert?
ich denke der code ist sehr einfach gehalten  nur für das Senden.

Wenn ich für den Empfang diese Zeilen hinzufügt bleibt aber das Programm 
hängen
//while (!(UCSR0A & (1<<RXC0)) );
/* Get and return received data from buffer */
x=UDR0;

Autor: Florian dielman (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
while (!(UCSR0A & (1<<RXC0)) );
/* Get and return received data from buffer */
x=UDR0;

Autor: Stefan B. (stefan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Florian dielman schrieb:

> das problem ist, dass ich keine IMpuls am PORTB bekomme  solange  ich
> diese  Zeile nicht hinzugefügt habe. Und das signal kommt periodisch
> alle 4 ms.
> Kommentiere ich diese Zeile kommt das Signal nach reset einmal sauber(
> ca. 1ms) und dann nur als Spitze von paar pikrosekunde.

Welchen Impuls/Signal willst du an PORTB periodisch BEkommen?

TXD und RXD liegen beim Atmega32 an PORTD; die kannst du nicht meinen. 
Die Enable-Leitung(en) zum MAX487 sind an einen Output-Pin (PORTB.0) 
gekoppelt, d.h. du willst ein Signal ABgeben; den kannst du auch nicht 
meinen.

Ist für PORTB.0 DDRB richtig auf Ausgang initialisiert? In deinem 
Codefetzen sieht man das nicht.

> Wenn ich für den Empfang diese Zeilen hinzufügt bleibt aber das Programm
> hängen

So lange keiner an deinem Bus was sendet, ja. Deshalb hatte ich ja auch 
vorgeschlagen, dass du den PSoC nur mit der Sendeaufgabe betreust und 
den AVR nur mit der Empfangsaufgabe.

Hast du noch einen MAX487 pkus einen MAX232 oder drei NPN-Transistoren 
im Lager um die RS485-to-RS232 Bridge zu bauen?

Autor: Florian dielman (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Welchen Impuls/Signal willst du an PORTB periodisch BEkommen?

das Umschaltsignal für den Treiber (DE,/RE).

>Ist für PORTB.0 DDRB richtig auf Ausgang initialisiert? In deinem
>Codefetzen sieht man das nicht.
 ja in dem Ini()

 hier ist der code zum senden:
#ifndef F_CPU
#define F_CPU 8000000UL   // Frequenz
#endif

#include <avr/io.h>
#include <util/delay.h>
#include <avr/interrupt.h>
#include <string.h>
#define BAUD 9600UL


#define TEILER (F_CPU/(16UL*BAUD))-1


void RS485_Init (void)
{
  unsigned int x;

  DDRB |=(1<<DDB0); //ausgang  Treiberumschaltung


    //   Baudrate Einstellung
    UBRR0H = (unsigned char) (TEILER>>8);
      UBRR0L = (unsigned char) TEILER;

    //Sender und Empfänger ein
    UCSR0B |= (1<<TXEN0)|(1<<RXEN0)|(1<<RXCIE0);
  

    //   Datenformats: 8 Datenbits, 1 Stoppbit
      UCSR0C |= (1<<UCSZ01)|(1<<UCSZ00);
  x=UDR0;     // Empfänger leeren

}


int main(void)
{  // Kalibrierung der internen RC-Oszillator
  OSCCAL = 0x6C;  

  unsigned char x,k;
  k=0x0F;



  RS485_Init();


while(1)
{
  PORTB |= (1 << DDB0);                       //Max485 auf Senden

       while ( !(UCSR0A & (1<<UDRE0)));            
       UDR0 = 0x0F;                               

    while ( !(UCSR0A & (1<<TXC0)));            //Warten bis Übertragung fertig 
    UCSR0A |= (1<<UDRE0);              //Register leeren

       PORTB &= ~(1 <<DDB0);            //Max485 auf Empfang


    _delay_ms(4);
}
}



in Projekt/ config   wird Frenquency auf 8000000 eingestellt.
in STK500 auf   "Fuses"  SUT_CKSEL : Int. RC.OSc.8MHz

>Hast du noch einen MAX487 pkus einen MAX232 oder drei NPN-Transistoren
>im Lager um die RS485-to-RS232 Bridge zu bauen?
Max487 ja .   Max232  nein.  aber eine STK500

>So lange keiner an deinem Bus was sendet, ja. Deshalb hatte ich ja auch
>vorgeschlagen, dass du den PSoC nur mit der Sendeaufgabe betreust und
>den AVR nur mit der Empfangsaufgabe.

mache ich nun auf diesem Weg.

Autor: Stefan B. (stefan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Florian dielman schrieb:

>>Welchen Impuls/Signal willst du an PORTB periodisch BEkommen?
> das Umschaltsignal für den Treiber (DE,/RE).

Wie vermutet ist das ein Mistverständnis. Du musst vom AVR Programm aus 
sorgen, dass an PORTB.0 das DE bzw. /RE Signal ausgegeben wird. Du 
bekommt dort kein Signal von außen. Im Programm ist das auch gemacht.

>   UCSR0B |= (1<<TXEN0)|(1<<RXEN0)|(1<<RXCIE0);
                                    ^^^^^^^^^^^

Wo ist die dazugehörige UART Receiver ISR? Wenn die fehlt, resettet sich 
der AVR beim ersten empfangenen Zeichen (also beim Echo des PSoC). Lass 
das |(1<<RXCIE0) weg.

Rest nicht mehr angeschaut.

Autor: Florian dielman (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Stefan B.

es  hat geklappt. ouf!
>Lass das |(1<<RXCIE0) weg.

was so eine kleines Bit(Schrift), jemand Studen kosten kann.

Aber nirgendwo habe ich deine Begründung/Erklärung gelesen. Kannst du 
mir ein Link zuschicken wo sowas  steht(wenn vorhanden).


vielen  Dank  an  dir für deine Gedult.
werde nun den Code erweitern  für ein  Telegramm(mehrere Bit 
nacheinander).

lg

Flo.

Autor: Stefan B. (stefan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schau dir den Artikel AVR-GCC-Tutorial/Der UART an und achte auf die 
"händischen" Sende/Empfangsverfahren (Polling) kontra die 
Interruptverfahren.

Die Bedeutung des Bits steht auch im Datenblatt. Es schaltet den 
Interruptbetrieb der UART ein. Und der verlangt eine Routine zum 
Behandeln des Interrupts, die sog. ISR (Interrupt Service Routine). Wenn 
die fehlt und der Interrupt kommt, gibt es Chaos. ISR vergessen oder 
falscher Name oder unabsichtlich anschalten oder nicht anschalten sind 
Fehler, die 99% der Programmierer mal machen.

Nächstes Mal gleich Sourcecode beibringen und auch eine echte 
Schaltplanskizze. Die Skizze muss nicht perfekt layoutet sein; sie darf 
handgezeichnet und eingescannt oder fotografiert sein. Den Bug hätten 
wir mit Sourcecode am ersten Abend gekillt ;-)

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.