Forum: Mikrocontroller und Digitale Elektronik PIC18F45K20 Taktprobleme


von Torsten (Gast)


Lesenswert?

Hallo liebe Gemeinde,

ich habe ein kleines Problem. Ich versuche derzeit ein 7'' TFT mit einem 
PIC18F45K20 anzusteuern. Klappt auch alles soweit wie gewollt, d.h. ich 
kann das darstellen was ich will. Das TFT arbeitet mit einem SSD1963, 
ich übertrage 24bit Farbe auf einem 8bit Bus.

Für den Entwicklungszeitraum hatte ich den internen Oszillator (16MHz) 
und PLL Enable verwendet, also 64MHz.

Der Bildaufbau war mir aber etwas zu langsam (Ein BMP von 160x480 dauert 
etwa 8 Sec. von einer SD-Card runter), weshalb ich auf einen 100MHz HS 
Oszillator wechseln wollte (Überaktung) Und da habe ich nicht schnlecht 
gestaunt, der PIC lief dann so schnell wie mit einem 16MHz Takt. Ich 
habe andere Quarze probiert, aber alle sind um ein vielfaches langsamer 
als der interne 64MHz Takt.

Kennt jemand das Phänomen? Gibt es bei einem externen HS Oszilator mehr 
als die FOSC Bits zu beachten, damit er ordentlich läuft oder ist der 
PIc in der Lage die Übertaktung zu erkennen und zu "bremsen"?

LG Torsten

von Max H. (hartl192)


Lesenswert?

Torsten schrieb:
> weshalb ich auf einen 100MHz HS
> Oszillator wechseln wollte (Überaktung) Und da habe ich nicht schnlecht
> gestaunt, der PIC lief dann so schnell wie mit einem 16MHz Takt.
Ist das ein Grund- oder ein Oberwellenquarz, mit oder ohne PLL?

Ich hab zwar keine Erfahrung mit dem Übertakten von µCs, da der PIC aber 
nur für 64MHz spezifiziert ist glaube ich kaum dass er mit 100MHz stabil 
läuft. Ich hätte aber eine Lösung für dein Problem:
Ein PIC24EP32GP204 mit 70MIPS, den kannst du mit der gleichen IDE und 
eventuell mit dem gleichen Programmer programmieren...

: Bearbeitet durch User
von Torsten (Gast)


Lesenswert?

Das übertakten sollte in dem Rahmen für den Pic kein Problem darstellen. 
Mich wundert nur, dass er so viel langsamer wird anstatt schneller. 
Vielleicht liegt es aber auch am Steckbrett. Der ds24 klingt gut. Muss 
ich mal prüfen ob der Pickit3 den kann. Und ich muss den xc16 mal 
installieren. Leider gibt es den aber nicht als PDIP . :(

von Max H. (hartl192)


Lesenswert?

Torsten schrieb:
> Mich wundert nur, dass er so viel langsamer wird anstatt schneller.
Hast du mal nachgemessen ob der Quarz auch wirklich mit 100MHz schwingt?

von Torsten (Gast)


Lesenswert?

Mein Oszi macht nur bis 60Mhz, werde mir morgen mal einen Frequenzteiler 
aufbauen und nach messen.

von Somebody123 (Gast)


Lesenswert?

Hallo,

prüfe doch deinen tatsächlichen Clock mal nach. Z.B. indem du einen 
Timer aufsetzt, der z.B. jede eine LED toggelt. Das kann man noch gut 
mit einer Uhr mit Sekundenzeiger nachprüfen (danebenhalten).

Sowas klingt aber eigentlich stark nach einem Flaschenhals in der 
Datenübertragung irgendwo zwischen SD-Karte und Display.
Ist das der Fall, bringt das ganze Übertakten des Kerns natürlich 
nichts, denn wenn die SPI oder wasauchimmer zur SD-Karte die Daten nicht 
herschafft. Da müsste man am IO bzw. Bustakt 
(SPI/SD-Interface/wasauchimmer) drehen.

Im Übrigen klingt sowas eher nach einer Aufgabe für einen kräftigeren 
32bit-Controller z.b. den PIC32MX250F128B, der dürfte einer der 
schnellsten PIC fürs Breadboard sein (83 MIPS). Programmieren geht mit 
MPLABX und dem XC32, der Umstieg von PIC16/24 ist nicht allzu groß (C 
vorausgesetzt).

Denk auch über DMA nach - das kann solche Bulk-Transfers enorm 
beschleunigen (bzw. eher den µC entlasten). Der genannte PIC32 hat 4 
DMA-Kanäle für sowas.

von Torsten (Gast)


Lesenswert?

Dank euch erst mal.

Wollte eigentlich mit einem "kleinen" 18F die Geschichte 
bewerkstelligen, da ich dachte der genügt. Nun habt ihr mich aber 
überzeugt....

Dennoch:
Also, der interne 4x16MHz Takt ist korrekt. Die Daten von der SD werden 
im RAM zu Blöcken von 512Byte gepuffert. Beim Bildaufbau ist keine 
Verzögerung durch die Pufferung zu bemerken. Daher denke ich ist die SPI 
Stecke zur SD nicht das Problem. Ist zwar eine SoftSPI aber dennoch fix 
genug so wie es aussieht.

Die Routine für den Bildaufbau (BMP Interpreter) selbst ist durch die 
Free-Version von XC8 ohnehin stark verstümmelt und könnte dadurch 
einiges an Tempo verloren haben.

Mich wundert in dem Zusammenhang eben nur, dass der externe Oszillator 
(habe 100MHz, 36MHz, 16MHz und 10MHz mit und ohne PLL getestet) stets 
langsamer ist als die internen 64MHz. HSPLL mit 100MHz Quarz (also 
eigentlich 400MHz) war gerade mal annähernd so schnell wie der interne 
64MHz Takt. (????)

Kann ein unrundes Schwingen durch das Breadbort entstehen?? Ich glaube 
ich hatte ein ähnliches Problem vor einigen Jahren schon einmal bin mir 
aber nicht sicher.

-----

Werde jetzt wie oben angedeutet den Versuch machen und den Controller 
wechseln. Habe mich für den 32MX440F512 entschieden. Da der 250er nur 28 
Pinner ist und ich doch einiges mehr brauche.

- 4 I/O SPI SD
- 4 I/O SPI Touch
- 4 I/O SPI zur Hauptplatine
- 8 I/O Daten TFT
- 6 I/O Steuerleitung TFT
- 2 CLK
- 4 Vdd/Vss
- 2 I/O LED's
- 2 GPIO's

der 32MX440 bringt zudem auch USB mit, da kann ich in diese Richtung 
auch noch ein wenig Experimentieren. :)

Und zum Thema DMA werde ich mich auch noch ausführlich schlau machen. 
Hab noch nie damit gearbeitet obwohl die Vorteile für mich wohl offen 
auf der Hand liegen.

Hab jetzt erst mal 2 von den kleinen Kerlchen und ein paar SMD TQFP 
Breakboards gleich dazu bestellt. Werde jetzt erst mal abwarten bis 
alles da ist und mich derweil mit XC32 vertraut machen. Hoffe mein 
PicKit3 kann die Teile programmieren....?!

von Michael S. (rbs_phoenix)


Lesenswert?

Der Witz von SPI ist doch, dass man einen BUS für mehrere Devices hat. 
Wieso also 3 getrennte SPI Busse? Selbst wenn da ein Argument für 
spricht, wären es 3 IOs, da man bei einem Device i.d.R. keine /CS 
Leitung braucht

Zum PLL fällt mir ein: Er besteht unter anderem ja aus einrm VCO, also 
Voltage controlled oscillator. Was denn, wenn der nur so viel Spannung 
annimmt, das 64 MHz rauskommen? Wenn beispielsweise 400MHz 4V 
entspräche, der Eingang aber auf 0.64V begrenzt ist.

Ich wäre beim übertakten auch vorsichtig. Dann betreibst du ihn mal 
anders , (z.B. nicht mehr aufm Steckbrett) und aus irgend einrm Grund 
gehts nicht mehr (100% ig)...

Ach ja. Ansich sollte das PICKIT3 jeden PIC programmieren können.

: Bearbeitet durch User
von X4U (Gast)


Lesenswert?

Torsten schrieb:
> Gibt es bei einem externen HS Oszilator mehr
> als die FOSC Bits zu beachten, damit er ordentlich läuft oder ist der
> PIc in der Lage die Übertaktung zu erkennen und zu "bremsen"?

Dein 100 Mhz Xtal ist vermutlich ein Oberwellenquarz und der Pic läuft 
auf der Grundwelle .

Besser einen Quarzoszillator zum testen nehmen.

Es macht aber eher Sinn eine Hardware SPI zu nutzen. Die braucht 0 
(null) Taktzyklen des Prozessors zum bit_schieben.  Der kann sich in der 
Zeit um anderes kümmern.

von Torsten (Gast)


Lesenswert?

Tatsächlich.... Ist ein Oberwellenquarz. Daran hätte ich ja zu aller 
letzt gedacht....

Die Sache mit den getrennten SPIs ist aus der Entwicklung heraus so 
gewachsen. Hab es mir da mit der Software etwas leicht gemacht, da sie 
"quasi" zeitgleich arbeiten. Mit dem 32er werd ich das gleich zu Beginn 
ändern und auch die Busbreite zum TFT auf 16bit hoch schrauben. Im 
besten Falle entfällt bei dem "Leistungsschwein" der zweite Controller 
auf der Hauptplatine und ich fasse die beiden gleich zusammen.

Mit dem Übertakten hatte ich beim 16f877 nie Probleme. Bis 150% lief er 
immer noch stabil und lies es sich auch gefallen. Denke das lässt sich 
der 18f auch gefallen.... Ja wenn man denn den richtigen Quarz nimmt. :)

Danke euch wie verrückt für eure Beiträge, habt mir einen dringend 
benötigten Schubs in die richtige Richtung gegeben. Hänge schon viel zu 
lange bei den 8 bittern rum. ;)

Gruß Torsten

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.