--> konkreteres zum Pumkt "ENA-Transistoren für Distanzsensoren": IRLML6402 ersetzt BS250
--> Displaybeleuchtung: @TR1 MOSFET IRLML6402 ersetzt Drahtbrücke, Ansteuerung über GPIO) -> Dimmung der Display-Beleuchtung (selbst implementiert mit ENA2) / Code: Tiefpass zur Verhinderung von Displayflackern im Grenzbereich (als Feature zum Code beigesteuert)
--> verbesserte Spannungsversorgung: eine Spannungsunabhängige Energieversorgung habe ich bei meinem Bot mit zwei LM2596 Gleichspannungswandlern implementiert (für 5V und 6V) Hier bietet es sich an sich so ein Teil (relativ simpler Aufbau) genauer anzusehen und die Schaltung äquivalent auf dem modifizierten Mainboard zu realisieren.
--> mechanische Halterung für Servo2
--> Überwachung der Eingangsspannung mit ADC; ersetzt Spannungsteiler (der im Ursprungsdesign falsch dimensioniert und daher ohnehin nicht funktioniert)
--> 5v/3v3-Levelausgleich im SPI-Bus auf dem ERW-Board (mit SPI-HW-Patch): Level-Shifter (Pegelwandler) 3,3V ↔ 5V zwischen AT-Mega & SD-Schacht ersetzt Spannungsteiler (unschöne Implementierung im Originaldesign)
--> neues PCB-Layout mit optimierter Baugruppenanordnung (funktional zusammenhängende Baugruppen bilden eigene Untergruppen) und komplett neuem Routing (großes Optimierungspotential). Sinnvoll könte hier zusätzlich ein Standard 3-Layer-Design sein (auch wenn dadurch die Stückkosten geringfügig höher ausfallen könnten).
--> Display gegen I2C-Display ersetzen, Schieberegister IC4 entfällt --> Ergänzung: es gibt inzwischen moderne, stromsparende und hochkontrastreiche OLED-Displays (https://www.lcd-module.de/produkte/oled.html) die einfach zu programmieren sind.
--> Ersatz für den Maussensor durch ein funktionierendes Modell neuerer Generation. Inzwischen gibt es hochpräzise, optische Maussensoren für den Gaming-Markt mit im Package integrierter LED. Dies sollte u.a. Streulichteinflüsse deutlich reduzieren. (http://www.pro-gamer-gear.de/maus-sensor/) Ich wälze hierzu mal ein paar Datenblätter & Specs.
--> LDR-Lichtsensoren werden von benachbarten blauen LEDs beeinflusst --> Repositionierung der LEDs bzw. der LDRs in neuem PCB Design
--> Erzeugung der 3V3 Versorgungsspannung aus den 5V sollte vom ERW-Board auf das Mainboard verlagert werden und zusammen mit der 5V- und 6V-Erzeugung (DC-DC-Wandler) eine funktionale Baugruppeneinheit bilden
--> Ersatz für WiPort entweder durch separates embedded Aufsteckmodul mit 2,4GHz WiFi (IEEE802.11b/g/n) (idealerweise auch 5 GHz-Unterstützung mit IEEE802.11ac, nach Verfügbarkeit, kein MustHave) und Bluetooth 4.2 LE; alternativ Funkmodul nur mit aufgestecktem Mikroprozessor-Board verfügbar. Vor- und Nachteile sind anhand von Beispielen zu diskutieren.
--> Verzicht auf ERW-Board, da bei Berücksichtigung aller schon genannten Punkte (inkl. Sammelliste) keine Features davon mehr übrig wären. Richtig?
--> Temperatursensor auf dem Mainboard Ideen für neues PCB-Board (harter Schnitt, keine Abwärtskompatiblität (entspricht ct-Bot v2.0):
--> neues Design mit GPIO-Buchsen-Reihe zur Überkopf-Montage eines RPi2 Model B v1.2 oder bevorzugt RPi3 (würde auf bisherigen Tests von eax und mir aufsetzen). Denkbar wäre aber auch (wenn man noch etwas mehr Geduld mitbringt) eine Implementierung auf Basis der RPi Zero W. Letzteres wäre hardwareseitig die elegantere Lösung da das RPi Zero Board hinsichtlich Baugröße / Funktionalität / Schnittstellen und Stromverbrauch aus meiner Sicht besser für das Projekt geeignet sein dürfte. Aktuell gibt es hier aber noch ein Problem: Der Zero W basiert (derzeit noch) auf der ARMv6Z (32-bit) Architektur, während RPi 2 v1.2 & 3 auf der neueren ARMv8-A aufbauen. Ubuntu Launchpad beispielsweise bringt aber keine Kompatibilität für ARMv6Z mit, sodass meines Wissens derzeit neben Raspbian keine alternativen Linux-Images vorhanden sind (https://askubuntu.com/questions/703070/ ... ry-pi-zero). Sofern man bereit wäre sich hierfür von der Atmel-Architektur zu lösen und auf ARM zu setzen, könnte man da sicherlich langfristig mehr gewinnen und den Horizont des Projekts durch diese moderne und vielseitigere Architektur wesentlich erweitern.
--> nach einem Austausch mit eax festigt sich auch bei mir der EIndruck dass ein bewusste Architekturwechsel auf ARMv7 oder neuer deutlich mehr Vorteile als Nachteile mit sich bringen dürfte, auch wenn es mehr Arbeit mit sich bringt:
(+) Man löst sich von Altlasten die aus unschönem Designentscheidungen herrühren, welche sich nun nachträglich nicht mehr rückgängig gemacht werden können ohne neue Inkompatibilitäten zu generieren
(+) Schaffung neuer Möglichkeiten für zukünftige Erweiterungen
(+) Beim Portieren des Codes auf die neue Architektur bietet sich noch einmal die Möglichkeit alle Implementierungen kritisch zu hinterfragen, Strukturen zu vereinfachen, exisitierende Fehler zu beheben, ohne dass dies Auswirkungen auf andere Module hat und Altlasten loszuwerden.
(+) Man würde auf eine zukunftsfähige, moderne Hardwarearchitektur setzen, die im Zeitalter mobiler Geräte zunehmende Verbreitung erlangt
(+) die obigen Optimierungsvorschläge können natürlich auch hier mitberücksichtigt werden
(-) Der alte Bot-Code ist nicht mehr kompatibel
(-) Da neuere ARM-Microcontroller in der Regel nur als SMD-Bauteile verfügbar sind, können diese nur mir großer Mühe selbst gelötet werden --> Eine Lösung wäre hier, wie von eax vorgeschlagen, ein Aufsteckboard, das bereits die notwendigen SMD-Komponenten enthält und möglichst alle relevanten Pins auf Stiftleisten führt.
Zumal gibt es bislang nur wenige Hersteller und der Wirkungsgrad ist gering. (z.B. 
) - mir wäre es lieber, die Beiträge werden in den Hardware-Thread verschoben. Wer ist hier noch aktiver Moderator?