mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik XC167 Interrupt zu langsam


Autor: Johannes (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Norbert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sieh' Dir mal den dissasemblierten Code der Interruptroutiene an.

Da siehst Du wo evtl. der Overhead liegt.


Norbert

Autor: Johannes (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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???

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Johannes (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Oryx (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Norbert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Johannes (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Johannes (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Johannes (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Johannes (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.