PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : UART Problem



danst
16.04.2005, 13:44
Hallo,

ich experimentiere gerade mit dem UART am ATMega8. Derzeit verbinde ich noch den AVR mit dem Hyperterminal.
Senden funktioniert immer, empfangen aber immer nur eine gewisse zeit lang, dann muss ich die verbindung trennen und wieder herstellen, damit es wieder funktioniert.
baudrate ist auf 1200 und der Rest auf 8N1, natürlich bei beiden.

Wäre super, wenn mir jemand einen Tipp geben könnte wieso das nicht geht.

Ciao,

Daniel

PicNick
16.04.2005, 14:21
Was meinst du mit "trennen" und "wiederherstellen" ? ab- und anstecken ?

danst
16.04.2005, 14:26
Also im Hyperterminal gibt es doch den "Auflegen" und "Verbinden" button und wenn ich diese nacheinander betätige habe ich wieder eine temporär stabile Verbindung.
Dasselbe, wenn ich in Delphi den Port schließe und danach wieder neu verbinde.

Irgendwie kommt die Verbindung also aus dem Tritt, aber nur einseitig (der Empfang von Zeichen vom PC funktioniert ja weiterhin).
Ich benutze einen USB to Serial Adapter. Könnte es sein, dass der vielleicht diese instabilität erzeugt?

Gruß,

Daniel

PicNick
16.04.2005, 15:40
Es sieht eigentlich so aus, denn dieses "Auflegen" etc. ist so garnix, was den AVR irgendwie interessiert.
Vielleicht aber schickst du unwissentlich irgend was Böses, wo das Terminal glaubt, du legst auf (glaub ich nicht recht).
Gefinkelte sache.
Irgendwer da mit einer Idee ?????

macrofoto
16.04.2005, 17:15
Hallo Daniel,

ist eventuell das Xon/Xoff Protokoll aktiv ?

danst
16.04.2005, 17:45
@robert: ich dachte halt, dass die verbindung durch das "auflegen-abheben" wieder syncronisiert (im Sinne von gleicher Takt) wird.

Xon/Xoff am PC ist aus und der AVR macht das ja nicht automatisch, oder?

Übertragen werden mittlerweile normale ASCII Zeichen, hauptsächlich 'a's und Zahlen.;-) Ich hab keine Sonderzeichen mehr dabei.

Das ist wirklich zum Mäuse melken...

Viele Grüße,

Daniel

PicNick
17.04.2005, 09:43
Sync: Nein, bei der Verbindung ist sowieso jedes Byte ein neues Spiel, ein neues Glück
XonXoff: kennt der AVR selbst überhaupt nicht.
ASCII: gut, hätt'ja sein können
Es MUSS gesetzt sein (beim Terminal) NO HANDSHAKE
Wenn da gesetz wär "Hardware", wär das übel

danst
17.04.2005, 10:00
Hallo!

Danke für den Tipp.
Hardware Flow-Controll ist auch aus.

Könnte jemand mal einen kurzen Blick auf meinen Code werfen und mir sagen, ob dort irgendein Fehler ist? Aber prinzipiell ist das jetzt sowieso nur noch die Originalroutine von Peter Fleury.



#include <avr/io.h>
#include <avr/pgmspace.h>
#include <avr/eeprom.h>
#include <string.h>
#include <avr/interrupt.h>
#include <avr/wdt.h>
#include <avr/signal.h>
#include <avr/delay.h>
#include "TWI/TWI_Master.h"
#include "zbox.h"
#include <stdbool.h>
#include "UART/uart.h"

// Fuses
// CKOPT programmed 0
// SUT0 unprogrammed 1
// SUT1 programmed 0
// CKSEL0 unprogrammed 1
// CKSEL1 unprogrammed 1
// CKSEL2 unprogrammed 1
// CKSEL3 unprogrammed 1
// BODEN programmed 0 (ein)
// BODLEVEL programmed 0 (4,0V)

#define EEPROM __attribute__ ((section (".eeprom")))

#define DevRTC 0b10100000 // 101000x + am Ende eine Null!
#define DevEEPROM 0b10101000 // 1010xxx
#define DevLCD 0b01000010 // 0100xxx
#define DevRelais 0b01111110 // 0111xxx
#define RTCStart 0x10 // RAM-Nutzung in RTC (16)
#define RTCEnde 0xff // RAM-Ende (255)
#define ExEEPROM 256 // Größe des EEPROM
#define IntEEPROM 512 // Größe des Int EEPROM
#define RTCRAM 240 //RTCEnde-RTCStart+1 RAM-Größe (240)
#define RTCKorr 52
#define UARTSPEED 1200
#define F_CPU 12000000

// Befehle identisch mit Computer?
#define BAlive 'a'
#define BZeit 'b'//0x01
#define BDatum 'c'//0x02


//von 7..0: DB7/DB6/DB5/DB4/RS/Beleuchtung-/Enable/XX
#define LCDEnable 1
#define LCDLightDisable 1
#define LCDLightEnable 0
#define LCDBefehl 0 // Befehl RS Bit
#define LCDZeichen 1

volatile uint16_t beepZahl;
volatile char LCD[32];
volatile uint8_t scheduler=0;
volatile uint8_t uhrCounter=0;

// Bools zu einem Bitfeld zusammenfassen!!
volatile bool LCDRS;
volatile bool LCDLight;
volatile bool LCDReady;
volatile bool PCAlive;
volatile uint8_t checkAlive;

uint8_t ZahlZeit, ZahlDatum=0xff;

uint8_t UBuffer[10];
// Problem: KEIN Zugriff auf das LCD darf erfolgen, bevor die X ms Maximal-Dauer um sind.
// Daher: changed Bit-Struktur: 7..0: Bereit:1 / XX / keine Arbeit:0 / 5Bit für Position
//volatile uint8_t changed;
uint8_t eeSpeicher[IntEEPROM] EEPROM;
uint8_t messageBuf[15];
zeitdatum zd;
volatile uint8_t sek, min, std=0;
volatile bool IntSagtLiesUhr=false;
volatile uint8_t ACR, TCR; // Alarm Control Register und Time Control Register

int main (void)
{

init();
TCR=0b00000000;
ACR=0b11011001; // Alarm löst interrupt aus, kein Timer, täglicher Alarm!
uint8_t durchlauf=0x30;
bool exit=false;
while(exit==false)
{
durchlauf++;
if (durchlauf==0x3A)
durchlauf=0x30;


uint16_t c = uart_getc();


if ( c & UART_NO_DATA )
{
}
else
{
if ( c & UART_FRAME_ERROR )
{
}
else if ( c & UART_OVERRUN_ERROR )
{

}
else if ( c & UART_BUFFER_OVERFLOW )
{
}

else
{
uint8_t tmp1;
uint8_t tmp2;
if (ZahlZeit!=0xff)
if (ZahlZeit<7) // nächstes Zeichen für die Zeit
{
UBuffer[++ZahlZeit]=(((unsigned char) c)-0x30);

} else // Zeit ist fertig empfangen!
{
messageBuf[6]=((UBuffer[1]<<4)+UBuffer[2]); // Stunden

messageBuf[5]=((UBuffer[3]<<4)+UBuffer[4]); // Minuten

messageBuf[4]=((UBuffer[5]<<4)+UBuffer[6]); // Sekunden
//setzeUhr();

ZahlZeit=0xff;
//LCDWriteStr(" ",24);
LCDLight=LCDLightDisable;
}

if (ZahlDatum!=0xff) // Datum aktualisieren!
if (ZahlDatum<9) // nächstes Zeichen für die Datum
{
UBuffer[++ZahlDatum]=(((unsigned char) c)-0x30);

} else // Zeit ist fertig empfangen!
{
// Tag/ Jahr
// Es wird nur die einerstelle des Jahres verwendet. Schaltjahr ist Null,
// daher ist 2005 (5) = 1. NUR BIS 2010 VERWENDBAR!!
messageBuf[3]=(((UBuffer[8]-4)<<6)+(UBuffer[1]<<4)+UBuffer[2]);

// Monat Wochentag
messageBuf[4]=((UBuffer[3]<<4)+UBuffer[4]);

//setzeDatum();
ZahlDatum=0xff;
//LCDWriteStr(" ",24);
LCDLight=LCDLightDisable;
}


switch((unsigned char) c)
{
case BAlive:
PCAlive=true;
checkAlive=0;
uart_putc(BAlive);
break;
case BZeit:
LCDLight=LCDLightEnable;
ZahlZeit=0;
UBuffer[ZahlZeit]=((unsigned char) c);
//LCDWriteStr("Zeit",24);
break;

case BDatum:
LCDLight=LCDLightEnable;
ZahlDatum=0;
UBuffer[ZahlDatum]=((unsigned char) c);
//LCDWriteStr("Datum",24);

break;
}

}
}
}

beep(2000);
for(uint8_t i=0;i<=200;i++)
_delay_ms(250);
return 0;
}
SIGNAL(SIG_INTERRUPT0)
{
IntSagtLiesUhr=true;
}


void beep(uint16_t dauer)
{
beepZahl=((F_CPU/(8*150))/1000)*dauer;
}
SIGNAL(SIG_OVERFLOW0)
{


// Beep-Routine 10000mal pro Sek. für 5000Hz; Interrupt wird mit 10000Hz aufgerufen!
if (beepZahl!=0)
{
beepZahl-=1;
PORTB^=(1<<PB3);
}
//PCAlive=false;

// der Uhr counter
if (scheduler++ >= 250)
{
scheduler=0;
uhrCounter++;
if (PCAlive)
{
checkAlive++;
if(checkAlive>=250) // nach etwas mehr als 6 Sek ohne Alive Signal ist der Computer
// abgeschalten!
PCAlive=false;
}

}
TCNT0=105;
}


void init()
{
wdt_disable();
uart_init(UART_BAUD_SELECT(UARTSPEED,F_CPU));// Set frame format: asynchronous, 8data, no parity, 1stop bit
DDRD=0x0; // Input Pin
PORTD=0xff; // Pullups
TCNT0=105; // TC-Startwert
TIMSK|=(1<<TOIE0); // Timer an!
sei();
TCCR0=0b00000010; // Clock/8 Prescaler
DDRB=0b11111111; // benötige PB3 für Beep
LCDReady=false;

}



Vielen Dank,

Daniel

PicNick
17.04.2005, 18:54
Schau mal, ob die diversen Fehlerbits irgenwann mal auftauchen
Du weißt, daß du zu beep und delay niemals hinkommst ?
exit ist doch immer "false"

danst
17.04.2005, 22:19
Hi Robert,

vielen Dank für die Hilfe ich habe den Fehler jetzt gefunden:
Der USB-To-Serial-Adapter funktioniert an meinem USB-Hub nicht richtig, jetzt habe ich ihn direkt an den Computer angeschlossen und jetzt funktioniert alles super...

So ein mist... das hat mehr als zwei tage gedauert dadrauf zu kommen!

Grüße,

Daniel

chr-mt
17.04.2005, 22:49
Hi,
einige USB nach Seriell Adapter (zB. die von Reichelt) haben anscheinend ein Problem unter XP. (Treiberproblem?)
Wenn man ständig Daten ausgibt und erst nach einer gewissen Zeit Hyperterminal startet, meldet das den Port als besetzt.
Im Betrieb kann sich Hyperterminal dann auch mal komplett aufhängen.
Ist kein Programm zum Abholen der Daten (also zB. Hyperterminal) aktiv, und werden trotzdem Daten vom uC an die serielle Schnittstelle des PCs gesendet führt das nach einer gewissen Zeit sogar zu einem Totalabsturz des Rechers mit Bluescreen. (eventuell ein Pufferüberlauf?)
Ist bei mir mit allen verwendeten Rechnern nachvollziehbar aufgetreten.
Ob das nun an XP, dem USB-Treiber, oder der Hardware liegt...
keine Ahnung.
An der normalen seriellen Schnittstelle gibt es keine Probleme.

Gruß
Christopher

danst
18.04.2005, 06:11
echt? das ist ja krass... So einen Mist hab ich da wieder gekauft... geht aber halt leider nicht anders, mein Laptop hat halt keine serielle schnitstelle mehr!

Grüße,

Daniel

PicNick
18.04.2005, 06:44
@chr-mt: Wenn das so ist, sollte man die ganze Sache in unser FAQ bereich reinhängen. Die UART ist eh bekannt, Spaß für viele Nächte zu liefern, da kann so ein Tip schon helfen.

chr-mt
18.04.2005, 12:32
Wenn das so ist, sollte man die ganze Sache in unser FAQ bereich reinhängen
Wäre sinnvoll, wenn das noch ein paar andere zuerst bestätigen könnten.
Vielleicht ist das ja nur bei mir so ;)

So einen Mist hab ich da wieder gekauft.
Nee, die Dinger sind schon OK und leider heutzutage unverzichtbar.
Wir haben in der Firma so an die 20 Stück im Einsatz, die problemlos ihren Dienst tun.
Solange man die Daten immer am PC abholt ist ja auch alles OK.
Leider habe ich gerade keinen Wandler hier, sonst könnte ich den Bluescreen mal fotografieren.
Klappt vielleicht heute Abend.

Gruß
Christopher

PicNick
18.04.2005, 12:37
..., sonst könnte ich den Bluescreen mal fotografieren.

Wär ein hübscher Screen-Saver.

Alter Knacker
18.04.2005, 12:53
Also im Hyperterminal gibt es doch den "Auflegen" und "Verbinden" button und wenn ich diese nacheinander betätige habe ich wieder eine temporär stabile Verbindung.
Dasselbe, wenn ich in Delphi den Port schließe und danach wieder neu verbinde.

Irgendwie kommt die Verbindung also aus dem Tritt, aber nur einseitig (der Empfang von Zeichen vom PC funktioniert ja weiterhin).
Ich benutze einen USB to Serial Adapter. Könnte es sein, dass der vielleicht diese instabilität erzeugt?

Gruß,

Daniel

http://www.kreatives-chaos.com/index.php?seite=usb_seriell

lies dir bloss kurz die ersten sätze durch ;-)
mfg knacki