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".
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" ;)
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 ;)
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?
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.
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.
1 | Uncompressing Linux.......................... done, booting the kernel. |
2 | |
3 | Linux version 2.6.32.3 (x@y) (gcc version 4.3.4 (GCC) ) #12 Sat Jan 9 07:38:14 CET 2010 |
4 | |
5 | CPU: ARM920T [41129200] revision 0 (ARMv4T), cr=c0007177 |
6 | |
7 | CPU: VIVT data cache, VIVT instruction cache |
8 | |
9 | Machine: Pingu920 |
10 | |
11 | Warning: bad configuration page, trying to continue |
12 | |
13 | Memory policy: ECC disabled, Data cache writeback |
14 | |
15 | Clocks: CPU 179 MHz, master 59 MHz, main 18.432 MHz |
16 | |
17 | Built 1 zonelists in Zone order, mobility grouping on. Total pages: 16256 |
18 | |
19 | Kernel command line: mtdparts=spi0.0-AT45DB321x:16896(dfboot),16896(env),236544(uboot),2162688(linux),1892352(root) root=/dev/mtdblock4 rootfstype=cramfs mem=64M |
20 | |
21 | PID hash table entries: 256 (order: -2, 1024 bytes) |
22 | |
23 | Dentry cache hash table entries: 8192 (order: 3, 32768 bytes) |
24 | |
25 | Inode-cache hash table entries: 4096 (order: 2, 16384 bytes) |
26 | |
27 | Memory: 64MB = 64MB total |
28 | |
29 | Memory: 62688KB available (1860K code, 173K data, 80K init, 0K highmem) |
30 | |
31 | SLUB: Genslabs=11, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 |
32 | |
33 | Hierarchical RCU implementation. |
34 | |
35 | NR_IRQS:192 |
36 | |
37 | AT91: 96 gpio irqs in 3 banks |
38 | |
39 | console [ttyS0] enabled |
40 | |
41 | Calibrating delay loop... 89.79 BogoMIPS (lpj=350208) |
42 | |
43 | Mount-cache hash table entries: 512 |
44 | |
45 | CPU: Testing write buffer coherency: ok |
46 | |
47 | NET: Registered protocol family 16 |
48 | |
49 | bio: create slab <bio-0> at 0 |
50 | |
51 | SCSI subsystem initialized |
52 | |
53 | usbcore: registered new interface driver usbfs |
54 | |
55 | usbcore: registered new interface driver hub |
56 | |
57 | usbcore: registered new device driver usb |
58 | |
59 | LinuxPPS API ver. 1 registered |
60 | |
61 | Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it> |
62 | |
63 | Switching to clocksource 32k_counter |
64 | |
65 | NET: Registered protocol family 2 |
66 | |
67 | IP route cache hash table entries: 1024 (order: 0, 4096 bytes) |
68 | |
69 | TCP established hash table entries: 2048 (order: 2, 16384 bytes) |
70 | |
71 | TCP bind hash table entries: 2048 (order: 1, 8192 bytes) |
72 | |
73 | TCP: Hash tables configured (established 2048 bind 2048) |
74 | |
75 | TCP reno registered |
76 | |
77 | NET: Registered protocol family 1 |
78 | |
79 | io scheduler noop registered |
80 | |
81 | io scheduler anticipatory registered (default) |
82 | |
83 | atmel_usart.0: ttyS0 at MMIO 0xfefff200 (irq = 1) is a ATMEL_SERIAL |
84 | |
85 | atmel_usart.1: ttyS1 at MMIO 0xfffc0000 (irq = 6) is a ATMEL_SERIAL |
86 | |
87 | atmel_usart.2: ttyS2 at MMIO 0xfffc4000 (irq = 7) is a ATMEL_SERIAL |
88 | |
89 | atmel_usart.3: ttyS3 at MMIO 0xfffc8000 (irq = 8) is a ATMEL_SERIAL |
90 | |
91 | atmel_spi atmel_spi.0: Atmel SPI Controller at 0xfffe0000 (irq 13) |
92 | |
93 | mtd_dataflash spi0.0: AT45DB321x (4224 KBytes) pagesize 528 bytes (OTP) |
94 | |
95 | 5 cmdlinepart partitions found on MTD device spi0.0-AT45DB321x |
96 | |
97 | Creating 5 MTD partitions on "spi0.0-AT45DB321x": |
98 | |
99 | 0x000000000000-0x000000004200 : "dfboot" |
100 | |
101 | 0x000000004200-0x000000008400 : "env" |
102 | |
103 | 0x000000008400-0x000000042000 : "uboot" |
104 | |
105 | 0x000000042000-0x000000252000 : "linux" |
106 | |
107 | 0x000000252000-0x000000420000 : "root" |
108 | |
109 | at91_ether: probe of at91_ether failed with error -1 |
110 | |
111 | ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver |
112 | |
113 | at91_ohci at91_ohci: AT91 OHCI |
114 | |
115 | at91_ohci at91_ohci: new USB bus registered, assigned bus number 1 |
116 | |
117 | at91_ohci at91_ohci: irq 23, io mem 0x00300000 |
118 | |
119 | usb usb1: configuration #1 chosen from 1 choice |
120 | |
121 | hub 1-0:1.0: USB hub found |
122 | |
123 | hub 1-0:1.0: 1 port detected |
124 | |
125 | Initializing USB Mass Storage driver... |
126 | |
127 | usbcore: registered new interface driver usb-storage |
128 | |
129 | USB Mass Storage support registered. |
130 | |
131 | udc: at91_udc version 3 May 2006 |
132 | |
133 | TCP cubic registered |
134 | |
135 | VFS: Mounted root (cramfs filesystem) readonly on device 31:4. |
136 | |
137 | Freeing init memory: 80K |
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.