Hallo zusammen! Ich hab für die Diplomarbeit endlich ein Thema bekommen! freu Im Prinzip kann ich frei entscheiden wie ich es machen soll. Nur "günstig" soll es sein. Die Aufgabe ist es eine endlich Anzahl von Signalleitungen (ca. 200-300) parallel auf Pegelwechsel zu überwachen. Bei Pegelwechsel soll ein Zeitstempel und ggf. sogar der Pegel in einer digitalen Form (z.B. CSV Datei) gespeichert werden. Das ist grob die eigentliche Aufgabe. Konfiguriert werden soll das System mit einem Windowsprogramm. Z.B. mit QT. Damit soll man jeden einzlen Pin konfigurieren. - Pin aktiv?! - In welcher Zeitspanne registriert der Pin einen Pegelwechsel - u.s.w. Ist noch nicht genau definiert. Sprich ich brauche auch sowas wie eine USB Schnittstelle mit ggf. verfügbaren USB Treiber. Zur Datenspeicherung wäre vielleicht eine SD oder ähnliches nicht schlecht. Das Gesamte wollte ich mit einem FPGA lösen. Allerdings habe ich nicht so den Erfahrungsschatz wie man eine Schaltung mit FPGA's aufbaut. Mit AVR's ja mit FPGA's nein. Wir haben in der FH mit Altera's rumgespielt. Allerdings nur softwaretechnisch. Also nun meine Frage wie fange ich am besten an. 6 Monate habe ich Zeit! ;-)
Max schrieb: > Konfiguriert werden soll das System mit einem Windowsprogramm. Z.B. mit > QT. Qt ist ein "Windowsprogramm"? Huh.
> Also nun meine Frage wie fange ich am besten an. 6 Monate habe ich Zeit! Falsch. Du hast nur knapp vier Monate Zeit. Die restliche Zeit brauchst du für die Dokumentation. > Sprich ich brauche auch sowas wie eine USB Schnittstelle mit ggf. > verfügbaren USB Treiber. Zur Datenspeicherung wäre vielleicht eine SD > oder ähnliches nicht schlecht. In ein FPGA? In vier Monaten. Und dazu ein PC-Programm...? > Das Gesamte wollte ich mit einem FPGA lösen. Allerdings habe ich nicht > so den Erfahrungsschatz wie man eine Schaltung mit FPGA's aufbaut. Mein Tipp: Halt den Ball flach. Es haben sich andere auch schon überschätzt :-/ > Ist noch nicht genau definiert. Definier das Ding mal fertig. Dann mach die Triggergeschichte, speicher die Daten im SRAM zwischen und übertrag sie zum PC und zeigst sie dort an. Wenn du das hast, dann geh an die Dokumentation. Ein Tipp: besser eine "einfache" Diplomarbeit, die fundiert und bombensicher da steht, als so ein Wolkengebilde, wo alles nur "gerade mal so" zusammengebastelt ist.
Hallo, ich stand bzw. stehe gerade noch vor einer ähnlichen Aufgabe ... hier ein paar Tipps aus den Erfahrungen der letzten Monate: Nimm als Schnittstelle was einfaches wie RS232 / RS485, dass lässt sich viel einfacher auf dem FPGA implementieren und du sparst sehr viel Zeit, für .Net / Mono gibts bereits Klassen, für QT vielleicht auch. Für den Einstieg in VHDL kann ich "Paul Molitor - Eine Einführung in VHDL" empfehlen. Die Aufgabe mit dem FPGA ist machbar, aber am Ende wird vermutlich wenig Zeit für die PC-Software bleiben. Wenn du dich in QT nicht so gut auskennst, würde ich die PC-Anwendung minimal halten und mehr Zeit in den Test der Logik und vor allem in ein gutes Konzept investieren. Mit den kostenlosen Modelsim-Versionen von Altera oder Xilinx lässt sich alles ganz gut testen, erst danach die Synthese und die realen Signale nochmals mit dem Oszi / Logic Analyzer messen. Kann die Altera-Tools und deren Dokumentation empfehlen.
@Lothar Jup 4 Monate ab Anmeldung. Aber bei uns die Professoren sehr kulant, was die Anmeldung angeht. Sprich angemeldet wird in der Regel erst, wenn alles in trockenen Tüchern ist. Wenn ich die Wahl hätte würde ich das gern mit AVR's machen. Dann würde ich das "locker" schaffen. Allerdings habe ich noch keinen Atmel gefunden der um die 200 I/O hat. Und die dann nahezu parallel verwalten kann. Aber was würdest du denn Empfehlen? Das hat die Aufgabe, woran ich leider nicht rütteln kann. Und einbissel PC Software muss sein, wie soll man die sonst konfigurieren?! @Gast Oh danke für den Tip. Werde ich mir mal anschauen. In QT kenne ich mich eigentlich recht gut aus. Ist ein echt schönes Framework mit dem man doch recht schnell grafische Oberflächen erstellen kann.
> Allerdings habe ich noch keinen Atmel gefunden der um die 200 I/O hat. > Und die dann nahezu parallel verwalten kann Das ist die Domäne des FPGAs. Aber ich würde schnellstmöglich die Datenrate soweit reduzieren, dass das ein uC verarbeiten könnte. > Aber was würdest du denn Empfehlen? Das hat die Aufgabe, woran ich > leider nicht rütteln kann. Und einbissel PC Software muss sein, wie soll > man die sonst konfigurieren?! Wie gesagt: - Das Einlesen der Eingänge und Vergleichen über ein FPGA. - Das Speichern über den AVR. - Die Kommunikation über den USB Nur die nicht näher spezifizierte Geschwindigkeit würde mir noch Falten auf die Stirn treiben (weniger wegen des FPGAs, mehr wegen der Frage, wie ich die Daten schnell genug dort weg bekomme...). Du hast dann immer noch genug zu tun: - Einfache FPGA-Programmierung (auch das kann schon Nerven kosten und Zeit brauchen) - AVR zur Kommunikation - PC-GUI
Oh das ein gutes Konzept. USB und AVR bekomme ich hin. Hab ich schon eine funktionierende Schaltung mit allem drum und dran hier liegen. :) Jetzt ist noch die Frage wie kommunizieren FPGA und AVR mit einander? Über eine Art UART? Ist der Aufbau der Hardware vergleichbar aufwendig wie beim AVR?
Aso Geschwindikeit. Hm also da es für ein Testrack für Autosimulationen ist würde ich mal sagen so normales PWM's im 100-200Hz Bereich?! Aber das bekomme ich ihn den nächsten Wochen raus. Offizielle Anmeldung ist erst mitte August.
200Hz? Da kannst du auch ne Latte Latches nehmen, die gleichzeitig triggern und dann nacheinander mit dem avr auslesen. Ist zwar mehr Bauteilaufwand und benötigt mehr Leiterplattenfläche, aber du sparst dir dein FPGA. Und falls du doch mit dem FPGA arbeiten möchtest würd ich den avr weglassen. Die USB Kommunikation würd ich nicht selbst machen, sondern ein FTDI Chip verwenden.
Der AVR ist überflüssig. Einfach einen FT245R oder wenn´s schneller gehn muss, den neuen FT2232H an den FPGA und das Ding als FIFO benutzen um die Daten zum PC zu streamen. Geht recht einfach, die Ablaufsteuerung kannst du dann in den FPGA machen.
Hallo Max, wenn ein AVR (oder AVR32) grundsaetzlich von der Beschaffenheit der I/Os geeignet ist, warum benutzt du dann nicht einfach soviele AVRs wie noetig? Gruss Christian
Bitte 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.