Hallo, ich bin ein 16 jähriger Schüler und habe schon ca. 2 Jahre Erfahrung mit Mikrocontrollern (AVR) und knapp 1 Jahr mit VHDL. Angefangen zu programmieren habe ich mit 12 oder 13. Nun will ich mal ein größeres Projekt umsetzen. Dafür habe ich mir ein 480x272 Pixel RGB (24bit) Display mit entsprechendem Touchscreen besorg (17€ zusammen! :O) und wollte damit mal bisschen arbeiten (Displaytreiber in VHDL schreiben). Dafür muss ich mir aber sowieso eine Platine machen (lassen) weil es für das Display nur SMD Anschlussbuchsen gibt. Daher kam ich auf die Idee gleich eine Ebene mehr zu machen. Der Plan ist nun also einen ARM mit Speicherinterface draufzumachen, paar MB RAM ran, FPGA drauf, den FPGA auch ans Speicherinterface, an den FPGA noch mal RAM für Grafikspeicher und dann in den FPGA einen doppelt gepufferten Displaytreiber implementieren, für den ARM bisschen Software basteln und dann halt zumindest 2D Grafiksachen machen zu können. Ich weiß dass es ARMs mit Displayinterface gibt, ich weiß dass ein FPGA oversized ist usw. (außerdem, auf dem FPGA könnte man mit viel Zeit ja evtl. noch eine art Hardware 2D Engine basteln, so von wegen Rotationen und so). Das ganze Projekt ist aber eher gedacht zum Lernen wie das alles geht. Nehmt mich also bitte nicht auseinander :). Naja, ich denk mir schon, dass ich das ganz alleine wohl nicht hinbekomme. Schon allein die Hardware aussuchen wird kompliziert, ich hab doch keine Ahnung von ARMs und so. Vor der ARM Programmierung selber habe ich ehrlich gesagt weniger Angst, macht man dann ja eh mit C, das kann ich :). Hätte also jemand mit mehr Erfahrung Interesse mir ein wenig zur Seite zu stehen? Danke :) TD
Schau Dir mal die neuen Teile von Actel an; da ist bereits ein ARM als Hardcore mit drin. Gibt sicherlich noch ein, zwei andere Anbieter, die FPGAs mit integriertem ARM haben. Stephan.
Ist mir bekannt, die sind aber nicht so richtig flott, stimmts? :) Hätte schon gern son 300MHz ARM oder so. Macht ja auch nix wenn die Platine größer wird, ist ja wie gesagt nur für mich zum Lernen und so :).
Ja, mit 16 hatte ich auch meine erste CPU sebst zusammengebastelt (Z80, damals vor 20 Jahren gab es kein Internet und ich hatte auch keinen internetfähigen Computer) Schaue Dir mal den STM32F217 an. hat zwar blos 120MHz, aber dafür alles im Chip. Im Artikel STM32 gibt es einen Link zu ST. Dieser ist noch brand neu und müsste als Sample beziehbar (irgendwoher) sein. Oder einfach noch 2 Monate warten, würde sich aber lohnen! PS: Ich sehe gerade, als Sample gibt es den auch noch nicht, aber bald.
Mhm ich habe ein STM32 Discovery Board hier. Bin aber noch nicht so richtig dazu gekommen mir das anzusehen. 120MHz ist aber auch relativ langsam. Mein Problem ist vorallem der Speichertakt, je schneller ich Daten in den FPGA reinjagen kann desto weniger Zeit brauche ich um Bilder darzustellen, desto mehr Zeit habe ich für andere Sachen. Mal ein Rechenbeispiel: Ein Bild braucht (480x272x24)/32 Speichertakte, also knapp 100.000 Speichertakte. Bei 60FPS habe ich also 6mio Speichertakte, man kann aber damit rechnen, dass man pro Frame 2 Bilder anzeigen will, macht dann also 12mio Speichertakte, das sind bei 120MHz schon ganze 10% CPU Zeit nur für memcpy! bei 300MHz bin ich nurnoch bei 4%. Und ich würde das sowieso so machen die Daten im FPGA Blockram zwischenzuspeichern, damit krieg ich also die volle FPGA Taktfreq., das wären dann bei nem S3E immerhin so über 200MHz, richtig? (hab grad den max. Takt nicht im Kopf)
memcpy würde ich hier durch DMA ersetzen, dann hast du die CPU wieder frei für andere Berechnungen.
@Mars: Bringt das überhaupt Vorteile? Denn ich habe die Bilder ja einzeln im RAM liegen, und dann muss ich die so zusammenkopieren, wie sie dann auf dem Bildschirm sein sollen, also übereinanderliegend. Das Einzige was man machen könnte wäre einen Bereich im Speicher belegen, in dem nur steht "GPU, kopiere mir ein Bild mit den maßen 100x50pxl von der addresse 0xAABBCCDD an die Stelle (20|30) auf dem Display". Das Problem was ich dabei sehe ist allerdings, dass ich trotzdem warten muss, bis der FPGA fertig ist, die Daten in seinen Screenbuffer kopiert hat. Naja, wenigstens könnte die CPU derweil was ganz anderes machen. Habe mich ehrlich gesagt noch nicht mit DMA beschäftigt, werde mir mal durchlesen was dafür nötig ist. Danke
Moment mal, solang der FPGA via DMA Daten in den Screenbuffer kopiert kann die CPU nicht auf den RAM zugreifen, also auch keine Instruktionen holen, richtig? Das läuft ja dann aufs Gleiche raus oder? :O
Die meisten DMA-Controller unterstützen Scatter-gather Transfers. D.h.:
du kannst einen Transfer von nicht zusammenhängenden Speicherbereichen
durchführen.
>Naja, wenigstens könnte die CPU derweil was ganz anderes machen.
Du wolltest doch unbedingt die CPU-Last senken! Wenn du eh nichts
anderes mit der CPU anfangen willst warum sind dann 10% CPU Auslastung
so schlimm?
TokyoDrift schrieb: > Moment mal, solang der FPGA via DMA Daten in den Screenbuffer kopiert > kann die CPU nicht auf den RAM zugreifen, also auch keine Instruktionen > holen, richtig? Das läuft ja dann aufs Gleiche raus oder? :O Die Instruktionen liegen ja typischerweise im Flash.
Naja, es geht mir mehr darum zwischen den Bildern mehr machen zu können
bzw. mehr Bilder anzeigen zu können. Ich kann mir halt nicht vorstellen,
dass eine normale CPU zu 10% damit beschäftigt ist Zeug auf den
Bildschirm zu kopieren. Also muss das ja in Spielekonsolen zB. anders
gelöst sein.
>Die Instruktionen liegen ja typischerweise im Flash.
Mhm, wenn ich nun ne exec. von einer SD Karte o.Ä. ausführen will muss
ich die doch in den RAM legen oder? Ich kenne mich ein wenig mit der PSP
aus und da ist es eben so, dass man execs normal von Memorycards oder
direkt vom Optischen Laufwerk startet, das wäre doch viel zu langsam
oder?
Ich gehe mal davon aus, dass eine PSP eine 3D Grafikkarte hat und bei Start des Spieles wird die geladen, so 200MB Daten. Die CPU sagt dann nur noch diese 3D Ansicht, der Sichtwinkel, Tag/Nacht Ansicht, usw. und der Rest rechnet die GPU selbst. Also könnte man auch einen AVR nehmen, nur bracht der halt etwas länger um die 200MB 3D Daten in die Grafikkarte zu schieben.
Ausserdem: Der STM32F2 hat einen LCD Controller drauf, also wäre der FPGA überflüssig. So wie die Daten im RAM stehen werden die im Display gezeigt und es muss nichts kopiert werden.
>Ich gehe mal davon aus, dass eine PSP eine 3D Grafikkarte hat und bei >Start des Spieles wird die geladen, so 200MB Daten. Die CPU sagt dann >nur noch diese 3D Ansicht, der Sichtwinkel, Tag/Nacht Ansicht, usw. >under der Rest rechnet die GPU selbst. >Also könnte man auch einen AVR nehmen, nur bracht der hat etwas länger >um die 200MB 3D Daten in die Grafikkarte zu schieben. Klar. Man kann aber auch 2D Sachen machen. Dabei müssen die Bilder ja auch angezeigt werden. Ich weiß nicht in wiefern da trozdem der 3D Teil des Grafikchips verwendet wird, also die Bilder auch nur einmal als Textur in den Grafikspeicher geladen werden. Wie ist das nun mit DMA, wenn ich die Anwendung auch im RAM habe weil sich die normal auf einer SD Karte befindet? >Ausserdem: >Der STM32F2 hat einen LCD Controller drauf, also wäre der FPGA >überflüssig. So wie die Daten im RAM stehen werden die im Display >gezeigt und es muss nichts kopiert werden. Naja: >Ich weiß dass es ARMs mit Displayinterface gibt, ich weiß dass ein FPGA >oversized ist usw. [...] Das ganze Projekt ist aber eher gedacht zum >Lernen wie das alles geht. :)
Es kommt darauf an welchen RAM man benutzt. der STM32F2 hat zwei RAM Bänke und kann externen ansteuern. Durch die Busmatrix sollte somit Befehle und DMA zur gleichen Zeit benutzt werden können. Siehe Device Overview Seite 15. Man muss natürlich bei der Programmierung aufpassen was in welchem RAM steht. Ich selbst bin da nicht so tief drin um die Abläufe exakt erklären zu können (hat mich auch nicht interessiert).
Also in dem STM32 ist ja ein (2) DMA drinn. Wie muss ich mir das vorstellen, dass das geht? Ich mein, ich habe ja nur ein Speicherinterface, da hänge ich ja den externen RAM ran. Kommt der FPGA dann an den gleichen RAM Bus und wenn ich den DMA aktivier kopiert der ARM automatisch die Daten vom RAM in den FPGA?
Die CPU möchte vom internen RAM was lesen/schreiben, die DMA auf das externe RAM zugreifen und dann auf eine externe Adresse kopieren. Das geht gleichzeitig. Weil Busmatrix, also der gesammte Adress/Datenbus gibt es mehrmals. Aber wie schon geschrieben, ich kenne mich damit im Detail nicht gut aus, also ARM Doku lesen. Vielleicht kann AK dazu auch ein Wort schreiben.
Bei externem RAM funktioniert das nicht ganz so einfach wie Markus das beschrieben hat. Man könnte aber zB die DMA Requests verschachteln...also nach dem Motto -> externes RAM -> internes RAM -> Display RAM. Aber wenn das ganz schon so aufziehen willst würde ich einen anderen Weg gehn und mir eine "Grafikkarte" mit dem FPGA bauen. Damit meine ich beim initialisieren alle Daten rüber in den großen Grafikspeicher und dort werkeln lassen. Wesentlich performanter und die CPU Last wird damit wohl deutlich nach unten gehen...und du könntest immernoch die "einfach" Methode gehn und ein Sprite in deinem RAM halten und das direkt reinschieben...(somit würdest du für den ARM auch mit dem internen locker auskommen, und könntest dafür ein FLASH dranmachen)
>Die CPU möchte vom internen RAM was lesen/schreiben, die DMA auf das >externe RAM zugreifen und dann auf eine externe Adresse kopieren. Ich würde gerne auch Programme aus dem externen RAM ausführen können. >Bei externem RAM funktioniert das nicht ganz so einfach wie Markus das >beschrieben hat. Man könnte aber zB die DMA Requests >verschachteln...also nach dem Motto -> externes RAM -> internes RAM -> >Display RAM. >Aber wenn das ganz schon so aufziehen willst würde ich einen anderen Weg >gehn und mir eine "Grafikkarte" mit dem FPGA bauen. Damit meine ich >beim initialisieren alle Daten rüber in den großen Grafikspeicher und >dort werkeln lassen. Wesentlich performanter und die CPU Last wird damit >wohl deutlich nach unten gehen...und du könntest immernoch die "einfach" >Methode gehn und ein Sprite in deinem RAM halten und das direkt >reinschieben...(somit würdest du für den ARM auch mit dem internen >locker auskommen, und könntest dafür ein FLASH dranmachen) Ja, das wäre auch eine möglichkeit. Einen kleinen Softcore habe ich schonmal geschrieben, ein 6502, der ist aber nicht ganz fertig geworden, Interrupts und Stack fehlen noch. Da müsste man dann nochmal was neues aufziehen, dass auf Speicheroperationen getrimmt ist. Dann würde ich den FPGA direkt ans Speicherinterface hängen und dann kann ich das am anfang so machen wie ich gedacht habe mit memcpy bei jedem Frame und wenn ich dann soweit bin kann ich das ändern auf GPU. Kann ich nicht FLASH und RAM dranmachen und dann eine Addressleitung als CS verwenden, evtl mit einem NOT gatter vor FLASH oder RAM, so dass eben der RAM zB. von Addresse 0b000 bis 0b011 und der FLASH von 0b100 bis 0b111 geht? (Ja, das wäre jetzt bisschen wenig RAM/FLASH ;))
Habe gerade nochmal bei Atmel nachgeschaut, die haben ja ARMs mit allem was man sich wünschen kann, AES Engine, LCD Treiber, 2D Grafikprozessor uvm. Was könnte ich denn sonst noch aus einem FPGA, dem Display, evtl. Touchscreen und evtl. einem ARM bauen? Soll möglichst was sein was es noch nicht (so oft) gibt und wo man gut was lernen kann. Sinnvoll muss es nicht wirklich sein. Danke :]
>Sinnvoll muss es nicht wirklich sein.
Dann baue doch einen Zähler für Fahrräder auf Autobahnen.
Ganz super Ideen. Wirklich. Naja gut wird dann wohl doch darauf rauslaufen, dass ich nen schnellen ARM und nen FPGA nehme und dann halt den ARM Displaytreiber nicht hernehm sondern nen eigenen baue, auch wenns völlig sinnlos ist. Was brauche ich denn alles auf der Platine? - ARM - RAM für den ARM - Flash für den ARM - FPGA - RAM für den FPGA - Konfig-Flash für den FPGA - Geschätzte 100 Spannungsregler - Display / Touchscreen Anschluss - JTAG und Debug Anschlüsse (kann ich den ARM + Flash + FPGA + Flash an eine JTAG Chain hängen?) - SD Karten Anschluss - USB Anschluss - Ein paar Hardwarebuttons - RTC Was noch? Das wird ziemlich groß, mhm? Und irgendjemand muss das alles routen/Schaltplan machen :O. Aber erstmal muss ich mir die Bauteile raussuchen.
Ich hätte noch eine Idee: Baue einen Tricorder a la Star-Trek
Bluetooth brauch ich eigentlich nicht. RS232/UART kommt eh drauf wegen Debug Zeug. Ethernet wäre nicht schlecht, ja. CAN? Hab doch noch nichtmal n Auto! :O Und IrDA ist jetzt auch nicht so der hammer find.
CAN ist nicht schlecht. Wenn du mal mehrere CPU's vernetzen möchtest, z.B. Hausbus, dann ist CAN ideal.
Mhm mal gucken was ich dafür so alles brauch. Kommt vorallem drauf an, was der ARM so alles drinn hat. Was soll ich da nun für einen nehmen? Vorgaben: - Schnell - Speicherinterface, das gleichzeitig mehrere Speichertypen verwalten kann - Möglichst viele Sachen drinn, also vllt. Ethernet und so, und Verschlüsselungszeug wär nett - Gute Entwicklungswerkzeuge verfügbar Als RAM würde ich einfach sowas nehmen: http://de.farnell.com/elite-semiconductor/m52s32321a-6big/sdram-32mb-2-5v-166mhz-vfbga90/dp/1629122 Da kann ich dann je an den FPGA und an den ARM einen machen, das müsste langen. kA was man so an flash nehmen sollte. Als FPGA würde ich halt einfach einen S3E mit 500k Gates nehmen, die sind wenigstens nicht sooo teuer.
Ich denke ein ARM9 sollte es schon sein. Schaue mal den an: AT91SAM9263 von Atmel. Musste vergleichen mit anderen Herstellern, die ARM9 Chips habe ich jetzt auch nicht alle im Kopf. Der RAM muss in jedem Fall zur CPU passen (Spannung 1,8V? Geschwindigkeit? Timing Diagramme? ...) Ein Atmel Dataflash (32MB) Chip über SPI ist auch nicht schlecht, der Atmel kann daraus booten.
>Der RAM muss in jedem Fall zur CPU passen (Spannung 1,8V? >Geschwindigkeit? Timing Diagramme? ...) O_o. Ich dachte da gibts Signale auf die der ARM wartet, bis den RAM halt soweit ist. >Ein Atmel Dataflash (32MB) Chip über SPI ist auch nicht schlecht, der >Atmel kann daraus booten. Was heißt daraus booten? Ist da nicht eh intern n wenig Flash drinn wo man dann den Bootloader drauf schreibt und der Bootloader springt dann eben zur entsprechenden Speicheraddresse? >Schaue mal den an: AT91SAM9263 von Atmel. mach ich! Danke!
In der Regel wird das Programm während dem Booten aus dem langsamen Flash in das RAM Kopiert und dann läuft alles aus dem RAM. Atmel bietet mehrere Möglichkeiten des automatischen bootens, unter anderem kann der auch aus solch einem über SPI angeschlossenen DataFlash Speicher booten. Nachteil: Booten dauert länger, Vorteil: weniger Vertrahtungsaufwand, somit weniger Platzbedarf auf der Platine.
@TokyoDrift Erstmal respekt das du dir für dein Alter das zutraust, aber auch das du schon einen groben Überblick über dein Vorhaben mit den ganzen Betrachtungen veschafft hast. Von dem was ich so lese scheinst du schon Ahnung davon zu haben. Von daher : Weiter so ! Vllt hast du mit deinem Projekt ja mehr Glück als ich mit meinem Audio-Projekt. Aber eine allgemeine Platform hat meist eine höhere Resonanz als ein spezielles Projekt (wie in meinem Falle). Drück dir die Daumen.
Dirs schon klar das die meisten ARM9 Chips im BGA Gehäuse daherkommen? --> Multilayer Platine, teuer! Nimm entweder fertige Module wo Controller und FPGA schon drauf sind und mach dafür ein Basisboard ODER beschränke Dich auf das wesentliche und nimm einen etwas einfacheren Controller in nem Gehäuse das Du auch noch von Hand gut löten kannst. Was planst Du denn so auszugeben?
> Was planst Du denn so auszugeben? So viel wie nötig, so wenig wie möglich ;). Ne also am Geld solls nicht scheitern, läuft halt dann irgendwo unter Weihnachtsgeschenk. Hab mal so 50 bis 70€ für die Platine an sich gerechnet und vielleicht nochmal 50 für die Komponenten. Dass das Multilayer wird war mir von anfang an bewusst, ich muss nur schauen wie ich den BGA Zeugs verlötet bekomme, vielleicht frag ich jemanden der nen Reflow Ofen hat mal ganz lieb an, müsste aber eig. auch mit soner billigen Heißluftpistole gehen oder? >Erstmal respekt das du dir für dein Alter das zutraust, aber auch das du >schon einen groben Überblick über dein Vorhaben mit den ganzen >Betrachtungen veschafft hast. Von dem was ich so lese scheinst du schon >Ahnung davon zu haben. Von daher : Weiter so ! >Vllt hast du mit deinem Projekt ja mehr Glück als ich mit meinem >Audio-Projekt. Aber eine allgemeine Platform hat meist eine höhere >Resonanz als ein spezielles Projekt (wie in meinem Falle). Drück dir die >Daumen. Danke :) . >In der Regel wird das Programm während dem Booten aus dem langsamen >Flash in das RAM Kopiert und dann läuft alles aus dem RAM. >Atmel bietet mehrere Möglichkeiten des automatischen bootens, unter >anderem kann der auch aus solch einem über SPI angeschlossenen DataFlash >Speicher booten. Nachteil: Booten dauert länger, Vorteil: weniger >Vertrahtungsaufwand, somit weniger Platzbedarf auf der Platine. SPI Flash? Hätte ich jetzt eh nicht gemacht. Ich hätte parallelen Flash genommen, eine Art boot0 Bootloader in den internen Flash gepackt der dann einen boot1 aus dem externen Flash in den RAM läd und boot1 kann dann nen Kernel o.Ä. laden und starten. Damit kann dann boot0 minimal bleiben und boot1 kann dann ja sogar ein Filesystem o.Ä. implementieren. Das ist die Idee, wenn boot1 dann direkt ein EABI ist ists ja auch okay. Passt doch, oder? :)
Habe jetzt den AT91SAM9G20 angeschaut. Der hat zwar weniger RAM und keinen Displaycontroller aber dafür läuft er fast doppelt so schnell und kostet weniger. Ich habe gesehen dass die ja beide garkeinen internen Flash haben. Also muss ich da sowieso extern welchen drannklemmen. Wozu muss man das Zeug dann überhaupt In-System-Programmieren? Nur wegen den Fuses und so? Mhm. Was gibts zu dem µc zu sagen? Ist der in Ordnung oder hab ich was übersehen? :)
> Was gibts zu dem µc zu sagen? Ist der in Ordnung oder hab ich was > übersehen? :) Datenblatt lesen. Zumindest ein Großteil. Errata Sheet lesen. usw. Schauen was es für Demo-Board Schaltpläne gibt und was für Codebeispiele im WWW existieren. Schauen welcher Compiller dir gefällt. Das braucht ca. 2-3 Wochen und ist die Grundlage. Wenn Dir da ein Fehler unterläuft und der Schapltplan passt dann nicht hast Du ein großes Problem an der Backe, denn Multilayer und BGA = NEU MACHEN = KOSTET VIEL GELD = noch mehr warten! Passende Bauteile raussuchen nochmals 2 Wochen. Layout Routen/Schaltplan 4-6 Wochen. Also, nehme Dir richtig viel Zeit und vergleiche die Prozessoren von unterschiedlichen Firmen, mache eine Tabelle in der man die Plus/Minus Punkte einträgt. Material bestellen und da haben bevor die Platine produziert wird, dann kann man auf einem Ausdruck die Teile mal drauflegen um zu schauen ob die wirklich alle passen.
>Also, nehme Dir richtig viel Zeit und vergleiche die Prozessoren von >unterschiedlichen Firmen, mache eine Tabelle in der man die Plus/Minus >Punkte einträgt. Okay. Danke schonmal :) . Was mich noch interessiert, wie siehts eigentlich aus mit HF Zeug? Muss ich da was auf der Platine beachten, bei 400MHz? Weil davon habe ich wirklich GARKEINE Ahnung. Nicht dass nachher was nicht geht weil iwas nicht HF kompatibel ist.
Ach, ich lese gerade, der interne Speicher ist tatsächlich ein ROM, kann also auch nicht von außen programmiert werden. Da ist also ein Boot-Programm drauf, dass dann den Bootloader von nem externen Speicher liest. Das heißt boot0 kann ich mir sparen und dann eben gleich einen boot1 in den Flash schreiben, vor einem möglichen Filesystem o.Ä. Na gut, das ist ja kein Problem. Ich habe nur gerade ein wenig Angst, dass dann am Schluss garnichts geht und ich nicht weiß woran es liegt. Dieser ganze ARM kram ist ein wenig kompliziert, mit Startup Code und so, ich habe ja noch nichtmal eine IDE o.Ä. für ARM9 gefunden. Habe aber schon geschaut, eval Boards mit entsprechendem ARM Prozessor sind auch super teuer, das rentiert sich also auch nicht.
Dann hilft erstmal nur eines: Das ganze etwas herunterschrauben und z.B. einen STM32F103 verwenden. Cortex-M3 Kern und ST bietet mit dem STM32 über 100 Variationen von Funktionen/Gehäuse/Speicher Flash ist im Chip, der läuft mit einfachen 3,3V, selbst sogar ein RC-Osillator ist drin. Minimalbeschaltung: - Strom anschließen - ein paar Kondensatoren Siehe hier: STM32 - Bezugsquellen - Demo-Boards - Software - Demo-Software Ich progge den schon seit 2 Jahren und bin begeistert. Kosten ARM9 Board ca. 300-500 EUR Kosten STM32 Board ca. 100-150 EUR (Aber Geld spielt für eigenbau ohnehin kaum eine Rolle) PS: Wegen HF und ARM9, schaue Dir alte Motherboards an, dort sind die Drahtlängen zum Speicher alle gleich lang und in Schlangen gelegt. Das müsstest Du auch so machen. Mindestens 6 Lagen, damit zwischendrinn die Versorgung eine eigene Lage hat (2x). Wenn da was nicht geht >> neu machen.
Hab ein STM32 Discovery hier. Bin noch nicht so recht dazu gekommen das auszprobieren. Was iKosten STM32 Board ca. 100-150 EUR ch machen könnte wäre das ARM Zeug erstmal zurückzustellen und nur eine ganz kleine, billige single layer Platine für das Display zu machen (also Spannungsregler + ADC) und das dann an mein S3E Starterkit zu hängen und erstmal n Displaytreiber zu schreiben und so. Dann könnt ich ja nen kleinen Softcore zum Testen reinmachen, und das ARM Zeug eben auf später verschieben. Ich will mich aber auf jeden fall noch mit ARM beschäftigen. was mich halt stört ist dass ich am S3E Board nur 40 I/Os zur freien Verfügung habe, deswegen also nicht ein ARM Board und das S3E Board und das Display Board zusammenstecken kann :O . Trotzdem, gibt es denn kein empfehlenswertes ARM9 Board für <200€?
Ein "gescheites" ARM9 Board sollte nicht nur ein Stück Pertinax mit Elektronik sein, sondern da gibt es z.B. noch Linux mit dabei. Und die Software/Demos drum herum lassen sich die Hersteller auch bezahlen. Daher Demo-Board ist nicht gleich Demo-Board.
Mit Selbstbau würdest Du aber auch nicht unter 200 Euro kommen... (beim Selbstbau von sowas komplexem steckt man eigentlich immer deutlich mehr rein als zuvor gedacht) Evtl. das hier: http://www.mikrocontroller.net/articles/Micro2440 oder eben das mini2440
Ich habe hier auch noch einen AT91RM9200 rum liegen. Nur zur Abschreckung damit ich niemals auf die Idee komme eine Platine mit BGA Gehäuse/Bauteile zu machen. Auf einem Bildschirm kann man 0,1mm Leiterbahnen rießig zoomen, doch in der Realität heißt das extrem teure Sonderfertigung. (Abgesehen von Bohrungen, die nur durch ein paar Lagen und nicht durch alle gehen.) Alles machbar, aber bezahlbar?
>Evtl. das hier: >http://www.mikrocontroller.net/articles/Micro2440 >oder eben das mini2440 Das ist ja cool und günstig :) . Dann wirds wohl darauf rauslaufen, dass ich erstmal nur den FPGA Teil mach und dann evtl. ein FPGA Modul und ein ARM Modul kaufe und die 2 dann einfach "zusammenstecke". Ich warte nur immernoch darauf dass das Display mal ankommt, dann kann ich da das Layout und so für machen.
Nach dem tagelangen Höhenflug kommt jetzt wohl die Landung :-) >Einen kleinen Softcore habe ich schonmal geschrieben, ein 6502, der ist >aber nicht ganz fertig geworden, Interrupts und Stack fehlen noch. Mach das doch erst einmal richtig fertig. Halbfertige Sachen über den Haufen zu werfen, bingt einen im Leben nicht weiter.
Naja, ich dachte halt dass das ARM zeug nicht soo kompliziert ist. Macht ja nichts. Ich werde die Tage mal anfangen einen Displaytreiber in vhdl zu schreiben, das dürfte ja nicht so dramatisch sein.
Im Grunde ist es gaaanz einfach. - Nur sehr teuer, vor allem wenn man zum ersten mal solch eine HF-Platine bastelt. (Mit dem mini2440 wäre das Vorhaben bezahlbarer, dafür ist man an diesen CPU-Chip gebunden) - Nur sehr Zeitintensiv, man muss wirklich viele Datenblätter lesen und verstehen. Und viel googlen um wirklich das Optimum zu finden. (wehe man übersieht einen Punkt aus einem Errata)
hey TokyoDrift, ich bin nicht so der Erfahrenste im gegeteil xD aber ich bin dafür ganz gut mit Hardeware ;) Also könnte dir beim Platinen herstellen etc helfen. Mit dem proggen muss ich noch sehr viel lernen^^.
Sooo. Habe jetzt mal den Displaytreiber in VHDL geschrieben. Ist nicht besonders ansehnlich geworden, eigentlich nur 2 State Machines, die eine gibt die Pixel aus und kümmert sich um den HSYNC, die andere koordiniert die Erste und kümmert sich um den VSYNC. Das ganze braucht dann 79 Slices auf meinem S3E und läuft mit bis zu ca 157MHz. Naja, das Display will nur 9MHz, von daher ist das mehr oder weniger witzlos. Ist aber nur der Display Treiber, also mit normalem SRAM Interface, ohne CLK GEN und so. Im Simulator läufts prima, Synthetisieren und Routen lässt es sich auch Fehler- und Warnungsfrei. Ich kanns nur leider nicht in echt testen, weil das Display immer noch nicht angekommen ist. Wenn jemand einen FPGA an nem entsprechenden Display hat und bereit wäre meinen Treiber zu testen wäre das echt super :) . Wenn nicht, auch okay, muss ich eben warten. Bin nur recht gespannt ob das wirklich geht. ^_^ Naja, vielleicht versuche ich mich in den Weihnachtsferien oder so mal mit dem DDR RAM auf meinem S3E Kit. Hab nächste Woche noch 2 Klausuren, dann ist Schluss für dieses Jahr (yay).
Und sowas von einem 16-Jährigen, ich glaub es nicht. staun Respekt, aus dir wird noch was!
ARM und FPGA ist ne schöne Kombination, man kann damit auch noch andere lustige Sachen machen als nur ein Display anzusteuern. Eigentlich ist der FPGA doch fast ein bisschen zu schade dazu, nur das Display anzusteuern, nicht? Willst du nicht lieber ein "normales" monochromes GLCD nehmen, und dafür ein paar andere lustige Funktionen im FPGA realisieren? z.B. highspeed digital I/Os oder ein Interface für ADCs und DACs, das selbständig z.B. Sensoren auslesen kann und die Messwerte im FPGA in einer Tabelle speichert. Der ARM kann dann bei Bedarf die Werte raus lesen. Oder eine digitale Signalverarbeitung: irgendwas mit dem ADC einlesen, der FPGA führt dann einige vom ARM vorgegebene Rechenoperationen auf den Daten aus, und macht mittels DAC wieder ein analoges Signal. Oder eine FFT in echtzeit. Was soll auf dem ARM für eine Software laufen? Ein OS muss da sicher her. Ich persönlich würde ja uC/OS-II nehmen, aber die Geschmäcker sind ja bekanntlich verschieden (ich bin kein grosser Linux-Anhänger). Alles in allem würde mich dein Projekt aber sehr interessieren; mir schwebt schon lange wieder einmal ein grösseres Mikrocontrollerboard vor. Im Moment benutze ich noch LPC2468, ist ein ARM7. Mein jetziges selbergemachtes Board hat ARM, FPGA, SDRAM, FLASH, Ethernet, RS-232, Multimedia Card Interface, ein paar Tasten und Lampen mit drauf. Das reicht vorerst zum Basteln, aber eine noch schnellere CPU wäre halt schon lustig. Leider habe ich noch keinen gescheiten Cortex-M3 gefunden mit externem 32 Bit breitem Dateninterface, und die meisten ARM9 kriegt man leider nur als BGA. Aber ich muss mal einen Freund von mir fragen, der mir das vielleicht löten kann... Gruss
@ Tobias Plüss (hubertus) >Leider habe ich noch keinen gescheiten Cortex-M3 gefunden mit externem >32 Bit breitem Dateninterface Kannst Du den mal anschauen: http://www.st.com/internet/mcu/product/250173.jsp Datenblatt: http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/DATASHEET/CD00263874.pdf Ich meine der könnte doch ziemlich g'scheit sein oder? Der hat ein 32 Bit breiten Datenbus. Im Datenblatt Seite 15, der hat auch ordentlich Pheriperie drin. Mich interessiert einfach mal Deine Meinung zu diesem Teil (gibt es leider noch nicht zu kaufen)
Markus, ich habe mir das Datenblatt nicht im Detail angeschaut. Aber: Der Prozessor scheint mir schon ziemlich brauchbar zu sein. Einziger Wermutstropfen ist, dass das grösste Gehäuse ein QFP176 ist, das nächst grössere wäre dann irgend ein BGA. Das heisst unterm Strich: Die QFP-Version ist irgendwo kastriert - womöglich beim Datenbus oder sonst wo. Aber sicher wird man dann plötzlich einmal feststellen, dass genau die Funktion, die man gerne hätte, beim QFP nicht herausgeführt ist. Das Gefällt mir eben beim LPC2468 so gut: es ist alles nach aussen geführt, und man kann die ganze Peripherie nutzen - deshalb auch das QFP208. Wenn jetzt dein Prozessor noch SDRAM unterstützen würde, dann wäre er nahezu perfekt und eine gute Alternative zum 2468er. Mir persönlich würde auch eine ROMless-Variante gut gefallen, wenn der Controller/Prozessor nur schnell genug ist und viel Peripherie drin hat: - min. 2 oder 3 SPI - 2 UART - ADC, 4..5 wären schön, mit vllt. 12 Bits oder 10 wären auch gut - DAC muss nicht sein, ist aber ganz lustig. Vielleicht mit DMA? - Externes Interface für SDRAM und Flash - RTC mit Battery RAM - Ethernet - Vielleicht ein Cache und eine MMU Dein ST kommt dem schon ziemlich nahe. Ein schöner Prozessor! Was ich mich nur Frage: CM3 soll ja Harvard sein. Kann ich denn da trotzdem Daten und Programme im selben Memory halten? schön wäre es natürlich, wenn man quasi ad-hoc via RS-232 was ins SDRAM laden und ausführen könnte. 8051 war ja auch Harvard, und ohne spezielle Hardwaretricks ging das nicht. Weisst du dazu etwas? Ich kenne nur ARM7, und da geht sowas definitiv.
>ARM und FPGA ist ne schöne Kombination, man kann damit auch noch andere >lustige Sachen machen als nur ein Display anzusteuern. >Eigentlich ist der FPGA doch fast ein bisschen zu schade dazu, nur das >Display anzusteuern, nicht? Willst du nicht lieber ein "normales" >monochromes GLCD nehmen, und dafür ein paar andere lustige Funktionen im >FPGA realisieren? z.B. highspeed digital I/Os oder ein Interface für >ADCs und DACs, das selbständig z.B. Sensoren auslesen kann und die >Messwerte im FPGA in einer Tabelle speichert. Der ARM kann dann bei >Bedarf die Werte raus lesen. >Oder eine digitale Signalverarbeitung: irgendwas mit dem ADC einlesen, >der FPGA führt dann einige vom ARM vorgegebene Rechenoperationen auf den >Daten aus, und macht mittels DAC wieder ein analoges Signal. >Oder eine FFT in echtzeit. Klar ist der FPGA ein Overkill. Aber ich habe geplant später evtl. noch einen oder mehrere auf Speicheroperationen optimierte Softcores einzubetten die dann eine Art 2D Hardwarebeschleunigung machen, also um zB. alle Bilder einmal in den Grafikspeicher zu laden und dann nurnoch Positionen und Rotationen und so übergeben und der FPGA soll das dann ausführen. >Was soll auf dem ARM für eine Software laufen? Ein OS muss da sicher >her. Ich persönlich würde ja uC/OS-II nehmen, aber die Geschmäcker sind >ja bekanntlich verschieden (ich bin kein grosser Linux-Anhänger). >Alles in allem würde mich dein Projekt aber sehr interessieren; mir >schwebt schon lange wieder einmal ein grösseres Mikrocontrollerboard >vor. Wollte eh mal so in richtung Betriebssystementwicklung gucken, von daher würde ich da wohl (versuchen) selber was zu basteln, wie gut das dann läuft ist ja letztendlich egal, geht ja nur ums Lernen. >Im Moment benutze ich noch LPC2468, ist ein ARM7. Mein jetziges >selbergemachtes Board hat ARM, FPGA, SDRAM, FLASH, Ethernet, RS-232, >Multimedia Card Interface, ein paar Tasten und Lampen mit drauf. >Das reicht vorerst zum Basteln, aber eine noch schnellere CPU wäre halt >schon lustig. >Leider habe ich noch keinen gescheiten Cortex-M3 gefunden mit externem >32 Bit breitem Dateninterface, und die meisten ARM9 kriegt man leider >nur als BGA. Aber ich muss mal einen Freund von mir fragen, der mir das >vielleicht löten kann... Ein ähnlich Board würde ich auch wollen. Allerdings nen schnellen ARM9 oder so, vielviel (D)RAM(?) und Speicherinterface zwischen FPGA und ARM. Dieser AT91SAM9G20 wär natürlich perfekt, aber ist eben ziemlich kompliziert. Interner ROM wäre mir btw. auch ganz recht, dann kann ich auch noch nen eigenen stage0 Bootloader schreiben :) . Sowas macht doch erst richtig Spaß!
Der CM3 hat 4 GB Adressraum. Der kann überall ROM und RAM haben, solange sich die Adressen nicht überschneiden. Somit kann problemlos ein Programm im RAM laufen, egal welche Adresse. Eine MMU hat der CM3 (glaube ich) nicht. Als externen Speicher kann der (Datenblatt): * Flexible static memory controller that supports Compact Flash, SRAM, PSRAM, NOR and NAND memories Also kein SDRAM. Wegen der fehlenden MMU ist z.B. kein richtiges Linux oder WindowsCE möglich. µLinux sollte gehen. Ich selbst habe mit OS noch nie etwas gemacht.
@Markus Müller : der STM32F2xx hat keinen internen Displaycontroller.
Hi Ist das BeagleBoard-xM nix für dich?? Hab mir das nicht genauer angesehen, daher vorher nachsehen ob das passt was drauf ist. Auch von mir RESPEKT und weiter so... Gruß
Habe das BeagleBoard MX mal angeschaut. Leider hat das kein externes Speicherinterface und damit kann ich es nicht mit meinem FPGA verbinden. Trozdem danke für den Tipp :)
Wie siehts eig. mit dynamisch gelinkten Libs aus? Wenn ich einen normalen ARM-GCC nutze, kann ich dann Libs builden und die in meine Programme linken? Ich habe mich wie gesagt eine Zeit lang mit PSP beschäftigt und da gabs dann Stub-Files in denen für Funktionen eine Addresse (?) drinn stand und dann eben Header mit den entsprechenden Prototypen und der PSP-GCC konnte das ganze dann linken. Aber woher soll ich die Addresse denn wissen? Ich mein, ich weiß ja nicht wo im Speicher ein Lib hingeladen wird. Das einzige was ich mir überlegen konnte ist, dass der Kernel sich eine art Liste anlegt wo welches Lib hingeladen wird und in der Lib am Anfang eine Sprungtabelle für Funktionen steht, dann kann man die Libs beliebig erweitern weil man ja nur den "Namen" der Funktion und des Libs kennen muss, dann fragt man mal den Kernel wo das Lib liegt, sucht dann nach der Funktion in der Lib und führt sie dann aus. Aber das kostet ja vielviel Rechenleistung und man muss es in den Compiler integrieren. Wie ist das normal umgesetzt? Kann das ein GCC? Zumindest die stdlib muss ich ja sowieso anpassen oder? Und grundsätzlich zum ARM, hat noch jemand Tipps oder fertige Schaltpläne oder so für nen ARM9 und so? :)
Siehe hier: http://olimex.com/dev/index.html > ARM > SAM9-L9261 Hier gibts das "SAM9-L9261 schematic"
Mhm das AT91SAM9260 Board wäre exakt was ich brauche, nur eben fehlt das Memory Interface. Kriegt man die Schematics auch als Eagle oder KiCad File oder so? Dann hätt ich wenigstens die Bauteile für die ARM Seite und so schonmal funktionstüchtig und so.
Mhm weiß noch jemand wie das mit dynamischen Libraries ist? Ich mein, es wäre ja kein Problem wenn der Kernel die geladenen Libs verwaltet, also so dass ein Programm dann die entsprechenden Addressen der Lib/Funktionen vom Kernel der in einem festen Speicher liegt abfragen kann. Aber kann GCC denn eine art Tabelle an Funktionen/Addressen in einer bin anlegen? Bei PSP gabs da immer diese Export.exp Files, in denen man festlegen konnte was alles von außen zugänglich sein soll, aber ich glaube nicht, dass das Standard ist. Langsam sollte das Display mal eintrudeln, dann lasse ich mir erstmal eine kleine Platine machen, die nur Spannungsregler für das Display enthält und so, dann kann ich den FPGA Part schonmal bisschen testen/erweitern/wie auch immer und über die Weihnachtsferien kann ich dann bisschen mehr mit ARM machen und schauen dass ich ein entsprechendes Board zusammenkriege. Wie gesagt, am Geld solls nicht scheitern, habe sonst eh keine "Wünsche" für Weihnachten, also da bleibt genug übrig.
Hab mich jetzt nochmal informiert und mir ein paar Gedanken gemacht. Naja, am besten ist es wohl, wenn ich einen AT91SAM9260 und einem Spartan3E FPGA nehme. Und zwar weil es beide im PQFP208 Package gibt. Der AT91SAM9260 hat zwar nur 50MHz Speichertakt und 190MHz Coretakt aber das müsste schon reichen. Um die Rechnung vom Anfang wieder aufzugreifen, für ein Bild braucht man ca. 100k Speichertakte, bei 60FPS sind das 6Mio Speichertakte, bin ich also bei 12% Auslastung. Naja, ist akzeptabel, man kann ja dann auf 30FPS gehen und ist schon bei 6% Auslastung, wenn man dann wirklich einen Prozessor im FPGA implementiert ist das ganze sowieso zu vernachlässigen. Naja, mit den beiden Chips im PQFP Package komme ich vielleicht sogar auf eine 2-Layer Platine, oder? Oben ARM und FPGA, unten RAMs und FLASHes, dann noch Spannungsregelungen und ein bisschen externe Hardware, also SD Slot, Ethernet, Display, Programming Interface, was sonst noch dazu gehört. Passt doch, oder? :)
Und 6 Löcher für Schrauben / Abstandhalter damit die Platine nicht direkt auf dem Schreibtisch rumkrazt.
Hallo! Zunächst einmal möchte ich betonen, dass ich es gut finde, dass Du Dich mit solch einem komplexen Projekt beschäftigen willst. Dennoch sei aber angemerkt, dass häufig der Teufel im Detail steckt, insbesondere wenn solch eine Schaltung so viele hochkomplexe Bauteile enthält. TokyoDrift schrieb: > Naja, mit den beiden Chips im PQFP Package komme ich vielleicht sogar > auf eine 2-Layer Platine, oder? Oben ARM und FPGA, unten RAMs und > FLASHes, dann noch Spannungsregelungen und ein bisschen externe > Hardware, also SD Slot, Ethernet, Display, Programming Interface, was > sonst noch dazu gehört. > Passt doch, oder? :) Nein, mit zwei Lagen wirst Du nicht auskommen. PQFP-Gehäuse sind zwar händisch lötbar, besitzen aber auch das Problem, dass man zwischen den Pins keine Leiterbahnen mehr verlegen kann. Bei den Frequenzen bzw. Flankensteilheiten der Signale ist eine ordentliche Masse- und Versorgungsspannungsführung absolut wichtig. Das bekommt man nur hin, wenn man dafür ziemlich durchgängige Lagen verwendet. Ein sehr, sehr erfahrener Layouter mag solch eine Leiterplatte vielleicht in mehreren Mannmonaten (8 Stunden pro Tag!!!) auf vier Lagen hinbekommen, aber dabei muss man ggf. schon große Kompromisse hinsichtlich der Signalintegrität eingehen. Realistisch, aber immer noch nicht einfach, sind sechs Lagen. Bedenke, dass nicht nur Bauteile und Leiterbahnen viel Platz beanspruchen, sondern auch die Durchkontaktierungen. In Deiner obigen 50-70 EUR Kosten für die Leiterplatte sind auch noch nicht die Einmalkosten für die Datenaufbereitung und Filmherstellung enthalten. Zudem sollten Multilayer auch immer elektronisch geprüft sein. Einzelstücke Deiner Leiterplatten kosten bei z.B. 200*200mm^2 etwa 300,- EUR (vierlagig) bzw. 500,- EUR (sechslagig). Stehen Dir denn die Messmittel zur Verfügung, um später auch noch Fehler zu suchen? Ich würde den Aufwand für solch ein Projekt (Schaltung, Layout, Initialisierungscode, FPGA-Code, usw.) auf mindestens ein halbes Mannjahr schätzen, und zwar ohne dass anschließend schon irgendeine brauchbare Anwendung darauf läuft. Um solch eine Schaltung stabil zum Laufen zu bringen, dürften ca. zwei bis drei Layoutdurchläufe erforderlich sein. Selbst im Hobby-Maßstab sind da 2.000,- bis 3.000,- EUR ganz schnell verpufft. Gruß Andreas Schweigstill
Platinenkosten kalkulieren: www.pcb-pool.de > Bestellung > Preis Online kalkulieren 1x 140x140 (kleiner geht es garantiert nicht) 6 Lagen Kleine Dukos/Leiterbahnen 300 EURS
@Andreas Schweigstill Volle Zustimmung! Bei Deiner Zeitkalkulation ist Voraussetzung, dass es sich um einen erfahrenen Entwickler handelt. Falls jemand darauf hoffen sollte, ein Adler-Autorouter nimmt einem dabei keine Arbeit ab.
Okay. Vielen dank für die gute Einschätzung und Bewertung des Projekts. Hat mir echt geholfen. Naja, wie gehts nun weiter? Ich denke ich werde mich mal nach ARM Softcores umsehen, dann kann ich das ganze ja direkt in einem FPGA machen, ein S3E Kit habe ich ja :) . Dann brauche ich mir um die Platine schonmal keine Sorgen machen und kann bei dem ARM auch schön Hardwaremodule ergänzen/weglassen. Noch ne ganz andere Sache. Ich hätte schon Lust später, wenn ich mit Schule/Studium fertig bin mal in die Richtung zu gehen, so Berufsmäßig. Ist das denn vernünftig gezahlt? ^_^ (ich weiß, man soll nicht nach dem Geld gehen und so aber das interessiert mich einfach)
TokyoDrift schrieb: > Das ganze Projekt ist aber eher gedacht zum Lernen wie das > alles geht. Dafür finde ich das Projekt zu teuer, bezüglich Kosten als auch Entwicklungszeit. Du wirst dann vielleicht wissen wie es geht, aber Du wirst nie auch nur annähernd den Funktionsumfang eines fertigen Gerätes erreichen. Es wird vielleicht ein extrem teurer digitaler Bilderrahmen werden (wenn wirklich alles klappt). Man kann heutzutage nicht mehr alles selber entwickeln. In vielen Geräten stecken Mannjahrhunderte an Entwicklung drin. Wenn Du eine Grafikanwendung schreiben willst, nimm ein fertiges Board mit nem fertigen OS (Linux) drauf. Wenn Du die PC-Grundlagen lernen willst, reicht auch ein einfaches Projekt mit nem Z80 und FBAS-Ausgang (ZX Spectrum). Das ist nachbausicher und ausgereift. Die Zeiten, wo man Motherboards in der Garage zusammenbasteln konnte, sind lange vorbei. Peter
Diese Mamut ARM9 super schnell CPU braucht es als Elektronik-Entwickler einer Firma nicht sehr oft. (Das gleiche gilt auch für FPGA) Wenn Du privat Erfahrung mit einer STM32F103 sammelst und damit Projekte realisiert, z.B. Hausbus, Sensoren, Display, CAN usw. Dann: - ist das bezahlbar - realistisch realisierbar - Aufwand hält sich in überschaubaren Grenzen - moderne 32-Bit ARM Cortex-M3 CPU - das ist garantiert in Firmen gefragt Dann bereitest Du Dein Projekt als Artikel auf und veröffentlichst es z.B. bei der Zeitschrift Elektor. Wenn das da ankommt und Du legst es den Bewerbungsunterlagen bei, dann ist das in jedem Fall ein dicker Pluspunkt. Sämtliche studierte können sich dann in die Ecke verkriechen.
Hallo, für Spartan 3E bieten sich ARM-Softcores leider nicht wirklich an, da es keine preisgünstigen fertigen Portierungen gibt. Natürlich kannst Du Dir bei ARM für ca. 1 Mio. EUR eine eigene ARM-Lizenz kaufen, aber das wäre nicht praktikabel. Die präferierten Softcores für Spartan 3E sind der Picoblaze (8 Bit, kostenlos) und der Microblaze (32 Bit, auch mit MMU erhältlich, ca. 500EUR). Für letzteren gibt es mindestens zwei Linux-Portierungen (Petalinux, Blue Cat Linux). Man benötigt etwa ein bis zwei Mannmonate an Arbeit, um solch ein System auf einem gut unterstützten Enwicklungsboard aufzusetzen und in Grundzügen zu verstehen. FPGA-übergreifend wäre z.B. der Softcore TSK3000, bei dem es sich um einen MIPS R3000-Abkömmling handelt. Dieser ist z.B. im Altium Designer enthalten und läuft wohl auf den meisten gebräuchlichen FPGAs. Ansonsten findet man auch Unmengen von Softcores auf OpenCores: http://opencores.org/ Gerade im Bereich der sog. "Vintage Computer"-Szene gibt es viele Leute, die ihre alten Lieblings-Computer in FPGAs nachempfunden haben. Dementsprechend viele Nachbildungen von Z80, 6502 usw. findet man im Internet. Gruß Andreas Schweigstill
>Natürlich kannst Du Dir bei ARM für ca. 1 Mio. EUR eine eigene ARM-Lizenz >kaufen, aber das wäre nicht praktikabel. [Ironie] Ach, kein Problem. [/Ironie] Ist ja echt ärgerlich, das ganze. Was könnte ich denn sonst mit dem Display an meinem FPGA anfangen? Ich mein, mit nem 8bit µc/Softcore brauch ich nich anfangen auf ein 480x272x24 Display zu zeichnen.
Wieso nur 8 Bit? Bei OpenCores gibt es doch Unmengen an Softcores, darunter zwar die meisten wirklich als 8-Bitter, aber z.B. auch die ausgesprochen erfolgversprechenden Prozessoren der OpenRISC-Familie mit 32/64 Bit. Es nützt auch nichts, wenn man sich den tollsten Prozessor aussucht und es dafür keinen (C-)Compiler oder zumindest Assembler gibt, was leider bei manchem hochakademischen Projekt der Fall ist. OpenRISC wird hingegen von GCC unterstützt, selbst unter Cygwin.
Mache es doch so: Platine mit: - Display - FPGA + RAM Das ganze arbeitet in sich und bietet Anschlussmöglichkeiten: - SPI - UART Damit könnte man ganz simpel mit wenigen Drähten das Display mit einer CPU verbinden. Dazu Software-Befehle die eine CPU über die Schnittstelle ansteuert: - Befehl "Zeichen Linie" - Befehl "Textausgabe", Text, Schriftgröße (Schrift ist im FPGA gespeichert) - Befehl "Zeichne Grafik", Grafikdaten - ... Damit hätte man ein Display, das wirklich universell mit vielen Prozessoren einsetzbar wäre und vor allem mit wenigen Drähten zum Prozessor auskommt. Von EADog gibt es so ein Display, kostet über 200 EUROnen, kannst mal nachschauen, damit Du verstehst wie ich meine.
TokyoDrift schrieb: > Ich mein, mit nem 8bit µc/Softcore > brauch ich nich anfangen auf ein 480x272x24 Display zu zeichnen. Z.B.: http://www.lcd-module.de/produkte/ediptft.html Da drin steckt ein ATmega128. Bewegtbilder kann man natürlich keine anzeigen. Aber wir benutzen es für Bedienmenüs für unsere Geräte. Man spart sich den ganzen Grafikschrunz und kann sich voll auf die Applikation konzentrieren. Peter
Die EA-DOG-Displays sind aber unglaublich langsam. Außerdem geht es TokyoDrift doch auch darum, an dem eigentlichen Grafikteil im FPGA herumbasteln zu können. Somit ist ein externes "intelligentes" Display doch exakt der falsche Ansatz.
Andreas Schweigstill schrieb: > Somit ist ein externes "intelligentes" Display > doch exakt der falsche Ansatz. Nicht benutzen, sondern nachentwickeln war gemeint. Benutzen tue ich es, weil ich nicht die Zeit habe, sowas zu entwickeln. Und weil ich mich darauf verlassen möchte, das EA die nötigen Anpassungen macht, wenn der LCD-Hersteller alle 6 Monate einen neuen Typ rausbringt. Peter
>Die EA-DOG-Displays sind aber unglaublich langsam. + >Da drin steckt ein ATmega128. Wisst Ihr, welcher Grafikchip da verwendet wird?
Was mir noch eingefallen ist, ich könnte ein Netzwerk-Display basteln! Einen Ethernet PHY habe ich auf meinem S3E, muss ich "nurnoch" einen MAC und die Portokolle implementieren (IP, ICMP, ARP, UDP). Ich habe mich schon ein wenig mit Ethernet beschäftigt (im Rahmen meiner Seminararbeit, eine Netzwerk-Farbwechsel-Lampe) und kenn so die groben Grundlagen, eigentlich muss man die Daten ja nur "auspacken". Da hab ich dann auch schön was zu tun, mit den ganzen Protokollen die man braucht. Für TCP müsste man wsl. sogar nen kleinen Softcore machen. Das wär doch ne Sache, oder? :)
Das würde mich auch sehr interessieren. Leider ist es so, dass man, sobald man nach einem TCP-Stack für Embedded Anwendungen sucht, nicht um den lwip herum kommt. Dieser scheint wirklich der einzige voll funktionstüchtige TCP-Stack zu sein, der alle Features hat, die man braucht. Mir persönlich gefällt diese Implementierung aber gar nicht, und eigentlich passt der lwip auch nicht in mein Konzept, aber selber implementieren ist wohl schlichtweg zu kompliziert. Ich habe es einmal versucht; ARP hatte ich komplett fertig und bin zu IP übergegangen, und dann habe ich gemerkt, dass man das wohl wirklich nicht selber machen kann. Schade eigentlich, es wäre ein schönes Projekt, aber es ist zu umfangreich. Das Problem sehe ich auch hier: willst du TCP nutzen, dann musst du den lwip nehmen. Es ist kompliziert genug, den auf einem richtigen Controller zum Laufen zu kriegen - auf einem FPGA möchte ich das gar nicht erst versuchen. Es gibt wohl wirklich keine guten Implementierungen für embedded TCP. Das ist bei mir auch der Grund, warum ich das wieder habe fallen lassen - zwar habe ich auf meinem ARM7/FPGA-Experimentierboard mir viel Mühe gegeben, um eine gute Ethernet-Hardware zu entwickeln.
>- zwar habe ich auf meinem ARM7/FPGA-Experimentierboard mir viel Mühe >gegeben, um eine gute Ethernet-Hardware zu entwickeln. Was für ein Board ist das denn? Wie siehts mit uIP aus? Ich dachte das wär ganz gut.
Hoi, das Board ist mit einem LPC2468 bestückt (ARM7 mit max. 72 MHz). Am externen Bus hängen 64MB SDRAM über einen 32 Bit breiten Datenbus angebunden, sowie ein 8MB grosses NOR-Flash mit 16 Bit Bus. Ein Altera EP2C8 FPGA (8k LEs) ist auch am Bus angebunden; des Weiteren beinhaltet das Board 2x RS-232, Ethernet, ein paar Schalter, 16 LEDs, einen SD-Kartenslot, einen Temperatursensor, eine Batterie für die RTC, einen 16 Bit ADC, und die Pins vom FPGA und Mikrocontroller sind auf eine grosse Stiftleiste rausgeführt. uIP ist schon nicht schlecht; kann aber kein DHCP. Das wäre dann schon eine Anforderung. Ich will nicht eine IP fest im Code einprogrammieren. Wenn schon, dann sollte es schon ein "richtiger" TCP-Stack sein - mindestens DHCP, DNS, UDP sollte er können. TCP ist mir nicht so wichtig, aber die genannten Protokolle sollten schon richtig unterstützt werden.
DHCP und DNS basieren eh auf UDP. Gibt bestimmt auch DHCP/DNS "stacks" die auf UDP aufbauen, da musste dann nur das Interface auf UDP auf uIP anpassen, ist doch alles nich so schlimm ^_^ Hast mal n Link/Namen zu dem Board?
@ Tobias Plüss (hubertus) Kann ich den Code für lwip für den 2468 irgend wo her laden? Ich habe ein Board mit dem 2368er drauf. uIP hatte ich schon mehr schlecht als recht am laufen (Demo Webserver). Aber als ich noch einen zweiten Port für Kommunikation mit einem PC-Programm implementieren wollte bin ich gescheitert. Ich hab den PHY KSZ8721BLI drin.
TokyoDrift schrieb: > Ich habe mich > schon ein wenig mit Ethernet beschäftigt (im Rahmen meiner > Seminararbeit, eine Netzwerk-Farbwechsel-Lampe) Was für Seminararbeiten schreiben 16-Jährige Schüler? Die Schule (Schulform) würde mich interessieren wo ein Fach unterrichtet wird das auch nur annährend deiner Seminararbeit gerecht wird.
>Was für Seminararbeiten schreiben 16-Jährige Schüler? Die Schule >(Schulform) würde mich interessieren wo ein Fach unterrichtet wird das >auch nur annährend deiner Seminararbeit gerecht wird. 11. Klasse, Informatik, Gymnasiale Oberstufe, Bayern Naja, das ist eben mein Projekt, was die anderen machen ist halt mehr so...naja...ein anderes Niveau eben. Macht ja nix, so habe ich wenigstens was, wo ich schön meine 15 Seiten drüber schreiben kann :) . Wenn du magst kann ich dir ja mal ein Bild zeigen, habe leider noch keine Projektbeschreibung dazu gemacht, sonst könnt ich einfach auf meine Website linken.
@Markus, jo, du kannst den Code haben. Schick mir mal ne PN, ich würde es präferieren, ihn dir zu mailen, anstatt ihn hir hochzuladen. Gruss Tobias
http://tokyodrift-dev.info/networklamp/ Habe mal 2 Bilder hochgeladen von meinem letzten kleinen Projekt. Das ganze kommt dann in eine Ikea Lampe und leuchtet schön hell und farbig. Ich weiß, ist nicht sonderlich schön gelötet, das hab ich mal schnell abends gemacht. :)
>FPGA Softcore? >ZPU:http://opencores.org/project,zpu >Es gibt sogar einen GCC dafür. Sieht gut aus! Merk ich mir/Guck ich mir an, danke. :)
Angehängte Dateien:
-
DSC00600.JPG
940 KB -
DSC00598.JPG
1,1 MB -
DSC00597.JPG
1 MB
Ein gutes Jahr später möchte ich mich mal wieder melden. Ich habe das Projekt ein wenig aufgeschoben, jedoch nie ganz vergessen. Zwischenzeitlich habe ich einige Platinen entwickelt, darunter zwei große, die ich mal beschreiben möchte. Das eine ist ein Add-On Board zu meinem Xilinx FPGA Kit mit großem CPLD und SRAM und einem PSP-Display (LCD, RGB, 480*272*24bit). Das Display lässt sich Pixelweise ansteuern, auch wenn es das Bild anders vermuten lässt. Ich habe im CPLD einen Controller für das Display implementiert, leider ist jeglicher Softcore im FPGA zu langsam das ganze voll auszureizen, da pro Frame der ganze Screenbuffer übertragen werden muss. Das soll später mal alles in einem FPGA intern ablaufen, ohne Softcore. Das andere ist ein ARM Board mit einem AT91SAM9XE, ein 200+ MHz ARM9 von Atmel. Dazu gibts 8MB RAM, viel Flash, SD, Ethernet, 2x USB und ne Menge Pin-Header. Ich habe ein wenig Programmiert und es funktioniert soweit alles, was ich getestet habe. Ich habe allerdings noch keine größere Anwendung darauf umgesetzt. Außerdem habe ich eine Platine für einen kleinen Xilinx CPLD entworfen, und zwar für das BGA Package. So zum BGA löten testen. Die Platinen habe ich schon hier, allerdings konnte ich die Bauteile noch nicht bestellen, da mir noch ca 30 Euro bei der DigiKey Bestellung fehlen. Anderweitig ist der CPLD in BGA für mich leider nicht aufzutreiben. Zuletzt habe ich mich informiert für eine größere Platine. Um die entsprechenden BGA Fanouts zu packen werden wohl kompliziertere Fertigungstechniken nötig. Eine 6-Layer Europlatine mit 4mil Strukturen und 0.2mm Vias kostet bei Leiton etwa 300 Euro, das wäre also noch im bezahlbaren Rahmen. Von Xilinx gibt es die Spartan6 FPGAs in BGA256 mit 1mm Pitch zwischen den Balls und DDR SDRAM Controller. Ich weiß, dass es von Atmel 400MHz+ ARMs im gleichen Package gibt, die habe ich mir aber noch nicht näher angeschaut, es gibt vermutlich bessere. Anbei noch Bilder der drei Platinen. Los, sagt was ihr denkt! Ist das Projekt schon näher gerückt oder immernoch ungreifbar? Anregungen? Interesse? :]
Keiner will was loswerden? Kommt schon leute, irgendjemand muss doch was zu meckern haben!
Was willst Du denn damit machen, was ist Dein Ziel? Als ich meinen ersten PC (286-er, DOS3.3) hatte, hab ich auch mal mit rumgespielt und eigene Treiber geschrieben (RAM-Disk, EGA-Grafik). Inzwischen stecken aber selbst in kleinen Systemen Mann-Jahrtausende an Software, das kann man nicht mehr selber wuppen. Entweder man baut zu irgenwas 100% kompatible Hardware und benutzt die fertigen Kernel. Oder man baut was eigenes, programmiert es aber nie, außer vielleicht ein paar Testroutinen. Dann ist es schade um den ganzen Aufwand. Ich entwickele und programmiere nur Steuerungen mit 8Bittern, die kann man noch komplett selber beherrschen. Das ganze GUI-Gedöns überlasse ich anderen. Peter
> Was willst Du denn damit machen, was ist Dein Ziel? Ausprobieren, lernen, sehen was man so machen kann, was geht. > Entweder man baut zu irgenwas 100% kompatible Hardware und benutzt die > fertigen Kernel. > Oder man baut was eigenes, programmiert es aber nie, außer vielleicht > ein paar Testroutinen. Dann ist es schade um den ganzen Aufwand. Ich habe kein Problem damit nur "ein paar Testroutinen" zu basteln. Ich will nur daran lernen, nicht ein nutzbares Endprodukt haben. Es geht mir mehr um den Weg, nicht um das, was dabei herauskommt. > Ich entwickele und programmiere nur Steuerungen mit 8Bittern, die kann > man noch komplett selber beherrschen. > Das ganze GUI-Gedöns überlasse ich anderen. Klar, wenn man das Endprodukt braucht muss man sich irgendwo einschränken. Aber es geht nur ums machen, nicht um das was am Schluss steht.
TokyoDrift schrieb: > Das eine ist ein Add-On Board zu meinem Xilinx FPGA Kit mit großem CPLD > und SRAM und einem PSP-Display (LCD, RGB, 480*272*24bit). > Ich habe im CPLD einen Controller für das Display implementiert, > leider ist jeglicher Softcore im FPGA zu langsam das ganze voll > auszureizen, da pro Frame der ganze Screenbuffer übertragen werden muss. Ein Softcore ist von der Leistung her mit einem µC zu vergleichen. Und bei einem µC mußt Du tief in die Trickkiste greifen, wenn kein Displaycontroller zur Unterstürtzung da ist. Mir erschließt sich nicht warum, man einen Displaycontroller in einem Softcore realisieren will. Wenn der FPGA da ist, kann der wunderbar die Controllerlogik übernehmen. > Das soll später mal alles in einem FPGA intern ablaufen, ohne Softcore. Warum später? Warum nicht gleich? Warum erst auf dem CPLD? Ich hätte das Display direkt an den FPGA gehangen. Auf Deinem Xilinx-StarterKit ist doch genug Speicher verbaut. Grüße Sven
> Ein Softcore ist von der Leistung her mit einem µC zu vergleichen. Wenn ich es richtig im Kopf habe läuft Plasma im Spartan3 mit 25MHz. Das RAM-Interface dazu mit der hälfte. Für ein paar Tests reichts, zu mehr aber nicht wirklich. > Mir erschließt sich nicht > warum, man einen Displaycontroller in einem Softcore realisieren will. > Wenn der FPGA da ist, kann der wunderbar die Controllerlogik übernehmen. So war das ja gedacht. Der FPGA soll die Controllerlogik machen. Nur brauchte ich natürlich auch noch eine Instanz, die die Bilder erzeugt. Also auf der das Spiel oder sonstwas läuft. DAS war ein Softcore und soll durch einen ARM ersetzt werden. > Warum später? Warum nicht gleich? Warum erst auf dem CPLD? Ich hätte das > Display direkt an den FPGA gehangen. Auf Deinem Xilinx-StarterKit ist > doch genug Speicher verbaut. Weil ich ausprobieren wollte ob ich mir ein eigenes PCB basteln kann mit eigenem Speicher und eigener Stromversorgung und allem. Der CPLD fällt später natürlich weg, braucht man ja nicht.
Guest schrieb: >> Ein Softcore ist von der Leistung her mit einem µC zu vergleichen. > Wenn ich es richtig im Kopf habe läuft Plasma im Spartan3 mit 25MHz. Das > RAM-Interface dazu mit der hälfte. Für ein paar Tests reichts, zu mehr > aber nicht wirklich. Es gibt ja auch noch andere Softcores. Der Microblaze soll 90 MHz schaffen (o.k. ist nicht kostenlos, aber siehe XAPP1141) und die ZPU schafft ihre 75 MHz. Ich kenne den Plasma (noch) nicht, daher kann ich nicht vergleichen. > Nur > brauchte ich natürlich auch noch eine Instanz, die die Bilder erzeugt. > Also auf der das Spiel oder sonstwas läuft. DAS war ein Softcore und > soll durch einen ARM ersetzt werden. Ok. Jetzt ergibt das einen Sinn für mich. Gut. > Weil ich ausprobieren wollte ob ich mir ein eigenes PCB basteln kann mit > eigenem Speicher und eigener Stromversorgung und allem. Der CPLD fällt > später natürlich weg, braucht man ja nicht. Alles klar. Den CPLD kannst Du ja jetzt als Displaytreiber für einen µC verwenden. Grüße Sven
> Es gibt ja auch noch andere Softcores. Der Microblaze soll 90 MHz > schaffen (o.k. ist nicht kostenlos, aber siehe XAPP1141) und die ZPU > schafft ihre 75 MHz. Ich kenne den Plasma (noch) nicht, daher kann ich > nicht vergleichen. Microblaze habe ich nicht ausprobiert da mir eben die Lizenz fehlt. ZPU ist zwar vom Kerntakt her schneller, das Speicherinterface ist aber erheblich langsamer als Plasma, da er für jeden Speicherzugriff erstmal den Stack benutzt. Plasma ist ein 32bit Softcore der scheinbar recht flott (aber auch groß, füllt den halben FPGA) ist. Zumindest im Vergleich.
@TokyoDrift Du sucht doch ein anspruchsvolles ARM/FPGA Projekt. Ich hätte da eine Idee: Eine SSD (Falsh Disc). Ich habe mir das so vorgestellt: 128x 8GB Flash mit jeweils 32 Bit Die parallel schalten, das wären 4096 Bit parallel, also 512 Byte so wie ein Sektor einer Festplatte groß ist. Je Adresse kann man somit immer 512Byte auf ein mal lesen / schreiben. Das ganze über mehrere FPGA's zusammen auslesen, ein FPGA kann vielleicht 512 Bits breite verarbeiten und diese seriell weiter leiten. Die 8 FPGA's gehen auf einen FPGA, der aus den 8 seriellen Bits wiederum die SATA Ansteuerung macht. Wenn das Flash mit 20MHz läuft, dann könnte man so knapp 10 GB/Sec raus holen. Jetzt muss nur noch der FPGA schnell genug sein ;-) Wäre ein cooles Projekt eine 1TB Selbstbau SSD mit SATA-III Anschluss.
> Du sucht doch ein anspruchsvolles ARM/FPGA Projekt. Neinnein. Ich suche jemand, der bei nem anspruchsvollen ARM/FPGA Projekt mitmacht! Das Projekt habe ich doch schon ;) . > 128x 8GB Flash mit jeweils 32 Bit Das wird teuer... > Wäre ein cooles Projekt eine 1TB Selbstbau SSD mit SATA-III Anschluss. Du meinst wohl mit 14 SATA-III Anschlüssen. SATA3 macht nur 6GBit/s. Wahlweise auch ca. 100 GBit LAN Anschlüsse! Nein, ernsthaft, das wird nichts. Ich wollte aber eh hier nochmal Posten, habe mir vorher schon was überlegt, ich mach später nochmal nen Post mit allem was es so neues gibt!
Angehängte Dateien:
-
Unbenannt.png
270 KB
Ich melde mich jetzt mit ein wenig Fortschritt wieder zurück. Ich habe mir also mal diverse Prozessoren und FPGAs angeschaut. Zur Erinnerung, das ganze soll ein Projekt zum Lernen und Experimentieren werden, kein System, das irgendeinem praktischen Nutzen gerecht werden soll. Also, ich habe mich vorläufig fuer einen AM3505 von TI entschieden, das ist ein 600MHz ARM Cortex A8. Inklusive FPU und co. Dazu ein Spartan6 FPGA. Beide bekommen DDR II SDRAM, der ARM NAND Flash und der FPGA Platform Flash. Dazu wollte ich noch einen STM32 Low Power Cortex M3 (STM32L151xx) schalten, der als Syscon Geschichten wie Power Management und Buttons erledigt und per SPI am ARM haengt. ARM und FPGA sollen per GPMC verbunden werden. Ausserdem bekommt der FPGA das Interface zum Display. Ich habe schon angefangen ein paar Schaltplaene zu zeichnen, allerding nur zur Rumprobieren, da fehlt noch extrem viel, Stromversorgung, Terminierung, Kondensatoren und viel viel mehr. Ich haenge dazu mal Bilder an. Kommentare? Irgendetwas? Interesse? tl;dr: Hab ein paar Bauteile ausgesucht und mit Schaltplaenen gespielt. Interesse am Mitmachen?
Hi Ich will dich nicht dran hindern es zu machen, aber wie viel soll denn am Ende das Board kosten? Wieviele Lagen. Wer bestückt dir die BGAs und vorallem für wieviel? Hier: http://microcontrollershop.com/product_info.php?cPath=154_170_481&products_id=4497 oder hier: http://microcontrollershop.com/product_info.php?cPath=154_170_481&products_id=3569 kosten die um die 120$ bzw. 129$. So sparst du dir die Zeit zum basteln der Platine. Zusätzlich noch eine Platine für den FPGA zum drunter stecken (1,27mm Header) und los gehts mit der Fehlersuche in der ->SOFTWARE<-. Ansonsten Hut ab und viel Erfolg. MfG elfreako
> Ich will dich nicht dran hindern es zu machen, aber wie viel soll denn > am Ende das Board kosten? > Wieviele Lagen. > Wer bestückt dir die BGAs und vorallem für wieviel? Das hatten wir doch schon! Ich würde sagen 8 bis maximal 10 Lagen, eher 8. Ich schätze mal so 500 Euro für ein PCB. Das BGA Bestücken weiß ich nicht, eventuell krieg ich das für günstig bei Freunden in der Firma gemacht. > So sparst du dir die Zeit zum basteln der Platine > Zusätzlich noch eine Platine für den FPGA zum drunter stecken (1,27mm > Header) Es geht mir ja darum, das PCB zu machen!
So, nun melde ich mich mal wieder. Habe den Schaltplan ein wenig weiterentwickelt. Was meiner Meinung noch fehlt ist die gesamte Stromversorgung, USB, UART des ARMs und UART Levelshifter und ein SD Slot. Ich würde gern den TPS65023 PMIC von TI nehmen, da dieser die Power-up Sequence des ARMs unterstützt. Leider liefert er nicht genug Strom für den FPGA, was dann wohl bedingt einen zweiten Regler für den FPGA zu nehmen. Ich denke dass das aber ohnehin nur vorteilhaft für die Qualität der Spannungen. Aktuell nutze ich nur 1.2V, 1.8V, 3.3V und 5V. Der ARM kommt dabei ganz ohne 3V3 aus, weswegen ich die 3V3 Schiene des TPS65023 gleich für die IO Spannung am FPGA für dessen Config Interface und das Display nutzen würde, entsprechend fehlen dann noch Regler für 1V2 und 1V8 des FPGAs, ich würde dann die 5V direkt vom Netzteil nehmen. Anbei der Schaltplan, vielleicht bekommt ja doch langsam mal jemand Lust, wenn nicht, dann eben nicht. Ahja, Xilinx nutzt in ihren Designs recht schnelle differenzielle Oszillatoren, eventuell ersetze ich den aber mit einem langsameren Single-ended in Verbindung mit dem DCM im FPGA, das sollte auch gehen. Noch was, im Schaltplan ist der ARM grün und der FPGA blau. ARM referenziert im Übrigen immer den großen Cortex M8, der kleine Cortex M3 ist Syscon.
Ich frage mich warum ich studiere, wenn ich kein Wort verstehe und mit dem Geld was du für Platinen ausgeben willst, mich ein Semester ernähren kann! ps: studiere lieber nicht, das wäre zu unterfordernd !
>Anbei der Schaltplan, vielleicht bekommt ja doch langsam mal jemand >Lust, wenn nicht, dann eben nicht. Auf was?
Das PDF will mir etwas mit JavaScript unterschieben ... Nicht nett.
> Das PDF will mir etwas mit JavaScript unterschieben ... > Nicht nett. Das tut mir leid, war nicht beabsichtigt. Habe das ganze einfach aus AD10 exportiert mit dem SmartPDF Tool. Ich werde nachher nochmal schauen ob ich dort etwas einstellen kann, ich kann mir aber vorstellen, dass er das Javascript für den Sprung zu den Netlabels braucht. Bin allerdings gerade in der Schule, mache das also heute nachmittag.
TokyoDrift schrieb: >> Das PDF will mir etwas mit JavaScript unterschieben ... >> Nicht nett. > > Das tut mir leid, war nicht beabsichtigt. Habe das ganze einfach aus > AD10 exportiert mit dem SmartPDF Tool. Ich werde nachher nochmal schauen > ob ich dort etwas einstellen kann, ich kann mir aber vorstellen, dass er > das Javascript für den Sprung zu den Netlabels braucht. > Bin allerdings gerade in der Schule, mache das also heute nachmittag. So. Leider habe ich es nicht geschafft das JavaScript aus dem Export zu nehmen. Allerdings sehe ich keinen Unterschied im PDF, wenn ich JavaScript im PDF Reader deaktivieren. Also weiß ich leider keinen Rat, außer JS in euren PDF Readern auszuschalten wenn ihr mir nicht traut ^^. holger schrieb: >>Anbei der Schaltplan, vielleicht bekommt ja doch langsam mal jemand >>Lust, wenn nicht, dann eben nicht. > > Auf was? Na, bei dem Projekt mitzuarbeiten.
Ich melde mich mal wieder. Irgendwie poste ich unter anderem schlichtweg weil ich es belustigend finde, dass es scheinbar keinen interessiert was ich hier veranstalte. Vielleicht hat ja doch jemand Lust sich das anzuschauen, ich denke ich bin mit dem Schaltplan soweit durch. Vielleicht schaut ja mal jemand drüber, ich hänge das ganze PDF (jetzt 15 Seiten) hier an. Als nächstes prüfe ich den ganzen Plan nochmals und mache dann die Footprints.
Hut ab, schickes Projekt. Übersteigt aber leider meine Fähigkeiten und vor allem die Zeit die ich in ein Hobbyprojekt investieren kann. Nur so interessehalber: du arbeitest mit Altium, ne 6lagige Platine für 300€ ist bezahlbar... wie finanzierst du dein Hobby? Ich verdiene nicht schlecht aber wenn ich mir ne Platine für 50€ fertigen lasse überleg ich mir das vorher schon zweimal ob das wirklich nötig ist.
> Nur so interessehalber: du arbeitest mit Altium, ne 6lagige Platine für > 300€ ist bezahlbar... wie finanzierst du dein Hobby? Ich gebe einfach sonst nichts aus und spare alles zusammen, was ich irgendwie kriegen kann. Seit dieser Thread vor über einem Jahr gestartet ist habe ich auch keine größeren Ausgaben mehr getätigt, und alles was ich von Eltern, Verwandten und co. bekommen habe gespart (da war zB. 2 mal Weihnachten dazwischen). Das ganze ist auch für mich sehr teuer und ich drehe eigentlich auch jeden Euro mehrmals um aber es ist irgendwie schon ein Traum, den ich seit Jahren habe, und es ist mir das einfach wert. Klingt wohl irgendwie verrückt, ich kann aber nicht anders. Außerdem verkaufe ich in letzter Zeit noch eine ganze Menge alte Technik, die ich nicht mehr unbedingt brauche, das bringt auch noch einiges. EDIT: Und die Altium Lizenz ist als Educational natürlich auch nicht so teuer, ca 120 Euro im Jahr, die habe ich mir letztes Jahr zum Geburtstag geholt.
Tokyo Drift schrieb: > Das ganze ist auch für mich sehr teuer und ich drehe eigentlich auch > jeden Euro mehrmals um aber es ist irgendwie schon ein Traum, den ich > seit Jahren habe, und es ist mir das einfach wert. Klingt wohl irgendwie > verrückt, ich kann aber nicht anders. Naja soo verrückt auch wieder nicht, und man kann sein Geld auch für deutlich nutzlosere Sachen ausgeben.
So, ich habe alles was ich kann nochmals überprüft, einige kleine und zumindest einen großen Fehler korrigiert, ein paar optionale Bauteile eingefügt. Außerdem habe ich alle Footprints gemacht und die Bestellnummern der Teile angefügt. Aktuell bin ich bei etwa 100Euro für die ganzen Bauteile, zzgl. Versandkosten. Ich hänge nochmal das PDF an, jetzt auch mit PCB Prints.
Hallo, also ich finde es ein bischen schade, das du so alleine schreiben musst, deshalb melde ich mich mal, denn ich lese schon seit ziemlich lange mit Allerdinsg weiß ich nach wie vor nicht, was du nun konkret vor hast, einfach ein Dev-Board zu entwickeln für 500€ ist dann doch wohl ein bischen viel oder? Mal abgesehen von der Tatsache das ich bezweifel das der erste Anlauf perfekt wird ;) Aber generell, arbeite weiter, poste weiter und ich lese weiter, finde es super das du in deinem Alter so ein Wissen hast! Hut ab!
beeindruckendes Projekt, in jeder Hinsicht. Mach weiter so. Ich hab mir grad mal deine Schaltpläne angeschaut, sieht schön strukturiert aus und Fehler konnt ich so auf die Schnelle auch nicht finden. Was ich allerdings etwas vermisst habe, ist ein Overview Plan der einem etwas veranschaulicht wie die einzelnen Schaltpläne zusammenhängen (Sheet Symbols, Sheet Entrys, Place Port).
Was schon mal nicht geht ist deine Mosfet verschaltung von 1,8V zu 1,8V complex... Seh dir mal die Bodydioden der FETs an.
Da liest ja doch jemand mit! Danke Leute! Hein: Vielen dank, dass du nach Fehlern gesucht hast! Um ehrlich zu sein ist mir die völlig verkorkste Schaltung der FETs aber schon selbst vor einiger Zeit aufgefallen, und hab diese behoben. Ich glaube am Anfang war oben sogar 5V statt 1V8! Nun müsste es jedenfalls stimmen. Ich habe schon großen Fortschritt gemacht, das Layout ist mehr oder weniger fertig, es ist auf eine 6-Layer Platine rausgelaufen. Ich habe auch schon SMD-Stencils bestellt, weil ich die mal anschauen wollte. Ich mache nachher ein paar Bilder und ein neues PDF. Danke für die Motivation!
Angehängte Dateien:
-
DSC00713.JPG
1,2 MB
Das wäre mal der Stencil. Ist garnicht so leicht, eine transparente Folie mit Löchern vernünftig auf einem Bild festzuhalten.
Das wäre dann das PDF mit Schaltplänen und Layout files. Ich muss noch auf die Signal Lagen außenrum Kupfer verteilen, um das Gleichgewicht zu halten. Layer Stack ist folgender:
1 | Top GND-Plane |
2 | Mid-1 Signal 1 |
3 | |
4 | Internal Plane-1 GND-Plane |
5 | Mid-2 Signal 2 |
6 | |
7 | Internal Plane-2 3V3 + 1V8 |
8 | Bot 1V2 |
Andere Stackups, also mit anderen Abständen sind leider nur sehr teuer zu bekommen. Tut mir leid, dass das PDF so groß geworden ist, aber es ist ja auch viel drinn. Ein Top-Level-Sheet werde ich noch basteln!
Mal eine kleine Frage am Rande... Du hast ja nahezu keine Kommunikations-Ports zur Außenwelt, keine I/Os, neben der einen USB-Schnittstelle auch keine Verbindungen die ein bisschen Bandbreite haben, nicht mal Tasten zur Benutzerinteraktion (Resets zählen ja da wohl kaum) - meinst Du, dass das so sinnvoll ist? Ich weiß ja nicht wofür Du diese Elektronik verwenden möchtest, aber gerade wenn es eine Universalplatine mit der Zielsetzung 'schauen wir mal was daraus wird' ist, wäre es doch ganz schlau sich auch alle Möglichkeiten zur Kommunikation mit der Außenwelt und eventuellen Erweiterungsschaltungen offen zu halten. Ansonsten natürlich gute Arbeit - Andere Leute werden für soetwas bezahlt ;) ...aber da wirst Du ja scheinbar auch noch hinkommen! Grüße Sascha
Sascha W. schrieb: > Mal eine kleine Frage am Rande... Du hast ja nahezu keine > Kommunikations-Ports zur Außenwelt, keine I/Os, neben der einen > USB-Schnittstelle auch keine Verbindungen die ein bisschen Bandbreite > haben, nicht mal Tasten zur Benutzerinteraktion (Resets zählen ja da > wohl kaum) - meinst Du, dass das so sinnvoll ist? > Ich weiß ja nicht wofür Du diese Elektronik verwenden möchtest, aber > gerade wenn es eine Universalplatine mit der Zielsetzung 'schauen wir > mal was daraus wird' ist, wäre es doch ganz schlau sich auch alle > Möglichkeiten zur Kommunikation mit der Außenwelt und eventuellen > Erweiterungsschaltungen offen zu halten. Ja ich weiß. Das ist wohl eine konzeptionelle "Schwäche". Es ist so gedacht, dass der große ARM so wenig wie möglich Mikrocontroller spielt, sondern einfach nur ein Anwendungsprozessor sein soll. Der hat Speicher drann und das wars. Die Verbindung zur Außenwelt soll über den Syscon, also den Schnittstellenprozessor geschehen. Der hat auch eine Hand voll IOs für Tasten nach außen geführt. Zum Debuggen haben Syscon und ARM UART, der ARM noch eine USB Schnittstelle und der FPGA auch 2 Pins rausgeführt über die man z.B. UART machen kann. Das ganze hat den einfachen Sinn, dass ich so nah wie möglich an eine reale Applikation kommen will. Quasi ein singleboard Computer, der so aufgebaut ist wie ein großer Computer, wo der Prozessor eben nur Prozessor spielt und dann auf andere Geräte (North bzw. Southbridge) zugreift, um mit der Außenwelt zu kommunizieren. Ich will eben kein 0815-Eval Board bauen, denn dann hätte ich auf ein entsprechendes ARM Board zurückgegriffen, sondern eine Plattform, mit der ich unter anderem so nah wie möglich an existierende Systeme kommen will. Ehrlich gesagt zweifle ich selbst ein wenig an dieser Entscheidung, andererseits wäre für mich nurnoch Ethernet einigermaßen interessant als Schnittstelle, und darauf kann ich auch verzichten.
Sascha W. schrieb: > meinst Du, dass das so sinnvoll ist? Tokyo Drift schrieb: > Zur Erinnerung, > das ganze soll ein Projekt zum Lernen und Experimentieren werden, kein > System, das irgendeinem praktischen Nutzen gerecht werden soll. Schade um die Arbeit, die Zeit und das Geld.
Angehängte Dateien:
-
DSC00714.JPG
820 KB -
DSC00716.JPG
1000 KB -
DSC00717.JPG
730 KB
Habe bei AVNET für ca 100 Euro Bauteile bestellt. Man man man. Hab 2 riesen Kisten bekommen. Bild 1: Alles was gekommen ist Bild 2: Eine der Verpackungen aufgemacht Bild 3: Der gesamte Inhalt von der Verpackung auf Bild 2
Angehängte Dateien:
-
DSC00721.JPG
940 KB -
DSC00723.JPG
770 KB
Außerdem habe ich meine neue Lötpaste erhalten, die andere ist im Hackerspace versandet. Habe mal bisschen damit rumprobiert, noch schnell einen der CPLD Boards gelötet (leider nicht komplett weil mir die Spannungsregler fehlen), man sieht schön die gleichmäßige Verteilung der Paste auf den Pads. Der CPLD (0.5er pitch BGA) hat keine Kurzschlüsse und sitzt fest. Werde ihn die Tage noch ganz durchtesten. Außerdem habe ich mal das große BGA Grid auf ein Blatt Papier gemacht, sieht schon recht gut aus wie ich finde. Ist normales 5mm-Raster Papier. Die Verunreinungen sind übrigens verschmierte Tinte, das Blatt hat auch für meine Mathe-Abivorbereitung herhalten müssen.
So. Ich habe nun noch die inneren Layer für bessere Copper balance gefüllt. Sollte so klar gehen. Am Mittwoch habe ich Wirtschafts-Abi, danach werde ich wenns gut geht die Platinen-Bestellung fertig machen und aufgeben. Dann wirds spannend!
Jetzt bei Digikey den Löwenteil der BOM bestellt, insgesamt 50 Posten und fast 1000 Komponenten (gut, hab vorallem bei den Cs und Rs viel mehr bestellt als ich brauche). Alles in allem kostet die gesamte BOM inkl. aller Komponenten und Versand etwa 200 Euro. Dazu kommt dann eben noch das PCB, aber zunächst muss ich die Footprints gegen die Bauteile verifizieren.
Tokyo Drift schrieb: Der CPLD (0.5er pitch BGA) hat keine Kurzschlüsse > und sitzt fest. Werde ihn die Tage noch ganz durchtesten. Hast du den bestücken lassen? Ich hatte ja auch mal überlegt ein bisschen mit BGAs zu spielen, aber 0.5mm Pitch ist ja schon bei TQFP nicht ganz einfach (für mich) zu positionieren und da seh ich ja noch die Pins. P.S. Beeindruckendes Projekt
Marco L. schrieb: > Hast du den bestücken lassen? Ich hatte ja auch mal überlegt ein > bisschen mit BGAs zu spielen, aber 0.5mm Pitch ist ja schon bei TQFP > nicht ganz einfach (für mich) zu positionieren und da seh ich ja noch > die Pins. Nein.Von den Boards hab ich schon ein paar gemacht. Beste Ergebnisse hatte ich bei Heißluft mit "Preheater". Bei ebay eine kleine Herdplatte für 15 Euro und eine Heißluftpistole für 20 kaufen, auf die Herdplatte 2 Metallstücke legen und darauf die Platine, so dass sie in ein paar cm Abstand über der Platte schwebt (für bessere Hitzeverteilung). Platte einschalten und warten bis die Platine 80 bis 100° hat, dann abschalten und mit Heißluft von oben auf die Platine, dabei immer schön kreisen, bis alles verlötet ist. Bestücken von kleinen Bauteilen am besten unterm Stereomikroskop (gibts für 50 Euro) bzw von BGA einfach nach dem Druck auf der Platine, das zieht sich dann schon richtig hin. Lötpaste am besten per Stencil auftrage, gibt billige SMD Stencils bei smtstencil.co.uk , da gibts ein ganzes Din-A4 Blatt voller Stencil für ca 17 Euro. EDIT: Wenn du interessiert bist kann ich dir auch die Layout-Daten für das CPLD Board zukommen lassen. Die Boards bei seeedstudio kosten 10 USD für 10 Stück, also 1 USD pro Board. Der Rest der Komponenten kostet pro Board maximal nochmal nen 10er obendrauf. Da kannst also für gute 100 Euro mal 10 Boards zum Üben machen. Ist aber kein Full-Grid BGA sondern 2 Konzentrische Ringe an Balls. 56 Ball hat das Teil.
Tokyo Drift schrieb: > > EDIT: Wenn du interessiert bist kann ich dir auch die Layout-Daten für > das CPLD Board zukommen lassen. Die Boards bei seeedstudio kosten 10 USD > für 10 Stück, also 1 USD pro Board. Der Rest der Komponenten kostet pro > Board maximal nochmal nen 10er obendrauf. Da kannst also für gute 100 > Euro mal 10 Boards zum Üben machen. Ist aber kein Full-Grid BGA sondern > 2 Konzentrische Ringe an Balls. 56 Ball hat das Teil. Ich wollte mir mal demnächst selbst ein paar Testboards machen und ein bisschen experimentieren. Scheinbar gibt es auch sehr gute Lötergebnisse mit "Pizzapfannen". Auf Heise online gab es da mal einen Beitrag. http://www.heise.de/hardware-hacks/artikel/Loeten-in-der-Pizzapfanne-Kleiner-Nachschlag-1406642.html Grüße
Marco L. schrieb: > Ich wollte mir mal demnächst selbst ein paar Testboards machen und ein > bisschen experimentieren. Scheinbar gibt es auch sehr gute Lötergebnisse > mit "Pizzapfannen". Auf Heise online gab es da mal einen Beitrag. > http://www.heise.de/hardware-hacks/artikel/Loeten-... Die löten eben nur von unten. Wenn dabei die Temperatur zu hoch wird geht halt sofort die Platine kaputt, mit Preheater und Heißluft von oben kann das nicht ganz so schnell passieren glaube ich.
Marco L. schrieb: > Ich wollte mir mal demnächst selbst ein paar Testboards machen Achja, der Chip heißt Xilinx XC2C64A bzw XC2C32A im CP56 Package.
Wenn mir jemand von euch weiterhelfen will, der PCB Hersteller, der die Platinen am günstigsten Fertig verkauft nur an Gewerbe. Wenn also jemand, der ein Gewerbe hat, die Platinen für mich bestellen würde wäre das eine riesen Hilfe. Ich würde natürlich das ganze zahlen bzw noch ein bisschen was drauflegen.
PCBs sind bestellt. 240 Euro für 2 Stück. Syscon Firmware steht auch schon, kompiliert sauber durch, hab das Target System noch nicht kanns also nicht testen. Macht bis jetzt UART + Power Management. SPI <-> GPIO kommt irgendwann mal wenn der Rest steht.
Angehängte Dateien:
-
Hardware-Block.png
7,1 KB
Hier mal ein kleines Blockdiagramm der Hardware, ohne Strom und Taktversorgung.
Hab mal die BOM schön mit Preisen und so fertig gemacht. Die BOM für eine Platine incl. aller Bauteile macht gut 270 Euro aus. Dazu kommt noch der Versand, also knapp unter 300 Euro für eine. Ich habe bis jetzt knapp 450 Euro ausgegeben, allerdings habe ich ja 2 Platinen bestellt und die meisten Bauteile auch doppelt.
Und was hast du nun konkret vor zu testen? Da bin ich nach wie vor nicht durchgestiegen Ich hab bei Seeed jetzt keine genauen Informationen über den Versand gefunden, was kostet denn der Versand auf DE?
Markus B. schrieb: > Und was hast du nun konkret vor zu testen? Da bin ich nach wie vor nicht > durchgestiegen Ich will nichts testen, ich will etwas lernen. Ich will verstehen wie das alles funktioniert. Außerdem macht das ganze Spaß. Markus B. schrieb: > Ich hab bei Seeed jetzt keine genauen Informationen über den Versand > gefunden, was kostet denn der Versand auf DE? ?? Worauf beziehst du dich? Der normale Versand bei SeeedStudio kostet nur 3 USD oder so, dauert aber auch bis 30 Tage. Schnellerer Versand kostet mehr.
Ok, das mitn Versand ist dann ok ;) Dann kann ich mir da doch was bestellen :-P Mir ist einfach nicht ganz ersichtlich was du mit dem fertigen Produkt vor hast. Oder geht es dir wirklich nur um den Herstellungsprozess?
Markus B. schrieb: > Mir ist einfach nicht ganz ersichtlich was du mit dem fertigen Produkt > vor hast. Oder geht es dir wirklich nur um den Herstellungsprozess? Ja. Bzw, Hardware-Design-, Herstellungs- und Programmierprozess. Halt alles was man braucht um von der Idee zum Produkt zu kommen.
So, kurzes Update für alle die es interessiert, also für niemanden: - Ich habe die Boards bekommen und eines Bestückt - Spannungsregelung geht komplett - SYSCON geht komplett - FPGA Config Speicher geht garnicht (Signale vertauscht) - FPGA geht in seiner Minimalbeschaltung - Display am FPGA geht nicht (falsche Spannungspegel) - RAM am FPGA konnte ich noch nicht fertig testen - ARM geht in seiner Minimalbeschaltung - RAM am ARM konnte ich auch noch nicht testen - Peripherie am ARM konnte ich noch nicht testen - Verbindung ARM-FPGA dürfte wegen falscher Spannungspegel nicht gehen - Einige Kleinigkeiten sollten geändert werden (FPGA JTAG Stecker Pitch, SYSCON Regler an 5V statt Vin, solche Sachen) Leider war ich in letzter Zeit ein wenig unter Zeitdruck, habe ja mein Abi gemacht und bestanden, übermorgen fliege ich in Urlaub und komme erst in 2 Monaten wieder, werde bis dahin also nicht weitermachen können. Danach gibt es eine zweite Revision und so. Im Wintersemester fange ich mit dem ETechnik Studium an.
Niemand ist falsch ;) Herzlichen Glückwunsch zum Abi, viel Spaß im zwei monatigen Urlaub Mach doch bitte mal ein Bild von deinem Projekt :)
Es ist immer wieder interessant wie ein (werdender) Ingenieur aus ein paar Bauteilen versucht ein System aufzubauen. Und es ist auch interessant, wie der Know-How-Transfer von einem Ingenieur zum Nächsten geht... Eine Frage brennt mir unter den Fingernägeln: Wie spricht der ARM mit dem FPGA und mit welcher Geschwindigkeit? Über die "General Purpose I/O (GPIO)" zu gehen soll den Prozessor sehr belasten und die Geschwindigkeit soll nicht überragend sein. Stimmt das so? Aus dem veröffentlichten Blockdiagramm sollen sie sich über den "General Purpose Memory Controller (GPMC)" [=> Memory Mapped I/O (MMIO)] oder über den "Serial Peripheral Interface Bus (SPI)" unterhalten. Die maximale Übertragung (Cycle time) über SPI ist als Master ca. 20ns = 50MHz und als Slave ca. 40ns = 25 MHz. Etwas mager für einen ARM mit 600 MHz. (siehe Datenblatt 6.6.2 Multichannel Serial Port Interface (McSPI) Timing). Über SPI muss am FPGA ein Gegenspieler die Daten vom ARM in Empfang nehmen und vom Seriallen ins Parallele konvertieren. Dabei geht auch wieder Zeit verloren. Über GPMC kann eine Geschwindigkeit von 12ns = 86 MHz erreicht werden, wobei Adress- und Daten gemultiplext werden. (siehe Summary, 2.4.1 External Memory Interfaces, 6.4.1 General-Purpose Memory Controller (GPMC)). Kann so ein I/O-Device angehängt werden? Im Datenblatt steht "The GPMC is the AM3517/05 unified memory controller used to interface external memory devices such as: Asynchronous SRAM-like memories and ASIC devices" => also auch ein FPGA? Dabei kann über eine Adresse (26-bit) direkt Daten (16-bit) angesprochen werden? Das heisst auch, jeder ARM, der über einen asynchronen Memory-Controller verfügt, kann einfach ein "Memory Mapped I/O-Device" ansteuern? Wie sieht es bei anderem ARMs aus? Freescale i.MX21/35/51: Über das "External Memory Interface (EMI)" an das "Wireless External Interface Module (WEIM)"? NXP LPC3131: Über den "Multi-Port Memory Controller (MPMC)"? CIRRUS LOGIC EP9315: Über den "General Purpose Memory Interface"? Wie sieht es da mit der Geschwindigkeit aus? P.S. Ich bin auch gerade daran, ein ARM mit FPGA-Gespielin zu layouten
Angehängte Dateien:
-
test.png
463 Bytes
So, nun bin ich wieder daheim. Mein Studium fängt am 15. Oktober an, bis dahin habe ich noch etwas Zeit. Ich habe mich aus diversen Gründen dazu entschieden, die vorhandenen Layout Fehler zu fixen und eine neue Platinenrevision zu bestellen, das sollte meine Arbeit stark erleichtern. Im Anhang, ein Bild, dass die Sprite GPU in ihrem jetzigen Zustand aus 5x64bit, also 40Byte Daten erzeugt hat. Es fehlt eben noch der Memory-Load Teil, einige Schnittstellen für die Parallelisierung der GPU-cores und die Optimierung. So wie es jetzt ist wird das gezeigte Bild in 5ms erzeugt. Die GPU läuft dann im FPGA. Nun zu den Fragen: Andreas Bachmann schrieb: > Eine Frage brennt mir unter den Fingernägeln: Wie spricht der ARM mit > dem FPGA und mit welcher Geschwindigkeit? Du hast richtig erkannt, dass sowohl SPI alsauch GPMC verbunden sind. Über GPIOs will ich nicht sprechen (EDIT: Ich meinte, über GPIOs sollen ARM und FPGA nicht kommunizieren, natürlich habe ich persönlich kein Problem damit, ein Gespräch mit dem Thema "GPIOs" zu führen). Es gibt einen Modus, in dem 8bit Adressen und 16bit Daten zur Verfügung stehen, nicht gemultiplext, mit 86MHz. Das entspricht dann 172MByte/s, also doch recht flott. Der Gedankengang ist, im FPGA eine Art Dual-Port Ringbuffer zu implementieren, in die der ARM schön Daten per DMA kopieren kann, also virtuell garkeine Prozessorleistung dazu braucht und doch einiges an Daten durchschaufeln kann. Parallel dazu soll das SPI als Steuereitung eingesetzt werden, also zB. sagt der ARM dem FPGA per SPI dass nun ein Bild an die Adresse XYZ im GRAM gespeichert werden soll und überträgt das dann per GPMC. Oder der ARM fragt per SPI nach dem VBlank. Oder, oder oder... Andreas Bachmann schrieb: > Das heisst auch, jeder ARM, der über einen asynchronen Memory-Controller > verfügt, kann einfach ein "Memory Mapped I/O-Device" ansteuern? Würde ich jetzt nicht ohne genauere Überlegung unterschreiben, aber im Grunde schon. Andreas Bachmann schrieb: > Wie sieht es bei anderem ARMs aus? > Freescale i.MX21/35/51: Über das "External Memory Interface (EMI)" an > das "Wireless External Interface Module (WEIM)"? > NXP LPC3131: Über den "Multi-Port Memory Controller (MPMC)"? > CIRRUS LOGIC EP9315: Über den "General Purpose Memory Interface"? > Wie sieht es da mit der Geschwindigkeit aus? Keine. Ahnung. All diese Chips sagen mir jetzt aktuell garnichts, ich hab in früheren Phasen meines Projektes ja viel Research betrieben, hab aber nicht mehr viel davon im Kopf, ich weiß nur, dass der TI ARM den ich benutze übrig geblieben ist. Andreas Bachmann schrieb: > P.S. Ich bin auch gerade daran, ein ARM mit FPGA-Gespielin zu layouten Hübsch Hübsch! Hast du vielleicht Lust bei mir mitzumachen? Oder schwebt dir ein anderes Grundkonzept vor? Markus B. schrieb: > Herzlichen Glückwunsch zum Abi, viel Spaß im zwei monatigen Urlaub > > Mach doch bitte mal ein Bild von deinem Projekt :) Vielen Dank! Ich fürchte wenn ich ein Bild mache, werde ich nur wieder als unfähig hingestellt. Leider musste ich aufgrund einiger Fehler (nicht Layouttechnisch) den ARM und seinen RAM ablöten, was erhebliche Schäden an allen Plastikteilen nach sich zog, die Platine sieht nun entsprechend grauenhaft aus. EDIT: Sprache ein wenig eindeutiger Gestaltet ;).
Ich finde das Projekt spannend, ein FPGA in Kombination mit einem ARM ist ein schlagkräftiges Duo. Leider wäre ich nicht in der Lage so etwas selbst zu entwickeln. Deshalb habe ich mir für mein Projekt so etwas fix und fertig gekauft: http://www.ebay.at/itm/180933898787 Gut, natürlich kann man eine CPU im FPGA abbilden und dasselbe erreichen. Trotzdem ist es faszinierend ...
Thomas Winkler schrieb: > Gut, natürlich kann man eine CPU im FPGA abbilden und dasselbe > erreichen. Trotzdem ist es faszinierend ... Mittlerweile gibt es auch die Zynq ICs verfügbar. Das sind DualCore ARMs mit ich glaube 1GHz pro Kern und außenrum eine Series7 FPGA Area, also quasi wie ein DualCore ARM mit Kintex7 FPGA. Ich wollte das ganze halt eben selber zusammenbauen :)
Thomas Winkler schrieb: > Gut, natürlich kann man eine CPU im FPGA abbilden und dasselbe > erreichen. Trotzdem ist es faszinierend ... Zum Beispiel ein Soft-Core-Prozessor wie NIOS II, doch Taktfrequenz nur 50 MHz. Genau das haben wir momentan, aber das reicht uns nicht mehr. Wenn du ein Linux mit mehreren User-Level-Programmen benutzen möchtest, reichen 50 MHz nicht mehr. Thomas Winkler schrieb: > Leider wäre ich nicht in der Lage so etwas selbst zu entwickeln. Deshalb > habe ich mir für mein Projekt so etwas fix und fertig gekauft: > http://www.ebay.at/itm/180933898787 ARM Cortex-M3 -> ohne MMU. Nicht gut für Linux, ausser man nimmt uClinux.
Andreas Bachmann schrieb: > Thomas Winkler schrieb: >> Gut, natürlich kann man eine CPU im FPGA abbilden und dasselbe >> erreichen. Trotzdem ist es faszinierend ... > Zum Beispiel ein Soft-Core-Prozessor wie NIOS II, doch Taktfrequenz nur > 50 MHz. Genau das haben wir momentan, aber das reicht uns nicht mehr. > Wenn du ein Linux mit mehreren User-Level-Programmen benutzen möchtest, > reichen 50 MHz nicht mehr. Als Produktivsystem mal das Digilent Zynq Board angeschaut? Garantiert billiger als selbst entwickeln ;) . Und flott ists auch. Sollt auch ne MMU haben.
Huch nun war ich nicht eingeloggt. http://digilentinc.com/Products/Detail.cfm?NavPath=2,719,1033&Prod=ZEDBOARD Hier der Link!
Tokyo Drift schrieb: > Als Produktivsystem mal das Digilent Zynq Board angeschaut? Garantiert > billiger als selbst entwickeln ;) . > Und flott ists auch. Sollt auch ne MMU haben. Zynq -> Xilinx Leider gibts von Altera noch nicht vergleichbares, sonst würden wir sowas nehmen. Es gibt zwar eine Vorankündigung: http://www.altera.com/socfpga Es sollen Cyclone V SE/SX/ST und Arria V SX/ST kommen. Warum nicht Xilinx: ganz andere Tools -> bis wir umgeschult wären, würde viel Zeit vergehen.
Dann melde ich mich auch mal wieder. Nachdem wie ja schon oben angemerkt und auch zu erwarten war in Revision 1 jeder Teil der Schaltung irgendwelche Fehler hatte (außer der Stromversorgung, was mich sehr verwundert hat) ist Revision 2 nun soweit fertig geroutet. Es hat sich so ziemlich alles geändert, vom Layer-Stack über die Length-Match Toleranzen usw. Ich hoffe, dass sich dadurch die Signalintegrität signifikant verbessert. Außerdem wurden einige BGA Komponenten eingespart/ersetzt durch normale SMD Bauteile, um Löt-Problemen vorzubeugen. Ich suche nun nach Personen mit Erfahrung, die so nett sind und über meine Projektdaten zu schauen, um etwaige Fehler zu finden. Allerdings bin ich den Rest des Wochenendes nicht hier, werde aber auf alle Nachrichten/Kommentare/Anfragen antworten, sobald ich wieder Zeit habe, spätestens Montag. Zu mir persönlich noch kurz, ich studiere nun seit einem guten Monat, es ist sehr anstrengend und zeitfressend (ich bin Montag bis Donnerstag jeweils 12 Stunden täglich unterwegs/in der Uni). Ich hoffe aber dass ich die Platine bis in einer Woche bestellen kann und sie dann in den Weihnachtsferien ausprobieren/verlöten kann. Schonmal danke an alle Helfer!
Dann viel Erfolg! Inzwischen bist du da ja schon fast 2 Jahre dran, das nenne ich mal Durchhaltevermögen ;)
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.