Abo
  • Services:
Anzeige
Code des Bootloaders
Code des Bootloaders (Bild: Christer Weinigel)

Arbeite cleverer, nicht fleißiger

Um das zu beschleunigen, schreibe ich einen kleinen Linux-Treiber, der alle unbekannten GPIO-Pins als Eingabe-Pins mit einem Pull-up-Widerstand konfiguriert. Der Treiber liest dann in einer Schleife die Datenregister der Pins und überwacht die Änderungen der Werte. Ändert sich der Wert eines Pins, gibt der Treiber eine Meldung auf der Linux-Konsole aus.

Ich messe zuerst die Spannung am Pin A0 des Multiplexers von Kanal 1 (U31, Pin 8), sie beträgt 3,3 Volt. Mit einem Kabel schließe ich dann A0 mit der Masse kurz. Durchatmen - aber es gibt keine Funken und ich erhalte eine Ausgabe auf der Konsole:

Anzeige
GPCDAT 0x0000007c -> 0x0000005c diff 0x00000020
GPCDAT 0x0000005c -> 0x0000007c diff 0x00000020

Ich schaue auf die Ausgabe und sie besagt, dass das fünfte Bit des GPCDAT-Registers auf Low wechselt, wenn ich den Pin mit dem Kabel berühre und wieder auf High, wenn ich das Kabel entferne. Der SoC hat einen schwachen Pull-up-Widerstand am Pin, wodurch er auf High schaltet. Berühre ich den Endpunkt der Leiterbahn des Pins am A0-Pin, erzwinge ich ein Low-Signal auf der Leiterbahn. Es ist also sehr wahrscheinlich, dass der SoC-Pin GPC5 mit dem A0-Pin des Multiplexers verbunden ist.

Tatsächlich benutze ich kein blankes Kabel, um die Verbindung mit der Masse herzustellen. Einen aktiven Ausgang mit der Masse zu verbinden, kann dazu führen, den Treiberschaltkreis zu beschädigen oder die Stromversorgung kurzzuschließen, sollte es sich um eine Stromschiene handeln. Stattdessen benutze ich zusätzlich einen 330-Ohm-Widerstand. Liegt an einem Pin 3,3 Volt an, begrenzt der Widerstand den Strom auf 10 mAmpere. Dieser Strom ist hoffentlich klein genug, um keine sofortigen Beschädigungen auszulösen. Es ist trotzdem immer noch riskant, aber sicher genug, um Pins zu testen - solange die Verbindung nicht zu lang besteht.

Mit dem Linux-Treiber gelingt es mir schnell, andere Verbindungen zu finden. Der Multiplexer ist mit den folgenden Pins verbunden:

GPC5    Channel 1 MUX A0 (U31 pin 8)
GPC6    Channel 1 MUX A1 (U31 pin 9)
GPH9    Channel 2 MUX A0 (UE pin 8)
GPH11   Channel 2 MUX A1 (UE pin 9)

An dieser Stelle habe ich vergessen, die Shutdown- und Enable-Pins des Multiplexers zu prüfen. Ich glaube, die Funktionen sind fest verdrahtet, aber eine Prüfung ist immer besser.

Noch mehr Pins

Ich setze meine Messungen fort und verbinde alle möglichen Pins und Kontakte mit der Masse, um sie auf ein Low-Signal zu ziehen. Es ist sinnvoll, zuerst die Spannung am Kontakt beziehungsweise dem Pin zu prüfen. Beträgt sie bereits 0 Volt, dann ist es sinnlos, den Pin auf Low zu ziehen. Beträgt die Spannung mehr als 3,3 Volt, ist der Pin nicht mit dem SoC oder dem FPGA verbunden, denn sie können nicht mit höheren Spannungen umgehen.

Wenn auf einem Kontakt oder Pin ein Low-Signal anliegt, kann er trotzdem mit dem SoC verbunden sein. Möglicherweise ist ein externer Pull-down-Widerstand stärker als der interne Pull-up-Widerstand im SoC. In dem Fall könnte ich das Kabel über einen Widerstand mit einem 3,3 oder 1,8 Volt-Anschluss verbinden statt dem Masse-Anschluss und so ein High-Signal erzeugen. Alternativ könnte ich im Linux-Treiber auch die internen Pull-down-Widerstände aktivieren und auf den Pins ein High-Signal anlegen.

Ich finde heraus, dass der Pin GPF3 mit dem Widerstand R174 verbunden ist, der nahe beim Steckverbinder für das Frontpanel sitzt. Das ist nicht so merkwürdig, wie es mir zuerst vorkam. Wenn ich GPF3 umschalte, leuchtet der Run/Stop-Button auf. Der Pin muss also irgendwie mit dem Frontpanel verbunden sein. GPH3 ist mit dem Widerstand R80 daneben verbunden, aber nichts passiert, wenn ich den Pin ansteuere. Keiner der anderen Kontakte am Steckverbinder für das Frontpanel löst irgendetwas bei meinem Test aus.

Der mysteriöse Steckverbinder U60 scheint mit vielen GPIO-Pins des SoC verbunden zu sein. Anscheinend handelt es sich um eine Debug-Schnittstelle, wo einige ungenutzte Pins anliegen:

1      GPL8
2      GPE8
3      GPE10
4      GPH2
5      GPF7
6      GPB5
7      GPH5
8      GPF4
9      GPG3
10     GPG1
11     GPG5
12     GPK9
13     GPK14
14     GPK10
15     GPK12
16     GPK3
17     GND
18     GND
19     7.3V, not the same wire as for pin 20
20     7.3V, not the same wire as for pin 19

An den GPK-Pins liegen 1,8 Volt an, an den übrigen 3,3 Volt. Ich hatte zuerst keine Ahnung, wo die 7,3 Volt herkamen und ob die beiden Kontakte sich überhaupt unterschieden. Wie mir aber später aufgeht, handelt es sich wohl um die Spannung der Stromversorgung des Oszilloskops. Ich speise es mit 7,5 Volt aus einem Netzteil über den Batterieeingang. Die Differenz ergibt sich wohl durch mein nicht kalibriertes Multimeter.

Ich finde es schade, dass die Owon-Ingenieure die Verbindungen der Pins vom SoC nicht etwas anders angeordnet haben. Es wäre mit kleinen Layoutänderungen auf der Platine wohl möglich gewesen, die Kontakte der SD/MMC-Schnittstelle am Steckverbinder anzulegen. Oder wenigstens eine serielle Schnittstelle oder die I2S-Schnittstelle. Natürlich können viele Protokolle einfach durch Bitbanging an den obigen Pins simuliert werden. Aber ohne Hardware-Unterstützung ist das langsamer.

Den Pin GPF2 und seine Funktion habe ich bereits früher durch Zufall entdeckt. Er dient zum Erkennen einer USB-Verbindung am USB-Client-Anschluss über das VBUS-Signal. Allerdings gibt er mir immer noch Rätsel auf. Wenn ich ein USB-Kabel einstecke und entferne, liefert mein Linux-Treiber keinerlei Ausgabe. Wo liegt mein Fehler? Schließlich finde ich heraus, dass das VBUS-Signal in einen Spannungsteiler eingespeist und von dort aus Pin GPF2 zugeführt wird. Ist der interne Pull-up-Widerstand durch meinen Treiber aktiviert, liegt an GPF2 ein High-Signal an, wenn keine USB-Verbindung besteht. Wird ein USB-Kabel angeschlossen, wird der GPF2 ebenfalls auf High gezogen. Da sich das Signal also nicht ändert, registriert mein Treiber auch keine Änderung. Ich deaktiviere also den Pull-up-Widerstand für GPF2 und nun funktioniert die VBUS-Erkennung. Bis dahin habe ich die direkte Verbindung von VBUS-Signal und dem Signalwert an GPF2 als gegeben vorausgesetzt.

Mein Linux-Treiber macht mich auch auf den merkwürdigen Pin GPB6 aufmerksam. Sein Zustand ändert sich gelegentlich, ohne dass ich bislang einen Grund oder einen Zusammenhang zu meinen Aktionen erkennen konnte.

 Mal eben einen Treiber schreibenEin kurzer Schreckmoment 

eye home zur Startseite
AgentBignose 25. Nov 2016

Ähm, ja.... Was meinst du wie Leute wie der ursprüngliche Autor gefragt sind...

Karl-Heinz 23. Nov 2016

heißen die Dinger hier. Vielleicht bin ich aber auch nur zu oldschool :)

Luu 23. Nov 2016

Einfach nur große Klasse. Könnten sich andere eine Scheibe von abschneiden.



Anzeige

Stellenmarkt
  1. Bertrandt Technikum GmbH, Ehningen bei Stuttgart
  2. Packsize GmbH, Herford (Home-Office)
  3. Bertrandt Services GmbH, Ulm
  4. stoba Präzisionstechnik GmbH & Co. KG, Backnang (nahe Stuttgart)


Anzeige
Hardware-Angebote
  1. 18,99€ statt 39,99€
  2. 699€

Folgen Sie uns
       


  1. Lego Boost im Test

    Jede Menge Bastelspaß für eine kleine Zielgruppe

  2. Platooning

    Daimler fährt in den USA mit Lkw im autonomen Konvoi

  3. Suchmaschine

    Apple stellt Siri auf Google um

  4. Gruppenchat

    Skype for Business wird durch Microsoft Teams ersetzt

  5. Teardown

    iFixit findet größeren Akku in Apple Watch Series 3

  6. Coffee Lake

    Intel verkauft sechs Kerne für unter 200 Euro

  7. MacOS 10.13

    Apple gibt High Sierra frei

  8. WatchOS 4.0 im Test

    Apples praktische Taschenlampe mit autarkem Musikplayer

  9. Werksreset

    Unitymedia stellt Senderbelegung heute in Hessen um

  10. Aero 15 X

    Mehr Frames mit der GTX 1070 im neuen Gigabyte-Laptop



Haben wir etwas übersehen?

E-Mail an news@golem.de


Anzeige
Bundestagswahl 2017: Viagra, Datenbankpasswörter und uralte Sicherheitslücken
Bundestagswahl 2017
Viagra, Datenbankpasswörter und uralte Sicherheitslücken
  1. Bundestagswahl 2017 IT-Probleme verzögerten Stimmübermittlung
  2. Bundestagswahl 2017 Union und SPD verlieren, Jamaika-Koalition rückt näher
  3. Zitis Wer Sicherheitslücken findet, darf sie behalten

Olympus Tough TG5 vs. Nikon Coolpix W300: Die Schlechtwetter-Kameras
Olympus Tough TG5 vs. Nikon Coolpix W300
Die Schlechtwetter-Kameras
  1. iZugar 220-Grad Fisheye-Objektiv für Micro Four Thirds vorgestellt
  2. Mobilestudio Pro 16 im Test Wacom nennt 2,2-Kilogramm-Grafiktablet "mobil"
  3. HP Z8 Workstation Mit 3 TByte RAM und 56 CPU-Kernen komplexe Bilder rendern

VR: Was HTC, Microsoft und Oculus mit Autos zu tun haben
VR
Was HTC, Microsoft und Oculus mit Autos zu tun haben
  1. Zukunft des Autos "Unsere Elektrofahrzeuge sollen typische Porsche sein"
  2. Concept EQA Mercedes elektrifiziert die Kompaktklasse
  3. GLC F-Cell Mercedes stellt SUV mit Brennstoffzelle und Akku vor

  1. Re: Super Gau

    ML82 | 09:41

  2. Yubico sollte erstmal seine Manuals korrigieren

    Hawk321 | 09:40

  3. Fehlt noch Amazon, dann ist alles gut!

    WalterWhite | 09:39

  4. Was ist eine Unternehmensfirma ? Oder ist eine...

    mziegler | 09:38

  5. "quetscht sich ein auto in die kolonne..."

    jake | 09:37


  1. 09:44

  2. 09:11

  3. 08:57

  4. 07:51

  5. 07:23

  6. 07:08

  7. 19:40

  8. 19:00


  1. Themen
  2. A
  3. B
  4. C
  5. D
  6. E
  7. F
  8. G
  9. H
  10. I
  11. J
  12. K
  13. L
  14. M
  15. N
  16. O
  17. P
  18. Q
  19. R
  20. S
  21. T
  22. U
  23. V
  24. W
  25. X
  26. Y
  27. Z
  28. #
 
    •  / 
    Zum Artikel