Hi, ich lese über den Adress-/Datenbus von einem STM32F103 Prozessor ein Interrupt-Register von einem anderen IC aus. Dieses Register wird mit einer bestimmten Frequenz immer wieder gesetzt und nach dem Lesen gecleart. Wie ist es möglich, dass ich im STM32F103 Prozessor einen Timer Interrupt erstelle, der genau auf diese Frequenz, die unterschiedlich sein kann, gesynct ist? Gruß Lars
Lars schrieb: > ich lese über den Adress-/Datenbus von einem STM32F103 Prozessor ein > Interrupt-Register von einem anderen IC aus. Dieses Register wird mit > einer bestimmten Frequenz immer wieder gesetzt und nach dem Lesen > gecleart. Es wäre eventuell von Bedeutung, um welchen externen IC es sich handelt. Da könnte man sich mal ein Gesamtbild machen. Du nutzt das External Bus Interface. Richtig? Gruß Oliver
Oliver J. schrieb: > Es wäre eventuell von Bedeutung, um welchen externen IC es sich handelt. > Da könnte man sich mal ein Gesamtbild machen. Du nutzt das External Bus > Interface. Richtig? Bei dem externen IC handelt es sich um den ICS2008B von IDT. Bei diesem IC gibt es ein Interruptregister, welches ich über das External Bus Interface auslese und daraus ersehe ob ein neues Pkt z.B. beim VITC Timecode beim ICS2008B angekommen ist oder nicht.
Lars schrieb: > Wie ist es möglich, dass ich im STM32F103 Prozessor einen Timer > Interrupt erstelle, der genau auf diese Frequenz, die unterschiedlich > sein kann, gesynct ist? hat jmd von euch noch ne Idee hierzu?
du kannst nur syncronisieren, wenn der ICS ein Signal an einem Pin ausgibt wenn sich die Daten im Interruptregister ändern (evl. der INTR-Pin ?)! Dann kannst du mit diesem am STM einen INT auslösen, in welchem du dann das Register des ICS ausliest - einen Timer brauchst du dann nicht. Sascha
Sascha Weber schrieb: > du kannst nur syncronisieren, wenn der ICS ein Signal an einem Pin > ausgibt wenn sich die Daten im Interruptregister ändern (evl. der > INTR-Pin ?)! das trifft leider beim Receiven vom Midi Timecode nicht zu. Hier kann ich lediglich das entsprechende Register auslesen und überprüfen ob das Received-Bit gesetzt ist oder nicht. Mit einem 1kHz-Timer oder höher bekomm ich zwar alle Midi Timecode Pakete allerdings weiß ich dann nicht wie ich diese synchron per LTC Timecode wieder absenden kann.
also empfängst du zum einen die Pakete und willst sie in korrekter Zeitlicher Abfolge wieder versenden - verstehe ich das so richtig? In den Timecodepaketen steht doch demzufolge ein Timecode drin, damit sollte sich doch der Zeitpunkt wann das Paket raus muss berechnen lassen. Wie hoch ist Auflösung der Timecodes? Sascha
Sascha Weber schrieb: > also empfängst du zum einen die Pakete und willst sie in korrekter > Zeitlicher Abfolge wieder versenden - verstehe ich das so richtig? genau, im Prinzip soll der Midi Timecode umgewandelt werden in LTC Timecode. Sascha Weber schrieb: > In den Timecodepaketen steht doch demzufolge ein Timecode drin, damit > sollte sich doch der Zeitpunkt wann das Paket raus muss berechnen > lassen. Wie hoch ist Auflösung der Timecodes? Beide Timecodes sind framebasierend. Beim LTC wird jedes Frame in einem einzigen Paket gesendet -> mit 30fps z.B.. Beim Midi Timecode wird nur jedes zweite Frame gesendet, weil es länger dauert die Zeitinformation zu übertragen. Für die Zeitinformation werden insgesamt 8x Pakete mit 2x Bytes benötigt. Hab das mal ohne Timer probiert und polle das Statusregister vom ICS (STATUS_MTC) bis der NEW_MTCBYTE_RCVD gesetzt wird, welches anzeigt das ein neues Midi Datenwort vorhanden ist und abgeholt werden kann. Sobald das erste Mal ein vollständiger Midi Timecode empfangen wurde (alle 8x Pkt) dann initialsiiere ich den Timer anhand der empfangenen Framerate für den LTC Timecode. Beim zweiten vollständigen Midi Timecode starte ich dann den Timer. Nach ein paar Sekunden ist der Fehler zwischen Midi Timecode received und dem Timer-Interrupt jedoch relativ groß. Man kann zwar ständig den Prescaler auf Null setzen, aber dadurch variiert die Periode vom Timer2 Interrupt so stark, dass ich keinen validen LTC Timecode senden kann. Ich bräuchte eine Routine mit der ich den Timer2 exakt auf die Midi Pkte triggern könnte, so dass die Abweichung nicht ständig größer wird.
1 | volatile unsigned char phasen = 0x00; |
2 | |
3 | void RcvMidiTimecode(void) |
4 | {
|
5 | unsigned char status, tmrvalue; |
6 | |
7 | status = STATUS_MTC; /* status midi register auslesen */ |
8 | if(status & NEW_MTCBYTE_RCVD) |
9 | { /* neues midi timecode pkt angekommen */ |
10 | |
11 | if(MidiRcvMessage()) |
12 | { /* noch nicht alle 8x pkt empfangen */ |
13 | return; |
14 | }
|
15 | else
|
16 | { /* ein komplettes mtc pkt empfangen */ |
17 | |
18 | if(!phasen) |
19 | { /* init phase */ |
20 | |
21 | /* man kennt die Framerate aus dem ersten rcvd midi pkt
|
22 | -> daraus timer initialisieren (so dass timer jedes komplett
|
23 | empfangene Midi Timecode Pkt triggert) */
|
24 | Timer2_Init(MIDI_FRAMERATE); /* MIDI_FRAMERATE z.B. = 30fps */ |
25 | phasen++; |
26 | }
|
27 | else if(phasen == 1) |
28 | { /* start timer mit diesem pkt */ |
29 | Timer2_Start(); |
30 | phasen = 2; |
31 | }
|
32 | else
|
33 | {
|
34 | /* aktueller Zählerwert vom Timer */
|
35 | tmrvalue = TIM2->CNT; |
36 | |
37 | if((tmrvalue >= 50) && (tmrvalue < (CNTR_VALUE - 50)) |
38 | { /* abweichung vom Timer2 zum rcvd midi tc pkt ist |
39 | größer als -/+ 0.5ms */
|
40 | |
41 | /* CNTR_VALUE = eingestellter Counterwert vom Timer */
|
42 | }
|
43 | }
|
44 | }
|
45 | }
|
46 | }
|
was du suchst ist eine Software-PLL! Jedoch sehe ich das Problem, das du durch das pollen des Statusregisters den genauen Punkt an dem der Frame eingegangen ist nicht ermitteln kannst und somit immer ein wechselnder Offset entsteht. Kann die Framerate jeden beliebigen Wert annehmen, oder gibt es nur bestimmte Raten, auf die man "einrasten" könnte? Sascha
Sascha Weber schrieb: > Kann die Framerate jeden beliebigen Wert annehmen, oder gibt es nur > bestimmte Raten, auf die man "einrasten" könnte? Insgesamt gibt es vier verschiedene Raten 24Hz, 25Hz, 29,97Hz und 30Hz. Sascha Weber schrieb: > was du suchst ist eine Software-PLL! wie würde das prinzipiell mit einer Software-PLL funktionieren? Wie wird hier zu Beginn die genauen Nulldurchgänge ausbalanciert?
Lars schrieb: > Sascha Weber schrieb: >> Kann die Framerate jeden beliebigen Wert annehmen, oder gibt es nur >> bestimmte Raten, auf die man "einrasten" könnte? > > Insgesamt gibt es vier verschiedene Raten 24Hz, 25Hz, 29,97Hz und 30Hz. hmm... bei dem geringen Abstand wird das nichts mit festen Werten > Sascha Weber schrieb: >> was du suchst ist eine Software-PLL! > > wie würde das prinzipiell mit einer Software-PLL funktionieren? nicht das ich schon mal sowas programmiert hätte, aber schau mal im Netz da gibt's schon Beschreibungen > Wie wird hier zu Beginn die genauen Nulldurchgänge ausbalanciert? wie gesagt - genaue "Nulldurchgänge" deiner Sollfrequenz hast du ja durch das Polling nicht - wie sich das auf die Reglung auswirkt kannst du nur probieren. Sascha
Hast Du keinen Studio-Takt irgendwo anders zum Abgreifen? Z.B. Video-Signal oder BB oder Wordclock? Wenn Du nichts dergleichen hast, ist eine Software-PLL durchaus sinnvoll. Sollte so schwer nicht sein. Sind ja nur enige Ausgabefrequenzen, die in Frage kommen. Arbeitet der TC echt noch mit Drop-Frame?
Hallo Lars, ich habe zwar gesehen, dass Du nur als Gast gelistet bist, aber vielleicht schaust Du ja noch einmal hier herein. Ich arbeite auch an einem Gerät mit dem ICS2008B und bin nun beim Midi Timecode. Wenn Du Interesse hast könnten wir ja schon gemachte Erfahrungen und Code für den Chip austauschen. Diese Anfrage gilt natürlich auch für alle anderen, die mit diesem Chip arbeiten. Gruß Harald
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.