Hallo zusammen, ich versuche hier seit längerem mit dem STM32-Discovery-Board einen seriellen Datenstrom (16 Bits, nur eine Leitung, keine separate Clockleitung), der manchester-codiert ist zu decodieren! Pulsdauer(!) sei 1µs, d.h. eine Bitdauer von 2µs. Ich muss also nur den entsprechenden Moment beim Pegelwechsel (0->1 bzw- 1->0) treffen, abtasten und habe den Bitwert! Geclockt wird die MCU mit der internen PLL, die auf 48MHz konfiguriert ist. Anfänglich dachte ich, super, ist einfach gemacht: Timer (hier: TIM2) konfigurieren und gib ihm. Beim Prüfen der Lösungsmöglichkeit(en) habe ich, um bspw. die Abtastzeitpunkte "sichtbar" zu machen einfach eine LED ein- und ausgeschaltet. Auf dem Oszilloskop ist dann ein Jitter der Abtastzeitpunkte zu sehen gewesen, die ich mir nicht erklären kann! Im weiteren Verlauf habe ich nach "Pin Toggel" gegoogelt und habe die Befürchtung, dass meine Messmethode über die PinToggelei mir einen Strich durch die Rechnung macht. Soll heißen, das Toggeln eines PINs scheint extrem lange bei einem STM32 zu dauern, d.h. ich kann so niemals die 2µs Bitdauer einhalten. Stimmt das so? Um das ganze etwas anschaulicher zu machen - und um nicht den gesamten Quellcode zu posten und zu erklären - habe ich jetzt nur EINE EXTI-Line (ein Pin) aktiviert, um Verzögerungen seitens der Timer-Peripherie zu umgehen. Es werden beide Flanken (steigend und fallend) betrachtet und wie oben mit LED an und LED aus "sichtbar" gemacht. Annahme ist, dass bei 48MHz ausreichend Zeitreserve vorliegt, um nach Eintritt einer ISR eine LED an- und auszumachen, wobei die Flanken des Datensignals einen Abstand von minimal 1µs haben! Leider muss ich mich eines Besseren belehren lassen und frage nach den Ursachen und Lösungsmöglichkeiten! Anbei sind zwei Bilder angehängt, die den Datenstrom(grün) zu den Abtastzeitpunkten(lila) zeigen. Nicht nur, dass überwiegend die letzten Flanken (das 2. Byte) betrifft, es werden offensichtlich Flanken übersehen, da theoretisch 2x so viele Abtastzeitpunkt zu sehen sein sollten wie Flanken! Es wird die Entwicklungsumgebung Atollic TrueStrudio verendet mit der entsprechenden StdLib!
abo schließe mich der frage an, habe bald etwas ähnliches vor
Das macht men doch mit ein input capture soll ich denken. Kann men dan mit 2 Channels und ein Timer machen, um das oder die Steigende Flanke, oder die Fallende Flanke ein Capture macht. Spater kann men dan die gemessene Zeiten ausgeben ueber UART, damit kann dan kontrolliert werden oder das genau genug ist. Ich habe so schon etwas erledigt mit eine Discovery board, aber das Manchester code war deutlich langsamer : 50µs und 25µs. Hat Problemlos functioniert. Kann die code auch veroffentlichen wenn sie wolle.
Hallo RP6Conrad, hmm, also hab bisweilen wirklich alle Möglichkeiten ausprobiert, auch die Capture-Funktionen der Timer! Innerhalb der ISR LED an/aus, um den Abtastzeitpunkt zu detektieren, aber auch hier das gleiche Phänomen: Die LED "jittert". Hab zum Testen die Pulsdauer der Menchestercodierung auf 10µs erhöht (-> Takt = 20µs), damit klappt es gut! Ich möchte das aber schnellere Pulse detektieren, s.o. Das mit der Ausgabe UART innerhalb der ISR denke ich ist ebenfalls zu langsam. Unabhängig von dem konkreten Anwendungsfall, kann Jemand die Verzögerung beim PinToggeln erklären? Wieso dauert das Toggeln so lange?
Kann man für sowas eigentlich irgendwie die Ethernet-Peripherie missbrauchen ? Statt dem PHY das Manchester codierte Signal einspeisen ? Ich meine früher hat es Manchester UARTs als Chips gegeben. Sind die mittlerweile mangels Bedarf ausgestorben ? Oder gibt es Manchester UARTs mittlerweile in uC oder standalone mit aktuell verwendeten Schnittstellen (z.B. SPI o.ä.) ?
die std-lib von ST ist für schnelles PIN-Togglen etwas umständlich. Schreib direkt in die Portregister und gut ist.
Ich habe es gerade mal vermessen mit den LED an C8 und C9 :
1 | #define LEDC8_OFF GPIOC->BSRR = 1<<24 ;
|
2 | #define LEDC8_ON GPIOC->BSRR = 1<<8 ;
|
3 | while (1) //main loop { |
4 | LEDC8_ON; |
5 | LEDC8_OFF; |
6 | LEDC8_ON; |
7 | LEDC8_OFF; |
8 | GPIO_WriteBit(GPIOC,GPIO_Pin_9,Bit_RESET); |
9 | GPIO_WriteBit(GPIOC,GPIO_Pin_9,Bit_SET); |
10 | GPIO_WriteBit(GPIOC,GPIO_Pin_9,Bit_RESET); |
11 | GPIO_WriteBit(GPIOC,GPIO_Pin_9,Bit_SET); |
12 | }
|
und das Ergebnis ist deutlich : Pin togglen mit port register : on/off cycle ist 200 ns, so um die 100 ns für einschalten und 100 ns für ausschalten. Pin togglen mit ST_lib : on/off cycle ist 1µs, so 5 mal langsamer !! Der discovery hat mit 24 MHz gelaufen. Beim Interesse kann isch das Ozi Bild hochladen.
Hallo, ja, das mit der StdLib habe ich mir gleich zu Beginn gedacht und habe entsprechend die LEDon()-bzw. LEDoff()-Funktionen durch direktes Setzen der Bits in den entsprechenden Registern geändert. Hatte dieses bereits mit den Timern probiert und jetzt eben auch an den EXTI-Interrupts angewandt(s.o.) mit dem oben bereits geschilderten Ergebnis! Sind die Pulse "länger", bspw. 12,5µs lang, dann ist das Toggeln wie erwartet: an jeder Flanke kurzes Aufblitzen (200ns Dauer). Werden die Pulse allerdings kürzer (1µs) sieht es wieder wie oben aus! Um den Effekt nachzuvollziehen, versucht doch bitte einfach in der while(1)-Schleife in der main() ein Pin zu Toggeln! Auch das direkte Setzen in den Registern führt es zu einem (großen) Versatz zwischen Sysclock und Blink-Frequenz. Ich nehme an, dass die Chip-Architektur dieses nicht zulässt. Hier ein Link, wo sich einige über die Performance des STM32 Gedanken gemacht haben: https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=%2Fpublic%2FSTe2ecommunities%2Fmcu%2FLists%2Fcortex_mx_stm32%2FTrue%20performance%20of%20STM32&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B¤tviews=14214 Ich frage mich nach wie vor, wieso bei Pulsen von 1µs Pulsdauer die Interrupts offensichtlich nicht schnell genug verarbeitet werden können?! Sind es die Takte für PUSH und POP bei den ISRs? Die STM32 benötigen 12 Cycles für PUSH und POP, sofern kein weiterer Interrupt eintritt. Bei Sysclock = 48Mhz bedeutet das
was in diesem Fall die halbe Pulsdauer entspricht. Kann es sein, dass das schon zu lange ist? Ich probiere es gleich mit einer größeren SysClock... Danke und schöne Grüße kyrel
Nicht nur, dass es mehr Takte sind, es kommen (ab bestimmter f) auch noch WaitStates dazu.
kyrel schrieb: > ich versuche hier seit längerem mit dem STM32-Discovery-Board einen > seriellen Datenstrom (16 Bits, nur eine Leitung, keine separate > Clockleitung), der manchester-codiert ist zu decodieren! Sag doch einfach, dass du ein Delta-Sigma-Modulator von TI hast... Lass mich tippen: ads1203 Für die Auswertung des datenstroms gibt es in diesem Fall aber besser geeignete Bausteine als ein uC. FPGA wäre z.B. ein guter Ansatz...
MCUA schrieb: > Nicht nur, dass es mehr Takte sind, es kommen (ab bestimmter f) auch > noch WaitStates dazu. Die verschiedenen Caches dürften auch noch zu undeterministischen Programmlaufzeiten führen. Grüße Sven
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.