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
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.
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 :-)
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.
