barney

Betriebssystem: Bananian würde ich favorisieren. Der Raspberry hat einen anderen ARM-Prozessor. Da müssen wir uns nicht orientieren. Akkuüberwachung: http://hardware-libre.fr/2014/11/banana-pi-axp209-battery-power-monitoring/ Wiring Pi: http://wiki.lemaker.org/WiringPi http://www.bananapi-kaufen.de/tag/gpio/ I2C: http://www.bananapi-kaufen.de/tag/gpio/ 40 Pin Anschluss: http://forum.lemaker.org/thread-10852-1-1-banana_pro_pin_definition.html Zeitsynchronisation GPS ist mit NTP total easy

Keine Leistung ohne Gegenleistung :devil:# Ich bitte dich hiermit, die aktuelle Fassung von http://www.elektro-skateboard.de/wiki/wissenswertes/teensy-programmieren durchzugehen. Ich habe nach deinen gestrigen Fragen einige Anpassungen vorgenommen. Sind diese hilfreich? Anmerkungen nehme ich gerne entgegen!

Jup ab jetzt im Teensy

Macht nix. Und gehts?

Bei define muss ein # stehen. True oder false ist der Schalter. Serial1 oder Serial bestimmt den Ausgang.

# muss stehenbleiben! Die Zahl hinten ist wichtig!

Ja! Die LED blinkt sekündlich wegen der Temperatursensorabfrage. Aber zu deiner Frage: Serielles Debugging durch aktivieren der Debug Anzeige oder #define Serial_BT Serial // Sollen die Werte fuer die BT-Schnittstelle auf USB oder Serial fuer das Debugging ausgegeben werden? #define Serial_DB Serial // Ausgabe der Debug Werte auf USB oder Serial ausgegeben werden? Dann werden die Messwerte über den USB-Anschluss des Teensy ausgegeben. Für das Debugging kann nach übertragung des Programms Unter TOOLS -> Serial Monitor gestartet werden.

Ich benutze Windows 7 und 8.1 und habe nicht diese Probleme. Ansonsten https://forum.pjrc.com/threads/27403-Teensyduino-1-21-Test-2-Available

Hast du als Admin die Installation durchgeführt? http://www.elektro-skateboard.de/wiki/wissenswertes/teensy-programmieren

Immer noch kein Namen[emoji22]

Die Finanzierung kam nicht zustande. Ist leicht zu googeln.

Eine sehr subtile Botschaft http://www.bubblegumboards.com/

Hallo elkick, ein Forum wie dieses, ist aus meiner Sicht dafür da, Erfahrungen mit anderen zu teilen, auch negative, wenn begründet. Natürlich sollte auch ggf. Ein Hersteller vorher informiert werden, damit der den Mangel beseitigen kann. Er sollte sich auch dazu äußern und Abhilfe aufzeigen. Daher finde ich schon, dass es wichtig ist, dass du uns schreibst, was dir aufgefallen ist. Ich sehe da kein Problem.

Protokoll: Einfaches Serielles Protokoll wie beim Sigma: "The transmission starts with a BOT (Begin Of Transmission – 0x11), followed by the command byte. After the command the payload for the command is transmitted. The amount of data for the payload is depending on the command. That means that there is not a fixed frame size. After the payload a crc8 calculated over the command and payload data is transmitted, followed by an EOT (End Of Transmission – 0x13)." Baudrate: Seriell 230400,8N1 Interface: a.) 3 Draht Serielle Rx, Tx und GND nicht potentialfrei b.) Bluetooth Wir müssen nur noch die command bytes festlegen. Der Teensy sendet ohne Anfrage und/ oder kann gezielt abgefragt werden. Das kann jeder umsetzen.

Parametrieren ist ein absolutes Oberziel!

Wie jeder Platz hat. Ich bekomme es im Bard unter. Andere ggf. nicht. Ich will nur keinen abkoppeln vom Projekt.

Das GPS-Modul hatte ich nur wegen der 6-9 Achsen Sensoren auf das Skateboard logisch verlagert. GPS selbst macht dort keinen wirklichen Sinn. Die Sensoren müssen natürlich richtig ausgerichtet werden. Was hältst du von der Tupper Idee? Natürlich im Übertragenen Sinn? http://en.wikipedia.org/wiki/Comparison_of_single-board_computers Da findest du Modelle mit ADC, DAC usw.

Hi FlyRasch, Beatbuzzer und Kai, noch ein Gedanke! Da der Banana PRo nun nicht gerade in Chrizz Pockedboard passt und er sicherlich nicht alleine dasteht, habe ich folgendes überlegt: Der Banana Pro wird ein autarkes System in der Tupperbox! D.h. Der Banana Pro kann ein LiPo verwalten, dass ist schon alles onboard. Durch die BT-Schnitttstelle koppelt man den Teensy mit den Banana Pro (BT-Dongle im USB). Dieses Konstrukt kann man in der Brotbox im Rucksack bei sich führen. Alle Daten werden im Banana geloggt und per Webservice bereitgestellt. Der GPS-Empfänger und weitere Sensoren (6,9-Achsen Sensoren) werden am Teensy gekoppelt und als Telemetrie-Daten an den Banana übertragen. Dieses Vorgehensweise erleichtert stark den technischen Aufbau. Der Banana Pro kostet € 45,- ein USB-BT-Dongle bekommt man für € 5,-. Das Akku, welches 3.3V bereitstellt, müsste um die 5Ah haben. Mit Kleinkram sollte ein Telemetrie-System unter € 100,- hinzubekommen sein. Und auch Beatbuzzer könnte das Projekt, wenn wer möchte, mitnutzen. Ich würde ein einfaches Protokoll verwenden mit Start- und Stopp-Symbol und CRC Absicherung. Das senkt den Implementierungsaufwand und ist für jeden portierbar. Da derzeit 15 Teensy Platinen im Umlauf sind, koppeln wir hier keinen ab! Keine Löterei, keine Modifikationen am Teensy System! Was haltet ihr davon? P.S.: http://hardware-libre.fr/2014/11/banana-pi-axp209-battery-power-monitoring/

<Gedanken> Modularer Aufbau Nachgedanken: Ich habe mir nochmals verschiedene Board angesehen. Klar gibt es auch andere Schöne Boards. Bei den einen Fehlt WLAN, beim anderen x, y, ... Ob Raspberry, Banana Board oder wie sie heißen, stellt sich immer die Frage, warum nicht gleich die Steuerung mit dem Board. Ich habe für mich mehrere Argumente gesammelt, warum nicht mit dem großen Board gesteuert wird. * Die CPU-Frequenz verändert sich, je nach Lastsituation * Es sind wichtige Schnittstellen wie ADC, DAC und PWM nicht vorhanden, oder nicht in der Qualität wie sie benötigt wird. * Ein Riesiges Betriebssystem mit vielen Unbekannten * keine feste Zeitscheiben Klar kann man mit einigen Tricks in der Software die Steuerung leicht portieren, es fehlen dann immernoch einfach die wichtigen Schnittstellen. Und gerade ein variabler CPU-Takt, und die PWM kann einen den Tag verhageln. (Gerade im Forum gelesen, dass sich die PWM-Frequenz mit dem CPU-Takt verändert hat) Die nächste Frage ist auch, wie lange bekommt man ein bestimmtes Board. Man macht sich ggf. sehr abhängig von einer bestimmten Ausführung. Für mich ploppen immer wieder Argument hoch, die mir aufzeigen, dass ein Mikrocontroller für die Zeitkritischen Anforderungen und für die I/O analog, wie digital, der bessere Kandidat ist. Der Banana ist das NTH eines Skateboards. Sozusagen der Tieferlegungssatz der Bord-Elektrik. Schön wenn man ihn hat, aber auch kein Totalverlust. Daher auch die Überlegung keine Aufsteckplatine für den Banana Pro mit dem Teensy zu basten, sondern den bewährten Teensy im Detail verbessern und am Banana Pro per Serielle (UART, I2C) andocken. Die Spannungsversorgung wird in Zukunft 5V auf dem Teensyboard betragen. Mit den 5V soll ggf. auch ein Banana versorgt werden. Der Teensy hat einen eingebauten Schaltregler um aus den 5V 3.3V zu generieren. Weiter möchte ich die Qualität der analogen Sektion verbessern, indem aus 5V per "analogen" Längsregler 3.3V erzeugt wird. Der Stromsensor wird sich mit einer höheren Messgenauigkeit bedanken. Vielleicht schrumpfen zusätzlich die Optokoppler auf SMD-Größe. Die Eingangsspannung wird auf ca. 60V erhöht. Da ist aber dann Schicht im Schacht! Nein, keine 100V für Beatbuzzer. Auch kein Drehstromanschluss! </Gedanken>

Ich relativiere mal meine Aussage, das man die Ports beliebig verschieben kann. Mann kann wie beim Teensy den Ports verschiedene Funktionen zukommen lassen. Ab Seite 20 wird es ein klarer. https://dl.linux-sunxi.org/A20/A20%20Brief%202013-02-27.pdf

Hi FlyRasch Und hast du schon den Lötkolben geschwungen?

Banana Pro Verschiedene Images für den Banana Pro sind mit Vorsicht zu genießen. Ich wollte die Seriellen Schnittstellen ausprobieren und hatte nach der ersten Seriellen Schnittstelle das große staunen. Die zweite Schnittstelle kam an einen Ort raus, wo ich nicht mit gerechnet hätte. Der A20 ist recht frei konfigurierbar. Es kann frei festgelegt werden, wo was herauskommt. Und das mache manche wirklich. Und nicht jedes Image schaltet alles frei. Das ich erwischt hatte, hat die zweite und dritte Serielle Schnittstelle nicht aktiviert. ist aber leicht abzuändern. Im /boot Verzeichnis ist eine banana.bin Datei vorhanden, die mittels bin2fex in menschlich lesbaren Code verwandelt werden kann. Dort kann abgelesen werden, welche Schnittstellen aktiviert sind und wo diese herauskommen. Diese Datei kann mittels fex2bin leicht generiert werden. Ein reboot später läuft die neue Konfiguration. Wirklich sehr einfach.

i2c Der Teensy 3.1 hat mit einer speziellen Lib zwei i2c-Anschlüsse. 29(SCL1)/30(SDA1) and 26(SCL1)/31(SDA1). https://forum.pjrc.com/threads/21680-New-I2C-library-for-Teensy3 Leider liegt der zweite Anschluss auf der Unterseite des Teensys. Aber es gibt ja noch den Anschluss 18(SDA0)/19(SCL0). Dort hängt momentan der Nunchuk dran. Da es ein Bus ist, können wir hier auch den Banana Pro ranhängen. Der Zweite Anschluss hat den Vorteil, dass der Bus auf einer höhren Datenrate eingestellt werden kann. CRC Es reicht völlig aus, wenn es bekannt wird, dass die Übertragung fehlerhaft ist. Da es sich um Messdaten handelt, können diese einfach verworfen werden. Wir sollten nur einen Counter integrieren, der Aufzeigt, dass da was nicht stimmt. In einen zweiten Schritt, kann ein Resent integriert werden. Messintervall Bis jetzt übertrage ich per Bluetooth im Sekundentakt telemetrische Daten. Durch die Speicherkapazität und Geschwindigkeit des Banana Pro können für einen kleinen Beobachtungszeitraum "Echtzeitdaten" übertragen werden. Ich stelle mir vor, Messwerte von Strom und Spannung für 60 Sekunden im 10ms Intervall zu übertragen. Diese können für einen besondere Analyse des elektrischen Systems herangezogen werden.

Können wir CAN bitte canceln. Bitte erst auf den Teensy schauen. Viele Pins sind nicht mehr frei. 2 Serielle und ggf. ein i2c Anschluss! Bei einer Übertragungsstrecke von wenigen cm mache ich mir da keinen Kopf. CRC hinten ran und gut ist. Reicht beim Sigma auch.

CRC Da habe ich für den Sigma eine Teensy angepasste Lib. 5V zu 3.3V kann der Teensy. Da ist ein Regulator vorhanden.