Telepräsenzpanzer: Unterschied zwischen den Versionen

Zur Navigation springen Zur Suche springen
K
(→‎Technische Daten: Abschnitt angelegt)
 
(35 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
|'''Modell''' || W90N745
|}
Möglicherweise wechselte die Bezeichnung irgendwann zu [http://www.nuvoton.com/hq/products/microprocessors/arm7-mpus/nuc700-series/nuc745adn/ NUC745].
 
=== Kameramodul ===
{|
???
|'''Schnittstelle''' || USB
|-
|'''Vendor ID''' || 0x1d0f
|-
|'''Product ID''' || 0x1801
|}
 
=== WLAN ===
{|
???
|'''Chipset-Hersteller''' || Ralink
|-
|'''FCC-ID''' || [http://fcc.io/XON/SR806000 XONSR806000]
|-
|'''Chipset''' || RT3070
|}
 
== Reverse EngineeringProjektlog ==
=== 2015-12-07 ===
Ein USART ist schon gefunden, da dieser sogar auf dem Board markiert war. (Wie zuvorkommend…)
 
[[Benutzer:Coffee|coffee]] versucht sich mal an diesem Buildroot, und hat außerdem das Board entführt, um mal daheim bessere Nahaufnahmen zu machen.
 
Kommando zum Flashen eines Kernel-Images:
<pre>
bootloader > fx 7 linux 0x7F020000 0x8000 -acxz
</pre>
 
=== 2015-12-21 ===
 
Ein wenig Recherche führt zu folgenden zwei Repositories (Buildroot und ein Kernel):
* https://github.com/Malvineous/buildroot-openipcam
* https://github.com/Malvineous/linux-nuc700
 
=== 2015-12-23 ===
 
Die inzwischen doch leicht angestaubte Buildroot-Version von
[https://github.com/Malvineous Malvineous] hat bei [[Benutzer:Coffee|Coffee]]
nie gebaut, also wurden Malvineous' Anpassungen in eine aktuelle
Buildroot-Version übertragen.
Mit dieser konnte wenigstens eine funktionierende Toolchain gebaut werden.
Interessanter ist jedoch der von Malvineous angepasste Kernel.
Dieser lässt sich nicht erfolgreich kompilieren, da eine Datei zu fehlen
scheint.
<pre>
arch/arm/mach-nuc700/dev.c:22:32: fatal error: mach/nuc700_keypad.h: No such file or directory
#include <mach/nuc700_keypad.h>
</pre>
 
=== 2015-12-27 ===
Nach einer Mail an Malvineous ist klar, dass der gepatchte Kernel schon damals nur Work-In-Progress war, siehe auch [[#2015-12-23|den vorherigen Eintrag]].
 
=== 2016-02-04 ===
* https://github.com/rhuitl/linux
* https://github.com/rhuitl/uClinux
* https://packages.gentoo.org/packages/dev-embedded/sgpp-lite-arm-uclinux-bin
uClinux und der Kernel, gepatcht von [https://github.com/rhuitl rhuitl], lassen sich kompilieren mit der ARM-Toolchain von CodeSourcery.
Beim Boot passiert aber ein Fehler:
<pre>
Processing image 1 ...
Processing image 2 ...
Processing image 3 ...
Processing image 4 ...
Processing image 5 ...
Processing image 6 ...
Processing image 7 ...
ERROR: Invalid zip file
Executing image 7 ...
Uncompressing Linux...
ERROR: Prefetch Abort @ pc=0x01687F00
</pre>
 
=== 2016-02-06 ===
Kaum nimmt man die gut abgehangene Toolchain aus dem BSP, schon lässt sich Software kompilieren und ausführen!
 
=== 2016-02-08 ===
Nach Anstarren der Board-Scans und vorsichtigem Pieksen mit Multimeter und Oszi scheint es, als könnten wir keinen freien UART haben, ohne andere Funktionen zu opfern.
 
{|
| '''UART0''' || dient für die Linux-Konsole
|-
| '''UART1, UART2''' || lägen auf den Pins, die für den [http://cache.nxp.com/documents/data_sheet/74HC_HCT259.pdf?pspll=1 74HC259] benutzt werden. Diese Pins toggelten, als die Originalsoftware die Schwenk-Neige-Antriebe betätigte.
|-
| '''UART3''' || läge auf den Pins, die für den Audio-Codec genutzt werden
|}
 
=== 2016-02-09 – selbstkompilierter Kernel! ===
<pre>
/ # busybox echo foo > /dev/ttyS3
sh: error opening /dev/ttyS3: No such device
</pre>
Vermutlich wird eine neue Kernel-Config benötigt, um UART3 tatsächlich benutzen zu können.
 
Empirisch wurde ermittelt, dass man eine alte GCC-Version braucht, um einen Kernel zu bauen, den das SOC auch booten will.
[[Benutzer:Coffee|coffee]] hat festgestellt, dass GCC 4.1.2 funktioniert, um den von rhuitl gepatchten Kernel zu bauen.
Der [https://github.com/rhuitl/linux eben genannte Kernel] lässt sich dann aber brav vom SOC booten!
 
Da der neue Kernel größer ist, und sein Image sich selbst dekomprimiert, ändern sich die Kommandos zum Flashen wie folgt:
<pre>
fx 7 linux 0x7F020000 0x8000 -acx
fx 6 rootfs 0x7F150000 0x7F150000 -af
</pre>
 
Mit dem neuen Kernel funktionieren auch `ifconfig` und `iwconfig` einfach so, aber gefunkt wird wegen fehlender WLAN-Firmware leider noch nicht.
 
=== 2016-02-10 ===
<pre>
/ # iwconfig wlan0 essid Freifunk
/ # ifconfig wlan0 up
phy0 -> rt2x00lib_request_firmware: Error - Failed to request Firmware.
SIOCSIFFLAGS: No such file or directory
</pre>
 
Zufallsfund bei der Web-Recherche: [http://customcam.blogspot.ch/ Steuerung der Positionierantriebe]
 
=== 2016-02-11 ===
Der von [https://github.com/rhuitl/ rhuitl] [https://github.com/rhuitl/linux gepatchte Kernel],
die [https://github.com/rhuitl/uClinux uClinux-Änderungen] desselben Users
und [https://sourceforge.net/projects/uclinux/files/uClinux%20Stable/dist-20160208/ das neueste uClinux]
wurden zusammengeführt,
um ein aktuelles Userland zu bekommen.
(Die alte uClinux-Version von rhuitl baute nicht richtig.)
 
=== 2016-02-13 ===
Nun ist auch [https://github.com/rhuitl rhuitls] <code>ipcamd</code> in das neueste uClinux integriert.
Die per USB angeschlossene Kamera wird auch tatsächlich von Linux unterstützt.
Der <code>ipcamd</code> wirft aber folgenden Fehler bei seinem Versuch, die Kamera zu konfigurieren:
<pre>
VIDIOC_S_FMT error 22, Invalid argument
</pre>
 
WLAN geht auch immer noch nicht.
 
 
=== 2016-03-20 ===
Es wurde festgestellt, dass die Firmwaredatei unter einem falschen Namen abgelegt war.
Ein Experiment mit <code>mdev</code> aus Busybox und korrekt benannter Firmware führte zu einer heftigen Kernel-Fehlermeldung:
<pre>
/ # echo /bin/mdev > /proc/sys/kernel/hotplug
/ # ifconfig wlan0 up
kernel BUG at mm/nommu.c:415!
</pre>
 
=== 2016-03-21 ===
Mit richtig benannter, in den Kernel einkompilierter WLAN-Firmware kann diese nun auch richtig geladen werden.
 
=== 2016-06-17 ===
Neue Gehversuche mit Buildroot, nun mit externer Toolchain.
 
=== 2016-06-18 ===
[[Benutzer:Coffee|coffee]] hat die Schnauze voll von dem Nuvoton-SOC, weil wpa_supplicant anscheinend nicht ohne MMU funktionieren kann.
Es wird irgendwann ein beliebiger Einplatinenrechner verwendet werden.
Die gute Nachricht: Die [http://emartee.com/product/41426/24BYJ%2048%20High%20Quality%20Stepper%20Motor%205V Motoren] sind einfache Stepper.
 
==== Wie treibt das Original-Board Schrittmotoren ohne Schrittmotortreiber? ====
Interessanterweise befindet sich auf dem Board kein Schrittmotortreiber, aber ein [http://www.ti.com/lit/ds/symlink/uln2003a.pdf Array von acht Darlington-Transistoren].
Bei den Steppern handelt es sich um Unipolar-Schrittmotoren. Zu den fünf Polen jedes Motors gehören die vier Enden der zwei Spulen und die zusammengeschalteten Mittenanzapfungen der Spulen.
Somit genügen vier Transistoren pro Motor, und das Darlington-Array reicht aus.
 
== TO DO ==
* Single-Board-Computer beschaffen (beispielsweise Raspberry Pi)
* neues Firmware-Image bauen
* Anschlüsse der USB-Kamera identifizieren
** <code>/bin/camera</code> ersetzen
* Treiberschaltung für Schwenk-Neige-Schrittmotoren aufbauen (benötigt werden 8 Ausgänge)
** <code>busybox</code> bauen
** Ethernet initialisieren
** <code>telnetd</code> starten
* Steuerung der DC-Motoren und Relais-Ausgänge identifizieren
* ???
* Profit!
217

Bearbeitungen

Navigationsmenü