3.2 Hardware

KO Messung Tastaturmultiplexer

0

Im Rahmen der Fehlersuche am Tastaturmultiplexer habe ich Messungen mit dem Oszillografen gemacht.

20110922-153116.jpg

Auf diesem Bild sind die Signale einer Adressleitung und des Multiplexer-Ausgangs zu sehen. Wir erkennen, dass die Ausgangssignale eine längere Zeit brauchen, um auf 0V zurückzukehren, als die Adresssignale.

20110922-153211.jpg

Auf diesem Bild sind die Signale von zwei Adressleitungen in einer höheren Auflösung abgebildet. Wir erkennen das Verhalten eines digitalen Zählers.

20110922-153148.jpg

Aus dem vorhergehenden Signal können wir die Frequenz der Zählers ermitteln. Ein Zyklus misst 3 Einheiten, was 0.6 ms entspricht. Demnach ist die Frequenz f=1/0.6ms=1.6kHz.

20110922-153234.jpg

Bei einer tieferen Auflösung erkennen wir, dass die Adressierung doch nicht ganz einem digitalen Zähler entspricht. Genauer gesagt habe ich zwei 8-Kanal Multiplexer an einen dritten angehängt. Das ergibt insgesamt 22 Eingänge, wobei die Adressierung nicht mehr linear abläuft. Vgl. dazu den Code.

Elektromechanische Probleme beim Tastatur-Decoder

0

Bei der Inbetriebnahme des Tastaturdecoders (TDC) stellt sich heraus, dass dieser sehr empfindlich ist auf äussere elektromagnetische Störungen, z.B. einen eingeschalteten Lötkolben. Diese Empfindlichkeit wird enorm verstärkt, wenn die Leiterplatte auf einem ungeeignetem Material aufliegt.

Das äussert sich darin, dass die Tasten als gedrückt erscheinen, bzw. der GPIO/Input des TMS320 als “High” erkannt wird, obwohl die Taste nicht gedrückt ist. Das kommt sogar vor, wenn man den Eingang auf dem TDC-Board direkt auf Masse schliesst. Ich vermute, dass Potentialschwankungen auf der Masse des TDC-Boardes vorhanden sind.

Diverse Versuche u.a. mit RC-Filtern am Input und Verlegen weiterer Masse-Leitungen brachten nicht den gewünschten Erfolg.

Etwas Stabilität brachte es, die Leiterplatte auf eine Sichtmappe aus Plastik zu legen.

Es stellte sich schlussendlich heraus, dass die Lötaugen auf der Leiterplatte (PCB) zu fein waren und durch die geringe mechanische Belastung beim Einbau ins Gehäuse abgerissen sind. Auf den unteren Bildern ist zu sehen, wie ich die Übergänge zu der Steckerleiste notbehelfsmässig repariert haben. Für einen Prototypen ist dieses Verfahren akzeptabel, doch für einen produktiven Einsatz muss die PCB verbessert und neu hergestellt werden.

20110922-153636.jpg

20110922-153655.jpg

 

DAC PCB 1

0

Da die eZdsp-Hardware nur über einen zweikanaligen DAC verfügt, muss ich eine Erweiterungs-Platine (PCB) entwickeln. Hier der erste Entwurf des DAC-PCBs:

 

Samtec, der Hersteller des PCB-Steckers, der zu der eZdsp-Hardware passt, hat ein Skript zum Design des SMD/PCB-Steckers als Download zur Verfügung gestellt. Das Skript kann im Programm Eagle dazu verwendet werden, um Layoutvorlagen zu erstellen. Ich habe dieses Skript auf die passende Anzahl Pins modifiziert (Ausschnitte aus dem Skript):

#  MEC1-130-02-S-D-A.scr
#
# Library Script
#  
#  PCB Matrix
SET WIRE_BEND 2;
Grid mm;
SET COLOR_LAYER 29 3
...
Layer 52 bDocu;
Description '<b>PCB Matrix Packages</b><p>\n';

Edit MEC1-130-02-S-D-A.pac;
Description '1MM MIN-EDGE CARD ASSEMBLY';
Layer 1;
SMD '1' 1.88 0.61 -0 R90 (-9.5 -3.53049993515015);
...
SMD '58' 1.88 0.61 -0 R90 (19.5 3.53049993515015);

Change Drill 1.02;
...

Design Frage Speicher (Board/CPU 5505/5515)

0

Wie sich heraus stellt, ist die ursprünglich intuitiv gewählte Speicher-Technologie der SD-Karte nicht frei, d.h. es steht eine Organisation dahinter, die eine Lizenzgebühr für die vollständige Dokumentation und für den Einsatz in Produkten verlangt. Ausserdem wird eine proprietäre Steckverbindung verwendet, die teuer und nicht so einfach erhältlich ist.

Als sinnvolle Alternative dazu bietet sich an, einen Onboard-Flash-Memory Chip zu verwenden. Ein solcher ist auf dem eZdsp-Board vorhanden. Dazu müsste ich eine USB-Anbindung schreiben, so dass unser Board sich als USB-Memory-Stick an einem Host anmelden kann. Diese Technologie zu ergründen und zu beherrschen ist sehr spannend, denn USB ist ein freier und weit verbreiteter Standard.

Aufgrund dieser Erkenntnis verzichte ich auf eine weitere Entwicklung mit der SD-Karte.

In folgendem Archiv findet sich ein USB-Stick Codebeispiel, das allerdings für ein C5515-Board geschrieben ist. Es ist jedoch ein Einstiegspunkt. Ich werde nun versuchen, dieses Beispiel auf unser VC5505-Board zu portieren.

support.spectrumdigital.com/boards/usbstk5515/reva/

Ausserdem habe ich schon mal die USB2.0-Spezifikationen besorgt:

www.usb.org/developers/docs/

Erkenntnisse:

  • USB kann auf dem VC5505-Board nicht getestet werden, da die benötigten Anschlüsse an der CPU gegen Masse verdrahtet sind (Schema Seite 3, Pins G13,J12,H14,G8…). Ausserdem würde ein zusätzliches 12-MHz-Quarz benötigt.
  • Bis auf eine höhere maximale Taktfrequenz (C5515: 120 MHz, VC5505: 100 MHz) sind die beiden CPUs identisch.
  • Die CPUs verfügen über einen SD-Card Controller, der auch im SD-Modus funktioniert
  • VC5505 scheit ein Auslaufmodell zu sein und wird vom Hersteller nicht für Neuentwicklungen empfohlen. Nachfolgermodell wäre C5505, C5515 ist ähnlich

Weiteres Vorgehen: Besorgen des C5515-Testboards: ch.farnell.com/spectrum-digital/c5515-ezdsp-usb-stick/entwicklungsboard-ezdsp-usb-stick/dp/1831928

 

SD-Karte an eZdsp-Board anschliessen

0

Gemäss funktionierendem Schaltplan von Sparkfun verdrahten wir die eZdsp-Karte mit der SD-Karte. Ein Spannungskonverter von 5V auf 3.3V ist nicht nötig, da eZdsp bereits auf 3.3V läuft. Die Verdrahtung sieht wie folgt aus:

Host MicroSDCard Pin SDCard Pin eZdsp edgecon
NC 1
CS CS 2 CS 1 SPI0_CS1 3
MOSI DI 3 DI 2 SPI0_DX 7
3.3V VCC 4 VDD 4 VCC_3.3V 39
SCK SCK 5 SCK 5 SPI0_CLK 5
GND GND 6 VDD 3;6 GND 1;11
MISO DO 7 DO 7 SPI0_RX 9
RSV 8

20111028-094304.jpg

Referenzen

www.sparkfun.com/datasheets/DevTools/Arduino/microSD_Shield-v13%20Schematic.pdf

elasticsheep.com/wp-content/uploads/2010/01/sd-card-pinout.png

www.sdcard.org/developers/howto/

Die Kommunikation zwischen SD-Karte und DSP funktioniert über die SPI-Schnittstelle. Bevor wir die SDFATLIB nachbauen können, versuchen wir, auf einfachste Weise die kommunikation mit der SD-Karte zu testen. Dies beinhaltet folgende Schritte:

  1. SD-Karte im SPI-Modus initialisieren
  2. Einen Befehl an die Karte schicken
  3. Die Antwort der Karte auslesen und überprüfen

Wir orientieren uns dabei an dem Code für die fat16lib (reduzierte SDFATLIB) und SPIROM:

fat16lib.googlecode.com/files/fat16lib20101009.zip

Weiter stehen uns folgende Dokumente mit Spezifikationen zur Verfügung:

www.sdcard.org/developers/tech/sdcard/pls/Simplified_Physical_Layer_Spec.pdf

Go to Top