Anbei ein kleines Projekt, an dem ich gerade arbeite. Es handelt sich um einen Einplatinencomputer auf Basis des Atmel AT91RM9200, der darauf ausgelegt wird, möglichst preisgünstig und vor allem mit "Hausmitteln" herstellbar zu sein. Auf der Platine: * AT91RM9200 (ARM920T @ 180 MHz) * 64 MByte SD-RAM * 4 MByte serielles Dataflash für Bootloader * USB-Host mit Buchse Typ A * USB-Device mit Buchse Typ B * Ethernet 10/100-Base-T mit Buchse RJ45 * SD-Karten-Slot * Schaltnetzteil 3,3V und 1,8V mit genügend Reserven für weitere Peripherie Ein einfacher 64-poliger Wannenstecker stellt folgende externe Schnittstellen zur Verfügung: * 4 x serielle Schnittstelle RXD/TXD, 3 x zusätzlich RTS/CTS * 1 x SPI mit Chip-Select * 1 x TWI bzw. I2C * External Bus Interface (EBI) mit 16bit Datenbus und 4 Adressleitungen für MMIO * zahlreiche GPIO * alle für ein IDE-Interface erforderlichen Signale stehen extern zur Verfügung Programmieren lässt sich das Board ganz einfach ohne JTAG, da das interne Bootprogramm im ROM des AT91RM9200 den Download per XMODEM über eine serielle Schnittstelle, die sog. "Debug Unit", zulässt. Diese Debug Unit ist über einen FT232R als USB nach draußen geführt. Über das Einlöten von Widerständen wird festgelegt, ob die USB-B-Buchse auf der Platine mit der Debug Unit oder dem USB Device Port des AT91RM9200 verbunden ist. Die Platine wird etwa eine halbe Eurokarte groß sein und in ein handelsübliches Aluprofil-Gehäuse passen. SD-Karten-Slot und alle Buchsen sind an einer Seite angeordnet, so daß sie über die Frontplatte zugänglich sind. Es kommen keinerlei BGA- oder QFN-Bauteile zum Einsatz. Der "schlimmste" Pitch ist 0,5mm; solche Bauteile lassen sich auch mit einfachem Werkzeug und etwas Efahrung per Hand löten. Die Platine ist zwar vierlagig, die Anforderungen bleiben mit 0,3mm als kleinster Bohrung und 150µm als feinster Struktur im Kupfer jedoch im Rahmen. Die Platine ist nur einseitig bestückt. Aktueller Stand: Schaltplan und Platinenlayout "so gut wie fertig".
Vorläufiger Schaltplan.
Jetzt hoffe ich natürlich, daß zahlreiche Tipps und Verbesserungsvorschläge eintrudeln, bevor die Platine in die Prototypen-Fertigung geht! Allerdings wird sich am grundlegenden Konzept nichts mehr ändern, denn ich benötige genau eine solche Platine als Bestandteil für ein größeres Projekt. Wer gravierende Fehler findet, wird im nächsten Iterationsschritt mit einer Gratis-Platine bedacht - "so lange der Vorrat reicht" ;)
Gast
#1158339
Ein paar Ferite / Filter täten in den Stromversorgungszweigen und in den Steckkontackten ganz gut.. Zusätzlicher Spannungsversorgungsstecker falls man man "Stand Alone" sein will Naja halt allerlei rund um EMV-Schutz und Störausstrahlung fehlt halt... Aber es kommt auch sehr stark auf das Layout an! Hab auch schon diverse mehrlagige (10+) EMV-Gerechte (mit bestandenen Test) zig MHz DSP-Layouts mit EAGLE ;) geroutet... ist halt alles ein sache des Könnens und des Wissens um Proble prahl ;) by the way Was für ein CAD-System benutzt du? Integra?
Nein, das ist nur das schnöde Eagle. ESD/EMV-Schutz wollte ich für den "User-Port" nicht vorsehen, das wäre zu viel Aufwand. Je nachdem, was da angeflanscht wird, muß man das halt extern machen. Für USB sollten die Kondensatoren reichen, der verwendete Magjack für Ethernet hat das nötige drin. Stromversorgung generell - ja, da hast du Recht, da werde ich mich nochmal dransetzen. Leider kann ich bei nur vier Lagen und so wenig Platz für Vias die "bösen" Signale nicht nach innen legen.
Ich gebe auch noch meinen Senf dazu: - Ethernet: Pullup für MDIO (Eventuell kann man auch den internen vom Atmel nehmen, wenn vorhanden) - DBGU: R8/R9 sind überflüssig, da die R-Versionen von FTDI die Widerstände schon drin haben. Pullup R2 u.U. auch überflüssig, da der FTDI interne Pullups an den Eingängen hat. - JTAG: Wenigstens auf Testpunkte legen. Vielleicht will mal einer doch debuggen ;) - Erweiterungsstecker: Etwas mehr Masseverbindungen wären nicht schlecht. Wie Tüddel schon geschrieben hat ein paar Ferrite würden sich gut machen. Noch eine andere Frage: Warum kein 9260?
> - Ethernet: Pullup für MDIO (Eventuell kann man auch den internen vom > Atmel nehmen, wenn vorhanden) Korrekter Hinweis, danke. > - DBGU: R8/R9 sind überflüssig, da die R-Versionen von FTDI die > Widerstände schon drin haben. Die Widerstände sollen nicht 27 Ohm haben, sondern 0 Ohm. Durch Ein-/Auslöten von R8/R9 oder R36/R37 wird die Umschaltung vom USB Device Port auf die Debug Unit gemacht. > Pullup R2 u.U. auch überflüssig, da der > FTDI interne Pullups an den Eingängen hat. Der Pin dient beim Starten als BMS - "Boot Mode Select", und auf die 200 kOhm vom FT232 wollte ich mich nicht verlassen. > - JTAG: Wenigstens auf Testpunkte legen. Vielleicht will mal einer doch > debuggen ;) Pah ;) > - Erweiterungsstecker: Etwas mehr Masseverbindungen wären nicht > schlecht. Ich kaufe... mehr Platz. Na gut, vielleicht kann man ein paar GPIOs opfern. > Noch eine andere Frage: Warum kein 9260? Erfüllt meine Anforderungen, ist leicht zu bekommen, und außerdem hatte ich schon ein Symbol in Eagle dafür gebaut. Keine weiteren guten Argumente.
Gerade noch selbst gesehen: Ein Oszillator funktioniert auch besser mit Stromversorgung ;)
Gast
#1158749
Die Lösung mit dem Ein-/Auslöten von Widerständen um zwischen Programmieren und USB-Device-Port umzuschalten finde ich alles andere als praktisch. Ich wäre für Steckbrücken. Oder bist du der perfekte Programmierer der keine Fehler macht und deswegen nur ein mal das Board flashen muss?
Gast
#1158752
Wie wird eigentlich das Board mit Spannung versorgt? Erfolgt die Spannungsversorgung über USB oder wird das Board über K1 mit Spannung versorgt oder fehlt da noch ein Stecker für den Niederspannungsanschluss inklusiver Verpolungsschutz? Bei X1 ist Pin 1 mit 5V bezeichnet, bei X2 ist ist Pin 1 mit USBD-C mit dem Prozessor verbunden, kann der Prozessor max. 500mA laut USB-Spezifikation liefern??? Erscheint mir etwas gewagt.
> Die Lösung mit dem Ein-/Auslöten von Widerständen um zwischen > Programmieren und USB-Device-Port umzuschalten finde ich alles andere > als praktisch. Ich wäre für Steckbrücken. > > Oder bist du der perfekte Programmierer der keine Fehler macht und > deswegen nur ein mal das Board flashen muss? Natürlich nicht. Allerdings würde es reichen, den Bootloader "u-boot" einmal auf dem Dataflash zu installieren. Das Board würde anschließend entweder über NFS vom PC booten, oder Betriebssystem und Kernel sind auf der SD-Karte installiert. Die Programmentwicklung oder das Anpassen des Kernels würde also nicht ein ständiges Umlöten erfordern. Trotzdem sind normale Jumper natürlich schöner. Ich ändere das, wenn noch Platz ist.
> Wie wird eigentlich das Board mit Spannung versorgt? Erfolgt die > Spannungsversorgung über USB oder wird das Board über K1 mit Spannung > versorgt oder fehlt da noch ein Stecker für den Niederspannungsanschluss > inklusiver Verpolungsschutz? Das Board soll über K1 mit stabilisierten +5V versorgt werden. Grund ist, daß in meinem Projekt eine Basisplatine zur Verfügung steht, auf der weitere Peripherie und das "Hauptnetzteil" vorhanden sind. Ein Niederspannungsanschluß wäre natürlich schön, solange man das Board als Entwicklungsplattform auf dem Schreibtisch einsetzt, auf der Platine ist aber definitiv kein Platz mehr für ein solch sperriges Teil. > Bei X1 ist Pin 1 mit 5V bezeichnet, bei X2 ist ist Pin 1 mit USBD-C mit > dem Prozessor verbunden, kann der Prozessor max. 500mA laut > USB-Spezifikation liefern??? Erscheint mir etwas gewagt. USBD-C soll als Eingang programmiert werden und dient nur der Erkennung, ob an X2 - dem USB-Device - ein Host angeschlossen ist. Deshalb auch der Spannungsteiler von 5V auf 3,3V. Das USB-Device versorgt nichts mit Spannung, und das Board selbst wird anders herum auch nicht über USB versorgt. Bei dem USB-Host - also X1 - habe ich einfach die 5V-Versorgung durchgeschleift. Theoretisch könnte man natürlich so einen Chip nehmen, wie er z.B. in USB-Hubs eingebaut ist, der den Strombedarf überwacht und den Port ggf. wegschaltet. Das halte ich aber für Overkill bei so einer Anwendung - die meisten ARM9-Boards machen das auch nicht anders.
Gast
#1158760
Alternativ noch folgender Vorschlag: Wenn du den FT232RL wirklich nur ein mal benötigst, dann wäre es sogar sinnvoller, diesen komplett vom Board zu nehmen und nur die nötigen Leitungen zum Programmieren heraus zu führen und extern dann den RS232RL auf eine eigene Platine zusetzen!?
Eher nicht, weil diese USB-Verbindung die Linux-Konsole darstellt. Den Bootvorgang kann man anders schlecht überwachen. So lange es noch kein Telnet, SSH etc. gibt, wäre das Board "stumm" und Kernelprobleme würden sich schlecht rausdebuggen lassen. Hat man irgendwann einmal eine fertige Anwendung, die keine Konsole, aber dafür ein USB-Device-Port benötigt, steht es einem natürlich frei, den FT232R einfach nicht zu bestücken. Ich brauche das USB-Device in meiner Anwendung sogar überhaupt nicht, und würde im Zweifelsfall eher die serielle Schnittstelle über den FT232R behalten als ein "echtes" USB-Device.
Hier die überarbeitete Version
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
24 | |
25 | |
26 | |
27 | |
28 | |
29 | |
30 | |
31 | |
32 | |
33 | |
34 | |
35 | |
36 | |
37 | |
38 | |
39 | |
40 | |
41 | |
42 | |
43 | |
44 | |
45 | |
46 | |
47 | |
48 | |
49 | |
50 | |
51 | |
52 | |
53 | |
54 | |
55 | |
56 | |
57 | |
58 | |
59 | |
60 | |
61 | |
62 | |
63 | |
64 | |
65 | |
66 | |
67 | |
68 | |
69 | |
70 | |
71 | |
72 | |
73 | |
74 | |
75 | |
76 | |
77 | |
78 | |
79 | |
80 | |
81 | |
82 | |
83 | |
84 | |
85 | |
86 | |
87 | |
88 | |
89 | |
90 | |
91 | |
92 | |
93 | |
94 | |
95 | |
96 | |
97 | |
98 | |
99 | |
100 | |
101 | |
102 | |
103 | |
104 | |
105 | |
106 | |
107 | |
108 | |
109 | |
110 | |
111 | |
112 | |
113 | |
114 | |
115 | |
116 | |
117 | |
118 | |
119 | |
120 | |
121 | |
122 | |
123 | |
124 | |
125 | |
126 | |
127 | |
128 | |
129 | |
130 | |
131 | |
132 | |
133 | |
134 | |
135 | |
136 | |
137 | |
Ein paar Fehler sind gefunden und behoben, ein paar andere sind noch offen (siehe oben). Der Ethernet PHY macht noch Probleme (25MHz-Oszillator läuft nicht an) und das JFFS2 als RootFS funktioniert nicht auf dem Dataflash. Letzteres ist anscheinend aber ein bekanntes Problem. Aber immerhin habe ich schon eine Partie GNUchess gegen das kleine Board gespielt.
Gibt es was neues oder ist das Projekt tot?
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.