Banana Pro & Teensy

[barney]

GPS-Modul: € 40,- ist sehr hoch gegriffen. Da gibt es deutlich billigere Boards von µ-Blocks.

CRIUS NEO-6 V3.0 GPS NEO-6M

 

€ 19,-

[barney]

Wollen wir für die serielle Kommunikation ein eigenen Datenprotokoll austüfteln oder auf was etabliertes zurückgreifen wie zb Modbus ASCII?

Hat da jemand Erfahrung?

 

Für ein Eigenes werfe ich den ersten Entwurf zur Ausarbeitung in den Raum:

 

   2Byte      1Byte        2Byte
+---------+-----------+------------+- - - - - - - - - - - - - - -
|   Go    |   Format  |    Länge   |  Datenblock 
+---------+-----------+------------+- - - - - - - - - - - - - - -

Go: Startflag, Kennzeichnet den Beginn eines neuen Datenblockheaders. x00 xFF oder sowas.


Format: gibt den Inhalttyp des Datenblocks an
gültige Werte 001 - 255
Beispiele:
000 ungültig
001 API v1 JSON
002 API v1 XML
003 API v1 Eigenes Format X
...
255 API vEndgültigFertig DasLassenWirJetztSoFormat
Hier wird nur das Datenformat angegeben.
In den Daten selbst kann dann definiert werden um welche Daten es sich handelt.
Telemetriedaten, Setupdaten ...

Länge: gibt die Länge in Bytes des Datenblocks an
gültige Werte 001 - 65535 Bytes
Reichen uns 64kByte?
Wir könnten auch 4Byte bzw. 32bit nehmen für maximal 4GB große Datenblöcke.
Soviel werden wir nie brauchen.

 

Denk bitte daran, das Datenformat so einfach wie möglich zu gestalten. Der Teensy sollte ein kompaktes Programm bekommen. Ich sehe mir mal die JSON Lib an.

 

Edit: Dein Vorschlag hat was....

[Beatbuzzer]

@barney: Ok, Sicherheit spielt ne Rolle wenns für alle ist. Das vergesse ich leider immer zu schnell ...

Was den Ripple angeht würde ich µCs oder zumindest den Analogteil davon auch nie direkt aus Schaltreglern versorgen. Hat der Teensy da keine getrennte Speisung? Bei Dir mit 3,3V ist das echt ideal. Da hast linear von 5V runter kaum Verlust.

 

@Kai: Ich würde versuchen, eine feste Länge zu finden. Sonst bräuchte es ja noch dynamische Arrays, und das ist mir bei der Grösse auf begrenzten µCs schon unheimlich.

Dafür aber in jedem Fall noch ne CRC anhängen. Wer weiss, wie später mal die Kabel liegen und wo noch die dicken Ampere des Antriebs mit einstreuen. Nicht, dass da mal Müll ausgewertet wird.

Da wäre es in rauen Umgebungen auch mit kürzeren Datenpaketen besser. Erzeugt zwar etwas overhead bei grossen Datenmengen, aber ist dafür in Fehlerfällen schneller neu gesendet und braucht auch nicht soviel ram in kleinen Controllern...

[barney]

CRC

Da habe ich für den Sigma eine Teensy angepasste Lib.

 

5V zu 3.3V kann der Teensy. Da ist ein Regulator vorhanden.

[Kai]

billigere Boards von µ-Blocks.

CRIUS NEO-6 V3.0 GPS NEO-6M

€ 19,-

 

Okay, für UART, viel besser, kann direkt auf auf die 40Pinleiste gesteckt werden.

 

 

Ich würde versuchen, eine feste Länge zu finden. Sonst bräuchte es ja noch dynamische Arrays, und das ist mir bei der Grösse auf begrenzten µCs schon unheimlich.

Dafür aber in jedem Fall noch ne CRC anhängen. Wer weiss, wie später mal die Kabel liegen und wo noch die dicken Ampere des Antriebs mit einstreuen. Nicht, dass da mal Müll ausgewertet wird.

Da wäre es in rauen Umgebungen auch mit kürzeren Datenpaketen besser. Erzeugt zwar etwas overhead bei grossen Datenmengen, aber ist dafür in Fehlerfällen schneller neu gesendet und braucht auch nicht soviel ram in kleinen Controllern...

Können wir versuchen. Es muss aber trotzdem flexible bleiben, zb für die Temperatursensoren die in Unterschiedlicher Anzahl vorhanden sein können.

Mit eine festen Länge kommen wir nicht hin, viele feste Längen, wenn wir jeden Wert, oder jedes Key=Value Paar einzeln übertragen.

Das treibt den Aufwand um einiges in die Höhe. Auf der Sender und Empfänger Seite.

Abwärtskompatibelität ist auch nicht.

 

Einer von der Größe variabler Payload beim Daten-Protokol setzt keine dynamischen Arryas in der Programierung voraus.

Dynamisch Speicher allozieren wird aber so oder so nicht ausbleiben.

Wenn die Parameter für den Controller über das Webinterface eingestellt und im EEPROM (2048 Bytes) (oder im Flash 256kB - Firmware, wenn das geht) des Teensys gespeichert werden.

Zb wenn im Webinterface die Anzahl der TempSensoren und deren Adressen eingetragen werden können.

 

Also momentan sagt mir eine dynamische Paketgröße und JSON noch am meisten zu weil wir damit flexibel sind. Liegt aber auch daran das ich noch nicht weis wo die Reise hingeht

 

Oder auf ein anderes Protokoll setzen welches weniger Störanfällig ist bzw. so nette Features wie CRC unter der Haube hat aber trotzdem nicht zu überladen ist.

I2C, SPI, PWM, CAN, I2S, SPDIF, LRADC, ADC, LINE-IN,FM-IN,HP-IN.

Das sind die Protokolle die man für die GPIO Ports einstellen kann.

Ist da was bei? CAN Bus vielleicht, hat sich in Autos bewährt.

Ich komme eher aus der Ethernet TCP/IP Ecke, sorry

[Beatbuzzer]

I2C, SPI, PWM, CAN, I2S, SPDIF, LRADC, ADC, LINE-IN,FM-IN,HP-IN.

Das sind die Protokolle die man für die GPIO Ports einstellen kann.

Das sind erstmal nur Hardware-Interfaces, die man an die Port-Pins schalten kann. Was man dann darüber sendet, ist damit noch nicht festgelegt.

CAN ist aufgrund symmetrischer Übertragung natürlich von Grund auf schon super stabil.

Zur Kommunikation bleiben da nur I²C, SPI, CAN. Der Rest ist eigentlich nicht für Datenübertragung in diesem Sinne gedacht.

I²C und SPI sind eher für kurze Verbindungen, z.B. zwischen zwei ICs auf einer Platine oder zu einer SD-Card. CAN kann wegen der erwähnten symmetrischen Übertragung auch längere Strecken so wie z.B. im Auto.

Was die effiziente Programmierung von Kommunikation angeht, da bist Du zumindest was uns beide angeht der bessere. Ich krieg sowas zum laufen wenns sein muss, aber frag nicht nach platz- und ressourcensparendem Code

[Kai]

Das sind erstmal nur Hardware-Interfaces, die man an die Port-Pins schalten kann. Was man dann darüber sendet, ist damit noch nicht festgelegt.

Zumindest bei CAN hab ich jetzt auf

Externe Links nur für Mitglieder sichtbar

gelesen das es wie Ethernet auf Layer1 und 2 liegt. Also auch die Datensicherungsschicht. (CRC)

 

I²C wäre laut eher Störungsanfällig. Und da haben wir wie bei UART kein Übertragungsprotokoll.

 

Leider hab ich für den Teensy keine CAN-Lib gefunden:

Hier ist der (hab ich noch nicht gelesen)

 

Edit

CANbus Library for Teensy 3.1:

bearbeitet 11. Februar 2015 von Kai

[barney]

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.

[Kai]

Bei mir läuft alles was den Controller angeht so ziemlich im Blindflug da ich noch keine Hardware hab auf die ich schauen kann. Aber ich bin heiß drauf...

Morgen müsste der Banana Pro kommen und dann mach ich mich erstmal an den.

Du kannst eigentlich auch erstmal mit dem Sigma, low level brushless Algorithmus, ... ?weitermachen.

 

CAN Canceln, wenn die Pins schon weg sind bleibt ja nix anderes übrig.

Ein Bussystem, egal jetzt ob CAN oder i2c hätte gegenüber UART den Vorteil das so viele Teilnehmer wie adressierbar sind das Übertragungsmedium teilen können.

Ideal wäre es demnach das für unsere Zwecke beste Bussystem auszuwählen und nur diese Schnittstelle (und Teensy Pins) für die Kommunikation zwischen allen Komponenten zu nehmen. Ob das in der Praxis bereits umsetzbar ist? Vermutlich nicht, ohne alles oder vieles from Scratch zu programmieren.

Ob das so ist müssen wir sehen...

 

"CRC hinten dran und gut ist"

Ist die Fehlerkorrektur ist dann schon inklusive?

Eher nicht oder? Mehr als ein false wird nicht rumkommen wenn der Check fehlschlägt.

d.h der Empfänger muss dem Sender mitteilen können das die soeben gesendeten Daten bitte nochmal gesendet werden sollen. Das müsste von uns implementiert werden wenn das nicht schon ein paar Protokollschichten untendrunter transparent gemacht wird.

Ein komplettes Protokoll für die Kommunikation neu zu Erfinden macht bestimmt Spass, aber auf bewährtes zurückzugreifen und sich um auf die eigentlich Anwendung zu konzentrieren ist auch nicht schlecht.

bearbeitet 12. Februar 2015 von Kai

[barney]

Bei mir läuft alles was den Controller angeht so ziemlich im Blindflug da ich noch keine Hardware hab auf die ich schauen kann. Aber ich bin heiß drauf...

Morgen müsste der Banana Pro kommen und dann mach ich mich erstmal an den.

Du kannst eigentlich auch erstmal mit dem Sigma, low level brushless Algorithmus, ... ?weitermachen.

 

CAN Canceln, wenn die Pins schon weg sind bleibt ja nix anderes übrig.

Ein Bussystem, egal jetzt ob CAN oder i2c hätte gegenüber UART den Vorteil das so viele Teilnehmer wie adressierbar sind das Übertragungsmedium teilen können.

Ideal wäre es demnach das für unsere Zwecke beste Bussystem auszuwählen und nur diese Schnittstelle (und Teensy Pins) für die Kommunikation zwischen allen Komponenten zu nehmen. Ob das in der Praxis bereits umsetzbar ist? Vermutlich nicht, ohne alles oder vieles from Scratch zu programmieren.

Ob das so ist müssen wir sehen...

 

"CRC hinten dran und gut ist"

Ist die Fehlerkorrektur ist dann schon inklusive?

Eher nicht oder? Mehr als ein false wird nicht rumkommen wenn der Check fehlschlägt.

d.h der Empfänger muss dem Sender mitteilen können das die soeben gesendeten Daten bitte nochmal gesendet werden sollen. Das müsste von uns implementiert werden wenn das nicht schon ein paar Protokollschichten untendrunter transparent gemacht wird.

Ein komplettes Protokoll für die Kommunikation neu zu Erfinden macht bestimmt Spass, aber auf bewährtes zurückzugreifen und sich um auf die eigentlich Anwendung zu konzentrieren ist auch nicht schlecht.

 

i2c

Der Teensy 3.1 hat mit einer speziellen Lib zwei i2c-Anschlüsse. 29(SCL1)/30(SDA1) and 26(SCL1)/31(SDA1).

Externe Links nur für Mitglieder sichtbar

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.

[barney]

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.

[barney]

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.

Externe Links nur für Mitglieder sichtbar

[barney]

<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>

[FlyRasch]

Hallo Barney,

ich finde das auch die beste Lösung.

 

Der Mikrocontroller erfasst die Messwerte und kann bei Bedarf auch direkt in die Steuerung eingreifen. Die erfassten Messwerte werden über eine definierte Schnittstelle ( BT und/oder I2C / UART ) an ein evtl vorhandenes Partnersystem weitergereicht.

 

Dieses kann dann die erfassten Daten Speichern, evtl mit weiteren Daten ( GPS ... ) und diese vielleicht via Webserver und Wlan anderen zugängig machen.

 

Damit bleibt man Modular und man kann wenn ein Gerät abgekündigt wird relativ einfach auf ein anders Modul ausweichen.

 

Modular, nachrüstbar und austauschbar.

 

Also nicht wie bei einem Serienboard das man weg werfen muss wenn der eingebaute Aschenbecher voll ist und man keinen passenden nachkaufen kann. ( na ja ich denke, Ihr wisst was ich meine )

 

gRuss Ralf

[Beatbuzzer]

Ich habe für mich mehrere Argumente gesammelt, warum nicht mit dem großen Board gesteuert wird.

Sehe ich ganz genauso. Und auch niemand sonst kommt auf so eine Idee. Jede noch so kleine Schirttmotoransteuerung hat nochmal einen eigenen µC, der sich um die Zeiten kümmert. Hat auch noch den Vorteil, dass die Steuerung autark arbeiten bzw. Sicherheitspositionen anfahren kann, wenn die Verbindung mal abreißt. Hier für uns hieße das einfach "stop" oder aber was ich verwende: Ein kontrolliertes Gas wegnehmen mit anschließend langsam aufbauender Bremse. Hilft im Falle eines Falles, auch bei >10 km/h noch auf dem Board zu bleiben

[barney]

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.:

Externe Links nur für Mitglieder sichtbar

[Kai]

meine Gedanken...

 

Der BananaPro ist auf keinen Fall die ideale Lösung für unser Projekt, klar.

Für mich ist das erstmal egal, den Krams vom Banana Pro auf ein anderes SBC System zu übertragen lässt sich machen.

Wir brauchen kein HDMI, kein IR, kein RJ45 ....

Ideal wäre ein Single Board Computer ohne all das aber mit einem über i2c oder CAN verbundenen onboard Mikrocontroller.

Wenn wir was passenderes finden wird der Banana Pro einfach ausgetauscht.

 

Wichtig sind die Schnittstellen nach außen vom Teensy.

Diese sollten über mehrere Wege (BT, UART, i2c ...) laufen, so hat man freie Auswahl ob Kabelgebunden oder über Funk.

Schön wäre es wenn wir uns dabei nur über unser Protokoll auf Applikationsebene gedanken machen müssten.

Aber das wäre ja zu einfach gewesen ne.

Über welche "Kanäle" kommuniziert wird lässt sich dann "einfach" austauschen, das ist das Prnzip des OSI-Schichten Modells.

 

Der Teensy sollte nur die wichtigsten Sachen machen - die zum Fahren notwendig sind und eben auch die Überwachung der Betriebsparameter.

Quasi das Fundament bilden.

Wenn er sowieso kein Logging macht (keine Daten speichert) braucht er auch nichtmal die genaue Uhrzeit.

Die Telemetriedaten können vom angeschlossenen System empfangen werden und mit eigenem Timestamp gespeichert.

Ob GPS direkt am Teensy sein muss / kann? Oder ob wir das auslagern?

Der Teensy wertet die GPS Daten selbst ja nicht aus, braucht sie auch nicht für irgendwelche Entscheidungen zu treffen, sondern würde sie nur zur Verfügung stellen.

Also könnte GPS auch auf das "Logging-System" ausgelagert werden, im aktuellen Fall der Banana.

Oder eben das Handy das per BT angekoppelt ist. Rudimentär geht das ja schon oder?

Und wer weis ob nicht doch jemand mal native Apps für die Smartphone programmieren will.

 

Wie gesagt wichtig ist nur das vom Teensy die Schnittstellen nach außen wohl definiert sind.

[barney]

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?

 

Externe Links nur für Mitglieder sichtbar

 

Da findest du Modelle mit ADC, DAC usw.

[Kai]

Die TupperIdee ist super :thumbsup:

Wie gesagt wenn die externe Anbindung an den Teensy über alle Möglichen physikalischen Schnittstellen geht kann jeder flexibel Entscheiden wie er was ankoppeln möchte.

Für mich wäre das zu unbequem ein weiteres Teil (plus USB Powerbank)dabei haben zu müssen und das auch noch im Rucksack. Okay es wäre ja nur fürs Loggen und fürs Livemonitoring (nach aktueller Planung), also kann man das auch weglassen, das Board fährt auch so.

Bequemer ist es für mich wenn ich einfach das Board einschalte und es automatisch alle Daten speichert, ich bei Bedarf mit dem Handy mal ins Monitoring schauen kann oder auch Einstellungen wie Hase / Igel ... ändern kann.

[barney]

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

[barney]

Parametrieren ist ein absolutes Oberziel!

[Kai]

Jeb

 

Ich kümmere mich jetzt erstmal um die Grundeinrichtung des Banana Pro für unsere Zwecke.

Dann kommt der Teensy an den Banana Pro dran und es geht an die Umsetzung der Kommunikation zwischen den Beiden.

Ich mach am WE einen Thread über den Banana Pro auf, mit meiner favorisierten Roadmap und Überlegungen und Aufrufen zur Mithilfe

[barney]

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.

[Kai]

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.

 

Du musst wohl dazuschreiben über welches Image du schreibst.

Bei Bananian ist der /boot Ordner leer.

Um an diesen .bin und .fex file ranzukommen musst du da ein mmcblk0p1 device mounten:

mount /dev/mmcblk0p1 /mnt

dann findest du unter

/mnt/fex/BananaPro

die Dateien script.bin und script.fex

 

Fex reference:

Externe Links nur für Mitglieder sichtbar

bearbeitet 15. Februar 2015 von Kai

[Beatbuzzer]

Die Eingangsspannung wird auf ca. 60V erhöht. Da ist aber dann Schicht im Schacht! Nein, keine 100V für Beatbuzzer. Auch kein Drehstromanschluss!

Manno. Ich wollte eigentlich heimlich still und leise von Version zu Version bis 400V kommen, damit ich bei der nächsten Reichweiten-Battle den Tesla-Akku anschliessen kann

 

Spass beiseite. Die gängigen RC-Komponenten gehen ja auch nur bis 12S, also vollgeladene 50,4V. Mit ein bisschen Sicherheitsreserve ist die Grenze bei 60V Schutzkleinspannung doch gut passend. Allerdings gehen die nicht galvanisch getrennten 3-poligen kleinen LM-Ersatz DC/DC-Wandler nur bis vielleicht 45V. Danach werden sie meistens galvanisch getrennt und grösser.