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
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
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
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
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
DSCI0071.JPG
(31 KB)
