Forum: Mikrocontroller und Digitale Elektronik Welcher Quarz bei PIC 18F2550 mit USB und RS232


von Carsten (Gast)


Angehängte Dateien:

Lesenswert?

Hallo!

Ich habe ein kleines Problem, welches mir Kopfschmerzen bereitet.

In meiner Aufgabenstlellung muss ich mit einem PIC 18F2550 einen USB 
Bootloader bedienen und eine RS232 Kommunikation aufbauen. (eigentlich 
RS485 via SN75176 mit 9 Bits, halbduplex).
Bootloader und RS232 funktioniert soweit, bis auf RS232 Empfang.

Die Signale die in den PIC RX Pin reingehen, habe ich mal angehängt.
Das kuriose ist, das die Daten am Oszi richtig sind, aber am Ende in der 
INT Variable ist das 9te Bit immer gesetzt. Kein FERR oder OERR liegen 
vor.
Ich nutzte Flowcode für die Programmierung. Da ist RS 232 schon fertig 
implementiert.


Was ist da los, kann das ein Timingproblem sein mit 9tem und Stopbit 
o.ä.?
Wie bzw. was muß ich evtl. bei USB und RS232 vielleicht anders 
einstellen.

Konfiguration:

PIC 18F2550, 20Mhz Quarz, PLL am Ende sind das 48Mhz. Ist doch keine 
Baudratenfrequenz oder? Die RS232 Signale, welche vom PIC rausgehen, 
sind auf dem Oszi auch ok!

Habt Ihr noch Ideen?

LG

Carsten

von Carsten S. (dg3ycs)


Lesenswert?

Carsten schrieb:
> PIC 18F2550, 20Mhz Quarz, PLL am Ende sind das 48Mhz. Ist doch keine
> Baudratenfrequenz oder? Die RS232 Signale, welche vom PIC rausgehen,
> sind auf dem Oszi auch ok!
>
> Habt Ihr noch Ideen?

Also die Zeit als man Baudratenquarze brauchte um eine halbwegs 
Timinggenaue Baudrate hinbzubekommen ist lange vorbei! Das war als die 
Taktraten klein waren und man unbedingt so schnell wie mit dem Takt 
möglich die Daten ausgeben wollte (Langsame Datenraten im verhältniss 
zur Taktfrequenz konnte man schon vor fast 20Jahren ohne Baudratenquarze 
innerhalb der Toleranzen ausgeben)

Heutige µC laufen meist viel Schneller als für die üblichen baudraten 
notwendig und können so mittel Timer und Baudratengeneratoren aus einer 
einzigen, immer gleichen, Taktquelle alle gängigen Taktraten mit nur 
kleinem Fehler erzeugen.

48Mhz ist für diesen PIC völlig Richtig, diese Frequenz wird für die USB 
Kommunikation mit dem PIC UNBEDINGT benötigt.

Was Schiefläuft kann man so aber nicht sagen...
Verwendung fertiger Routinen ist immer Super wenn etwas nicht läuft. Wo 
soll man da ansetzen um den Fehler zu finden ???

Was ich sagen kann, das ist das der Pic bei 9Bit Übertragung (die er 
noch kann!) intern mit zwei 8Bit Registern arbeitet. Das 9te Bit steht 
in einem anderem REgister.

Wie jetzt aber aus den beiden 8Bit Registern deine IntVariable wird wo 
die 9Bit komplett sein sollen, das kann nur jemand beantworten der deine 
Entwicklungsumgebung UND die von dir verwendete RS232 Lib kennt.

Aber eines sei direkt gesagt: Flowcode und PIC18F2550... DAS machen nur 
sehr wenige...

ICh würde vermuten das dein Problem entweder in de rInitialisierung 
steckt (der Pic arbeitet beim Transfer im 8Bit Modus) oder aber bei der 
Zusammenführung des 9en Bit aus dem zweiten Register mit den anderen 
8Bit aus dem ersten Empfangsregister liegt.
Soll in deiner Variable überhaupt sofort das komplette 9Bit Wort stehen 
oder ist es erst noch nötig selbst das 9te Bit zu besorgen?

Aber wie gesagt: Alles weitere... Dagegen ist die Glaskugel schon 
Präzise,
Dazu müsstest du Programmcode, Einstellungen und etwas mehr an 
Messwerten veröffentlichen.

Gruß
Carsten

von Carsten (Gast)


Lesenswert?

Hi!

Danke für die Infos,
Etwas genauer geht logischerweise auch:
In der bestehenden Senderoutine wird folgendes abgearbeitet:

#if(RS232_UART_HW == 1)
    if (test_bit(nChar, 8))
      st_bit(txsta, TX9D);
    else
      cr_bit(txsta, TX9D);
    #endif

Das ist das reinodern des 9ten Bit der übergebenen INT Variable.
Gesendet werden auch 9 Bit.
****************************************************************

In der bestehenden Empfangsroutine wird folgendes abgearbeitet:
                retval = 0;
    #if(RS232_UART_HW == 1)
       if(ts_bit(rcsta, RX9D));
       retVal = 0x100;
    #endif
    retVal = retVal | rcreg;

Da ist das reinodern des 9ten Bit in die Return value. Retval bzw. nchar 
ist INT. Soweit auch logisch.
Empfangen werden auch 9 Bit aber das 9te ist immer "1".
Das Oszi zeigt auch top Telegramme, Bit 9 = "0".
Bitzeiten mit exakt 26us.
Deshalb dachte ich an ein Timingproblem zwischen 9ten Bit und dem 
Stoppbit.

Warum meinst Du das mit Flowcode + 18F2550 machen nur weinige - 
schlechte Lösung? Ich finde das mit Bootloader und RS232 eucht super und 
vor allen Dingen mal schnell geändert.

Gruß
Carsten

von Carsten (Gast)


Lesenswert?

Hey!

Die Lösung ist nun da.

Der Hersteller der Programmiersoftware hat in seinem RS232 Makro, einen 
Fehler gefunden.

Hat zur Folge, das das IF Statement immer war ist und das Bit mit 0x100 
immer setzt!

...
if(ts_bit(rcsta, RX9D));
...

muss sein
...
if(ts_bit(rcsta, RX9D))
...
und alles ist tutti!!

Danke

LG
Carsten

von Carsten S. (dg3ycs)


Lesenswert?

Hallo nochmal Namensvetter,

Da das Ursprungsproblem ja gelöst ist... :

Carsten schrieb:
> Warum meinst Du das mit Flowcode + 18F2550 machen nur weinige -
> schlechte Lösung? Ich finde das mit Bootloader und RS232 eucht super und
> vor allen Dingen mal schnell geändert.

Flowcode ist eine der Klassischen Programmiermöglichkeiten für "Laien" 
die nicht die Lust haben sich in C und/oder ASM einzuarbeiten und 
trotzdem einfache Projekte schnell realisiseren wollen.
Praktisch noch einmal eine Steigerung von Basic.

Als Nebeneffekt hat man aber kaum eine Chance auch nur annähernd das aus 
dem µC rauszuholen was mit C oder ASM direkt möglich ist. Und wenn es 
auch nur leicht komplizierter wird, dann endet das schnell in 
Seitenweiser "Malerei".

Zudem möchte ich mal eine Äusserung von Peter Dannegger aus einem 
älteren Thread zum Thema "Flowcode contra 'C'" zitieren:

Peter Dannegger schrieb:
> Die Frage ist auch, wie zuverlässig diese Flowcode-Libs geschrieben
> sind.
>
> Man ist dann quasi in "Gottes Hand", d.h. hat keinerlei Kontrolle, ob
> Bugs drin sind.
Thread: Beitrag "Flowcode contra "C""
Wie richtig dies ist hast du ja gerade selbst erfahren ;-)

Daher ist das absolut nichts für diejenigen die etwas mehr mit µC machen 
wollen, sondern wie schon geschrieben etwas für Einsteiger die schon von 
vornehrein wissen das die nicht wirklich tief in die Materie einsteigen 
wollen oder nur vom Ablauf relativ einfache Programme schreiben wollen.

Natürlich wird es hier sicherlich auch den einen oder anderen von dieser 
Sorte geben. Aber viele sind es halt nichts.

Gegen den Bootloader ist aber im Grunde nichts einzuwenden wenn man denn 
die Absicht hat erst einmal zu lernen/üben und daher viele einfache 
Programme oft ändern und aufspielen will. Das wird durchaus angewendet. 
Insbesondere auf fertigen Entwicklungs-/Experimentierboards.

Wenn es dann später aber um echten Einsatz in Produkte geht wo der PIC 
einmal programmiert wird und dann seinen Dienst verrichtet, dann nimmt 
man natürlich keinen Bootloader mehr, denn ein wenig braucht der ja auch 
an ressourcen.

Wenn du später doch mal etwas in C machen willst:
Auf der Microchip Website gibt es viele Beispiele, darunter auch das CDC 
Serial demo wo eine komplette USB-Serial Umsetzung stattfindet. Ein mit 
diesem Demo bespielter Pic kann also als Ersatz für einen Kommerziellen 
Wandler oder einem dieser FTDI Umsetzer verwendet werden ;-)
Das habe ich auch schon gemacht als ich gerade nichts anderes zur HAnd 
hatte. Und wenn es NUR um RS232 geht, dann gibt es da noch viel viel 
mehr an Beispielen.

(Bei den Beispielen aus dem Framework handelt es sich um 
Universalbeispiele für vershciedene Controller/Entwicklungsboards mit 
unterschiedlichen ConfigEinstellungen die bewirken das dieses PRogramm 
immer passend für den Controller compiliert wird. Die Auswahl der 
Einstellungen erfolgt automatisch anhand der MPLAB Einstellungen. Der 
18F2550 ist dabei nicht berücksichtigt worden. WOhl aber der 18F4550. Da 
der 2550 nur die von der Pinnzahl abgespeckte Version des 4550 ist kann 
man diese Voreinstellungen nutzen.
Man muss dazu in der Datei Hardwareprofile.h den 2550 mit derselben 
Einstellung wie für den 4550 hinzufügen, und in der 
Board/Prozessorspezifischen Profildatie sicherstellen das die richtigen 
Pins definiert werden. (Meist passt es aber von vorneherein.
Bei einigen Beispielen ist der 18F4550 abern icht mit "namen" 
aufgeführt, dann verbirgt der sich hinter dem Abschnitt "PICDEM_FS 
DemoBoard"...;-)
)

Gruß
Carsten

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.