Kai

Banana pro ist bestellt! Teensy flashen ohne Button auf dem Teensy drücken zu müssen: http://www.pjrc.com/teensy/jump_to_bootloader.html Teensy -usb- Banana http://www.pjrc.com/teensy/usb_serial.html

Ein Microphone ist auch dran. "Moses, wie weit kommen wir noch?"

WIESO WESHALB WARUM Wer mich fragt bleibt dumm :devil:

Darüber hatten wir es schon, schmeiß das WLAN-Modul weg, wir verpassen Debian Räder. Banana pro - USB - Teensy, so dass man den Teensy über den Banana Pro aus Flashen kann. Herrlich und das über Wlan. Hupe: Banana pro AudioOut vollwertiger Webserver ...

However, hau weg den Chip :cornut: Ich war doch eh für ein kleines Debian :peace: Ich würde mich dann auf deine Wahl zu der Profi Banane verlassen und es dann später auch bestellen.

Dann musst du noch die Prioriäten definieren, sonst dürfen sich die Timer gegenseitig unterbrechen. Die Motorsteuerung kann ohne Priorität auch unterbrochen werden von den anderen beiden Timern und den anderen Interrupts die Teensy so anbietet. Die wichtigen Funktionen sollten zwischen 0 - 127 sein. Die unkritischen zwischen 129 - 255. In der Doku steht die meisten andern Intrerrupts haben 128 als Priorität. Webserver läuft doch auf dem ESP8266. Teensy muss nur die Telemetriedaten über seriell an den ESP8266 bereitstellen. Entwerder pusht Teensy die über einen Timer oder besser, die Telemetriedaten werden erst dann gelesen wenn der ESP8266 die Daten abruft. ServialEvent() So das der ESP8266 die Daten nur bekommt wenn er loggt oder jemand mit dem Webserver verbunden ist. wenn man an den ESP8266 eine sd card bekommt wäre eh besser auch für das Docroot des Servers. Oder willst du mit dem ESP jetzt gar nix mer machen? ... Mal sehen du schickst mir ja eins mit. Auf keinen Fall. Das bekommt man aber bestimmt noch optimiert, die ganzen unnötigen Treiber raus, nicht in den Windowmanager booten ... Gut also bei meinem Beispiel könnte die Motorsteuerung auch unterbrochen werden von irgendwelchen teensy interrupts. Aber nicht von den Timern. Schön wäre es natürlich wenn man auch normalen Funktionen eine Priorität geben könnte, vielleicht geht das, so tief bin ich noch nicht drin. Der Gedankenansatz im Beispiel ist die Motorsteuerung ohne Verzögerung auszuführen, auf Interrupts komplett zu verzichten aber trotzdem Funktionen mit Timerintervall zu haben. Aber angenommen die Ausführung einer Timer-Funktion dauert länger als der Intervall des Timers was passiert dann? Um erstmal festzustellen wie lange die Funktionsaufrufe dauern habe ich if (DEBUG_Runtime) { // Variable zur Messung der Ausführungszeit elapsedMicros Runtime; } ... if (DEBUG_Runtime) Serial_DB.println("tmrTelemetrie tmrTelemetrie_timeout: Runtime Start"); ... if (DEBUG_Runtime) Serial_DB.println("tmrTelemetrie tmrTelemetrie_timeout: Runtime Ende"); eingebaut. So kann man feststellen wie lange die Funktionen laufen und wie lange es dauert bis zum nächste Loop und Motorsteuerungsaufruf. Nur als Beispiel, in der Endfassung würde ich nicht nur den Zeitstempel sondern auch die Differenz, also die Laufzeit ausgeben ... Alles mit Interrupts zu machen ist am Ende meiner Meinung nach intuitiver und einfacher und besser strukturiert programmierbar. serialEvent() wäre zb die Callback-Funktion die gefeuert wird sobald Daten da sind. Leider steht in der Doku nicht wie die Priorität des Interrupts ist. Im Zweifelsfall 128 aber das kann man rausfinden. Wird in der Nunchuck LIB alles gepollt oder kann man dort auch mit ISR arbeiten? Muss ich mir noch ansehen...

Wie sind die Realtime Anforderungen eigentlich für die Steuerung? Also wie schnell muss die Reaktionszeit sein? Momentan wird ja nur alle 50ms gefeuert. Also wäre alles was <50ms abgearbeitet wird Realtime für die Motorsteuerung und FB. Bei Computeranwendungen würde eine Reaktionszeit von <= 10ms als sofort wahrgenommen werden. Brauchst du die IRQ-Timer? Falls ja würde ich die Timer noch priorisieren und den Timer für Nuchchuk und Motorsteuerung maximal 5ms setzen. Andere Möglichkeit wäre alles in der Loop-Routine abzufackelen und mit elapsedMillis arbeiten. In dem Beispiel werden alle 100ms die Telemetriedaten eingelesen, jede Sekunde ein zweiter Timer gefeuert und die Motorsteuerung so schnell es die Hardware hergibt. Die Motorsetuerung wird so zu dem definierten intervallen unterbrochen. Wie lange das sein kann wird mit der elapsedMicros Variable gemessen. So können wir feststellen ob uns das alles noch realtime genug ist. // Timer für das Einlesen der Telemetriedaten elapsedMillis tmrTelemetrie_elapsedMillis; uint16_t tmrTelemetrie_timeout = 100; // Timer2 als weiteres Beispiel elapsedMillis tmrTimer2_elapsedMillis; uint16_t tmrTimer2_timeout = 1000; if (DEBUG_Runtime) { // Variable zur Messung der Ausführungszeit elapsedMicros Runtime; } void loop() { if (DEBUG_Runtime) Serial_DB.println("loop: Runtime Start"); // Funktionsaufruf für Nunchuck //... // Funktionsaufruf für Motorsteuerung //... if (tmrTelemetrie_elapsedMillis >= tmrTelemetrie_timeout) { if (DEBUG_Runtime) Serial_DB.println("tmrTelemetrie tmrTelemetrie_timeout: Runtime Start"); // Telemetrie Timeout zurücksetzten tmrTelemetrie_elapsedMillis = tmrTelemetrie_elapsedMillis - tmrTelemetrie_timeout; //Funktionsaufruf fürs auslesen der Telemetriedaten //... if (DEBUG_Runtime) Serial_DB.println("tmrTelemetrie tmrTelemetrie_timeout: Runtime Ende"); } if (tmrTimer2_elapsedMillis >= tmrTimer2_timeout) { if (DEBUG_Runtime) Serial_DB.println("tmrTimer2 tmrTimer2_timeout: Runtime Start"); // Timer2 Timeout zurücksetzten tmrTimer2_elapsedMillis = tmrTimer2_elapsedMillis - tmrTimer2_timeout; //Funktionsaufruf für Timer2 //... if (DEBUG_Runtime) Serial_DB.println("tmrTimer2 tmrTimer2_timeout: Runtime Ende"); } if (DEBUG_Runtime) Serial_DB.println("loop: Runtime Ende"); } (Der Code ist nur zur Veranschaulichung) Das Einlesen der Telemetriedaten würde ich noch schaltbar machen wollen. Wenn die Daten nicht geloggt oder angezeigt werden kann der Timer aus sein. Die Ausgabe ebenso. Wenn keiner da ist der die Ausgabe haben will kann der Timer aus bleiben.

Buggy Programme könnten Probleme mit dem Realtime Kernel Patch machen. Ein Grund den Patch sein zu lassen. Und vielleicht reicht es auch einfach schon mit die Software mit nice -20 zu starten oder mit chrt -f 99 Den 50ms Timer für die Motorsteuerung-Routine einzuhalten sollte ja kein Problem sein, solange parallel kein Youtube-Video in FullHD auf der Banane läuft. Die Daten vom Nunchuck werden momentan auch nur alle 50ms gepollt. siehe http://www.elektro-skateboard.de/forum/eigenbauten-95/wii-nunchuck-mit-teensy-3-1-a-2540-103.php#post26364 thread Für mich wäre die Frage noch offen ob ein SBC mit allen nötigen Schnittstellen ok wäre, Preisleistungs, Stromaufnahme und Performancemäßig. Ich tendiere aber zu der Modularen Lösung

Klingt super, auch das alles Modular aufgebaut sein wird. Ich les mich gerade ein wenig in die Echtzeitprogrammierung ein und hab eben das hier entdeckt: http://debian.pengutronix.de RT Kernel für Debian, allerdings für i368 und 64Bit AMD/Intel CPUs und nicht den Cortex A7 ...Realtime Linux für den Fall auch komplett auf Banana Pro oder einen alternativen SBC gehen zu können. Für den Modularen Aufbau, wenn Teensy die Echtzeitroutinen macht brauchen wir keinen Realtime Kernel. Mich interessiert es gerade nur was mit dem Linux Kernel machbar wäre. Eventuell kann man den Kernel für den Banana mit den rt-Patch selbst kompilieren. Falls der nicht eh schon drin ist. https://rt.wiki.kernel.org/index.php/Frequently_Asked_Questions

hehe ok. Barney, willst du die Arduino source trotzdem ins git stellen? Tut ja nicht weh.

@barney: Ich hab für das Controller Nunchuck Arduino Projekt auch ein git Repository erstellt. Sobald barney die Sourcen ins git gestellt hat kann es entweder per git über git clone http://esk8b.de/git/Controller_Nunchuck_Arduino oder als zip http://esk8b.de/git/Controller_Nunchuck_Arduino.zip geladen werden. Wer auch Schreibzuriff haben möchte meldet sich bei mir.

Ein Traum, 44,2 Ah :cornut: Ich nehme dann bei der nächsten Tour vorsichtshalber ein Abschleppseil mit. Mit meinen 20 Ah komm ich ja nicht mal auf die Hälfte :drama:

Juhu langsam kommt das Brainstorming ins Rollen Weiter so!!! @Fly: Wie? Du hast erst _nach_ der Mädels-Party den Keller zum Basteln?

Ist das etwa ein BMS? Ich mein den Kondensator zwischen dem Minuspol der ersten Zelle und dem Pluspol der Zweiten. GP60 010 steht da drauf.

BOSS - Dann können wir zur Taufe mit eisgekühlten Hugo anstoßen Bossy Board? Herleitung: Barney B [st]arne[/st] y B OSS y

Geil: http://sharkwheel.com Ich überleg schon wie ich da ein Ritzel dran krieg

Ehm noch ein Hinweis zur Anmeldung:

N = Nicht auf Rekursion, steht der Barney? Vielleicht sollte man einfach keine Parallelen zur Bibel ziehen und die Sache mit etwas mehr deutscher ernstahftigkeit angehen. Mofa Moped Moses :peace:

Dann halt Moser - ... rollbrett oder doch Poser :popcorn:

Der Vorteil ist das du dich einfach mit einem Browser deiner Wahl auf dem Gerät deiner Wahl mit dem Board verbinden kannst. 100% kompatibel. Es muss keine App für Endgeräte programmiert da die Applikation onBoard ist. Es ist ausbaufähig. Version 1.0 Einfach Anzeige der Daten. Version 2.0 Konfigurationsparameter können geändert werden Version x.0 Das Board wird ein Teil der IoT (Internet of Things) Meldet zb auf dein Handy wenn der Akku voll ist, oder schaltet selbst die Funksteckdose in dem das Ladegerät steckt aus und geht auf Standby. GSM als Addon, als Ortung und zur Fernsteuerung wenn das Board geklaut wurde. Ich würde das auch noch auf den Wunschzettel vom Weihnachtsmann schreiben wenn noch platz ist - logisch So wie ich das verstanden hab läuft der ESP8266 doch quasi Autark und wird über AT-Befehle nur konfiguriert (WLAN Mode etc.). Irgendwie müssen die Telemetriedaten aus dem Teensy in den ESP8266. Über die serielle Schnittstelle oder so ein GPIO port? Keine Ahnung. Das ganzen WLAN und HTTP Zeug macht der ESP8266 selbst. Dazu muss man den mit seiner angepassten FW flashen, was über die Arduino IDE geht. Richtig? Der Teensy muss die Telemetriedaten nur FIFOmäßig flüstern. Das Loggin kann dann machen wer will. Entweder der ESP8266 oder irgendwas anderes, von mir aus auch eine App über Bluetooth. Das eine schließt das andere ja nicht aus. Ich brauch erstmal die aktuelle Hardware hier damit ich mir ein besseres Bild machen kann. So ist mir das alles zu theoretisch

Wie gesagt, mit FreeRTOS habe ich auch noch keine Erfahrung. Ich würde sagen wir machen das in der ersten Version erst mal mit dem WLAN Chip und nur um Daten abzufragen beziehungsweise zu exportieren. Um den Webserver und die Anzeige der Daten kümmere ich mich dann ich muss nur wissen wie ich die Daten lesen kann. Ein extra board mit debian Linux wär zwar richtig cool aber das zieht natürlich auch mehr Strom. Von daher wäre es meiner Meinung nach am sinnvollsten wenn das alles Modular aufgebaut ist. Die Grundfunktionen und Hardwarenahen Sachen eben mit Teensy und alle Schnickschnack Erweiterungen plugabel.

Ja ich habe dem Händler ja schon bereits eine E-Mail geschrieben. Wenn ich mir aber überlege was für ein Aufwand es ist einen Karton zu kaufen den Nunchuck wieder zusammen zu schrauben, ihn zu verpacken und auf die Post zu bringen... Da investiere ich meine Zeit und mein Geld lieber in eine Performancesteigerung von 41, Periode 6 % durch einen neuen Akku. Der Händler solle einfach ein paar Euros gutschreiben und gut ist.

Ich hab mir auch noch kein Freebord bestellt, das würde doch nur die meiste Zeit in der Ecke stehen. Das neue Z-Board, ist interessant ja, bin gespannt auf deine Erfahrungsberichte :thumbsup:

Du weißt doch genau das ich noch überhaupt keine Erfahrung mit dem Arduino / Teensy habe und fragst mich sowas :noidea: Ich nehme an du denkst darüber nach wegen Multitasking und ereignisgesteuerten Funktionen? Ich kann dir leider keine Vor/Nachteile gegenüber dem was sonst so mit Arduino geht nennen. So aus dem Bauch raus vermute ich aber das der Umstieg auf Freertos als Unterbau bedeuten würde den komplette Code neu zu schreiben und einige Libs wie zb die Nunchuck auf freertos portiert werden muss. Na siehst, gibt doch ne Lib. Kann man an das WLAN Modul einen Schalter und LED löten um den Betriebsmodus zu wählen? HIGH: AP-Mode, wenn bereit LED blinkt / Anzahl verbundener clients > 0: LED leuchtet LOW: Client-Mode: WLAN Modul verbindet sich mit voreingestellten WLAN als client. Und noch einen an/aus Schalter

Die Reichweite von 12 Kilometern ist echt sehr knapp. Also zum ausprobieren und als Spassgerät bei Events reicht es erstmal. Wenn nicht habe ich da einen guten Kollegen mit Punktschweißgerät für Akkus ;-) Und das ZBoard?