STM32F103C8 Plattformprojekt mit Display, FATFS, IMU MPU-9250 und Examples
- Themenstarter nichtgedacht
- Beginndatum
- Status
Hi
Falls es jemand interessiert. Man kann tatsächlich im SRAM eine Variable von der Firmware an den Bootloader übergeben.
Damit der Bootloader weiß, dass er nicht die Firmware sondern ein DFU Interface starten soll, muss er diese Information irgendwoher bekommen. Z.B. einen Taster beim Reset festhalten, oder ein Flag das die Firmware irgendwo vor einem software getriggerten Reset hinterlegt.
Ich hatte bisher ein Flag am Ende der Flashpage gesetzt, die auch die Konfiguration enthält. Dann musste der Bootloader aber jedes Mal die Page löschen und die Konfiguration zurückschreiben um das Flag wieder los zu werden.
Jetzt wird per Linker Script und dem Startup File eine künstliche nicht initialisierte Variable im Bootloader erzeugt und am Ende vom SRAM wo der Stack endet (eigntl. anfängt, der wächst ja rückwärts) ein Stückchen Speicher reserviert indem das Ende vom Stack um 8 Bytes nach unten verschoben wird. Letzteres erfolgt in den Linker Scripten sowohl von der Firmware als auch vom Bootloader. In der Firmware kann man dann gefahrlos an dieser Adresse schreiiben. Im startup file vom Bootloader wird das ausgesparte Stückchen Speicher in die Variable kopiert und dann gelöscht. Die Variable wird vom Linker einer nicht zu initialieren Speicher Section zugeordned und hat dann auf magische Weise einen Inhalt im Bootloader obwohl sie dort nur als extern deklariert wurde, also ohne im Programm Speicher anzuziehen.
Jetzt ist der Bootloader kleiner und verschleißt kein Flash mehr.
Gruß
Dieter
Falls es jemand interessiert. Man kann tatsächlich im SRAM eine Variable von der Firmware an den Bootloader übergeben.
Damit der Bootloader weiß, dass er nicht die Firmware sondern ein DFU Interface starten soll, muss er diese Information irgendwoher bekommen. Z.B. einen Taster beim Reset festhalten, oder ein Flag das die Firmware irgendwo vor einem software getriggerten Reset hinterlegt.
Ich hatte bisher ein Flag am Ende der Flashpage gesetzt, die auch die Konfiguration enthält. Dann musste der Bootloader aber jedes Mal die Page löschen und die Konfiguration zurückschreiben um das Flag wieder los zu werden.
Jetzt wird per Linker Script und dem Startup File eine künstliche nicht initialisierte Variable im Bootloader erzeugt und am Ende vom SRAM wo der Stack endet (eigntl. anfängt, der wächst ja rückwärts) ein Stückchen Speicher reserviert indem das Ende vom Stack um 8 Bytes nach unten verschoben wird. Letzteres erfolgt in den Linker Scripten sowohl von der Firmware als auch vom Bootloader. In der Firmware kann man dann gefahrlos an dieser Adresse schreiiben. Im startup file vom Bootloader wird das ausgesparte Stückchen Speicher in die Variable kopiert und dann gelöscht. Die Variable wird vom Linker einer nicht zu initialieren Speicher Section zugeordned und hat dann auf magische Weise einen Inhalt im Bootloader obwohl sie dort nur als extern deklariert wurde, also ohne im Programm Speicher anzuziehen.
Jetzt ist der Bootloader kleiner und verschleißt kein Flash mehr.
Gruß
Dieter
Hi
Ich habe jetzt mal OneShot125 implementiert und bin heute damit geflogen.
Die Regelschleife läuft jetzt mit 1,25 kHz und in jeder Periode werden auch die ESCs neu beschrieben. Bei normal PWM gibt es 4000 Schritte Auflösung bei OneShot jetzt nur noch 3000.
Vorher liefen die Abfrage der Gyros und der Regleralgorithmus ebenfalls mit 1,25 kHz, aber vom Reglerergebnis wurde über 3 Perioden der Durchschnitt gebildet und dann an die ESCs geschrieben. Einen wirklichen Unterschied beim Fliegen merke ich nicht, obwohl die Latenz: Gyros-Regler->ESCs jetzt deutlich kleiner ist. Ich bin fliegerisch wohl noch nicht so weit und habe erst heute meine ersten Loopings und Rollen geflogen.
Gruß
Dieter
Ich habe jetzt mal OneShot125 implementiert und bin heute damit geflogen.
Die Regelschleife läuft jetzt mit 1,25 kHz und in jeder Periode werden auch die ESCs neu beschrieben. Bei normal PWM gibt es 4000 Schritte Auflösung bei OneShot jetzt nur noch 3000.
Vorher liefen die Abfrage der Gyros und der Regleralgorithmus ebenfalls mit 1,25 kHz, aber vom Reglerergebnis wurde über 3 Perioden der Durchschnitt gebildet und dann an die ESCs geschrieben. Einen wirklichen Unterschied beim Fliegen merke ich nicht, obwohl die Latenz: Gyros-Regler->ESCs jetzt deutlich kleiner ist. Ich bin fliegerisch wohl noch nicht so weit und habe erst heute meine ersten Loopings und Rollen geflogen.
Gruß
Dieter
Anhänge
Zuletzt bearbeitet:
Hi
OK, ich kann den Timer für die Schleife auf eine an sich zu lange Periodendauer stellen und dann von dem RAW_RDY_EN Signal der IMU per z.B. dem TI2FP2 Trigger Input resetten lassen. Das erfolgt dann mit 1kHz und ich kann somit aus mehreren Stufen Low Pass Filterung auswählen. Mit dem so generierten Update Event von diesem Timer lasse ich dann gleichzeitig den Timer für die OneShot125 Pulsgenerierung resetten. Den letzteren Timer stelle ich auch auf eine längere Periodendauer ein, so dass hier auch nur ein Update Event vom Reset kommen kann. Damit ist für OneShot125 alles synchron mit der Leserate vom IMU Chip.
Leider läuft dann das normale PWM nicht mehr synchron mit dem erstgenannten Timer (der Schleife). Das ist aber wahrscheinlich egal, weil die Pulsdauer hier sowieso bis zu 1ms variiert, was ja der Länge der Schleife entspricht.
Gruß
Dieter
OK, ich kann den Timer für die Schleife auf eine an sich zu lange Periodendauer stellen und dann von dem RAW_RDY_EN Signal der IMU per z.B. dem TI2FP2 Trigger Input resetten lassen. Das erfolgt dann mit 1kHz und ich kann somit aus mehreren Stufen Low Pass Filterung auswählen. Mit dem so generierten Update Event von diesem Timer lasse ich dann gleichzeitig den Timer für die OneShot125 Pulsgenerierung resetten. Den letzteren Timer stelle ich auch auf eine längere Periodendauer ein, so dass hier auch nur ein Update Event vom Reset kommen kann. Damit ist für OneShot125 alles synchron mit der Leserate vom IMU Chip.
Leider läuft dann das normale PWM nicht mehr synchron mit dem erstgenannten Timer (der Schleife). Das ist aber wahrscheinlich egal, weil die Pulsdauer hier sowieso bis zu 1ms variiert, was ja der Länge der Schleife entspricht.
Gruß
Dieter
Zu beachten ist was die esc denn so an auflösung lesen kann. Bei oneshot ist es dann faktor 8 weniger. Ich denke da sind wir weit weit unter 3000 steps.
Die frage ist ob eine berechnung im 1khz takt sinn macht wenn normal-pwm nur 500hz rüberbringen kann. Ich denke nein. Die meinung 1ms looptime sei mehr "locked in" wird durch die bei schnellerer looptime anders wirkenden pid werte verursacht.
[rant]
Auf die frage was denn an dshot gut sei kam als häufigste antwort "keine esc kalibrierung nötig". Weder kürzere latenz noch höhere auflösung werden genannt. Weil man das gar nicht merkt.
[/rant]
Ein kalibrationsfreies rein digitales protokoll ist in konze/simonk firmware schon eingebaut. Wenn man an den RXD pin des atmega8 rankommt sollte das ohne reflash funktionieren. (getestet an afro 20A). Driver für baseflight hier:
Im flug hab ich das nicht getestet weil jede esc mit einer andern ID geflasht werden muss wenn man nicht 4 uart verwenden will.
Die frage ist ob eine berechnung im 1khz takt sinn macht wenn normal-pwm nur 500hz rüberbringen kann. Ich denke nein. Die meinung 1ms looptime sei mehr "locked in" wird durch die bei schnellerer looptime anders wirkenden pid werte verursacht.
[rant]
Auf die frage was denn an dshot gut sei kam als häufigste antwort "keine esc kalibrierung nötig". Weder kürzere latenz noch höhere auflösung werden genannt. Weil man das gar nicht merkt.
[/rant]
Ein kalibrationsfreies rein digitales protokoll ist in konze/simonk firmware schon eingebaut. Wenn man an den RXD pin des atmega8 rankommt sollte das ohne reflash funktionieren. (getestet an afro 20A). Driver für baseflight hier:
Code:
// Driver for serial esc (konze protocol) on UART2
#define SESC_SYNCBYTE 0xF5
#define SESC_MAX_CHANNEL 4
void sEscInit(void)
{
core.sescport = uartOpen(USART2, NULL, 38400, MODE_RXTX);
}
void sEscSend(void)
{
int i;
uint8_t sEscData;
serialWrite(core.sescport,SESC_SYNCBYTE);
for (i = 0; i < SESC_MAX_CHANNEL; i++)
{
sEscData = constrain(((motor[i] - 1000) >> 2),0,200);
serialWrite(core.sescport,sEscData);
}
}
Zuletzt bearbeitet:
Das ist leider wahr. Die von mir z.Zt. verwendeten Kiss 18A machen nur 950 Schritte. Wenn ich aber die Auflösung der Ansteuerung genauso klein machen würde, wären effektiv es noch weniger Schritte, oder?
Ich denke, auch nicht, dass die Berechnung mit höherer Frequenz eine Auswirkung hat. Für den Regelkreis sind 200Hz schon quasi kontinuierlich. Aber die Abtastfrequenz hat Auswirkungen. Ich verwende aktuell 92Hz Low Pass Filter für die Gyros. Diese Filter haben aber offenbar einen sehr flachen Verlauf(1. Ordnung). Bei zu geringer Abtastrate kann man merken, dass der Kopter bei bestimmten Drehzahlen rau läuft. Ich erkläre mir das damit, das Vibrationsfrequenzen nicht ausreichend durch die Low Pass Filter unterdrückt werden. Wenn dann die Differenz zwischen Abtastfrequenz und Vibrationsfrequenz klein wird, kann der Kopter mit dieser Frequenz erschüttert werden, da die Phasenlage des Regelkreises für diese Frequenzen keine Stabilität ergibt. Eine höhere Abtastrate und Durchschnittsbildung unterdrückt die höheren Frequenzen zusätzlich. Oder anders betrachtet: Generell müssen Frequenzen mit doppelter Abtastrate ja vom Regler fern gehalten werden. Durch erhöhen der Abtastrate werden die Low Pass Filter wirksamer, da zu den höheren Frequenzen die Amplitude weiter abfällt.
Ich finde dass Protokoll auch fraglich. Eine Vergewaltigung der Timerhardware und die vielen passenden DMA Kanäle stehen nur in bestimmten MCUs zur Verfügung. Die Kiss Leute wollen uns einen Standard aufzwingen, der sich hoffentlich nicht durchsetzen wird.
Interessant. Da könnte man doch gleich I2C nehmen und die Adressen mit Lötjumper einstellen.
Gruß
Dieter
Ich denke, auch nicht, dass die Berechnung mit höherer Frequenz eine Auswirkung hat. Für den Regelkreis sind 200Hz schon quasi kontinuierlich. Aber die Abtastfrequenz hat Auswirkungen. Ich verwende aktuell 92Hz Low Pass Filter für die Gyros. Diese Filter haben aber offenbar einen sehr flachen Verlauf(1. Ordnung). Bei zu geringer Abtastrate kann man merken, dass der Kopter bei bestimmten Drehzahlen rau läuft. Ich erkläre mir das damit, das Vibrationsfrequenzen nicht ausreichend durch die Low Pass Filter unterdrückt werden. Wenn dann die Differenz zwischen Abtastfrequenz und Vibrationsfrequenz klein wird, kann der Kopter mit dieser Frequenz erschüttert werden, da die Phasenlage des Regelkreises für diese Frequenzen keine Stabilität ergibt. Eine höhere Abtastrate und Durchschnittsbildung unterdrückt die höheren Frequenzen zusätzlich. Oder anders betrachtet: Generell müssen Frequenzen mit doppelter Abtastrate ja vom Regler fern gehalten werden. Durch erhöhen der Abtastrate werden die Low Pass Filter wirksamer, da zu den höheren Frequenzen die Amplitude weiter abfällt.
Ich finde dass Protokoll auch fraglich. Eine Vergewaltigung der Timerhardware und die vielen passenden DMA Kanäle stehen nur in bestimmten MCUs zur Verfügung. Die Kiss Leute wollen uns einen Standard aufzwingen, der sich hoffentlich nicht durchsetzen wird.
Interessant. Da könnte man doch gleich I2C nehmen und die Adressen mit Lötjumper einstellen.
Gruß
Dieter
Hi
Es funktioniert wie ich mir das vorgestellt habe.
Es gibt Timer4 für die Schleife und Timer2 für die Pulse mit 4 Ausgangskanälen. Im OneShot Betrieb wird Timer2 anders initialisiert als für normal PWM.
Timer4 ist auf eine Periodendauer von 1,1ms eingestellt. Im OneShot Betrieb ist die Periode von Timer2 ebenfalls auf 1,1ms eingestellt. Timer4 bekommt jedoch vor Ablauf der 1.1ms vom Int Pin der IMU einen Reset Trigger. Timer2 bekommt dann seinerseits vom Update Event von Timer4 einen Reset. So haben beide Timer tatsächlich eine Periode nahe 1ms die von der IMU aufgezwungen wird. Mit Start der Periode sind immer die aktuellen Daten lesebereit.
Im normal PWM Betrieb läuft Timer2 frei mit 2.2ms Periode und nur Timer4 wird von der IMU synchronisiert. In der Schleife wird dann nachgesehen ob Timer2 abgelaufen war und dann die neuen Impulslängen geschrieben.
Das schöne an der Bastellösung ist, dass man einfach mit Lötkolben und Draht die Hardware ändern kann.
Bilder:
1. IMU lesen (Gyros und Accel) mit 1ms. Normal PWM Vollschub (Motortest)
2. Das Gleiche mit OneShot und synchronen Ausgangspulsen
3. Das Gleiche Motor aus.
Es funktioniert wie ich mir das vorgestellt habe.
Es gibt Timer4 für die Schleife und Timer2 für die Pulse mit 4 Ausgangskanälen. Im OneShot Betrieb wird Timer2 anders initialisiert als für normal PWM.
Timer4 ist auf eine Periodendauer von 1,1ms eingestellt. Im OneShot Betrieb ist die Periode von Timer2 ebenfalls auf 1,1ms eingestellt. Timer4 bekommt jedoch vor Ablauf der 1.1ms vom Int Pin der IMU einen Reset Trigger. Timer2 bekommt dann seinerseits vom Update Event von Timer4 einen Reset. So haben beide Timer tatsächlich eine Periode nahe 1ms die von der IMU aufgezwungen wird. Mit Start der Periode sind immer die aktuellen Daten lesebereit.
Im normal PWM Betrieb läuft Timer2 frei mit 2.2ms Periode und nur Timer4 wird von der IMU synchronisiert. In der Schleife wird dann nachgesehen ob Timer2 abgelaufen war und dann die neuen Impulslängen geschrieben.
Das schöne an der Bastellösung ist, dass man einfach mit Lötkolben und Draht die Hardware ändern kann.
Bilder:
1. IMU lesen (Gyros und Accel) mit 1ms. Normal PWM Vollschub (Motortest)
2. Das Gleiche mit OneShot und synchronen Ausgangspulsen
3. Das Gleiche Motor aus.
Anhänge
Pfui 
CAN ja, oder irgendwas Anderes, aber nur kein I2C. Das ist viel zu störanfällig und eh eigentlich für die meisten Sachen, die man in unserem Bereich hier macht, ursprünglich überhaupt nicht gedacht.
CAN ja, oder irgendwas Anderes, aber nur kein I2C. Das ist viel zu störanfällig und eh eigentlich für die meisten Sachen, die man in unserem Bereich hier macht, ursprünglich überhaupt nicht gedacht.
Mit dem normal PWM musste ich dann doch auf 3ms Periode gehen. Ich krieg sonst das averagen nicht hin.
Im Bild noch mal alle Signale in voller Pracht mit SRXL vom Empfänger und dem Synchron Pulse von der IMU. Der Puls bleibt übrigens so lange stehen bis die Register ausgelesen wurden. Wenn also ein Display im nicht armed Zustand den Ablauf aufhält kommen auch keine Reset Flanken. Insofern sollte die native Periode von Timer4 nur knapp länger sein als mit Reset.
Anhänge
Das war nur ein gut gemeinter Rat. I2C ist (weil es dafür nie gedacht war, I2C war als serieller Bus innerhalb einer Platine konzipiert) ab einer gewissen Leitungslänge und Umgebung extrem störanfällig. Wenn wie bei Mikrokopter ESCs und Controller direkt aufeinander sitzen, spielt das weniger eine Rolle. Aber in der EMV-versuchten Umgebung eines Kopters hast Du spätestens bei 30cm ungeschirmte Kabellänge potentiell Probleme. Frag mal die ganzen leidgeplagten Gimbalbauer wie auch beispielsweise Olli mit seinem Storm, was die von I2C als Protokoll über Kabel halten. Der ist z.B. von I2C inzwischen ganz weg. Phobotic z.B. nimmt CAN als Verbindung zwischen IMU und Controller.
Wenn ich eh was neu konzipiere, fange ich doch nicht mit etwas an, was sich in der Vergangenheit als problematisch erwiesen hat. Schon gar nicht, wenn es weit bessere Alternativen gibt. Aber das ist Deine Sache, wie gesagt: einfach nur gut gemeinter Rat.
Viele Grüße,
Stefan
Wenn ich eh was neu konzipiere, fange ich doch nicht mit etwas an, was sich in der Vergangenheit als problematisch erwiesen hat. Schon gar nicht, wenn es weit bessere Alternativen gibt. Aber das ist Deine Sache, wie gesagt: einfach nur gut gemeinter Rat.
Viele Grüße,
Stefan
Hi
Bei Mikrokopter gibt es, wie woanders auch, eine Platine mit dem Flightcontroller und von da ein kurzes Stück Kabel zu einer Platine die ringsum verläuft. Diese Platine dient als Strom- und Signal-Verteiler für die ESCs. Die ESCs wiederum werden mit Drahtbrücken in Aussparungen der Verteilerplatine eingesetzt. Die Verteilerplatine gibt es in verschiedenen Formen für Quad- Hexa- und Okto-kopter.
Ich habe bisher auch nicht vor die Firmware in ESCs selber zu schreiben. Aber was praktikableres als D-Shot würde ich mir schon wünschen.
Gruß
Dieter
Bei Mikrokopter gibt es, wie woanders auch, eine Platine mit dem Flightcontroller und von da ein kurzes Stück Kabel zu einer Platine die ringsum verläuft. Diese Platine dient als Strom- und Signal-Verteiler für die ESCs. Die ESCs wiederum werden mit Drahtbrücken in Aussparungen der Verteilerplatine eingesetzt. Die Verteilerplatine gibt es in verschiedenen Formen für Quad- Hexa- und Okto-kopter.
Ich habe bisher auch nicht vor die Firmware in ESCs selber zu schreiben. Aber was praktikableres als D-Shot würde ich mir schon wünschen.
Gruß
Dieter
Warum nicht das konze protokoll der bestehenden firmware verwenden? Wenn sich das bei tests als praktikabel erweist kann man das relativ einfach auf 12bit pro motor und schnellere baudrate modifizieren.
Wie lesen eigentlich dshot kompatible esc das signal? Wenn das eine uart ist sollten sich diese leicht auf ein normales serielles protokoll umflashen lassen.
BTW:
Die simonk und blheli esc lassen sich mit "blheli_suite" vom normalen pwm stecker aus flashen. Man muss nix löten umd die motor-ID oder die firmware zu ändern. Das geht ganz fix und einfach... wusste ich bis heute nicht. Ich hab alles da für serielle ansteuerung , nur zu faul.
Wie lesen eigentlich dshot kompatible esc das signal? Wenn das eine uart ist sollten sich diese leicht auf ein normales serielles protokoll umflashen lassen.
BTW:
Die simonk und blheli esc lassen sich mit "blheli_suite" vom normalen pwm stecker aus flashen. Man muss nix löten umd die motor-ID oder die firmware zu ändern. Das geht ganz fix und einfach... wusste ich bis heute nicht. Ich hab alles da für serielle ansteuerung
, nur zu faul.
Zuletzt bearbeitet:
Hi
Das sind ja ganz gute Ideen. Ich habe von der Soft/Hardware von ESCs bisher kaum Ahnung. Ich weiß bei meinen ESCs meistens nicht mal welche Software darauf läuft, geschweige denn in welcher Version.
Ich dachte bisher, dass die ESCs am Frontend einen Timer mit Capture Compare angeschlossen haben. Dass alternativ eine UART Peripherie da dran sitzt ist natürlich denkbar, wenn die MCU das zulässt. UART könnte man vielleicht auch mit einem Timer emulieren. Wird beim Flashen denn ein UART Protokoll verwendet?
Poste doch mal ein paar erhellende Links
Gruß
Dieter
Das sind ja ganz gute Ideen. Ich habe von der Soft/Hardware von ESCs bisher kaum Ahnung. Ich weiß bei meinen ESCs meistens nicht mal welche Software darauf läuft, geschweige denn in welcher Version.
Ich dachte bisher, dass die ESCs am Frontend einen Timer mit Capture Compare angeschlossen haben. Dass alternativ eine UART Peripherie da dran sitzt ist natürlich denkbar, wenn die MCU das zulässt. UART könnte man vielleicht auch mit einem Timer emulieren. Wird beim Flashen denn ein UART Protokoll verwendet?
Poste doch mal ein paar erhellende Links
Gruß
Dieter
Das ist die luxusvariante mit ICP. Die meisten gehen mit pinchange interrupt und lesen dann einen freilaufendem timer.
Nein, das ist irgendein 1 wire bitbang protokoll. Braucht einen $4 "usb linker" oder einen $2 arduino. Das geht aber einwandfrei. Und ... man kann auch die esc von der FC aus flashen ohne etwas einzustöpseln oder abzuziehen.
Wenn du spielen willst: simonk firmware auf git. Avrstudio4.
Das ist murks. Wie dshot. Für das flashen brauchbar aber nicht für betrieb.
Normalerweise ist RXD nicht mit pwm-in verbunden. Nur bei den afro esc (von TC, dem baseflight author) ist das seitlich rausgeführt und in der firmware enabled (rxd pad unten im bild). Ob dshot die uart nutzt und ob bei den blheli-s esc input mit uart rx verbunden ist weiss ich nicht.
Noch was: mpu6050 support machst du nicht?
Nein, das ist irgendein 1 wire bitbang protokoll. Braucht einen $4 "usb linker" oder einen $2 arduino. Das geht aber einwandfrei. Und ... man kann auch die esc von der FC aus flashen ohne etwas einzustöpseln oder abzuziehen.
Wenn du spielen willst: simonk firmware auf git. Avrstudio4.
Das ist murks. Wie dshot. Für das flashen brauchbar aber nicht für betrieb.
Normalerweise ist RXD nicht mit pwm-in verbunden. Nur bei den afro esc (von TC, dem baseflight author) ist das seitlich rausgeführt und in der firmware enabled (rxd pad unten im bild). Ob dshot die uart nutzt und ob bei den blheli-s esc input mit uart rx verbunden ist weiss ich nicht.
Noch was: mpu6050 support machst du nicht?
Zuletzt bearbeitet:
- Status
