Hi, ich habe hier einen PIC32MX350. An diesem stehen (unter anderem) zwei Signale an, die jeweils einen eigenen Interrupt auslösen. Zu Testzwecken habe ich in meinen Interrupt-Serviceroutinen nichts weiter als je einen Zähler, mit denen ich ermittle, wie oft der jeweilige Interrupt aufgetreten ist. Das eine Signal (ein Clock) sollte dabei 22 mal auslösen währen das andere (Synchronisation) ein mal auslöst. Sprich nach einer gewissen Laufzeit sollten die beiden Zähler dieses Verhältnis von 22:1 darstellen. Mein Problem: Das Verhältnis liegt bei ca 5:1 (es ist tatsächlich ein krummer Wert, das Verhältnis scheint also noch nicht mal stabil bei immer 5:1 zu liegen). - wenn ich mit dem Oszi die beiden Eingangssignale überprüfe, sind diese vollkommen in Ordnung, es ist auch kein Noise auf den Leitungen - wenn ich die Sync-Leitung (also die mit dem Verhältnis :1) abklemme, dann wird der zugehörige Interrupt gar nicht mehr ausgelöst, es existiert also kein anderes Signal, das dort hineinstreut. Da ich momentan eher komplett ratlos bin, ist jede noch so abgwegige Spekulation willkommen: was könnte die Ursache für dieses dubiose Verhalten sein? Was könnte hier möglichwerweise schief laufen? Danke!
Narvik schrieb: > - wenn ich die Sync-Leitung (also die mit dem Verhältnis :1) abklemme, > dann wird der zugehörige Interrupt gar nicht mehr ausgelöst, es > existiert also kein anderes Signal, das dort hineinstreut. Wie schaut den die andere Sichtweise (auf CLOCK) aus: ist denn HW und SW überhaupt in der Lage, die gewünschte, mehr als 5fache Menge (22:1 statt 5:1) der CLOCK-impulse ISR seitig zu verarbeiten? Von was für Frequenzen reden wir denn überhaupt? Vg Stephan
Allenfalls waere etwas mehr Info, zB was ist aussen angehaengt, Schema, Bild vom Aufbau, usw hilfreich.
Angehängte Dateien:
-
mcc_clock.png
14 KB
Stephan schrieb: > Wie schaut den die andere Sichtweise (auf CLOCK) aus: ist denn HW und SW > überhaupt in der Lage, die gewünschte, mehr als 5fache Menge (22:1 statt > 5:1) der CLOCK-impulse ISR seitig zu verarbeiten? Interessante Idee eigentlich! Der Aufbau sieht so aus: Das Clock-Signal hängt an den Eingängen D8 und D9. Dort löst es INT1 und INT2 aus, die auf die positive und negative Flanke des Clock-Signals reagieren. Es gibt etwa alle 180 nsec eine Flanke. Der PIC läuft mit 96 MHz (siehe MCC-Konfiguration im Anhang). Das entspricht dann etwas 17 Taktzyklen pro Interrupt - was meiner Meinung nach locker reichen sollte, um einen Zähler zu inkrementieren und das Interrupt-Flag zu löschen?
Narvik schrieb: > as entspricht dann etwas 17 Taktzyklen > pro Interrupt - was meiner Meinung nach locker reichen sollte, um einen > Zähler zu inkrementieren und das Interrupt-Flag zu löschen? Ziemlich knapp, hast du dir mal die Interrupt Latenz angeschaut? Die Frage wozu man einen Prozessor nimmt wenn der eh nur noch Interrupts abarbeitet ist etwas off topic. Die Antwort würde mich aber interessieren.
Narvik schrieb: > Das entspricht dann etwas 17 Taktzyklen > pro Interrupt - was meiner Meinung nach locker reichen sollte, um einen > Zähler zu inkrementieren und das Interrupt-Flag zu löschen? Für Zähler inkrementieren und Flag lösche - Ja. Aber beim Interruptaufruf werden auch noch Register gesichert und beim Exit wiederhergestellt. Wie werden die gesichert? Als shadow Register(SRS) or per Software (SOFT)?
Toby P. schrieb: > Die Frage wozu man einen Prozessor nimmt wenn der eh nur noch Interrupts > abarbeitet ist etwas off topic. Die Antwort würde mich aber > interessieren. Folgendes ist noch zu erwähnen: - im endgültigen Zustand gibt es nur alle 480 nsec einen Clock-Interrupt - im endgültigen Zustand soll der PIC mit 120 MHz laufen - ich habe mich tatsächlich ein wenig verrechnet, so arschnknapp hätte das gar nicht sein sollen
Chris B. schrieb: > Aber beim Interruptaufruf werden auch noch Register gesichert und beim > Exit wiederhergestellt. > Wie werden die gesichert? Als shadow Register(SRS) or per Software > (SOFT)? Gute Frage...wie/wo kann ich das beim OIC32MX denn konfigurieren?
Narvik schrieb: > Folgendes ist noch zu erwähnen: > > - im endgültigen Zustand gibt es nur alle 480 nsec einen Clock-Interrupt > > - im endgültigen Zustand soll der PIC mit 120 MHz laufen > > - ich habe mich tatsächlich ein wenig verrechnet, so arschnknapp hätte > das gar nicht sein sollen Versuch macht kluch, Toggle mal einen Pin in der ISR und schau dir die Latenz am Scope an. Spart vllcht. ne Menge arbeit.
hier noch etwas Futter: Interrupt latency on PIC32 - impossibly long https://www.microchip.com/forums/m709091.aspx
Narvik schrieb: > Folgendes ist noch zu erwähnen: > > - im endgültigen Zustand gibt es nur alle 480 nsec einen Clock-Interrupt > > - im endgültigen Zustand soll der PIC mit 120 MHz laufen > > - ich habe mich tatsächlich ein wenig verrechnet, so arschnknapp hätte > das gar nicht sein sollen Ein wenig Lektüre zur Interrupt-Latency hast du ja bereits gekommen. Mich interessiert aber dennoch, warum die Test-Signale 4x so schnell kommen, der Controller dazu aber "nur" bei 80% des endgültigen Taktes liegt? Narvik schrieb: > Zu Testzwecken > habe ich in meinen Interrupt-Serviceroutinen nichts weiter als je einen > Zähler, mit denen ich ermittle, wie oft der jeweilige Interrupt > aufgetreten ist. Was sollen die Routinen denn "endgültig" machen? Reicht es dann auch im "endgültigen" Zustand?^^
> Mich interessiert aber dennoch, warum die Test-Signale 4x so schnell > kommen, der Controller dazu aber "nur" bei 80% des endgültigen Taktes > liegt? Das diente dazu, zu ermitteln, wie viel Luft denn noch vorhanden ist. Wie ich jetzt weiß, gar keine: So wie es aussieht, ist die Hardware tatsächlich zu lahm (auch mit den deutlich entspannteren Zeiten im endgültigen Zustand und mit allen Optimierungen gehen ca 30% aller Clock-Flanken verloren, die Latenz ist einfach zu hoch). Es muss also wirklich was rechenleistungsstärkeres her. Blöd allerdings: ich habe ein Platzproblem und würde doch gerne bei einem Gehäuse in der Größe des 48-Pin-TQFP bleiben. Allerdings kann ich da bisher nichts passendes finden, mehr Takt (sinnvollerweise mehr als 200 MHz) bedeuten immer mehr Peripherie und damit mehr Pins und demzufolge ein größerer Footprint...
Narvik schrieb: > Es muss also wirklich was rechenleistungsstärkeres her. Warum? Ich kenne den PIC nicht, aber in der Regel lassen sich Timer auch als Counter schalten, d.h. sie zählen ein externes Signal ganz ohne Interruptlast. Bzw. wenn es sich um serielle Daten handelt, könnte ein SPI-Slave (mit DMA) die einlesen. Man müßte halt wissen, was Du eigentlich willst.
Peter D. schrieb: > Ich kenne den PIC nicht, aber in der Regel lassen sich Timer auch als > Counter schalten, d.h. sie zählen ein externes Signal ganz ohne > Interruptlast. > Bzw. wenn es sich um serielle Daten handelt, könnte ein SPI-Slave (mit > DMA) die einlesen. > Man müßte halt wissen, was Du eigentlich willst. Es ist kein Timer, sondern ein Clock für ein SPI-artiges Datensignal. SPI kann ich trotzdem nicht verwenden, weil ein Frame eine variable Länge im Bereich von 18..22 Bit haben kann. Die genaue Länge wird wiederum durch das Synchronisationssignal festgelegt (das ist das :1 Signal) und ein Datenbit ist immer bei einem Flankenwechsel gültig (SPI hingegen nimmt ja immer die steigende ODER fallende Flanke).
Typischer Fall von höher schneller weiter. Man könnte sich ja mal Gedanken über den Ansatz machen. Da muß man aber zu viel Schmalz verbraten und man giert da lieber nach einem noch schnelleren µC. Peda hat sich da schon mehr Gedanken gemacht. Ist aber immer noch im trüben fischen , da das Ganze ja sehr geheim ist.
Zeno schrieb: > Peda hat sich da schon mehr Gedanken gemacht. Ist aber immer noch im > trüben fischen , da das Ganze ja sehr geheim ist. Ich weiß nicht, was du noch wissen willst, was ich nicht schon beschrieben hätte: - es gibt eine Datenleitung, auf der Datenbits im Bereich 18..22 Bit übertragen werden - es gibt eine Clock-Leitung (das ist das 22: Signal), auf der die Gültigkeit eines Datenbits mit einer Flanke signalsiert wird - es gibt eine Sync-Leitung (das ist das :1 Signal), die vor Bit 0 auf High geht und vor Bit n-1 auf Low geht und damit die Länge eines Datenframes festlegt. Die so übertragenen Daten werden eingelesen und in einen 16..20 Bit Zahlenwert umgewandelt, der dann per SPI weitergereicht wird. Es sieht also aus wie SPI, ist aber kein SPI (keine feste Anzahl Bits, keine fixe Flanke auf dem Clock, Sync geht vor dem letzten Bit auf Low).
Narvik schrieb: > - es gibt eine Datenleitung, auf der Datenbits im Bereich 18..22 Bit > übertragen werden > > - es gibt eine Clock-Leitung (das ist das 22: Signal), auf der die > Gültigkeit eines Datenbits mit einer Flanke signalsiert wird > > - es gibt eine Sync-Leitung (das ist das :1 Signal), die vor Bit 0 auf > High geht und vor Bit n-1 auf Low geht und damit die Länge eines > Datenframes festlegt. Also auf gut Deutsch ein bescheuertes Protokoll, das möglichst schwierig zu implementieren ist.
Wir haben jetzt für sowas kleine FPGAs benutzt. Die können mitzaehlen und nach Daten schauen. Und die CPU fragt ab und zu per SPI nach den Werten. Kleine FPGAs gibts schon für unter 5 Euro. Und viel Platz brauchen die auch nicht.
Dieter W. schrieb: > Also auf gut Deutsch ein bescheuertes Protokoll, das möglichst schwierig > zu implementieren ist. Das Protokoll zu beschimpfen mag helfen, löst aber mein Problem nicht. Das Clock-Signal ließe sich ja so ändern, dass immer die gleiche Flanke verwendet wird, aber die variable Datenlänge wird in jedem Fall bleiben. An FPGAs habe ich auch schon gedacht, leider geht meine Erfahrung damit gegen Null...
Narvik schrieb: > An FPGAs habe ich auch schon gedacht, leider geht meine Erfahrung damit > gegen Null... Home-Office Zeit ist Zeit um etwas neues zu lernen. Gerade jetzt sollten doch ein paar zeitliche Freiräume vorhanden sein. Ich habe auch etwas länger dafür gebraucht. Doch es hat eine komplett andere Sichtweise ermöglicht.
PittyJ schrieb: > Narvik schrieb: >> An FPGAs habe ich auch schon gedacht, leider geht meine Erfahrung damit >> gegen Null... > > Home-Office Zeit ist Zeit um etwas neues zu lernen. Gerade jetzt sollten > doch ein paar zeitliche Freiräume vorhanden sein. > > Ich habe auch etwas länger dafür gebraucht. Doch es hat eine komplett > andere Sichtweise ermöglicht. OK...hast du einen Tipp für einen passenden FPGA (mit genügend Logikblöcken für für 2x SPI, 2 Datenleitungen eine Clock- und eine Sync-Leitung, optional 1x UART) und/oder ein einsteigergeeignetes Evaluation-Board? Danke :-)
Es gibt einige Controller ich glaub von nxp, die haben ein sehr kleines konfigurierbares Gate array. Vielleich reicht das ja fūr die deserialisierung.
Pics finde ich ja sehr brauchbar, robuste stabile Arbeitspferde mit allem was man braucht. Außer man will einen Ferrari daraus bauen, führt nur zu Enttäuschungen. In deinem Fall nehme ich an das deren I/O nicht schnell genug ist. Meiner einer würde da erstmal die max. Times and Frequencies checken. Ein FPGA wäre auch für mich Mittel der Wahl. Sich mit den Grenzbereichen der PIC32 Hardware zu quälen find ich eher sinnlos. Wenn dann die Alternative ist was neues zu lernen ... .
Narvik schrieb: > An FPGAs habe ich auch schon gedacht, leider geht meine Erfahrung damit > gegen Null... Dann würde ich CPLDs empfehlen, z.B. XCR3064 (44-pin VQFP). Der hat 64 Macrozellen, d.h. bis zu 64 D-FFs. Da muß man kein kompliziertes VHDL lernen, sondern kann logische Ausdrücke direkt hinschreiben, z.B. in Abel.
> ast du einen Tipp für einen passenden FPGA (mit genügend > Logikblöcken für für 2x SPI, 2 Datenleitungen eine Clock- und eine > Sync-Leitung, optional 1x UART) und/oder ein einsteigergeeignetes > Evaluation-Board? Das sollte schon der kleinste alte CycloneI oder CycloneII schaffen. Boards nebst JTAG-Adapter gibt es beim Chinesen. Warum sollte man sich mit > Abel quaelen, wenn man VHDL haben kann.
Narvik schrieb: > OK...hast du einen Tipp für einen passenden FPGA (mit genügend > Logikblöcken für für 2x SPI, 2 Datenleitungen eine Clock- und eine > Sync-Leitung, optional 1x UART) und/oder ein einsteigergeeignetes > Evaluation-Board? Ich bin mit Xilinx 'verbandelt', daher würde ich jetzt kleine Spartans empfehlen. Ich hatte damals einen kleinen Spartan 3. Jetzt gibt es so etwas hier: https://www.xilinx.com/products/boards-and-kits/1-elhae0.html Ein Bekannter hat mit Lattice gespielt, die sind noch kleiner und günstiger. An mehr Info würde ich aber erst nach Ostern kommen.
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.