Serielle Schnittstelle µC

[Dominik (Gast)]

Hallo,
wir haben derzeit ein Schulprojekt am laufen und müssen es morgen 
abgeben!
Unser Problem ist die Kommunikation zwischen der Seriellen Schnittstelle 
und den µC. Wir verwenden einen Max3232 und einen PIC18F4550.
Es werden Buchstaben vom Notebook über die serielle Schnittstelle 
gesendet, der Max empfängt diese auch richtig, doch er invertiert diese.

So jetzt brauch ich euch und zwar wir haben zwei Varianten versucht:
1. µC Eingang negieren (nicht geklappt oder falsch gemacht)
                 char negieren;
                 negieren=~ReadUSART;

2. Es wird über LabView genutzt und dort wurden sie negiert und dann 
erst gesendet, also sollten am µC wieder die richtigen Zeichen sein, 
doch das ist nicht so.

Wir haben auch schon an ein NOT-Gatter gedacht doch diese Lösung wäre 
die umständlichste da die Schaltung auf einer geätzten Platine ist.

Neuestens hab ich den PIC so programmiert, dass wenn irgendetwas ankommt 
dann sollen alle LEDs leuchten. Zeitweise funktioniert es.

Danke im Voraus
Mfg Domi

PS: Zur Verständnis, ein Buchstabe bedeutet eine LED.

[Ingo P. (Gast)]

Normalerweise wird keine Negation (nirgends) gebraucht,
wenn man Daten über die serielle Schnittstelle übertragen will.
Der MAX negiert, ok, aber auf der PC-Seite ist wieder ein
MAX und auch der negiert, dann passt es wieder.

Habt Ihr auch GND am seriellen Anschluss angeschlossen?
(weil nicht eingezeichnet...)

[Karl H. (kbuchegg)]

Dominik schrieb:
> Hallo,
> wir haben derzeit ein Schulprojekt am laufen und müssen es morgen
> abgeben!
> Unser Problem ist die Kommunikation zwischen der Seriellen Schnittstelle
> und den µC. Wir verwenden einen Max3232 und einen PIC18F4550.
> Es werden Buchstaben vom Notebook über die serielle Schnittstelle
> gesendet, der Max empfängt diese auch richtig, doch er invertiert diese.

Und das ist auch richtig so.
Denn der MAX macht nur das rückgängig, was im Notbook bereits mit den 
Zeichen gemacht wurde. Denn dort sitzt (im Prinzip) ebenfalls ein 
MAX232. 2 mal invertiert gibt aber wieder alles richtig rum.

Im Notbook (vor dem ersten MAX) und im µC (nach dem zweiten Max) 
herrschen jeweils dieselben Pegel. Auf dem Kabel jedoch ist genau alles 
verkehrt rum und die Spannungslage ist auch eine andere (-12V und +12V 
anstelle von 5V und 0V). Das ist aber nur am Kabel so. Der MAX im 
Notebook setzt PC-seitig die Daten entsprechend um und der MAX im µC 
macht es wieder rückgängig.

Nichts von all euren Negier-Versuchen ist notwendig (oder richtig).

Euer Problem liegt woanders. Ihr bellt den falschen Baum an.

[as (Gast)]

such mal im Datenblatt nach:

RXDTP: Received Data Polarity Select bit
TXCKP: Clock and Data Polarity Select bit

ist auf der Seite 242.

[Michael K. (Gast)]

Dominik schrieb:
> wir haben derzeit ein Schulprojekt am laufen und müssen es morgen
> abgeben!

Na da seid Ihr ja nicht zu früh dran.
Mess erstmal direkt auf Rx & TX (mit einem Oszilloskop) ob da überhaupt 
was passiert. Die Pegel sollten so um und bei +10V und -10V sein.

http://de.wikipedia.org/wiki/RS-232
Stimmt Deine Pinbelegung ?
Geht PC-TX auf PIC-RX und umgekehrt ?
Hast Du den GND auf beiden Seiten angeschlossen ?

Sende auch vom PIC aus was und schau Dir das Signal an.
Vergleiche die Zeiten der Signalpegel um einen Eindruck davon zu 
bekommen ob beide mit gleicher Baudrate senden.

Wenn das soweit stimmt dann gibt es schon mal eine prinzipiell richtige 
Übertragung. Bleiben noch genug andere Möglichkeiten was falsch zu 
machen.

[Martin M. (capiman)]

Läuft eure Übertragung mittlerweile schon?
Wo seid ihr denn? Vielleicht kann auf die Schnelle
heute Abend noch jemand vor Ort mit drauf schauen?

Soll euer Projekt noch mehr machen, als die Zeichen zu übertragen
bzw. was soll euer Projekt denn insgesamt überhaupt machen?

[Launga (Gast)]

Hallo also ich bin mit von der Truppe die das Projekt machen.

Martin Maurer schrieb:
> Läuft eure Übertragung mittlerweile schon?
> Wo seid ihr denn? Vielleicht kann auf die Schnelle
> heute Abend noch jemand vor Ort mit drauf schauen?

Übertragung, also wir können zeitweise etwas senden, nur sind das 
irgendwelche zeichen.

Das mit dem Draufschauen wird glaub ich nichts, also wir sind von 
Österreich (Niederösterreich) aus dem Bezirk Mistelbach.

> Soll euer Projekt noch mehr machen, als die Zeichen zu übertragen
> bzw. was soll euer Projekt denn insgesamt überhaupt machen?

Ja also wir machen eine LED-Matrix, diese wird mittels LABView und den 
Mikrocontroller angesteuert.
d.h. LabView sendet für jede LED eine anderen Buchstaben über die 
serielle Schnittstelle an den µController und dieser schaltet dann die 
Ledtreiber durch.

LG Laungaa

[Launga (Gast)]

Michael Knoelke schrieb:

> Na da seid Ihr ja nicht zu früh dran.
> Mess erstmal direkt auf Rx & TX (mit einem Oszilloskop) ob da überhaupt
> was passiert. Die Pegel sollten so um und bei +10V und -10V sein.
>
> http://de.wikipedia.org/wiki/RS-232
> Stimmt Deine Pinbelegung ?
> Geht PC-TX auf PIC-RX und umgekehrt ?
> Hast Du den GND auf beiden Seiten angeschlossen ?
>
> Sende auch vom PIC aus was und schau Dir das Signal an.
> Vergleiche die Zeiten der Signalpegel um einen Eindruck davon zu
> bekommen ob beide mit gleicher Baudrate senden.
>
> Wenn das soweit stimmt dann gibt es schon mal eine prinzipiell richtige
> Übertragung. Bleiben noch genug andere Möglichkeiten was falsch zu
> machen.

Wir haben schon alles in den Bereich von Serieller SChnittstelle bis zum 
µC durchgemessen, das funktioniert überall.

Wir haben dann den Binärcode mittels Ozilloskop ausgelesen
Wir haben mit einem hyperterminal ein a gesendet dann war vor dem Max 
der binärcode des a's vorhanden, also 01100001 und hinter dem Max war es 
ein komischen z also 1001110

daher dachten wir wir müssen es invertieren.

[holger (Gast)]

>Wir haben mit einem hyperterminal ein a gesendet dann war vor dem Max
>der binärcode des a's vorhanden,

Wie sieht die serielle Schnittstelle eures PCs aus?
Ein USB-Seriell TTL Wandler? Dann braucht ihr den MAX nicht.

[Launga (Gast)]

holger schrieb:
>
> Wie sieht die serielle Schnittstelle eures PCs aus?
> Ein USB-Seriell TTL Wandler? Dann braucht ihr den MAX nicht.

ein RS232 also D-Sub 9PIN

[Martin M. (capiman)]

Habt Ihr ein Voltmeter?
Messt doch mal sämtliche Spannung aus,
die an den Kondensatoren des MAX sind und schreibt diese hier!
Ihr habt die Kondensatoren wie im Datenblatt angeschlossen
und auch ähnliche Größe? Und richtig herum?
Ausreichende Spannung der Kondensatoren?

Habt Ihr das LabView-Programm selbst geschrieben?
Vielleicht mal hier rein stellen?
(Ich hab noch nie LabView benutzt, noch programmiert...)
Oder vielleicht mal ein Terminal-Programm statt LabView benutzen?

Welche Baudrate benutzt ihr? 8N1?
Die Negier-Sachen sind jetzt überall draußen?

Oder statt dem uC einen zweiten seriellen Port
(gleicher oder anderer PC) anschließen
(GND1 <-> GND2, RX1 <-> TX2, RX2 <-> TX1)
und schauen, ob die gesendeten Zeichen dort ankommen.

Ist es ein 32 Bit Windows oder 64 Bit?
Falls 32 Bit, könnte Portmon weiterhelfen...

Kann man bei Labview zyklisch Zeichen senden,
z.B. jede Sekunde ein 'a'.
Dann mit dem Oszi eine Aufnahme machen?
2-Kanal-Oszi? Dann auf je einem Kanal
einmal vor dem MAX und einmal dahinter.
Dann müsste man sehen, wie sich die Bits verändern
(in eurem Fall von 'a' nach komischem 'z').

[Bülent C. (mirki)]

Schaumal was ich für euch gefunden habe....Scheint ein Problem mit dem 
PIC zu sein....
Hier ein Auszug
Using the PIC24 with BRGH = 1 is a problem and you will find many 
occurances of this problem here in the forum. Whether this problem is 
the one you are seeing depends on the silicon revision of your chip, see 
the errata http://ww1.microchip.com/downloads/en/DeviceDoc/80471a.pdf . 
The only sure fire way to get around it if you have one of the affected 
revisions is to stick with BRGH = 0.
Hope this helps,


Nachdem BRGH = 0 gesetzt wurde hatte es geklappt....Er hatte genau die 
gleichen probleme wie ihr.


http://www.microchip.com/forums/m451419-print.aspx

[as (Gast)]

Und warum schaltet ihr nicht die Konvertierung im uC ein?

[Launga (Gast)]

Martin Maurer schrieb:
> Habt Ihr ein Voltmeter?
> Messt doch mal sämtliche Spannung aus,
> die an den Kondensatoren des MAX sind und schreibt diese hier!
> Ihr habt die Kondensatoren wie im Datenblatt angeschlossen
> und auch ähnliche Größe? Und richtig herum?
> Ausreichende Spannung der Kondensatoren?
Die Spannungen passen weiß sie nicht auswendig aber wir haben sie schon 
einmal geprüft und die Kondensator sind die die im Datenblatt angegeben 
sind und sie sind richtig verbaut.

> Habt Ihr das LabView-Programm selbst geschrieben?
> Vielleicht mal hier rein stellen?
> (Ich hab noch nie LabView benutzt, noch programmiert...)
> Oder vielleicht mal ein Terminal-Programm statt LabView benutzen?
Ja das wurde von mir geschrieben
Ja es wurde ein Hyperterminal verwendet und getestet gleiches Problem 
wie beim Labview.

> Welche Baudrate benutzt ihr? 8N1?
> Die Negier-Sachen sind jetzt überall draußen?
Baudrate 9600
wie meinst du draußen? also in den Programmen ist keine negier funktion 
mehr

> Oder statt dem uC einen zweiten seriellen Port
> (gleicher oder anderer PC) anschließen
> (GND1 <-> GND2, RX1 <-> TX2, RX2 <-> TX1)
> und schauen, ob die gesendeten Zeichen dort ankommen.
ja das funktioniert haben wir schon mal getestet.

> Ist es ein 32 Bit Windows oder 64 Bit?
> Falls 32 Bit, könnte Portmon weiterhelfen...
64-Bit Win7

> Kann man bei Labview zyklisch Zeichen senden,
> z.B. jede Sekunde ein 'a'.
> Dann mit dem Oszi eine Aufnahme machen?
> 2-Kanal-Oszi? Dann auf je einem Kanal
> einmal vor dem MAX und einmal dahinter.
> Dann müsste man sehen, wie sich die Bits verändern
> (in eurem Fall von 'a' nach komischem 'z').
Puh dass weiß ich gar nicht aber, ich habe zuhause e kein Oszi zu 
verfügung

[Bülent C. (mirki)]

Launga schrieb:
> Baudrate 9600

Wunderbar, dann setzt BRGH=0...dann sollte es evtl. fliegen.

[Dominik (Gast)]

Hab jetzt folgendes geändert:

OpenUSART(USART_TX_INT_OFF & USART_RX_INT_ON & USART_ASYNCH_MODE & 
USART_EIGHT_BIT& USART_CONT_RX & USART_BRGH_LOW, 129 ); //von 
USART_BRGH_HIGH zu USART_BRGH_LOW

Leider ändert es nichts an dem Endergebnis, es leuchten weiterhin alle 
LEDs.

Hier mal ein Auszug aus dem Programm:

#include <p18cxxx.h>
#include "init.h"
#include <delays.h>
#include <usart.h>
#include <timers.h>
#include <pwm.h>

#pragma code


//Prototypes for Additional Delay Functions
void DelayFor18TCY(void);
void DelayPORXLCD(void);
void DelayXLCD(void);
void LED1(void);
void LED2(void);
void LED3(void);
void LED4(void);
void LED5(void);
.
.
.
void LED25(void);
void Muster1(void);
void Muster2(void);
void Muster3(void);
void Muster4(void);
void Muster5(void);
void Back(void);
void Falsch(void);
void USARTRxIntHndl(void);
void HighIntHndl(void);

#pragma code IntVectHigh=0x08
void IntVectHigh (void)
{
_asm GOTO HighIntHndl _endasm
}


//pragma to return to normal program section 
#pragma  code



#pragma interrupt HighIntHndl
void HighIntHndl(void)
{

  Nop();
  
  if(PIR1 & 0b00100000)      
    {
    USARTRxIntHndl();
    return;
    }
  

}

//USART Rx Int Hndl
void USARTRxIntHndl(void)
{
char      USARTRxVal;
static int    PWM1DCVal;
  

  USARTRxVal=ReadUSART();              
  PIR1bits.RCIF=0;
  
  switch(USARTRxVal)
    {
      case ('A'|'a'):
        LED1();
        break;
        
      case ('B'|'b'):
        LED2();
        break;
      
      case ('C'|'c'):
        LED3();
        break;
.
.
.
                        case ('Y'|'y'):
        LED25();
        break;
        
      case ('Z'|'z'):
        Back();
        break;
      
      case ('1'|'5'):
        Muster1();
        break;

        
      default:
        Falsch();
        break;

}
void LED1(void)
{
  if (PORTAbits.RA0==0)
    PORTAbits.RA0=1;
    
  else 
    PORTAbits.RA0=0;
}  
.
.
.
void Back(void)
{
PORTA=0x00;
PORTBbits.RB0=0;
PORTBbits.RB1=0;
PORTBbits.RB2=0;
PORTBbits.RB3=0;
PORTBbits.RB4=0;
PORTCbits.RC0=0;
PORTCbits.RC1=0;
PORTCbits.RC2=0;
PORTD=0x00;
PORTE=0x00;
}

void Falsch(void)
{
PORTA=0xFF;
PORTE=0xFF;
PORTBbits.RB0=1;
PORTBbits.RB1=1;
PORTBbits.RB2=1;
PORTBbits.RB3=1;
PORTBbits.RB4=1;
PORTCbits.RC0=1;
PORTCbits.RC1=1;
PORTCbits.RC2=1;
PORTD=0xFF;
PORTE=0xFF;
}

void main()
{
  
  init();
  
  TRISA = 0x00;
  TRISBbits.TRISB0=0;
  TRISBbits.TRISB1=0;
  TRISBbits.TRISB2=0;
  TRISBbits.TRISB3=0;
  TRISBbits.TRISB4=0;
  TRISCbits.TRISC0=0;
  TRISCbits.TRISC1=0;
  TRISCbits.TRISC2=0;
  TRISD = 0x00;
  TRISE = 0x00;
    
  //--->>> Open USART
  //--->>> Rx Ints Enabled, Async Mode, 8N1, 9600Baud @ 20MHz
  OpenUSART(USART_TX_INT_OFF & USART_RX_INT_ON & USART_ASYNCH_MODE & USART_EIGHT_BIT& USART_CONT_RX & USART_BRGH_LOW, 129 );  //25
  
  
  INTCONbits.GIEH=1;

  //Loop Forever
  while(1)
  {
    Nop();

    
  }
}

[Martin M. (capiman)]

Das geht so nicht:

case ('A'|'a'):

Musst du 2 Fälle draus machen!
Aber nicht der Kern des Problems...

[Martin M. (capiman)]

Ich glaube, dass dies auch nicht funktioniert:

void LED1(void)
{
  if (PORTAbits.RA0==0)
    PORTAbits.RA0=1;

  else
    PORTAbits.RA0=0;
}

Hast du dies mal einzeln getestet,
ob du damit LEDs steuern kannst?

Aber zum UART:

OpenUSART(USART_TX_INT_OFF & USART_RX_INT_ON & USART_ASYNCH_MODE & 
USART_EIGHT_BIT& USART_CONT_RX & USART_BRGH_LOW, 129 );  //25

Was soll die Zeile machen?

'&' ist ein binäres AND, also kommt als Wert vermutlich 0 raus...
Vermutlich muss es statt '&' überall ein '|' sein?

[Launga (Gast)]

Martin Maurer schrieb:
> Das geht so nicht:
>
> case ('A'|'a'):
>
> Musst du 2 Fälle draus machen!
> Aber nicht der Kern des Problems...

naja ich schicke aber nur kleinbuchstaben mit Labview ist dann ein 
problem ?

[Martin M. (capiman)]

Kannst du mal suchen lassen, welche Werte (nur ein paar)
diese Defines haben?

USART_TX_INT_OFF & USART_RX_INT_ON & USART_ASYNCH_MODE &
USART_EIGHT_BIT& USART_CONT_RX & USART_BRGH_LOW

Ich sehe viele solche Beispiele, wenn ich danach Google...
(vielleicht doch nicht falsch?)

[Karl H. (kbuchegg)]

Launga schrieb:
> Martin Maurer schrieb:
>> Das geht so nicht:
>>
>> case ('A'|'a'):
>>
>> Musst du 2 Fälle draus machen!
>> Aber nicht der Kern des Problems...
>
> naja ich schicke aber nur kleinbuchstaben mit Labview ist dann ein
> problem ?

Dein Glück, oder Pech, dass 'A' und 'a' fast dieselbe Bitdarstellung 
haben. WEnn du die miteinander veroderst, dann kommt 'a' raus. Wären die 
ASCII Darstellungen anders, dann würde da Unsinn rauskommen.


Generell: solange ihr nicht sicher seid, dass die UART problemlos 
funktioniert seid ihr gut beraten möglichst wenig Code zu haben, in den 
ihr Fehler einbauen könnt. Um die UART an sich zu debuggen, ist es 
sinnvoll ein Programm zu schreiben, welches nichts anderes tut, als zb 
ein 'x' zu senden. Solange ihr auf dem PC in einem Terminalprogramm 
diese 'x' nicht korrekt seht, ist die UART noch fehlerhaft. Solange das 
so ist, ist es sinnlos, da noch mehr Code drüberzustülpen, so werdet ihr 
die UART nie debuggen können. Denn ihr wisst nie, ob das Problem jetzt 
die UART ist, oder ob ihr in eurem eigenen Programm noch Fehler habt. 
Und wenn ich mir das Programm so ansehe, dann seid ihr gut beraten, 
diese letzte Fehlerquelle erst mal auszuschliessen.
Erst dann, wenn klar ist, dass die UART einwandfrei funktioniert, erst 
dann macht es Sinn, euren eigentlichen Code zu testen.

[Rufus Τ. F. (rufus)]

Launga schrieb:
> naja ich schicke aber nur kleinbuchstaben mit Labview ist dann ein
> problem ?

Das ist dann eher Zufall, daß das funktioniert.

Schreib' entweder

  switch (USARTRxVal)
  {
    case 'A' :
    case 'a' :
      ...
      break;

    case 'B' :
    case 'b' :
      ...

oder

  switch (toupper(USARTRxVal))
  {
    case 'A' :
      ...
      break;

    case 'B' :
      ...

Was Du machst, ist ein bitweises OR aus den Werten von 'A' und 'a' (0x41 
und 0x61) - was 'a' (0x61) ergibt. Mit einem 'A' würde Dein Code also 
nie funktionieren.

[Karl H. (kbuchegg)]

Rufus Τ. Firefly schrieb:

> Was Du machst, ist ein bitweises OR aus den Werten von 'A' und 'a' (0x41
> und 0x61) - was 'a' (0x61) ergibt. Mit einem 'A' würde Dein Code also
> nie funktionieren.


Exakt.
Das zb

      case ('1'|'5'):

wird nie richtig funktionieren.

[holger (Gast)]

>Um die UART an sich zu debuggen, ist es
>sinnvoll ein Programm zu schreiben, welches nichts anderes tut, als zb
>ein 'x' zu senden.

Ich sende immer erst mal ein 'U' -> 0x55.
Dann kann man mit dem Osci die Bitzeiten ausmessen
und nachrechnen ob die Baudrate stimmt. Leider hat er ja kein Osci.

[Dominik (Gast)]

Also noch mal von Vorne. Hab das ganze jetzt einmal vereinfacht, sodass 
er nur das 'a' sucht bzw. wenn irgendetwas kommt alle leuchten soll.

#include <p18cxxx.h>
#include "init.h"
#include <delays.h>
#include <usart.h>
#include <timers.h>
#include <pwm.h>

#pragma code


//Prototypes for Additional Delay Functions
void DelayFor18TCY(void);
void DelayPORXLCD(void);
void DelayXLCD(void);
void LED1(void);
void Falsch(void);
void USARTRxIntHndl(void);
void HighIntHndl(void);
  

//Insert Hign Interrupt Vector at 0x08 including code pragma
#pragma code IntVectHigh=0x08
void IntVectHigh (void)
{
_asm GOTO HighIntHndl _endasm
}


//pragma to return to normal program section 
#pragma  code


//High Interrupt Handler Tests for ADIF
//On interrupt true calls ADIFIntHndl
#pragma interrupt HighIntHndl
void HighIntHndl(void)
{
//Determine which Interrupt occurred
  Nop();
  //--->>>Determine if Rx Int fired
  //--->>>If fired call USARTRxIntHndl function
  if(PIR1 & 0b00100000)      //Test USART RXIF
    {
    USARTRxIntHndl();
    return;
    }
  

}

//USART Rx Int Hndl
void USARTRxIntHndl(void)
{
char      USARTRxVal;
static int    PWM1DCVal;
  

  USARTRxVal=ReadUSART();              
  PIR1bits.RCIF=0;
  
  switch(USARTRxVal)
    {
      case 'a':
        LED1();
        break;
        
      default:
        Falsch();
        break;
    }
  
  SetDCPWM1(PWM1DCVal);
  return;
}

void LED1(void)
{
  if (PORTAbits.RA0==0)
    PORTAbits.RA0=1;
    
  else 
    PORTAbits.RA0=0;
}  


void Falsch(void)
{
PORTA=0xFF;
PORTE=0xFF;
PORTBbits.RB0=1;
PORTBbits.RB1=1;
PORTBbits.RB2=1;
PORTBbits.RB3=1;
PORTBbits.RB4=1;
PORTCbits.RC0=1;
PORTCbits.RC1=1;
PORTCbits.RC2=1;
PORTD=0xFF;
PORTE=0xFF;
}

void main()
{
  
  init();
  
  TRISA = 0x00;
  TRISBbits.TRISB0=0;
  TRISBbits.TRISB1=0;
  TRISBbits.TRISB2=0;
  TRISBbits.TRISB3=0;
  TRISBbits.TRISB4=0;
  TRISCbits.TRISC0=0;
  TRISCbits.TRISC1=0;
  TRISCbits.TRISC2=0;
  TRISD = 0x00;
  TRISE = 0x00;
  
    
  //--->>> Open USART
  //--->>> Rx Ints Enabled, Async Mode, 8N1, 9600Baud @ 20MHz
  OpenUSART(USART_TX_INT_OFF & USART_RX_INT_ON & USART_ASYNCH_MODE & USART_EIGHT_BIT& USART_CONT_RX & USART_BRGH_LOW, 129 );  //warum genau & sind kann ich nicht sagen, aber  es sind auf alle Fälle USART Einstellungen und denke mal das diese mit & erweitert werden
  

  //Set GIEH
  INTCONbits.GIEH=1;

  //Loop Forever
  while(1)
  {
    Nop();
  }
}

[Martin M. (capiman)]

OpenUSART(USART_TX_INT_OFF & USART_RX_INT_ON & USART_ASYNCH_MODE &
USART_EIGHT_BIT& USART_CONT_RX & USART_BRGH_LOW, 129 );  //25

Ich habe gerade mal im usart.h nachgeschaut,
die '&' könnten stimmen.
Da gibt es 2 Modes: AND (default) und OR

Sind die 129 richtig?

[holger (Gast)]

>Also noch mal von Vorne. Hab das ganze jetzt einmal vereinfacht, sodass
>er nur das 'a' sucht bzw. wenn irgendetwas kommt alle leuchten soll.

Und was tut sich bei deinen LEDs?

[Launga (Gast)]

Martin Maurer schrieb:
> Sind die 129 richtig?

Bin mir ziemlich sicher:
9600Baud
20MHz

[Karl H. (kbuchegg)]

Martin Maurer schrieb:
> OpenUSART(USART_TX_INT_OFF & USART_RX_INT_ON & USART_ASYNCH_MODE &
> USART_EIGHT_BIT& USART_CONT_RX & USART_BRGH_LOW, 129 );  //25
>
> Ich habe gerade mal im usart.h nachgeschaut,
> die '&' könnten stimmen.

Kann ich mir nicht vorstellen.

Sinn der Sache ist es ja wohl, genau diese Bits alle zu setzen. Dazu 
brauchst es aber das |

Mit einem & würde da eine Schnittmenge rauskommen. Welche Bits sind in 
all diesen Werten auf 1? Und nur dieses Ergebnis würde gesetzt werden.

Da müssten sie schon die Definitionen 'active Low' gemacht haben. Was 
mehr als ungewöhnlich wäre.

[Bülent C. (mirki)]

Ist Masse verbunden? Auf dem skizzierten Schaltplan ist es nicht....Hast 
Du die gleiche baudrate am PC?

[Launga (Gast)]

Bülent C. schrieb:
> Ist Masse verbunden? Auf dem skizzierten Schaltplan ist es nicht....Hast
Ja ist verbunden

> Du die gleiche baudrate am PC?
ja ist auch eingestellt

[Martin M. (capiman)]

@Karl-Heinz:

Die sind so definiert:

#ifndef USE_OR_MASKS

#define USART_TX_INT_ON   0b11111111  // Transmit interrupt on
#define USART_TX_INT_OFF  0b01111111  // Transmit interrupt off
#define USART_RX_INT_ON   0b11111111  // Receive interrupt on
#define USART_RX_INT_OFF  0b10111111  // Receive interrupt off
#define USART_BRGH_HIGH   0b11111111  // High baud rate
#define USART_BRGH_LOW    0b11101111  // Low baud rate
#define USART_CONT_RX     0b11111111  // Continuous reception
#define USART_SINGLE_RX   0b11110111  // Single reception
#define USART_SYNC_MASTER 0b11111111  // Synchrounous master mode
#define USART_SYNC_SLAVE  0b11111011  // Synchrounous slave mode
#define USART_NINE_BIT    0b11111111  // 9-bit data
#define USART_EIGHT_BIT   0b11111101  // 8-bit data
#define USART_SYNCH_MODE  0b11111111  // Synchronous mode
#define USART_ASYNCH_MODE 0b11111110  // Asynchronous mode
#define USART_ADDEN_ON    0b11111111  // Enables address detection
#define USART_ADDEN_OFF   0b11011111  // Disables address detection


//------------AND MASK------------------------------------------------
#else
#define USART_TX_INT_ON       0b10000000  // Transmit interrupt on
#define USART_TX_INT_OFF      0b00000000  // Transmit interrupt off
#define USART_TX_INT_MASK    (~USART_TX_INT_ON)  //Mask Trnasmit 
Interrupt select bit

#define USART_RX_INT_ON       0b01000000  // Receive interrupt on
#define USART_RX_INT_OFF      0b00000000  // Receive interrupt off
#define USART_RX_INT_MASK    (~USART_RX_INT_ON)  //Mask Receive 
Interrupt select bit

#define USART_ADDEN_ON        0b00100000  // Enables address detection
#define USART_ADDEN_OFF       0b00000000  // Disables address detection
#define USART_ADDEN_MASK    (~USART_ADDEN_ON)  //Mask address detection 
select bit

#define USART_BRGH_HIGH       0b00010000  // High baud rate
#define USART_BRGH_LOW        0b00000000  // Low baud rate
#define USART_BRGH_MASK      (~USART_BRGH_HIGH)  //Mask baud rate select 
bit

#define USART_CONT_RX         0b00001000  // Continuous reception
#define USART_SINGLE_RX       0b00000000  // Single reception
#define USART_CONT_RX_MASK    (~USART_CONT_RX)   //Mask Continuous 
Reception select bit

#define USART_SYNC_MASTER     0b00000100  // Synchrounous master mode
#define USART_SYNC_SLAVE      0b00000000  // Synchrounous slave mode
#define USART_SYNC_MASK      (~USART_SYNC_MASTER)  //Mask usart mode 
select bit

#define USART_NINE_BIT        0b00000010  // 9-bit data
#define USART_EIGHT_BIT       0b00000000  // 8-bit data
#define USART_BIT_MASK       (~USART_NINE_BIT)    //Mask 9 bit transmit 
select bit

#define USART_SYNCH_MODE      0b00000001  // Synchronous mode
#define USART_ASYNCH_MODE     0b00000000  // Asynchronous mode
#define USART_MODE_MASK      (~USART_SYNCH_MODE)   //Mask sync/async 
mode select bit

#endif

[Bülent C. (mirki)]

Setzte die mal mit UART_UXRX_IDLE_ZERO und UART_UXRX_IDLE_ONE

[Michael S. (rbs_phoenix)]

Bülent C. schrieb:
> Schaumal was ich für euch gefunden habe....Scheint ein Problem mit
> dem
> PIC zu sein....
> Hier ein Auszug
> Using the PIC24 with BRGH = 1 is a problem and you will find many
> occurances of this problem here in the forum. Whether this problem is
> the one you are seeing depends on the silicon revision of your chip, see
> the errata http://ww1.microchip.com/downloads/en/DeviceDoc/80471a.pdf .
> The only sure fire way to get around it if you have one of the affected
> revisions is to stick with BRGH = 0.
> Hope this helps,
>
> Nachdem BRGH = 0 gesetzt wurde hatte es geklappt....Er hatte genau die
> gleichen probleme wie ihr.
>
> http://www.microchip.com/forums/m451419-print.aspx

Da steht "Using PIC24", doch die Jungs nehmen doch den PIC18F4550, in 
dessen Errata nichts bzgl. diesen Problems steht.

Ist das richtig, das in dem "Schaltplan" Bild die RX Leitung nicht an Rx 
vom PIC geht?

Martin Maurer schrieb:
> Ich glaube, dass dies auch nicht funktioniert:
>
> void LED1(void)
> {
>   if (PORTAbits.RA0==0)
>     PORTAbits.RA0=1;
>
>   else
>     PORTAbits.RA0=0;
> }

Das könnte meines Wissens so aussehen:
PORTAbits.RA0 = ~PORTAbits.RA0
Ich hätte das aber denke ich anders gemacht als eine extra Funktion (pro 
LED), die nur die LED toggelt.

PS: Schönes (vorallem übersichtliches) Blockschaltbild von LabVIEW und 
erahnendes Hintergrundbild ;)

[Karl H. (kbuchegg)]

Martin Maurer schrieb:
> @Karl-Heinz:
>
> Die sind so definiert:

Wahnsinn. Die haben tatsächlich eine Version für 'active Low' gebaut.
Und? Ist USE_OR_MASKS defaultmässig definiert oder nicht?

[Michael L. (michaelx)]

Karl Heinz schrieb:
> Martin Maurer schrieb:
>> OpenUSART(USART_TX_INT_OFF & USART_RX_INT_ON & USART_ASYNCH_MODE &
>> USART_EIGHT_BIT& USART_CONT_RX & USART_BRGH_LOW, 129 );  //25
>>
>> Ich habe gerade mal im usart.h nachgeschaut,
>> die '&' könnten stimmen.
>
> Kann ich mir nicht vorstellen.
>
> Sinn der Sache ist es ja wohl, genau diese Bits alle zu setzen. Dazu
> brauchst es aber das |
>
> Mit einem & würde da eine Schnittmenge rauskommen. Welche Bits sind in
> all diesen Werten auf 1? Und nur dieses Ergebnis würde gesetzt werden.
>
> Da müssten sie schon die Definitionen 'active Low' gemacht haben. Was
> mehr als ungewöhnlich wäre.

Die Zeile mit den & ist schon richtig. Zur Info, so sind die einzelnen 
Makros definiert:

#define USART_TX_INT_ON   0b11111111  // Transmit interrupt on
#define USART_TX_INT_OFF  0b01111111  // Transmit interrupt off
#define USART_RX_INT_ON   0b11111111  // Receive interrupt on
#define USART_RX_INT_OFF  0b10111111  // Receive interrupt off
#define USART_BRGH_HIGH   0b11111111  // High baud rate
#define USART_BRGH_LOW    0b11101111  // Low baud rate
#define USART_CONT_RX     0b11111111  // Continuous reception
#define USART_SINGLE_RX   0b11110111  // Single reception
#define USART_SYNC_MASTER 0b11111111  // Synchrounous master mode
#define USART_SYNC_SLAVE  0b11111011  // Synchrounous slave mode
#define USART_NINE_BIT    0b11111111  // 9-bit data
#define USART_EIGHT_BIT   0b11111101  // 8-bit data
#define USART_SYNCH_MODE  0b11111111  // Synchronous mode
#define USART_ASYNCH_MODE 0b11111110  // Asynchronous mode
#define USART_ADDEN_ON    0b11111111  // Enables address detection
#define USART_ADDEN_OFF   0b11011111  // Disables address detection

Grüße.

[holger (Gast)]

>> Sind die 129 richtig?
>
>Bin mir ziemlich sicher:
>9600Baud
>20MHz

Sicher?

> OpenUSART(USART_TX_INT_OFF & USART_RX_INT_ON & USART_ASYNCH_MODE &
> USART_EIGHT_BIT& USART_CONT_RX & USART_BRGH_LOW, 129 );  //25

Für BRGH = 0 steht aber 31 im Datenblatt.

[Launga (Gast)]

Michael Skropski schrieb:
> Ist das richtig, das in dem "Schaltplan" Bild die RX Leitung nicht an Rx
> vom PIC geht?

jetzt wo du es sagst.. das verwirrt mich jetzt selbst.

> PS: Schönes (vorallem übersichtliches) Blockschaltbild von LabVIEW und
> erahnendes Hintergrundbild ;)
Das Caos in meinen LapView programm weiß ich nur zu gut, auch wenn man 
es nicht glaubt aber ich kenne mich noch aus in meinen Caos aus :P
Ein bisschen nackte haut an desktop vertreibt kummer und sorgen :)

[Michael L. (michaelx)]

Mal eine ganz andere Frage:

Warum wollt ihr den 18F4550 ausgerechnet über RS232 mit dem PC 
verbinden?
War das die exakte Aufgabenstellung?
Wurde der PIC vorgegeben?

Ich frage nur, weil dieser PIC ein USB-Interface hat, und es für den PIC 
Bibliotheken gibt, um eine serielle Schnittstelle über den USB und einen 
virtuellen COM-Port nachzubilden.

;-)

[Martin M. (capiman)]

Zu diesem Teil nochmal:

> if (PORTAbits.RA0==0)
>     PORTAbits.RA0=1;
>
>   else
>     PORTAbits.RA0=0;

Kann man bei einem PIC18, wenn ein GPIO als Ausgang definiert ist,
den Wert, den man gesetzt hat, wieder zurück lesen?

@Karl Heinz:
Hab ich vorher auch noch nicht gesehen...

USE_OR_MASKS kommt zumindest in obigem Code nicht vor.
Aber es könnte natürlich in der IDE irgendwo definiert sein...

Vielleicht mal so etwas ergänzen...

#ifndef USE_OR_MASKS
#else
ERROR-ERROR-ERROR
#endif

Dann wirft er einen Fehler, falls es definiert ist.

[Dominik (Gast)]

Michael L. schrieb:
> Mal eine ganz andere Frage:
>
> Warum wollt ihr den 18F4550 ausgerechnet über RS232 mit dem PC
> verbinden?
> War das die exakte Aufgabenstellung?
> Wurde der PIC vorgegeben?
>
> Ich frage nur, weil dieser PIC ein USB-Interface hat, und es für den PIC
> Bibliotheken gibt, um eine serielle Schnittstelle über den USB und einen
> virtuellen COM-Port nachzubilden.
>
> ;-)

Nein war nicht vorgegeben, allerdings haben wir schon mal mit der 
Seriellen Schnittstelle gearbeitet und damals klappte es auch nur da 
hatten wir einen anderen PIC.

[Launga (Gast)]

Michael L. schrieb:
> Mal eine ganz andere Frage:
>
> Warum wollt ihr den 18F4550 ausgerechnet über RS232 mit dem PC
> verbinden?
> War das die exakte Aufgabenstellung?
> Wurde der PIC vorgegeben?
>
> Ich frage nur, weil dieser PIC ein USB-Interface hat, und es für den PIC
> Bibliotheken gibt, um eine serielle Schnittstelle über den USB und einen
> virtuellen COM-Port nachzubilden.
>
> ;-)

Ja wir wählten diesen da wir mit den schon Erfahrungen hatten und ein 
Lehrer der uns µController programmieren gelernt hat, hat gemeint in 6 
Wochen schaffen wir es nicht das Usb-Interface und allen anderen Sachen 
auseinanderzusetzen die wir für dieses Projekt benötigen, daher die 
Serielle Schnittstelle da wir mit dieser schon am Demoboard gearbeitet 
haben

[holger (Gast)]

@Launga

Hast du meinen Post gelesen?

Beitrag "Re: Serielle Schnittstelle µC"

[Dominik (Gast)]

Martin Maurer schrieb:
> USE_OR_MASKS kommt zumindest in obigem Code nicht vor.
> Aber es könnte natürlich in der IDE irgendwo definiert sein...
>
> Vielleicht mal so etwas ergänzen...
>
> #ifndef USE_OR_MASKS
> #else
> ERROR-ERROR-ERROR
> #endif
>
> Dann wirft er einen Fehler, falls es definiert ist.


Selbst wenn ich die 4 Zeilen einfüge ändert sich nichts. Er kann es 
übersetzen, auf den PIC spielen und srpingt wieder in das default wenn 
er ein 'a' bekommt, welches, so denke ich, nicht als 'a' sondern 
irgendetwas anderes kommt.

[Bülent C. (mirki)]

Dominik schrieb:
> Nein war nicht vorgegeben, allerdings haben wir schon mal mit der
> Seriellen Schnittstelle gearbeitet und damals klappte es auch nur da
> hatten wir einen anderen PIC.

Gleicher code?
Wenn ja, dann liegt der Verdacht mit BRGH=0 evtl. nahe...ändert die 129 
noch in 31 ab...

[greg (Gast)]

Dominik schrieb:
> Es werden Buchstaben vom Notebook über die serielle Schnittstelle
> gesendet, der Max empfängt diese auch richtig, doch er invertiert diese.

Nein, der invertiert nicht. Das ist falsch ausgedrückt. Der MAX232 
konvertiert auf RS232-Pegel, und die sind:

Logische 0: +3 bis +15V
Logische 1: -15 bis -3V

Dabei sind -3 bis +3V undefiniert.

[holger (Gast)]

>Wenn ja, dann liegt der Verdacht mit BRGH=0 evtl. nahe...ändert die 129
>noch in 31 ab...

Oder USART_BRGH_HIGH mit 129. Ergibt auch einen kleineren Fehler.

[Dominik (Gast)]

greg schrieb:
> Dominik schrieb:
>> Es werden Buchstaben vom Notebook über die serielle Schnittstelle
>> gesendet, der Max empfängt diese auch richtig, doch er invertiert diese.
>
> Nein, der invertiert nicht. Das ist falsch ausgedrückt. Der MAX232
> konvertiert auf RS232-Pegel, und die sind:
>
> Logische 0: +3 bis +15V
> Logische 1: -15 bis -3V
>
> Dabei sind -3 bis +3V undefiniert.

Das Problem dabei ist das wir keinen MAX 232 besitzen sondern einen MAX 
3232.

[greg (Gast)]

Dominik schrieb:
> Das Problem dabei ist das wir keinen MAX 232 besitzen sondern einen MAX
> 3232.

Das ist kein Problem, denn das ist eigentlich nur eine moderne Version 
vom MAX232, u.a. mit größerem Betriebsspannungsbereich.

[Dominik (Gast)]

Bülent C. schrieb:
> Dominik schrieb:
>> Nein war nicht vorgegeben, allerdings haben wir schon mal mit der
>> Seriellen Schnittstelle gearbeitet und damals klappte es auch nur da
>> hatten wir einen anderen PIC.
>
> Gleicher code?
> Wenn ja, dann liegt der Verdacht mit BRGH=0 evtl. nahe...ändert die 129
> noch in 31 ab...

Habe jetzt folgende Kombinationen probiert:
1. OpenUSART(USART_TX_INT_OFF & USART_RX_INT_ON & USART_ASYNCH_MODE & 
USART_EIGHT_BIT& USART_CONT_RX & USART_BRGH_LOW, 31 );

2. OpenUSART(USART_TX_INT_OFF & USART_RX_INT_ON & USART_ASYNCH_MODE & 
USART_EIGHT_BIT& USART_CONT_RX & USART_BRGH_LOW, 129 );

3. OpenUSART(USART_TX_INT_OFF & USART_RX_INT_ON & USART_ASYNCH_MODE & 
USART_EIGHT_BIT& USART_CONT_RX & USART_BRGH_HIGH, 129 );

Bei alle 3 Varianten ändert sich nichts. Sobald ich den µC mit dem 
Hyperterminal ein 'a' sende, was bedeutet LED1(RA0) sollte leuchten, 
springt er in den Interrupt Falsch() und lässt alle LEDs leuchten.

[Launga (Gast)]

holger schrieb:
> @Launga
>
> Hast du meinen Post gelesen?
>
> Beitrag "Re: Serielle Schnittstelle µC"

Oh übersehen sry,
ja auch wenn wir 31 einsetzen funktioniert es nicht

[holger (Gast)]

>ja auch wenn wir 31 einsetzen funktioniert es nicht

Also:

USART_BRGH_LOW und 31 geht nicht.
USART_BRGH_HIGH und 129 geht auch nicht.

Steht aber beides so im Datenblatt.

Die zweite Version hat bei mir früher mal funktioniert.
Dann liegt der Verdacht nahe das euer PIC gar nicht mit 20MHz läuft.

[Michael L. (michaelx)]

Launga schrieb:
> Ja wir wählten diesen da wir mit den schon Erfahrungen hatten und ein
> Lehrer der uns µController programmieren gelernt hat, hat gemeint in 6
> Wochen schaffen wir es nicht das Usb-Interface und allen anderen Sachen
> auseinanderzusetzen die wir für dieses Projekt benötigen

Wenn man das USB Interface in Assembler und alles von Grund auf selbst 
schreiben wollte, dann wären 6 Wochen evtl. etwas knapp.

Aber für USB gibts eine Bibliothek + CDC-Demo für virtuelle serielle 
Schnittstelle. Das kann man mit Installation in 1 Stunde zum laufen 
bekommen. Hab ich mal probiert, als der 18F4550 neu auf den Markt kam 
...

Edit: Das heißt aber nicht, dass ihr heute damit anfangen sollt ..

[Bülent C. (mirki)]

holger schrieb:
>>ja auch wenn wir 31 einsetzen funktioniert es nicht
>
> Also:
>
> USART_BRGH_LOW und 31 geht nicht.
> USART_BRGH_HIGH und 129 geht auch nicht.
>
> Steht aber beides so im Datenblatt.
>
> Die zweite Version hat bei mir früher mal funktioniert.
> Dann liegt der Verdacht nahe das euer PIC gar nicht mit 20MHz läuft.

Da könnte was dran sein....

[Launga (Gast)]

holger schrieb:
> Die zweite Version hat bei mir früher mal funktioniert.
> Dann liegt der Verdacht nahe das euer PIC gar nicht mit 20MHz läuft.
wie kann man das am besten nachprüfen?

[Karl H. (kbuchegg)]

Ich kann mich nur wiederholen:

Beendet endlich das Stochern im Nebel und lasst den PIC ein Zeichen an 
den PC senden. Dort SIEHST du ob es korrekt ankommt!

Du hättest dieses Problem schon längst ausgeräumt, wenn du nicht so stur 
darauf beharren würdest, mit deinem Programm die UART debuggen zu 
wollen.
Geht die UART in die eine Richtung (wegen der Baudrate), dann geht sie 
auch in die andere Richtung.

[holger (Gast)]

>> Dann liegt der Verdacht nahe das euer PIC gar nicht mit 20MHz läuft.
>wie kann man das am besten nachprüfen?

Lass doch mal eine LED blinken.

[Karl H. (kbuchegg)]

Launga schrieb:
> holger schrieb:
>> Die zweite Version hat bei mir früher mal funktioniert.
>> Dann liegt der Verdacht nahe das euer PIC gar nicht mit 20MHz läuft.
> wie kann man das am besten nachprüfen?

Indem du irgendwas machst, was sensistiv auf die Taktfrequenz ist.
Zb eine LED blinken lassen mittels Warteschleifen (typischerweise 
heissen derartige fertige Verzögerungsschleifen irgendwas mit 'delay').

[Launga (Gast)]

Karl Heinz schrieb:
> Launga schrieb:
>> holger schrieb:
>>> Die zweite Version hat bei mir früher mal funktioniert.
>>> Dann liegt der Verdacht nahe das euer PIC gar nicht mit 20MHz läuft.
>> wie kann man das am besten nachprüfen?
>
> Indem du irgendwas machst, was sensistiv auf die Taktfrequenz ist.
> Zb eine LED blinken lassen mittels Warteschleifen (typischerweise
> heissen derartige fertige Verzögerungsschleifen irgendwas mit 'delay').

Eine Led können wir blinken lassen, dass funktioniert einwandfrei.

[Dominik (Gast)]

holger schrieb:
>>> Dann liegt der Verdacht nahe das euer PIC gar nicht mit 20MHz
> läuft.
>>wie kann man das am besten nachprüfen?
>
> Lass doch mal eine LED blinken.


Diese Variante funktioniert:

while(1)
  {
    if(PORTAbits.RA0==0)
      PORTAbits.RA0=1;
      
    else
      PORTAbits.RA0=0;
return;
}

[Karl H. (kbuchegg)]

Launga schrieb:
> Karl Heinz schrieb:
>> Launga schrieb:
>>> holger schrieb:
>>>> Die zweite Version hat bei mir früher mal funktioniert.
>>>> Dann liegt der Verdacht nahe das euer PIC gar nicht mit 20MHz läuft.
>>> wie kann man das am besten nachprüfen?
>>
>> Indem du irgendwas machst, was sensistiv auf die Taktfrequenz ist.
>> Zb eine LED blinken lassen mittels Warteschleifen (typischerweise
>> heissen derartige fertige Verzögerungsschleifen irgendwas mit 'delay').
>
> Eine Led können wir blinken lassen, dass funktioniert einwandfrei.

Es geht nicht ums Blinken an sich, sondern um die Zeiten.

Wenn du deine Funktion hast, die _delay_ms heisst UND die von der 
Taktfrequenz abhängt UND du das programmierst

  while( 1 )
  {
    LED einschalten
    _delay_ms( 1000 );
    LED ausschalten
    _delay_ms( 1000 );
  ]

und dann die Leucht bzw Dunkelphasen tatsächlich 1 Sekunde lang sind, 
DANN kann man davon ausgehen, dass die Taktfrequenz (die in _delay_ms 
mit eingeht) auch stimmt.

_delay_ms wird auf deinem System anders heissen, aber irgend so eine 
Funktion gibt es meistens.

[Bülent C. (mirki)]

Launga schrieb:
> Karl Heinz schrieb:
>> Launga schrieb:
>>> holger schrieb:
>>>> Die zweite Version hat bei mir früher mal funktioniert.
>>>> Dann liegt der Verdacht nahe das euer PIC gar nicht mit 20MHz läuft.
>>> wie kann man das am besten nachprüfen?
>>
>> Indem du irgendwas machst, was sensistiv auf die Taktfrequenz ist.
>> Zb eine LED blinken lassen mittels Warteschleifen (typischerweise
>> heissen derartige fertige Verzögerungsschleifen irgendwas mit 'delay').
>
> Eine Led können wir blinken lassen, dass funktioniert einwandfrei.

Auch im vorgegebenem INtervall...z.B 1sec an und 1sec aus?

[Bülent C. (mirki)]

> Diese Variante funktioniert:
> while(1)
>   {
>     if(PORTAbits.RA0==0)
>       PORTAbits.RA0=1;
>
>     else
>       PORTAbits.RA0=0;
> return;
> }

Und das Blinkt? :-) Dann hab ihr definitiv keine 20MHz!

[Karl H. (kbuchegg)]

Dominik schrieb:
> holger schrieb:
>>>> Dann liegt der Verdacht nahe das euer PIC gar nicht mit 20MHz
>> läuft.
>>>wie kann man das am besten nachprüfen?
>>
>> Lass doch mal eine LED blinken.
>
>
> Diese Variante funktioniert:

Schön.
Es geht aber nicht ums Blinken selber, sondern um die Zeiten. Die sind 
ein Indikator dafür, ob Zeitberechnungen, die auf den 20Mhz Taktfrequenz 
beruhren auch stimmen. Die LED dienen nur dazu, etwas zu haben, womit 
man die Sache sichtbar machen kann.
ISt ein Delay von 1 Sekunde auf 20Mhz berechnet worden UND ist dieser 
Delay dann auch tatsächlich 1 Sekunde lang (mit der Armbanduhr 
vergleichen) DANN stimmen auch die 20Mhz. Ok, auf das Herz genau kann 
man das nicht bestimmen, aber ob das 20Mhz sind oder doch nur 10, das 
kann man damit schon rauskriegen.

[Karl H. (kbuchegg)]

Launga schrieb:

> hat gemeint in 6
> Wochen


6 Wochen!
Und am Vorabend der Abgabe kommt ihr drauf, dass eure UART gar nicht 
funktioniert?
d.h. in weiterer Folge auch, dass das Programm noch nie getestet wurde!

Gute Nacht.

[holger (Gast)]

>> while(1)
>>   {
>> return;
>> }
>
>Und das Blinkt? :-) Dann hab ihr definitiv keine 20MHz!

Und das "return" sollte ein blinken eigentlich unmöglich machen;)

[Launga (Gast)]

Karl Heinz schrieb:
> Launga schrieb:
>
>> hat gemeint in 6
>> Wochen
>
> 6 Wochen!
> Und am Vorabend der Abgabe kommt ihr drauf, dass eure UART gar nicht
> funktioniert?
>
> Gute Nacht.

Wir sind erst vor zwei Wochen mit der Hardware fertig geworden und dann 
haben wir nur mehr Fehlersuche betätigt und heute wollten wir nochmal 
mit einem Lehrer durchgehen, doch dieser war heute nicht da und nun 
haben wir euch gefragt :)

[Bülent C. (mirki)]

holger schrieb:
>>> while(1)
>>>   {
>>> return;
>>> }
>>
>>Und das Blinkt? :-) Dann hab ihr definitiv keine 20MHz!
>
> Und das "return" sollte ein blinken eigentlich unmöglich machen;)

Irgendwie komme ich mir auch verarscht vor

[Michael L. (michaelx)]

Wie sehen die Config-Bits aus?

Die müssen her!

Wenn ich mich recht erinnere, werden die in den Delays berücksichtigt, 
und der Blink-Test bringt dann u.U. trotz falscher Konfiguration die 
richtige Blinkfrequenz.

[Karl H. (kbuchegg)]

Launga schrieb:
> Karl Heinz schrieb:
>> Launga schrieb:
>>
>>> hat gemeint in 6
>>> Wochen
>>
>> 6 Wochen!
>> Und am Vorabend der Abgabe kommt ihr drauf, dass eure UART gar nicht
>> funktioniert?
>>
>> Gute Nacht.
>
> Wir sind erst vor zwei Wochen mit der Hardware fertig geworden

und du denkst, das kann mich jetzt beruhigen? 4 Wochen um einen 
popeligen 8-Bit PIC auf eine Platine zu kleistern und einen MAX232 
anzuschliessen?
Du reitest dich immer weiter rein.

[Michael L. (michaelx)]

Karl Heinz schrieb:

>> Wir sind erst vor zwei Wochen mit der Hardware fertig geworden
>
> und du denkst, das kann mich jetzt beruhigen? 4 Wochen um einen
> popeligen 8-Bit PIC auf eine Platine zu kleistern und einen MAX232
> anzuschliessen?
> Du reitest dich immer weiter rein.

Ich will es nicht gut heißen, aber: Software ist nichts was man anfassen 
kann. Die hatten vermutlich keinen blassen Schimmer, wie viel Arbeit da 
drinn steckt, und haben in aller Seelenruhe an der Platine gewerkelt.

(Allerdings hätte der Lehrer das sehen und eingreifen können.)

;-)

[Launga (Gast)]

Karl Heinz schrieb:
> und du denkst, das kann mich jetzt beruhigen? 4 Wochen um einen
> popeligen 8-Bit PIC auf eine Platine zu kleistern und einen MAX232
> anzuschliessen?
> Du reitest dich immer weiter rein.

Bauteile bestellen über weihnachten und da haben wir uns nicht gesehen 2 
Wochen, davor schaltplan, programmierung und Labviewprogramm gemacht. 
Nach Weihnachten also 2014 einmal auf dem Steckbrett aufgebaut, dann 
geätzt und dann hardware eingelötet, wir haben einmal in der woche 4 
stunden im labor.

[Michael L. (michaelx)]

Kleiner Tipp an Dominik und Launga:

Wenn ihr diese Nacht noch was sinnvolles machen wollt, schreibt einen 
Antrag auf Verschiebung des Abgabetermins (Begründung nicht vergessen).

;-)

[Boah (Gast)]

Habt ihr nun die Delay Funktion drinne oder nicht ?

[Launga (Gast)]

Michael L. schrieb:
> Kleiner Tipp an Dominik und Launga:
>
> Wenn ihr diese Nacht noch was sinnvolles machen wollt, schreibt einen
> Antrag auf Verschiebung des Abgabetermins (Begründung nicht vergessen).
>
> ;-)

Würden wir gerne,  nur steht alles im Pflichtenheft auch Uhrzeit. Wir 
werden den Lehrer jetzt einfach mit einem Guten Protokoll und einer 
detaillierten Fehlerüberprüfung überzeugen

Und danke für die Hilfe und noch einen schönen Abend ;D

Mfg Launga

[Dominik (Gast)]

Michael L. schrieb:
> Kleiner Tipp an Dominik und Launga:
>
> Wenn ihr diese Nacht noch was sinnvolles machen wollt, schreibt einen
> Antrag auf Verschiebung des Abgabetermins (Begründung nicht vergessen).
>
> ;-)

Besten Dank aber programmieren kann man nur die Bedienungsoberfläche 
funktioniert halt nicht. Mit einer guten Dokumentation, was mir haben, 
wird es schon eine gute Note werden.

@Heinz

Es war unser erstes größeres Projekt, welches wir selbstständig 
erarbeitet haben. Wir wussten es ist eine Herausforderung und die haben 
wir zum größten Teil geschafft. Und wie Launga bereits erwähnt hat, 4 
Stunden jede Woche und das ganze 6 Wochen lang, ein solches Projekt 
fertig zu stellen ist nahe zu unschaffbar, für die die normalerweise 
damit nichts zu tun haben bzw. nur sehr wenig.

@alle anderen

Wollte mal Danke sagen an Alle die geholfen haben oder es probiert 
haben, bin schwer begeistert wie schnell man hier Hilfe bekommt.

[Markus G. (mgebha)]

Noch ein Schnellschuss ohne Blick ins Datenblatt von mir:

- Habt ihr den RX-Pin als Input definiert?
- Habt ihr die ANSEL-Register dafur von analog-in auf digital-in 
gesetzt?

Das war bei mir letztens Ursache eines ähnlichen Problems. Ansonsten 
empfehele ich den Blick ins datenblatt, da ist unter serial receiver 
schritt für schritt erklärt, was man machen muss (umgeht aber die 
bibliothek und setzt die Bits direkt)

[Klaus I. (Gast)]

Karl Heinz schrieb:
> und du denkst, das kann mich jetzt beruhigen? 4 Wochen um einen
> popeligen 8-Bit PIC auf eine Platine zu kleistern und einen MAX232
> anzuschliessen?
> Du reitest dich immer weiter rein

Ruhig Blut Karl Heinz :o)
Wenn ich nichts übersehen habe, hat es hier auch 6 Stunden gedauert bis 
mal das Thema Baudrate/Takt überprüfen angesprochen wurde. ;o)

[Markus M. (Firma: EleLa - www.elela.de) (mmvisual)]

#define USART_BRGH_HIGH   0b11111111  // High baud rate
#define USART_BRGH_LOW    0b11101111  // Low baud rate

Bei 20MHz und 9600 Baud.

Ich kenne jetzt das Datenblatt nicht wie der PIC die Baudrate 
ausrechnet, um die richtig ein zu stellen könnte man darin vielleicht 
auch mal NACHLESEN.

Zum anderen, wenn man ein wenig Google bemüht gibt es sicher auch für 
den PIC jede Menge Baudraten-Rechner sicher Online oder als Excel 
Tabelle.
Ihr habt euch ja richtig Mühe gegeben zur allgemeinen Verwirrung bei zu 
tragen.

In der Regel wird so gerechnet:

20MHz / 9600 = 2083,33

Nun Sampeln* die UART's meist mit 16 Teilungen je Bit oder um eine 
höhere Bautdrate zu erreichen auch mit 8. Dafür ist der Parameter 
USART_BRGH_xxx zuständig.
(*) Zahlen stehen im Datenblatt ich kenne die nicht auswendig.

Somit:
2083,33 / 16 = 130
oder
2083,33 / 8 = 260

Manchmal muss auch noch 1 von den Zahlen abgezogen werden, steht auch im 
Datenblatt.
Microchip schreibt sicher in einer passenden Application Note wie man 
vorgehen muss um einen UART zu nutzen und Microchip hat sicher auch 
passende Demo-Programme in denen man was abschreiben kann.

Erst wenn man diese Möglichkeiten alle Abgeschöpft hat sollte man das 
Forum bemühen - wie man hier sieht ist das Forum kein "Wundermittel".

[Stefan R. (kroko)]

Ich bin auch aus Bez. Mistelbach. Wenn ihr euch etwas früher gemeldet 
hättet, wäre das nicht so das Problem gewesen.
Ich hab gestern Abend leider nicht mehr rein geschaut.