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!
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.ä.) ?
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
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
