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
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...
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 . :(
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?
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.
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....?!
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.
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.
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
