Hi heute wollten wir mal testen wie schnell die PICs tatsächlich sind, darum haben wir ein C-file (in CCS) geschrieben. Es schaltet prinzipiell einen Pin auf high und dann ohne verzögerung wieder auf low. Ich versorge den PIC mit 12MHz, aber wie wir dann mit dem Oszi gemessen haben, kam am Pin nur eine frequenz von 500kHz raus?!?! irgendwie ist mir das zu langsam! was kann es denn da haben? while (1) { output_high(PIN_B1); output_low(PIN_B1); } mfg schoasch
Das ist abhängig davon, was der Compiler daraus macht, außerdem davon, wieviele Quarzzyklen ein Befehl benötigt. Wenn ich mich recht erinnere, wird die Quarzfrequenz im PIC durch 4 geteilt, dann haben wir eine "Befehlsfrequenz" von 3 Mhz. Ein Befehl zum Einschalten, einen zum Ausschalten - schon haben wir nur noch 1,5 Mhz. Der nun übrige Verlust im Rahmen von Faktor 3 könnte durchaus auf Sprungbefehle zurückzuführen sein. Ist also garnicht so verwunderlich. (nein, ich werde jetzt nicht schreiben, daß der Atmel schneller ist ;-))
sind die AVRs schneller? bzw weisst du einen extrem schnellen AVR für den es auch einen C-Compiler gibt? Bis jetzt haben wir mal mit einem 89C4051 und 89C52 maximal 1MHz zusammengebracht. aber nachdem der PIC den ich benutze bis 48MHz geht und ich somit mit 1/4 der maximalen frequenz gefahren bin, würde er dann bei 48MHz auf 2Mhz kommen, was ja auch noch zu langsam ist ;-)... oda zumindest wäre es mit schneller lieber ;-) mfg schoasch
Was soll der PIC denn sonst noch machen ? Wenn er nur mit Pin toggeln beschäftigt ist geht das mit reiner Hardware wesentlich schneller. Gruß Dieter
das war ja nur ein kleiner test. der PIC soll nachher in einer etwas grösseren schaltung verwendet werden wo er dann rechnen muss und danach eben die Ports setzen muss... also das ist dann mit reiner hardware nicht mehr möglich ;-).. naja möglich schon.. aber wäre zu kompliziert ;-)
Das schreit doch geradezu nach einer Hybrid-Lösung, PIC plus ein paar Krümel Hardware. Das Problem mit den µC's ist bei so schnellen Vorgängen meistens auch die zeitliche Auflösung (1, 2 oder 4 Quarztakte) und das Laufzeitverhalten des Programms ist mit C auch nicht besonders gut beherrschbar. Ein externer Timer in Hardware tut sich da doch etwas leichter. Dieter
Im endeffekt wirds ja eh eine hybridlösung ;-). aber 500khz sind ja nicht gerade die welt. da könnt ich gleich mit dem I²C bus arbeiten (langsame version). aber ich würde gern mit SPI arbeiten, da meine Bauteile bis zu 26MHz bustakt schaffen. und diese will ich ausnutzen ;-) oder zumindest mit der 1,6MHz variante arbeiten. naja.. der langen rede kurzer sinn... mit den Fuses ist das so eine sache ;-)... hab die jetzt etwas anderst gestellt und bin nun auf 2MHz gekommen. Also es wird :D
Ich arbeite auch häufig mit PIC (18F252), und benutze die integrierte SPI Schnittstelle, aber im Augenblick bin ich zu faul im Datenblatt nachzusehen welche Taktfrequenz man da rauskriegt. Meine Anwendungen laufen aus Stromspargründen oft mit 4MHz Quarz, da kommt es auf die SPI Geschwindigkeit nicht an. Dieter
Wie schnell der PIC (oder auch jeder andere Prozessor) den Pin Togglen kann ist zur Beurteilung der Prozessorgeschwindigkeit völlig irrelevant. Vor allem wenn man ein C-Programm verwendet, wo der Compiler vor jedem Ausgabenbefehl das Port-Richtungs-Register (TRISB) umsetzt oder habt ihr die Option #USE FAST_IO verwendet? Ein Blick in das generierte ASM-File bringt da schnell mal Klarheit. Die SPI-Schnittstelle läuft übrigens maximal mit Fosc/4 also 12MHz bei 48MHz.
Das Problem ist nur das ich kein asambler kann und es mir auch nicht beibringen will.. zumindest im moment. Ich setzte nich vor jedem Befehl die richtung des Registers, denn sie sind nur ja nur zus ausgabe also reicht das wenn ich sie einmal setze. was passiert eigentlich wenn ich einem µC eine zu hohe taktfrequenz zuführe? also zb statt 20MHz halt 24Mhz oda so?
> was passiert eigentlich wenn ich einem µC eine zu hohe taktfrequenz > zuführe? also zb statt 20MHz halt 24Mhz oda so? Er verbraucht mehr Strom und wird wärmer. Für den Fall, daß die höhere Frequenz außerhalb der Spezifikation liegt, kann es pasieren, daß einzelne Hardwarekomponenten nicht mehr funktionieren.
@Schoaschi Ihr verwendet CCS-spezifische Sonderfunktionen. Ohne die Direktive #use Fast_IO wird durch die Sonderfunktion output_high(PIN_B1); das Richtungsregister entsprechend dem Befehl gesetzt, was natürlich auch "Rechenzeit" braucht. Wie es wesentlich sinnvoller, einfacher und vor allem für alle Compiler (fast) kompatibel geht findest Du z.B. hier --> http://www.fernando-heitor.de/picforum/viewtopic.php?t=1268
Wenn Schnelligkeit so wichtig ist, warum dann C? Dann musst du auch die Programmierart nehmen, die am schnellsten ist. bsf PORTB,1 ; 1 Takt bcf PORTB,1 ; 1 Takt goto $-2 ; 2 Takte 1 Takt = 1/fosz*4
Wenn Schnelligkeit so wichtig ist, warum dann C? Dann musst du auch die Programmierart nehmen, die am schnellsten ist. Richtig! bsf PORTB,1 ; 1 Takt bcf PORTB,1 ; 1 Takt goto $-2 ; 2 Takte 1 Takt = 1/fosz*4 So geht es noch ein bischen schneller! xorwf PORTB,1 ; 1 Takt goto $-1 ; 2 Takte Wenn ich allerdings Bit Spi o.ä. programmiere, dann nehme ich keine Schleife sondern schreibe das 10 mal untereinander und spare die Zeit für den Rücksprung. MfG Manfred Glahe
Vergeßt das mal wieder, geht nicht! So geht es noch ein bischen schneller! xorwf PORTB,1 ; 1 Takt goto $-1 ; 2 Takte Schade!
Die neuen Atmels 48 und seine Freunde können 20Mhz und besitzen die Funktion, wenn man in das PIN-Register schreibt, dass der Pin getoggelt wird. Ein SBI (also Bit setzen) kostet normalerweise 2Takte. Ich weis nicht, wie schnell das toggeln ist, aber so kommt man dann ungefähr auf 5MHz.. also 20Mhz/2*2 dave
@Schoaschi Wenn Du mit einem µC - ganz gleich ob PIC, Atmel oder anderer - einen anderen Baustein über SPI ansprechen willst, und das auch noch möglichst schnell, bleibt nur die Verwendung der integrierten SPI Schnittstelle. Mit Assembler tut man sich da im Allgemeinen etwas leichter weil für diesen Fall nur selten Standard C Routinen zur Verfügung stehen. Ich habe vor ca. 3 Jahren mal angefangen für PIC18C252 ein Programm in C zu schreiben. Da das Zeitverhalten nicht vernünftig in den Griff zu bekommen war, wurde schlussendlich doch wieder auf Asm zurückgegriffen. Als Nebenwirkung war das Prg dann auch nur noch etwa halb so groß. Dieter
Ich glaube ich werde mir zwangsweise eh einmal ASM lernen müssen, jedoch kenne ich mich mit C recht gut aus ( ein bisschen basic kann ich auch,aber ich habe irgendeine abgneigung gegen diese sprache). ich hab mal kurz in asm reingelesen. dürfte nicht so schwer sein jedoch hab ich momentan etwas anderes zu lernen (hab gerade matura ;-) ) und so manche befehle sind mir noch nicht so ganz klar... abver was nicht ist kann noch werden. achja und die µC die ich benutzen haben SPI und I²C schon integriert. kann mir vl jemand einen link empfehlen wo die handhabung der USB schnittstelle gut beschrieben ist, und wie ich dann über windows daruaf zugreife bzw wie der PC dann den Controller erkennt? das hab ich noch nicht so ganz gecheckt. DANKE SCHOASCH
"kann mir vl jemand einen link empfehlen wo die handhabung der USB schnittstelle gut beschrieben ist, und wie ich dann über windows daruaf zugreife bzw wie der PC dann den Controller erkennt? das hab ich noch nicht so ganz gecheckt." Bei Microchip gibt es ein paar Beispielprojekte zum Thema USB. Hier geht es unter anderem darum --> http://www.fernando-heitor.de/picforum/viewtopic.php?p=6121#6121. Mit C kannst Du eigentlich fast ganauso effiziente Programme schreiben, wenn Du den Controller richtig kennst. Wenn Du aber einmal in ASM programmiert und die Arbeitsweise des Controllers kennst ist das Ganze wesentlich einfacher. MfG
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.