Xnyle
Naja, schon mal über Schnittmenge nachgedacht? Was Du da machst ist ja schon krasses ETechnik Gefrickel, wo man viel (angelernetes) Wissen für braucht.
Auf der komplett anderen Seite sind dann Leute die sich ein Fertigbike kaufen. >90% davon würden eh schon mal nie im Leben auf die Idee kommen dadran rumzufrickeln, selbst wenn ihnen die Steuerung nicht gefällt.
Wieviel von den <10%, die das doch tun wollen kaufen überhaupt erst so ein Fertigbike statt ein billiges China Kit mit dann halt KT drin.
Und von dem Rest: Wieviel frickeln dann am teuren Fertigbike (mit einer alpha Software) rum.
Das muss man ja dann auch laufen bekommen. Wenn ich mir überleg, wie viel Zeit ich allein bei der KT Software versenkt hab, bis ich da durchgestiegen bin und anfangen konnte Probleme zu lösen....
Für meinen Teil finde ich das zwar alles sehr spannend, hätte auch Lust mal andere Controller zu probieren, aber eigentlich stört mich der Umweg über "andere Controller" schon ich möcht lieber gleich was besseres:
Mich stösst z.B. das rumhantieren mit verschiedenen Displays Protokollen ab - deren Halbwertzeit eh sehr begrenzt ist-. Mal ehlich, wir haben 2019, wozu noch diese ganze Bitfrickelei, das ist doch reine Zeitverschwendung. Dazu die ganzen Unzulänglichkeiten aufgrund zweifelhafter Designentscheidungen in proprietären Komponenten: STM32 kein Flash, muss beim Start gesendet werden, mit irgend einem 80er Jahre Protokoll, argh....
Wenn man sich schon die ganze Mühe macht, FOC zu verstehen / implementieren/ Verbessern, dann doch bitte als "Rechenkern" mit sauberem Schichtenmodell auf möglichst offener / gut verfügbarer Hardware:
High Level ARM/RISCV basiertes Board (momentan z.B. irgend ein RPI nano Klon) mit 20+GPIO auf dem man auch mit OS Toolchain kompfortabel debuggen / "flashen" kann, da wird auch in mehreren Ebenen/Schichten der ganze Kram bis hin zur Errechnung der PWM/DC aus den dann abstrakt definierten GPIO Signalen umgesetzt.
Die Taktfrequenz der Boards sollte ja locker für eine gescheite Signalabstastung reichen. Dann kann man das evtl. auch direkt in Hochsprache umsetzen, wenn das Board 2GHZ kann, nehm ich irgend eine C++/Java Math Library und kann mich mehr ums Was, anstatt ums Wie kümmern. Das Board braucht dann 2W statt 1W, schrecklich ;-)
Und dahinter nur noch eine OS Platine mit den AD Wandlern und dem Hochstrom Gedöns.
Es müsste halt mal einer eine eben diese moderne und einfach zu bestückende 6/9/12/18 Hochstrom Platine entwickeln, die auch stabile 5V für das Digitalboard und weiteres (BT) liefert.
Auf der komplett anderen Seite sind dann Leute die sich ein Fertigbike kaufen. >90% davon würden eh schon mal nie im Leben auf die Idee kommen dadran rumzufrickeln, selbst wenn ihnen die Steuerung nicht gefällt.
Wieviel von den <10%, die das doch tun wollen kaufen überhaupt erst so ein Fertigbike statt ein billiges China Kit mit dann halt KT drin.
Und von dem Rest: Wieviel frickeln dann am teuren Fertigbike (mit einer alpha Software) rum.
Das muss man ja dann auch laufen bekommen. Wenn ich mir überleg, wie viel Zeit ich allein bei der KT Software versenkt hab, bis ich da durchgestiegen bin und anfangen konnte Probleme zu lösen....
Für meinen Teil finde ich das zwar alles sehr spannend, hätte auch Lust mal andere Controller zu probieren, aber eigentlich stört mich der Umweg über "andere Controller" schon ich möcht lieber gleich was besseres:
Mich stösst z.B. das rumhantieren mit verschiedenen Displays Protokollen ab - deren Halbwertzeit eh sehr begrenzt ist-. Mal ehlich, wir haben 2019, wozu noch diese ganze Bitfrickelei, das ist doch reine Zeitverschwendung. Dazu die ganzen Unzulänglichkeiten aufgrund zweifelhafter Designentscheidungen in proprietären Komponenten: STM32 kein Flash, muss beim Start gesendet werden, mit irgend einem 80er Jahre Protokoll, argh....
Wenn man sich schon die ganze Mühe macht, FOC zu verstehen / implementieren/ Verbessern, dann doch bitte als "Rechenkern" mit sauberem Schichtenmodell auf möglichst offener / gut verfügbarer Hardware:
High Level ARM/RISCV basiertes Board (momentan z.B. irgend ein RPI nano Klon) mit 20+GPIO auf dem man auch mit OS Toolchain kompfortabel debuggen / "flashen" kann, da wird auch in mehreren Ebenen/Schichten der ganze Kram bis hin zur Errechnung der PWM/DC aus den dann abstrakt definierten GPIO Signalen umgesetzt.
Die Taktfrequenz der Boards sollte ja locker für eine gescheite Signalabstastung reichen. Dann kann man das evtl. auch direkt in Hochsprache umsetzen, wenn das Board 2GHZ kann, nehm ich irgend eine C++/Java Math Library und kann mich mehr ums Was, anstatt ums Wie kümmern. Das Board braucht dann 2W statt 1W, schrecklich ;-)
Und dahinter nur noch eine OS Platine mit den AD Wandlern und dem Hochstrom Gedöns.
Es müsste halt mal einer eine eben diese moderne und einfach zu bestückende 6/9/12/18 Hochstrom Platine entwickeln, die auch stabile 5V für das Digitalboard und weiteres (BT) liefert.
