Kai Geschrieben 14. Februar 2015 Geschrieben 14. Februar 2015 Ich nenne jetzt vorerst so :-) Untertitel: Banana du alte Frucht ich pell dich. GIT Repositiory: git clone Externe Links nur für Mitglieder sichtbar Zip Download: .zip Jeder der bereits einen GIT Zugang über SSH hat kann auch schreibend auf das Repository zugreifen. Bis her gibt es nur eine Pseudo README und ein Bash-Script für die automatisierte Konfiguration des Bananas. Der Thread hier dient zur Diskussion, Vorschläge und vor allem Mithilfe. Offene Fragen 1. Welches Image nehmen wir am Besten als Basis. In Fragen kommen nur welche die Debian als zurundeliegende Distribution verwenden. Es stehen drei zur Auswahl: Lubuntu, Raspbian oder Bananian. Ich habe als erstes zu Bananian gegriffen aber mir die anderen noch nicht genauer angesehen. Ich glaube aber das Raspbian weiter verbreitet ist, wegen dem Raspberry PI. Ist hier jemand der dazu schon mehr sagen kann? 2. Eigenes Image bootstrapen? Ich bin mir noch nicht schlüssig ob wir ein eigenes Image bauen müssen/wollen oder ob es auch ausreicht unser APT Repository hinzuzufügen und die Konfiguration über apt-get install banana_setup4xxxx auszuführen. Die Entscheidung hängt auch von der Klärung der Frage 1 ab. Bananian ist eine minimal Image und installiert nur was absolut notwendig ist. Das ist schonmal gut. Eigene Images hätte den Vorteil das man es einfach nur runterladen und auf die SD-Karte spielen muss. 3. Für die Web-GUI würde es sich anbieten ein Framework zu verwenden? Kennt da jemand zufällig das Beste wo gibt. Sollte gleich auch für Smartphones was haben und eigene Elemente wie Slider, Gauges und so. 4. Wie kann ich einen Schalter am Banana anschließen und den Status abfragen? Ich möchte drei zustände schalten können. WLAN aus WLAN im AP Mode WLAN in Client Mode (verbinden mit eigenen Netzwerk) ROADMAP so oder so ähnlich sieht meine Roadmap aus. Naja eine richtige Roadmap ist es nicht, eher der Versuch die Entwicklung der Features in eine Reihenfolge zu bringen die Sinn macht. v0.1.0 Grundkonfiguration des Systems (Bash, Tools, Lokalisierung, BananaPro spezifische Einstellungen ...) WLAN Der Banana wird so konfiguriert das er einen AP aufmacht wenn er keine bekannte SSID von einem WLAN-Netzwerk findent für das er als Client konfiguriert ist. Ist man zuhause verbindet er sich automatisch mit dem Heimnetz und hat so auch Internet. GPS Zeitsynchronisation über GPS Geo-Daten auslesbar, vorbereitung für späteres Logging. v0.2.0 Dummy Webinterface Einstellungen des Banana Pros über Webinterface v0.3.0 Anbindung Teensy, Telemetriedaten auslesen und im Webinterface als Live Ansicht anzeigen. Einfache Logging Funktion v0.4.0 Erweitertes Logging. Chronologische Ansicht der gespeicherten Daten. v1.0.0 Alle bisherigen Features funktionieren Stabil. v1.0.0 Konfiguration des Teensy Controllers über CLI v1.1.0 Konfiguration des Teensy Controllers über Web-GUI ... Spielereien wie Hupe über Audio-out mit konfigurierbare Sounddatei. Sprachausgabe ... So der grobe Verlauf, es gibt aber noch ein paar "unbekannte" die in der Roadmap nicht berücksichtigt sind. Zitieren
Kai Geschrieben 15. Februar 2015 Autor Geschrieben 15. Februar 2015 WiringBP installieren apt-get install git-core sudo make gcc libc6-dev libc-dev git clone https://github.com/LeMaker/WiringBP.git -b bananapro cd WiringBP chmod +x build ./bulid Testen: gpio -v gpio version: 2.20 Copyright (c) 2012-2014 Gordon Henderson This is free software with ABSOLUTELY NO WARRANTY. For details type: gpio -warranty Banana Pro Details: Type: Banana Pro, Revision: 1.2, Memory: 1024MB, Maker: LeMaker gpio readall +-----+-----+---------+------+---+--Banana Pro--+---+------+---------+-----+-----+ | BCM | wPi | Name | Mode | V | Physical | V | Mode | Name | wPi | BCM | +-----+-----+---------+------+---+----++----+---+------+---------+-----+-----+ | | | 3.3v | | | 1 || 2 | | | 5v | | | | 2 | 8 | SDA.1 | ALT5 | 0 | 3 || 4 | | | 5V | | | | 3 | 9 | SCL.1 | ALT5 | 0 | 5 || 6 | | | 0v | | | | 4 | 7 | GPIO. 7 | IN | 0 | 7 || 8 | 0 | ALT0 | TxD | 15 | 14 | | | | 0v | | | 9 || 10 | 0 | ALT0 | RxD | 16 | 15 | | 17 | 0 | GPIO. 0 | ALT4 | 0 | 11 || 12 | 0 | IN | GPIO. 1 | 1 | 18 | | 27 | 2 | GPIO. 2 | ALT4 | 0 | 13 || 14 | | | 0v | | | | 22 | 3 | GPIO. 3 | ALT4 | 0 | 15 || 16 | 0 | IN | GPIO. 4 | 4 | 23 | | | | 3.3v | | | 17 || 18 | 0 | IN | GPIO. 5 | 5 | 24 | | 10 | 12 | MOSI | IN | 0 | 19 || 20 | | | 0v | | | | 9 | 13 | MISO | IN | 0 | 21 || 22 | 0 | ALT4 | GPIO. 6 | 6 | 25 | | 11 | 14 | SCLK | IN | 0 | 23 || 24 | 0 | IN | CE0 | 10 | 8 | | | | 0v | | | 25 || 26 | 0 | IN | CE1 | 11 | 7 | | 0 | 30 | SDA.0 | ALT4 | 0 | 27 || 28 | 0 | ALT4 | SCL.0 | 31 | 1 | | 5 | 21 | GPIO.21 | IN | 0 | 29 || 30 | | | 0v | | | | 6 | 22 | GPIO.22 | ALT4 | 0 | 31 || 32 | 0 | ALT4 | GPIO.26 | 26 | 12 | | 13 | 23 | GPIO.23 | IN | 0 | 33 || 34 | | | 0v | | | | 19 | 24 | GPIO.24 | IN | 0 | 35 || 36 | 0 | IN | GPIO.27 | 27 | 16 | | 26 | 25 | GPIO.25 | IN | 0 | 37 || 38 | 0 | IN | GPIO.28 | 28 | 20 | | | | 0v | | | 39 || 40 | 0 | IN | GPIO.29 | 29 | 21 | +-----+-----+---------+------+---+----++----+---+------+---------+-----+-----+ | BCM | wPi | Name | Mode | V | Physical | V | Mode | Name | wPi | BCM | +-----+-----+---------+------+---+--Banana Pro--+---+------+---------+-----+-----+ Links: Externe Links nur für Mitglieder sichtbar Zitieren
Kai Geschrieben 15. Februar 2015 Autor Geschrieben 15. Februar 2015 Der Schalter für das WLAN soll den Modus durchschalten. Jedes Mal wenn der Zustand vom PIN von LOW auf HIGH wechselt wird in den nächsten Modus gewechselt. 1. AUS 2. WLAN-AP 3. WLAN-Client Mal sehen wie man die Überwachung des Schalters macht. Ob man das jetzt am besten mit gpio macht oder doch mit inotify bzw. iwatch die virtuelle Datei des GPIO Ports auf Änderung überwacht. /sys/class/gpio/... Zitieren
barney Geschrieben 15. Februar 2015 Geschrieben 15. Februar 2015 Betriebssystem: Bananian würde ich favorisieren. Der Raspberry hat einen anderen ARM-Prozessor. Da müssen wir uns nicht orientieren. Akkuüberwachung: Externe Links nur für Mitglieder sichtbar Wiring Pi: I2C: 40 Pin Anschluss: Zeitsynchronisation GPS ist mit NTP total easy Zitieren
barney Geschrieben 16. Februar 2015 Geschrieben 16. Februar 2015 Der Schalter für das WLAN soll den Modus durchschalten.Jedes Mal wenn der Zustand vom PIN von LOW auf HIGH wechselt wird in den nächsten Modus gewechselt. 1. AUS 2. WLAN-AP 3. WLAN-Client Mal sehen wie man die Überwachung des Schalters macht. Ob man das jetzt am besten mit gpio macht oder doch mit inotify bzw. iwatch die virtuelle Datei des GPIO Ports auf Änderung überwacht. /sys/class/gpio/... Hier würde ich kein Durchtasten favorisieren, sondern absolute Einstellungen, da was man was man hat (oder wollte). Zitieren
Kai Geschrieben 16. Februar 2015 Autor Geschrieben 16. Februar 2015 espeak -vde "wlan verbunden! ei pie ist: $(hostname -i)" --punct="." espeak -vde "accesspoint gestartet! ei pie ist: $(hostname -i)" --punct="." espeak -vde "wlan aus!" Zitieren
Kai Geschrieben 19. Februar 2015 Autor Geschrieben 19. Februar 2015 (bearbeitet) Video: Externe Links nur für Mitglieder sichtbar Das Script dazu funktioniert auch schon inkl. Konfiguration der Netzwerkschnittstelle und dem Umschalten des WLAN Mode. Als nächstes mache ich das Setup Script fertig. Modul NEO-6 GPS Modul funktioniert auch. Loggen der Daten im gpx Format auch. Das möchte ich aber noch in mysql bringen damit man es dort zusammen mit den Telemetriedaten abfragen kann. bearbeitet 19. Februar 2015 von Kai Zitieren
FlyRasch Geschrieben 19. Februar 2015 Geschrieben 19. Februar 2015 Cool, das hört sich ja schon fast ein wenig nach Max Headroom an. ( Kennt Du den ?? Der ist noch aus dem letzten Jahrtausend ) gRuss Ralf Zitieren
barney Geschrieben 20. Februar 2015 Geschrieben 20. Februar 2015 Cool, das hört sich ja schon fast ein wenig nach Max Headroom an. ( Kennt Du den ?? Der ist noch aus dem letzten Jahrtausend ) gRuss Ralf Hey natürlich! Keine Frage, wer denn nicht? Zitieren
Kai Geschrieben 23. Februar 2015 Autor Geschrieben 23. Februar 2015 zu meinen Eingangsfragen nochmal: 1. Welches Image nehmen wir Also ich bin immer noch bei bananian weil es ein minimal System ausgeliefert wird. Gute Ausgangsbasis für eigene Anpassungen. Raspbian hatte ich kurz mal gebootet. Da müsste man halt alle Pakete die man nicht möchte "purgen" was aber kein Problem ist wenn man die erst mal festgelegt hat. Lubuntu hab ich mir noch nicht angesehen. 2. Eigenes Image bootstrapen? Meine aktuelle Idee ist es das ein original Image zu nehmen und anzupassen (siehe unten gemu chroot) Das heißt es braucht ein paar Scripte die das original Image automatisiert anpassen. Im GIT ist das aktuelle Script, welches noch eher als Notiz in Bashscript form betrachtet werden soll Ich möchte am Ende ein komplett vorkonfiguriertes Image anbieten sowie die manuelle Installation über das APT-Repository. 3. Für die Web-GUI würde es sich anbieten ein Framework zu verwenden? Es gab und gibt da schon mehrere Projekte für den Raspberry. Sehr tief bin ich da nicht eingestiegen aber Ideal wäre ein Bananian-WebGui das man mit Add-Ons erweitern kann. Diese WebGui wäre dann für das Setup des Systems und für den EBoardcontroller. Eine zweite WebGUI fürs Fahren. 4. Wie kann ich einen Schalter am Banana anschließen und den Status abfragen? Han ich bereits gelöst. Leider erstmal nur mit "Polling" (while schliefe, status abfragen, sleep Kombination) Da das mit inotify und dem sys-fs nicht so funktioniert wie mit richtigen Filesystemen. In der Endfassung soll das noch mit Interuppt gelöst werden. Muss da mal ein Feature request stellen an den WiringPi Entwickler. Er schreibt zwar wie man das Programmiert, hat das aber (scheinbar) in seinem gpio cli tool nicht eingebaut. kurzes Update was bereits funktioniert: - per script Hardware auf bananapro einstellen - Powerbutton fährt Bananian runter (ACPI) - Blinkende Grüne LED abschalten. Blinkt nur noch während dem Booten - wiringBP per script runterladen und kompilieren - GPS Modul - Tracks als .gpx speichern - GPS Modul - Uhrzeit per GPS abgleichen - Soundausgabe - Sprachausgabe - teensy flashen über Shell - wlan umschalten per Script - wlan umschalten per (gpio) Button Das alles muss noch schön ordentlich in .deb Pakete verpackt werden die dann über unser (noch zu erstellende) apt repository geladen werden können. Dazu ein Meta-Paktet das alles in einem Rutsch installiert. wie man angepasste Images erstellen kann hab ich auch schon raus: Mit einem "qemu architectural chroot" Genial simpel. #!/bin/bash BCH=$HOME/banana_chroot mount -t ext4 -o loop,offset=$((512 * 104448)) bananian-1501.img $BCH cp /usr/bin/qemu-arm-static $BCH/usr/bin/ cd $BCH mount -t proc /proc proc mount -o bind /dev dev mount -o bind /dev/pts dev/pts mount -o bind /sys sys chroot . /bin/bash Das reicht um ein chroot auf die root Partition des original bananien Image zu machen und dabei den ARM Prozessor zu emulieren. Das Script ist "vereinfacht" (Offset hardcodiert) und funktioniert mit dem aktuellen 1501 Image. Es wird noch ausgebaut so das es den Offset der Partition zur Laufzeit ausliest und berechnet. Für eine saubere Build-Umgebung habe ich mir Wheezy in einer VirtualBox VM installiert. Noch ein bisschen Feinschliff und Cross-Compiling einrichten, dann werde ich es veröffentlichen. PS: Max Headroom war das coolste was damals lief Zitieren
barney Geschrieben 24. Februar 2015 Geschrieben 24. Februar 2015 Hi Kai, schönes Tempo, was du da vorlegst. Weiter so :thumbsup: Also nächste Woche ist dann alles betriebsbereit? Welches GPS-Modul hast du genommen? Wie hast du den Teensy geflasht? Habe mich in der letzten Woche mit KiCad auseinander gesetzt, musste leider viel umdenken, heißt aber nicht das es schlecht ist. Es ist halt alles woanders. Viele Grüße Barney Zitieren
FlyRasch Geschrieben 24. Februar 2015 Geschrieben 24. Februar 2015 Wow Ihr beiden seid schneller als der Blitz. Also ein minimales Image um die benötigten Teile aufzubauen hat auf alle Fälle den Vorteil, das man alle zusätzlich benötigten Komponenten kennt und bewusst benutzt. Man wird also nicht davon überrascht, wenn irgendwelche vorinstallierten Komponenten aus einem "Luxusimage" in einer neueren Version verschwinden. Die Idee den Kernel mit Inotify das Filesystem auf Veränderungen zu überwachen ist eigentlich prima. Ich denke aber, das Du dazu einen Wechsel von dem Staus des Filedescriptors brauchst. Also z.B. einen "Datei wurde gerade verändert und geschlossen" oder " Datei wurde gerade zum lesen geöffnet". Wenn sich jetzt in der geöffneten Datei gerade ein Bit ändert wird der Inotify noch kein Event abliefern. Was für eine Kernel Version hat den das Banaian. gRuss Ralf Zitieren
Kai Geschrieben 24. Februar 2015 Autor Geschrieben 24. Februar 2015 (bearbeitet) Welches GPS-Modul hast du genommen? Das Crius NEO-6 GPS. Ich würde beim nächsten Mal wahrscheinlich eins nehmen mit Timepluse / PPS Ausgang. Das erspart das Anlöten eines extra Kabels. PPS braucht man anscheinend weil die Genauigkeit des Zeitstempels über GPS nicht so toll sein soll. Hab da noch keine Tests gemacht. Das PPS Kabel ist zwar schon angelötet aber ich habe erstmal nur das GPS Signal in den NTPd gebracht. Mal sehen... ob man PPS zwingend braucht. Wie hast du den Teensy geflasht? Zuerst das CLI Tool kompliliert und udev rule für den Teensy hinzugefügt. Wie genau steht in gescripteter Form im Abschnitt ###################################### # Teensy Loader ###################################### in der bananian_mod.sh im git Dann hab ich Externe Links nur für Mitglieder sichtbar runtergelden. In den Teensy laden geht dann so schnelles Blinken: teensy_loader_cli -mmcu=mk20dx128 -v -w blink_fast_Teensy31.hex langsames Blinken: teensy_loader_cli -mmcu=mk20dx128 -v -w blink_slow_Teensy31.hex Usage: teensy_loader_cli -mmcu=<MCU> [-w] [-h] [-n] [-v] <file.hex> -w : Wait for device to appear -r : Use hard reboot if device not online -n : No reboot after programming -v : Verbose output <MCU> = atmega32u4 | at90usb162 | at90usb646 | at90usb1286 | mk20dx128 For more information, please visit: http://www.pjrc.com/teensy/loader_cli.html Für den 3.1er Teensy müsste eigentlich mk20dx256 die richtige Angabe für -mmcu sein. Der Test hat aber auch so funktioniert. Man muss da aber im Hinterkopf behalten und ggfls. den Paul fragen wenn das mit größeren Files probleme machen sollte. Debian Paket für teensy_loader_cli hab ich erstellt, ist im Anhang. Das soll später mal ins Repository rein. dpkg -i teensy-loader-cli_2.1_armhf.deb installiert teensy-loader-cli nach /usr/bin und schreibt die udev rules in /etc/udev/rules.d/49-teensy.rules Die Idee den Kernel mit Inotify das Filesystem auf Veränderungen zu überwachen ist eigentlich prima. Hat auch funktioniert als ich die Zustände noch per echo geändert hatte echo "1" > /sys/class/gpio/gpio17/value Als ich den Button angeschlossen hatte änderte sich zwar der Wert aber Inotify bekam das nicht mit. Jetzt hab ich inotifywait -qq -e modify /sys/class/gpio/gpio17/value erstmal ersetzt durch while [ `gpio -g read 17` = 0 ]; do sleep 0.1 done Ist gar nicht schön aber schön wenn man etwas Verbesserungpotential für die Zukunft aufheben kann. ;-) Was für eine Kernel Version hat den das Banaian. uname -a Linux bananapi 3.4.104+ #1 SMP PREEMPT Thu Jan 8 15:40:40 CET 2015 armv7l GNU/Linux teensy-loader-cli_2.1_armhf.deb bearbeitet 24. Februar 2015 von Kai Zitieren
FlyRasch Geschrieben 25. Februar 2015 Geschrieben 25. Februar 2015 Hallo Kai, wenn Du mit echo in eine Datei/Gerätedatei schreibst dann öffnest Du die Datei zum schreiben, schreibst etwas hinein und schliesst die dann wieder. Wenn du von aussen den Wert verändert, dann schliesst Du die Datei dabei nicht. Den verändeten wert würde inotify erst nach dem schliessen der Datei mitbekommen. ( Wenn du da mit ein Backup steuern oder neue Dateien versenden willst, dann möchtest Du das ja auch erst machen wenn die Datei vollständig geschrieben wurde) Na ein 3.4er ist ja schon ein relativ moderner. Das müsste da ja schon relativ gut in den Kernel integriert sein. gRuss Ralf Zitieren
Dude Geschrieben 25. Februar 2015 Geschrieben 25. Februar 2015 So, jetzt hab ich mir auch mal einen bananapipro und gps bestellt. Kai, welche Verbindung zum Teensy hast Du verwendet, seriell? Dude Zitieren
Kai Geschrieben 25. Februar 2015 Autor Geschrieben 25. Februar 2015 Cool, möchtest du bei der Bananian Konfiguration / Programmierung für das Projekt einsteigen? Für's Flashen ganz normal über USB. Mehr habe ich noch nicht gemacht, also keine Telemetriedaten ausgelesen. @barney wie machen wir das denn jetzt? Sollen wir auf dem Bananapro zwei GPIO Pins zur Kommunikation zw. Teensy und Banana konfigurieren oooder geht das etwa auch über die USB Verbindung? Zitieren
barney Geschrieben 25. Februar 2015 Geschrieben 25. Februar 2015 Cool, möchtest du bei der Bananian Konfiguration / Programmierung für das Projekt einsteigen? Für's Flashen ganz normal über USB. Mehr habe ich noch nicht gemacht, also keine Telemetriedaten ausgelesen. @barney wie machen wir das denn jetzt? Sollen wir auf dem Bananapro zwei GPIO Pins zur Kommunikation zw. Teensy und Banana konfigurieren oooder geht das etwa auch über die USB Verbindung? Beide! Die Serielle Kommunikation über den Umweg Bluetooth am Teensy und Bluetooth-Stick im Banana. Die zweite Möglichkeit sollte die USB-Verbindung sein. Diese wird Teensy seitig wie eine Serielle Schnittstelle gehandhabt. Mit der USB-Verbindung kann dann auch der Teensy geflasht werden. Ich hätte aber nicht vor den Banana mit den Teensy ins Board zu quetschen. Hinweis! Die USB-Verbindung zwischen Teensy und Banana darf nicht die 5V koppeln! Zitieren
Kai Geschrieben 25. Februar 2015 Autor Geschrieben 25. Februar 2015 (bearbeitet) du sagst Beide aber GPIO erwähnst du nicht 1. BT 2. USB 3. GPIO Serial ok also brauchen wir kein GPIO Serial Port, das ist cool. Das heißt wir können den Teensy Flashen über die USB Verbindung, können die Telemietrie Daten auslesen und können Daten für das Setup der Motorsteuerung an den Teensy senden. Wenn du noch eine Bootloader Jump Funktion einbaust braucht man den Button auf dem Teensy nicht drücken zum Flashen. Externe Links nur für Mitglieder sichtbar Dann können wir auch Teensy updates über das Repository ausrollen und automatisiert flashen. 5V Koppeln? Was meinst du damit? USB Port hat doch 5V Betriebsspannung? Ich hätte aber nicht vor den Banana mit den Teensy ins Board zu quetschen. Ich schon, da der ja alles Loggen soll. bearbeitet 25. Februar 2015 von Kai Zitieren
barney Geschrieben 25. Februar 2015 Geschrieben 25. Februar 2015 @Kai Was zum spielen. 5V: Jup. Der Banana stellt 5V bereit und der Teensy macht aus 5V 3.3V, die er aber schon vom LC78_03 bekommt. Nicht gut! Elektroskate_Teensy31_v41p0_ADC_LIB_SwitchDriveMode_Leiterplatt.cpp.zip Zitieren
Kai Geschrieben 25. Februar 2015 Autor Geschrieben 25. Februar 2015 Das mit den 5V kapier ich nicht was du meinst. Wie schließt du den Teensy denn an den PC an zum flashen? Zitieren
barney Geschrieben 25. Februar 2015 Geschrieben 25. Februar 2015 Das mit den 5V kapier ich nicht was du meinst.Wie schließt du den Teensy denn an den PC an zum flashen? Entschuldigung Langfassung: Wenn du das derzeitige namenlose Teensyboard hast, bekommt der Teensy seine Spannung vom Spannungsregler der Platine. Wenn du dann einen weitere Quelle anschließt, also die 5V über USB, besteht die gute Möglichkeit den Teensy dabei zu killen. Es darf nur eine geben! (Spannungsquelle) Zitieren
Kai Geschrieben 25. Februar 2015 Autor Geschrieben 25. Februar 2015 (bearbeitet) jetzt hab ich's geschnallt Dann nehmen wir beim USB Kabel die Kabel für VBUS und GND raus und gut ist? Und so ein Kabel hast du dir gemacht zum Flashen? Oder trennst du den Teensy vorher vom Barney Board Controller bearbeitet 25. Februar 2015 von Kai Zitieren
Dude Geschrieben 25. Februar 2015 Geschrieben 25. Februar 2015 Cool, möchtest du bei der Bananian Konfiguration / Programmierung für das Projekt einsteigen? Ich werd damit erst einmal versuchen zu verstehen, was ihr da treibt Zitieren
barney Geschrieben 26. Februar 2015 Geschrieben 26. Februar 2015 jetzt hab ich's geschnallt Dann nehmen wir beim USB Kabel die Kabel für VBUS und GND raus und gut ist? Und so ein Kabel hast du dir gemacht zum Flashen? Oder trennst du den Teensy vorher vom Barney Board Controller Aber ich nicht mehr! Externe Links nur für Mitglieder sichtbar So weit wie ich verstanden habe, wird der USB-Port erst aktiviert wenn VRegin die 5V vom USB-Anschluss bekommt. In diesem Moment springt der Teensy interne Spannungsregler an und versorgt den Vout33 Ausgang mit einer geregelten Spannung. Paul hat Vout33 und Vdd miteinander verbunden. So dass wie auf Seite 114 beschrieben, der gesamte Teensy mit einer Spannungsquelle (3.3V) versorgt wird. Dies passt natürlich nicht zur Situation, dass die 3.3V schon vom LC78_03 kommt. Jetzt ist die Frage, wie der interne Spannungsregler arbeitet. Ab Seite 112: Fazit: Wer vor hat, denn Teensy am Banana Pro zu betreiben, sollte die Spannungsversorgung der TeensyBoard Leiterplatte nicht mehr über den LC78_03 erfolgen. Einfach den Spannungsanschluss abziehen. Der Teensy ist in der Lage sich selbst und das Bluetooth Modul, durch die 5V des Banana Pro, zu versorgen. Die LEDs und den Optokoppler natürlich auch. Im zweiten Betriebszustand, Banana Pro im Rucksack, ist durch die Funkschnittstelle Potentialfreiheit zwischen den Teensy und Banana Pro gegeben. Zitieren
Kai Geschrieben 26. Februar 2015 Autor Geschrieben 26. Februar 2015 So auf die schnelle überflogen find ich auch erstmal nur "Spuren" denen man weiter nachgehen kann. Was ist damit: Externe Links nur für Mitglieder sichtbar Rechts oben: Cut to separate VIN from VUSB... Ist das nicht das was wir brauchen? Zitieren
Empfohlene Beiträge
Tritt dem Gespräch bei
Du kannst jetzt posten und dich später registrieren. Wenn du bereits einen Account hast kannst du dich hier anmelden.