Hallo, programmiere mit dem neuen XC167 von Infineon. Habe da einen Fast Interrupt programmiert. Nun ist es so, dass dieser viel zu langsam ist. Setzte in der Interruptroutine ein Füschen hoch. Bis dieses kommt, vergehen 600ns. Bischen lang oder? Bei 40Mhz sind das 24 Befehle. Oder täusche ich mich jetzt und das ding ist wirklich so langsam? was meint ihr?? Danke Johannes
Sieh' Dir mal den dissasemblierten Code der Interruptroutiene an. Da siehst Du wo evtl. der Overhead liegt. Norbert
Naja, mein Problem besteht aus zwei Problemen, eigentlich. Also erst mal noch mal eine genaue Beschreibung was ich machen will: -Wenn P2_P8 nach unten geht, dann soll ein Fast Interrupt ausgelöst werden. -Dieser Interrupt setzt als erst P9.4 auf High. -Dann arbeitet er ab was er machen soll(Daten empfangen und senden) -Während er das macht, geht P2.8 auf High und dann wieder auf Low =>Request ist wieder also wieder da. - Dann setzt er P9.4 auf Low So, die Interrupt Routine hat 15 Befehle und der Controller läuft mit 40MHz. Der XC kann ein Befehl pro Takt. Das sind 25ns*15 Befehle = 375ns. Da der Interrupt ein Fast Interrupt ist, müsste er in einem Takt wieder kommen = 25ns. So, habe jetzt mit dem Oszi mal das Signal gemessen. Es ist 1us auf High und 720ns auf Low. Brauche aber unbedingt, volle geschwindigkeit, wass soll ich denn jetzt machen???
Hallo Johannes! Ich weiß zwar nicht was du dagegen machen kannst, aber ich habe schon mal sowas mit dem alten C167 programmiert und die Zeit gemessen. Gemessen wurde mit dem Oszi das Eingangssignal, welches den IRQ auslöste und jenes Signal, welches nach Einsprung in die IRQ-Routine vom Kontroller invertiert wurde. Bei 20MHZ kam folgendes heraus: Normaler IRQ: 1,53 µs Schneller IRQ: 1,33µs Ich habe auch gerade mit dem XC167 begonnen. Vielleicht könnten wir ab uns zu unsere Erfahrungen austauschen. Tschüss! Martin
Hallo Martin.
Dass meine InteruptRoutine zu lange braucht, passt schon.
Rechenfehler!weil ich noch warte bis USB frei ist, zum senden. passt
also schon.
Tja, und wenn du sagst das hat auf dem C167 1,33us gebraucht, und jetzt
800ns, dann könnte das so natürlich passen, aber in meinem C167
Dateblatt steht was von 400ns. Kommt natürlich auf den Speicher an den
du verwendet hast. So, jetzt ist es aber so, dass mein Programm im
internen Flash läuft, das heist, dass ich in nur einem Takt
normalerweise einen Befehl ausführen kann. Da aber nach einem Int die
Pipeline leer ist, also wenn ich nochmal neu rechne, dann brauche ich
25 ns um Interrupt zu sampeln
5*25 ns um Pipeline zu füllen
-----------------------
150ns lass es das doppelte sein, ok, aber 800ns.
also, werd mal weiter probieren
johannes
p.s. klar können wir uns austauschen.
p.p.s entwickle mit keil und dave
Hi, ist euer Controller wirklich so schnell, das er für einen Befehl nur einen Takt braucht. Andere Controller brauchen für ein nop einen Takt und bei aufwendigeren Befehlen geht der Spass erst richtig los. 6 oder 8 Takte sind nicht viel. Wenn es bei Infineon wie in alter Siemens Manier läuft, würden mich auch 10 bis 15 Takte nicht wundern. Oryx
1 Befehl = 1 Takt = 25nanoSek.@40MHz Coreclock. Wenn das Forwarding im Rechenkern jedoch erkennt, daß, z.B. auf das Register R4 jeden 3.Befehl zugegriffen wird, so werden hierzu 0-Takte (in Worten Null-Takte = 0ns) benötigt. Bedingten Sprünge dauern ebenfalls 1 Takt. Möglich wird dies durch eine 5-stufige Pipeline, durch die alle Befehl müssen. Dieses hochgezüchtete Verhalten hat jedoch einen Nachteil: Es ist nicht mehr Vorhersehbar wie lange eine Programmsequenz dauert. Norbert
Hallo, bist du sicher dass bedingte Sprünge einen Takt brauchen? Wenn ein bedinger Sprung geladen wird, dann kommt doch die Sprungvorhersage, und wenn die richtig vorhersagt, wird in der Pipline der Sprung gleich geladen, und der Jump fällt weg. Hat sich die Sprungvorhersage allerdings geirrt, dann kannst du die ganze pipeline nachladen=125ns. oder täusche ich mich da? Johannes
Hallo @Johannes: Mir kommt das Ganze auch einwenig langsam vor. Damals beim C167 hatte ich ja auch externes Flash. Prozessoren mit internem Flash war eigentlich nicht zu bekommen. Eine Frage habe ich noch. Machst du gerade eine Anwendung mit USB? Kannst du die bitte näher beschreiben, denn USB interessiert mich unheimlich. Schreibst du dafür selbst den Treiber für den PC? .... Zu deiner letzten Frage: Auch ich habe das so verstanden mit der Sprungvorhersage, darum glaube ich das es richtig ist, was du sagst. @Oryx: Ich glaube, dass es einer der Leistungsfähigsten 16BIT Kontroller überhaupt ist. Eine 16*16Bit Multiplikation schafft er in einem Maschinenzyklus. Die Division wird in 19 Maschinenzyklen ausgeführt, wobei nur die ersten 4 erkennbar ausgeführt werden. Das Ergebnis ist erst nach weiteren 15 Zyklen verfügbar. Durch die Jump Prediction-Einheit können Sprungbefehle quasi ohne Zeitverlust in 0 Maschinenzyklen ausgeführt werden. Außerdem besitzt der Prozessor einen Clock-Generator mit dem die Frequenz softwaremäßig eingestellt werden kann. Wenn man z.B. einen 8MHZ - Quarz anschließt können damit verschiedenste Frequenzen für den Prozessor erzeugt weren. z.B.: 20,25,33 ... MHZ. Meine Persönliche Meinung: Ich finde es toll, dass der neue Prozessor endlich ein internes Flash hat (128KByte). Außerdem wurde endlich an eine Hardware-Debugger-Schnittstelle gedacht, mit der man den Prozessor auch flashen kann, wenn man möchte. Oder man flasht ihn über die serielle Schnittstelle. Was finde ich weniger gut: Ganz klar die Dokumentation könnte noch um einiges übersichtlicher und besser gestaltet werden. Man hat hierfür das Datasheet und zwei User-Manuals. Man kann den Prozessor, je nachdem welchen Portpin man zu Beginn auf low oder high zieht, verschieden konfigurieren. Z.B. Bootstap-Modus ein oder aus, starten vom internen oder externen Flash usw. Nur welcher Pin einen Pull-up oder einen Pull-down hat sucht man in den drei Büchern vergeblich (Pech gehabt auch im Datasheet steht davon nichts, obwohl dort eigentlich die Portpins beschrieben werden). Hierfür gibt es auf der beigelegten CD irgendwo ganz verstreut und versteckt andere Dokumentationen, die sich vorsichtig an das Thema rantasten, ohne zuviel zu verraten. Ich programmiere auch Atmel-Prozessoren und ich finde, dass in diesen Datenblätter viel besser auf den Hardwareentwickler eingegangen wird. Und viele Abbildungen erleichtern das Ganze. Alle wichtigen Antworten auf viele Fragen sind dort leicht zu finden: Wie schließe ich den ADC an? Wie kann man den Prozessor selbst flashen? Wie schließe ich den Quarz richtig an? usw. So, jetzt habe ich meinem Frust freien lauf gelassen. Ich bin aber froh, dass ich mich in dieses Thema eingearbeitet habe, denn was man kann das kann man. Trozdem bleibt der XC167 eine tolle Sache. Tschüss! Martin
Ach ja! Noch was: Der Prozessor benötigt jetzt zwei Versorgungen. 5V für die Pinversorgung und 2,5V für den Prozessor selbst. Dafür ist er auch um ca. 1/3 kleiner als sein Vorgänger bei einer Pinanzahl von 144. Martin
Hallo, schreibe gerade an meiner Diplomarbeit. Thema ist eigentlich USB. Und gleichtzeitig soll dabei ein bischen rauskommen, was der XC167 kann. Habe 2 USB Chips bestellt. ISP1581 von Phillips. USB 2.0 und sonst auch voll die eierlegende Wollmilchsau. Habe angefangen Firmware zu schreiben. Fazit: -sehr zeitaufwendig -entwicklung ohne teueren USB Analyzer nicht möglich -keinen mehrwert, können Perfomance nicht nutzen -Chip für den Pc-Markt(Lebenszeit) So, habe jetzt den FT245BM von FTDI, da muß man keine Firmware schreiben, sondern nur in das FIFO schreiben. Mache da jetzt Geschwindigkeitsanalysen. Problem ist der 8 bit Datenbus. Also, man bringt die Daten nicht schnell genug aus dem FIFO wie der USB sie senden kann. Wenn du was wissen willst. kein problem. Achja, was die Datenblätter anbelangt, kann ich dir zustimmen Johannes
Hallo Auch ich halte mir die Problematik der kurzen Lebenszeit ständig vor Augen und versuche Alternativen zu finden. Ich finde die RS232 toll, da sie sich bewährt hat und einfach aufzubauen ist. Auch wenn sie nicht hardwaremäßig vorhanden ist kann sie leicht softwaremäßig nachgebildet werden. Und wenn man ab und zu mal einen Messwert übertragen muss ist sie schnell genug. Ich programmiere meine Atmel-Prozessoren über die Serielle. Das Problem besteht darin, dass viele Rechner nur noch eine Serielle haben. Manche Notbooks haben überhaupt keine mehr. Aus diesem Grund habe ich mir ein USB-RS232 Wandler-Kabel besorgt, um Mobil bleiben zu können. Mein Problem sehe ich in der parallelen Schnittstelle. Ich habe noch kein Kabel gefunden, dass von USB auf Parallel wandelt. Nur USB-Kabeln, die man an einen parallelen Drucker hängen kann habe ich gefunden. Aber ich weiß nicht, ob man das Kabel auch als parallele Schnittstelle nutzen kann. Ich brauche die Parallele für das neue XC167 Board von Infineon. Der on BOARD-Debugger lässt sich nur mit der Parallelen ansprechen. Es gibt auch Debugger über USB, aber die sind teuer. Dann gibt es noch diesen parallelen Hardware-Dongle vom Compiler-Hersteller.). Deshalb bin ich froh, in die Mikrokontroller-Technik eingestiegen zu sein, da hier die Entwicklung nicht ganz so sprunghaft ist. Und wenn die Hardware oder Software einmal nicht einwandfrei funktioniert kann man sich selbst bei der Nase nehmen. Martin
Hi.
Naja, eben das mit den Notebooks istein Problem. Mancher Kunde will
eben ein Notebook an die Maschiene anschliesen. Ausserdem, bringt der
USB geschwindigkeitsvortele.
So, nochmal zum XC. Entwickle mit Keil, programm läuft im Flash.
Debugge im Flash.
So, jetzt folgendes Programm:
#define USB_ADR (*((BYTE volatile huge *) 0x210000)) //Adresse
USB-Chip
...
volatile BYTE EmpfangenesByte;
...
do{
if(!IO_ubReadPin(P6_P7))
{
EmpfangenesByte=USB_ADR;
USB_ADR=EmpfangenesByte;
};
}while(EmpfangenesByte!=0x03);
So, also das ist ein Echo. Alles was ich aus dem FIFO lese, schreibe
ich zurück und sende es an den PC, solange bis das Zeichen ETX kommt.
So, funktioniert ganz gut,solange das Programm normal läuft. Nur wenn
ich debugge, wird nur jedes zweite Byte übertragen. Auf dem
Logicanalyzer sehe ich, das auf USB_ADR zugegriffen wird, wenn ich auf
die Zeile <i>EmpfangenesByte=USB_ADR;</i> Springe, und nochmal wenn ich
von ihr weg springe. Was mache ich falsch??
johannes
OK! Also, wenn ich das richtig verstehe hast du einen FIFO-Speicher an den EBC-Kontroller angeschlossen und du hast diesen Speicher auf die Adresse 0x210 000 gelegt. Also dieser Speicherbereich sollte frei sein. Der Bereich liegt nach dem CAN. Debuggst du über die Serielle oder über die Hardware-Debugger-Schnittstelle? Den Hardware-Debugger habe ich mir noch nicht so richtig angesehen. Aber dafür den seriellen Debugger, da ich diesen auch beim C167 benötigte. Bei mir gab es beim seriellen Debuggen folgendes Problem als ich ein externes Ram ansprechen wollte: Ich legte es in einen ähnlichen Speicherbreich. Doch bei mir funktionierte das Programm überhaupt nicht richtig. Ich kam dahinter, dass der Debugger anscheinend nur bis zur Adresse 0x80 000 reicht. Dies kann man in folgender Option erkennen: Option for target - Debug - Keil Montor 166 driver - settings - Infineon XCBoard Dort steht folgendes: BOOTSTRAP MODE ============== Memory map: 00:0000h - 00:7FFFh free RAM 00:F000h - 00:FFFFh on-chip RAM and SFR's 01:0000h - 07:E9FFh free RAM 07:EA00h - 07:EBFFh RAM used by Monitor (Data Area) 07:EC00h - 07:FFFFh RAM used by Monitor (Code Area) Als ich den externen Speicher auf eine niedrigere Adresse schob funktionierte es plötzlich einwandfrei. Es kann sein, dass es bei dir ein ähnliches Problem gibt. Martin
Hallo, es könnte sein, dass der Debugger das FIFO auch noch ausliest(ist halt neugierig), und dadurch geht dann jedes zweite byte verloren. Die Einstellungen die du beschreibst, gibt es bei OCDS leider nicht. Naja, habe es jetzt so gelöst, dass ich naxch der whileschleife einen breakpoint mache, und dann darüber gehe, dann funktioniert es auch. habe aber das gefühl, dass die technik wohl noch nicht ganz ausgereift ist. danke für die hilfe. johannes
Ich bin derselben Meinung! Aus diesem Grund benutze ich nur den Simulator. Wenn ich ein Programm wirklich testen möchte, so flashe ich es gleich direkt im Compiler runter. Es ist bei einer Programmentwicklung sowieso besser, das Programm zu oft zu testen als zu wenig. Jedesmal, wenn ich einen neuen Schritt programmiert habe teste ich diesen gleich aus. Mir ist da mit dem Debugger zu aufwändig. Man muss hierfür extra die gesamte Speicherkonfiguration ändern. Das ist mir zu dumm. Martin
Thread beobachten
Seitenaufteilung abschaltenBitte 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.