Ich entwickle gerade einen Schrittmotor-Impusgeber der Rechtecksignale von bis zu 50kHz erzeugen und Zählen muss. Nach längerem rumprobieren und vielen Diskussionen in einem anderen Thread, hab ich das mit einem ATxmegaA3 realisieren können. Nun bin ich aber auf eine weitere Anforderung für meine Schaltung gestoßen, die sich so nicht mit einem AVR allein realisieren lässt. Kurzgesagt möchte ich meine Schaltung so abändern, dass der AVR nur noch für die RS232 Kommunikation und das Bereitstellen der Frequenzen (als Wert in irgend einer Form, nicht als Frequenz-Signal) und der Schrittzahlen zuständig ist. Die Frequenzen sollen in einem FPGA erzeugt werden, was mir schonmal in dem anderen Thread vorgeschlagen wurde. Meine Frage ist nun, wo beginne ich am besten, wenn ich noch nie mit einem FPGA gearbeitet hab? Die Funktionsweise hab ich verstanden und auch schon einige Entwiklungsboards gefunden. Auch in einigen Threads hier im Forum hab ich mich schon umgeschaut. Die 3 wichtigste Fragen die ich habe sind gerade: A Nach welchen Kriterien wählt man einen FPGA aus? Bei einem AVR sind es z.B. Taktgeschwindigkeit, IO-Pins, Timer-Anzahl usw. B Mit welchem Entwiklungsboard/"Programmer" sollte ich anfangen ? Es sollte nicht zu teuer sein (möglichst unter 200€) aber die Pins des FPGAs als DIP/Pin-Header bereitstellen so dass ich nicht erst noch Adapterboards löten muss und das alles mit Drahtbrücken verbinden muss. C Welche Entwiklungsumgebung ist für Anfänger am besten geeignet ? Ich habe schon einige gefunden, aber bisher hat Windows (10) diese entweder als "gefährliche Software" eingestuft, oder sie liefen in einer VM auf Linux (warum so kompliziert ???) und waren sehr mit Funktionen überladen und ohne große Dokumentation.
Ich fand diese tinyFPGAs eigentlich recht witzig gemacht. Wirklich sehr kleines Board und man kann relativ schnell mit starten. Ansonsten würde ich mich evtl. mal noch nach den typischen Xilinx Boards umsehen mit Artix o.ä.
Hallo, fang mit Frage B an. Nimm die Boards, die die Pins über normale Pins heraus geführt haben. Da wird das Suchergebnis schon deutlich eingeschränkt. Die großen Player sind Xilinx und Altera. Da wirst du dich für einen entscheiden müssen. So wie früher die Diskussion PIC oder AVR. Das ist eher eine Glaubensfrage, als dass man sich als Neuling damit beschäftigt, was die alles im einzelnen können. Unter dem Strich nehmen die sich nicht viel. Für deine ersten Gehversuche sind beide gleichermaßen geeignet. Sonderexemplare würde ich dir nicht empfehlen. Du willst ja Fragen stellen und beantwortet haben beim Lernen. Und bei den beiden Firmen oben gibt es einfach die meisten User. Und für die Größe des Boards kaufst du das größte, das du mit deinem Budget bekommst. Die Entwicklungsumgebung ist damit dann auch schon ziemlich fest. Achja: um ein Buch für VHDL wirst du nicht drumrum kommen. Das braucht man meiner Meinung nach als Nachschlagewerk immer neben der Tastatur. Ich verwende für meine ersten Versuche Xilinx und ISE Webpack. Beides schon veraltet, aber für meine Zwecke komme ich noch an keine Grenze. Reicht also vollkommen aus. Grüße, Jens
Marvin K. schrieb: > Kurzgesagt möchte ich meine Schaltung so abändern, dass der AVR nur noch > für die RS232 Kommunikation und das Bereitstellen der Frequenzen (als > Wert in irgend einer Form, nicht als Frequenz-Signal) und der > Schrittzahlen zuständig ist. Auch das geht wunderbar im FPGA. Marvin K. schrieb: > A Nach welchen Kriterien wählt man einen FPGA aus? Für ein Projekt oder generell zum Lernen? Für ein Projekt machst du erstmal deine Hardwarebeschreibung am PC und dann guckst du wie viele IOs und sonstigen FPGA Ressourcen du brauchst. Und dann kaufst du den FPGA in den das Design reinpasst. Aber keinen der 10 mal "größer" ist. Zum Lernen kannst du ein beliebiges FPGA Board nehmen das auch eben Spielwiesen bietet. Taster, Schalter, LEDs, Display, ADC, DAC, RAM, Flash, I2C/SPI Bausteine, ... wichtig ist, dass das von einer aktuellen Entwicklungsumgebung unterstützt wird. Denn du willst ja den aktuellen Stand lernen. Marvin K. schrieb: > B Mit welchem Entwiklungsboard/"Programmer" sollte ich anfangen ? Ich würde aktuell etwas mit Xilinx 7er Serie nehmen. Also Artix7/Spartan7/Zynq7. Begründung: Das wird vom aktuellen Vivado unterstützt und ist nicht sooo irre teuer. Ja, man könnte auch den MAX10 nehmen, aber der MAX10LP wird leider nie ordentlichen VHDL2008 Support bekommen. Wenn dir das egal ist dann nimm den. Marvin K. schrieb: > C Welche Entwiklungsumgebung ist für Anfänger am besten geeignet ? Naja, Hardwarebeschreibung schreibt man, das geht mit jedem Texteditor, dann simuliert man recht viel, dazu gibt es GHDL/Modelsim/... und dann muss man das noch auf die Hardware bringen. Und nur für den letzten Schritt brauchst du die Software vom Hersteller. So wie dein Projekt klingt könnte das https://github.com/dukelec/cdpga/tree/master/cdpga_h gut passen. Das ist aktuell sogar über eBay/Aliexpress recht gut zu bekommen. Ist aber kein Lernboard weil das ausser FPGA und Taktgeber nicht viel drauf hat.
Danke schonmal für die schnelle Antwort, ISE hab ich mir schon runtergeladen (Webpack hab ich nirgends gelesen, ist das was anderes ?) ISE hat aber eine VM mit Linux installiert und läuft nicht unbedingt sehr stabil. Ich werde mich dann erstmal nach einem Board umsehen. Ich hab mal mein aktuelles Konzept für den (neuen) Impulsgeber als Grafik angehängt, ich denke das das die bisher beste Lösung ist die ich gefunden habe. Ziel ist es auf dem Board das ich mit kaufe, diesen FPGA zu realisieren und zu testen, es sollte also genug IO Ports haben und der FPGA braucht genügend Bausteine für den Oszillator, den Zähler usw. Genau dieser letzte Punkt hat mich am meisten daran gehindert ein Board zu kaufen, ich hab keine Ahnung welche "Werte" der FPGA benötigt. Bei einem AVR kann ich einfach mal ein Programm schreiben und schauen wieviel Flash, welchen CPU Takt usw. ich brauche. Für den Anfang vielleicht erstmal: Benötige ich für eine solche Aufgabe eher einen "größeren" FPGA, oder ist das ein minimal-Fall ? Bei einem AVR ist das schon eher die obere Grenze gewesen, aber bei FPGAs hab ich keine Erfahrung. Kurze Eckdaten für mein Vorhaben: 8 Kanäle mit Frequenzen bis 50kHz oder optional auch 100kHz. Laufende Änderung der Frequenz durch den AVR. Frequenzen stehen als 8 Bit werte bereit, Schrittzahlen als 16 Bit werte bereit (vom AVR). Für eine Kommunikationsart (seriell, parallel, I2C, UART usw.) zwischen FPGA und AVR hab ich mich noch nicht entschieden.
Marvin K. schrieb: > ich hab keine Ahnung welche "Werte" der FPGA benötigt. Du kannst dein komplettes FPGA Design auch jetzt schon ohne FPGA aufsetzen, simulieren und synthetisieren. Und dann siehst du ganz genau was du brauchst. Dann wählst du einen passenden FPGA. Aber egal, dass passt so ziemlich in das kleinste FPGA. Marvin K. schrieb: > Kurze Eckdaten für mein Vorhaben: > 8 Kanäle mit Frequenzen bis 50kHz oder optional auch 100kHz. > Laufende Änderung der Frequenz durch den AVR. > Frequenzen stehen als 8 Bit werte bereit, Schrittzahlen als 16 Bit werte > bereit (vom AVR). > Für eine Kommunikationsart (seriell, parallel, I2C, UART usw.) zwischen > FPGA und AVR hab ich mich noch nicht entschieden. Ich würde den AVR weglassen. UART kann man auch im FPGA machen. Und 8 Kanäle sind auch einfach, die Frage ist eger wie genau die Frequenz sein muss, also was ist die Frequenzauflösung? Wie schnell muss ein externer Takt sein der zur Erzeugung der 8 Signale verwendet wird? Wenn du auch den UART im FPGA machst dann sparst du Pins und musst dich nur um einen Baustein kümmern. Was noch fehlt: Welche Spannungspegel sollen die Ausgangssignale haben und müssen sie viel Strom liefern können? Normale FPGA IOs können grob 3.3V maximal und eher wenig Strom, so um die 10 bis 20 mA.
:
Bearbeitet durch User
Der Strom ist nicht so hoch, aber es sind 5V-24V (Eingangsbereich des Treibers). Ich habe aber sowieso vor Optokoppler oder Level-Shifter zu nutzen. Den AVR würde ich gerne behalten, der würde sich dann nämlich um die genauen Frequenzabläufe kümmern. Wie gesagt, die Frequenzen müssen sich laufend ändern können, je nach RS232 Befehl. z.B. eine Rampe von 1-20kHz dann für 10 Sekunden halten, und wieder auf 1kHz runter (nur ein Beispiel). Problematisch bei meinem aktuellen Aufbau mit nur dem AVR ist, dass keine Rechenleistung dafür übrig bleibt. Daher würde ich gerne die Freuqenzgenerierung auf einen FPGA verlagern, und nur die Frequenzen als veränderlichen Wert bereitstellen. Ich weis nicht in wie weit es möglich ist solche Abläufe in einem FPGA zu programmieren. Die Frequenzauflösung muss nicht so hoch sein, mindestens 8 Bit (also bei max. 50kHz sind das dann 196Hz Schritte), aber wenn es die Hardware hergibt, setze ich sie auf das was halt möglich ist hoch. Das Programm für den AVR hab ich ja schon, ich müsste nur alles was mit Timern und Frequenzgenerierung zu tun hat rausnehmen und die Werte über ein beliebige Schnittstelle ausgeben. Die Info das das in einen kleinen FPGA passt, reicht mir erstmal. Ich werde mich dann mal nach einem Board und der entsprechenden Software umschauen.
:
Bearbeitet durch User
> Und dann siehst du ganz genau > was du brauchst. Dann wählst du einen passenden FPGA. Was beim Anfaenger auch schon fuerchterlich schief gehen kann. Fehler in der Beschreibung koennen ganz schnell dazu fuehren, dass der Aufwand im FPGA "explodiert". > Aber egal, dass passt so ziemlich in das kleinste FPGA. Eben. Vorteil bei Intel/Altera: Die JTAG/Programmieradapter sind ausgesprochen guenstig zu bekommen und die Software laueft recht stabil und ohne Macken. Geeignet waeren, geordnet von jung nach alt: MAX10, Cyclone 2 und Cyclone 1. Jeweils in der kleinsten Groesse. Fue die aelteren Typen braucht man aber auch die aeltere Software. Solange die auf deinem Rechner laeuft, bedeutet das aber keinen weiteren Nachteil. Lass am Anfang die Finger von "Softcores" die auch deine Software laufen lassen koennten und bleib bei deinen AVRs. Marvin K. schrieb:
Marvin K. schrieb: > Problematisch bei meinem aktuellen Aufbau mit nur dem AVR ist, dass > keine Rechenleistung dafür übrig bleibt Und Du bist sicher, daß Du deren Möglichkeiten (wie das Event-System) schon ausgeschöpft hast? Aufgaben wie Signale bis 50kHz zu erzeugen oder als TCA-Event zu zählen sollten doch einen AVR noch vor keine großen Probleme stellen.
:
Bearbeitet durch User
Marvin K. schrieb: > Meine Frage ist nun, wo beginne ich am besten, wenn ich noch nie mit > einem FPGA gearbeitet hab? So wie Jens schrieb mit einem Buch. Ich habe zwei, VHDL Synthese aus dem Oldenburg Verlag für den Einstieg und das Golden Reference von Doulos für all die VHDL Details die man seltener braucht. Marvin K. schrieb: > Kurze Eckdaten für mein Vorhaben: > 8 Kanäle mit Frequenzen bis 50kHz oder optional auch 100kHz. > Laufende Änderung der Frequenz durch den AVR. > Frequenzen stehen als 8 Bit werte bereit, Schrittzahlen als 16 Bit werte > bereit (vom AVR). Schon mal die HostMot2 Firmware für die Mesa Karten angesehen? Kommt aus der LinuxCNC/MachineKit Ecke, ist in Verilog geschrieben, open source und bietet Blöcke für noch ein paar weitere typische Dinge in Maschinen. > Für eine Kommunikationsart (seriell, parallel, I2C, UART usw.) zwischen > FPGA und AVR hab ich mich noch nicht entschieden. Wenn der AVR daneben stehen bleibt, was ich persönlich nicht so schlecht finde, bietet sich SPI an. Im Lattice MachXO2 ist SPI auch schon fix eingebaut ist aber auch sonst nicht zu komplex bzw. als Einstiegsprojekt geeignet. Lattice Diamond als Entwicklungssoftware ist auch nicht viel anders als Vivado oder Quartus.
Actel (jetzt microsemi?) hat mal eine seiner CPLD/FPGA Serien für Motoransteuerung, Powercontrol vermarktet. Da war/ist wohl gleich eine kräftigerer Endstufe dabei: https://www.microcontrollertips.com/fpgas-target-multi-axis-motor-control-tasks/
Fpgakuechle K. schrieb: > Actel (jetzt microsemi?) Du wirst alt. Die heissen jetzt Microchip :-) https://www.microsemi.com/applications/motor-control
Ron T. schrieb: > Und Du bist sicher, daß Du deren Möglichkeiten (wie das Event-System) > schon ausgeschöpft hast? Aufgaben wie Signale bis 50kHz zu erzeugen oder > als TCA-Event zu zählen sollten doch einen AVR noch vor keine großen > Probleme stellen. Dachte ich auch als ich den Artikel gelesen habe. Ich finde nichts was ein uC nicht leisten könnte. Also vielleicht nicht der erwähnte. Aber der Sprung zu einem anderen uC ist halt deutlich kleiner als zu einem FPGA. Wie willst du denn die uC/FPGA Kommunikation machen? Parallel? Dann brauchst du einige Pins. Also eher Seriell... Dann kannst du den uC auch gleich ganz einsparen. Wenn es unbedingt ein FPGA sein soll würde ich mir wahrscheinlich ein Max10 oder ähnliches holen. Max1000 war Mal ein Board das es sehr günstig gab. Wenn es denn dann unbedingt ein uC sein muss ein kleiner Softcore rein alla NIOS o.ä. und der Drops ist gelutscht. Letzten Endes spielt der genaue Typ aber eher eine untergeordnete Rolle. Den die Aufgabe ist jetzt nicht so fordernd.
Für Deine Aufgabe reicht ein beliebig kleines FPGA, denn letztendlich musst Du ja nur ein Interface zum Empfang der Daten programmieren (SPI, RS232 o.ä.) und ein paar Zähler. Dein interner FPGA Takt bestimmt die Granularität deiner Ausgangsstufen. Typische Frequenzen sind 50-100 MHz, d.h. Du könntest Ausgangsseitig eine Granularität von 10 ns erreichen, was sicherlich deutlich genauer ist, als du es benötigst. Was die FPGAs angeht, würde ich eher die aktuelleren bevorzugen. Von ISE rate ich Dir beispielsweise ab. Von Xilinx kannst Du die 7er Serie nehmen, z.B. Artix 7 Von Intel/Altera würde ich auf einen Max10 oder Cyclone10 setzen Von Lattice gibt es für Deine Aufgabe den MachXO3 Von Actel/Microsemi/Microsemi rate ich für den Anfang ab, da die m.E. nur kleine Nieschen abdecken. Die Entwicklungsumgebung ist durch die FPGA Auswahl vorgegeben (Vivado, Quartus, Diamond). Neben der Entwicklungsumgebung benötigst Du eine Simulationsumgebung, denn FPGAs testet man nicht in Hardware, sondern erst einmal durch eine Simulation. Dabei simulierst Du Deine Umgebung (beispielsweise das Interface zum AVR) und kannst wesentlich tiefer und schneller sehen, was Du implementiert hast. Auch hier findest du auf den Seiten der Hersteller die zugehörige Simulationsumgebung (Vivado, Modelsim, ActiveHDL) Als Evalboards sind mir spontan das CYC1000 oder MAX1000 eingefallen. Die gibt es für schlankes Geld, man kommt gut an die GPIO (Stiftleiste) und Du brauchst keine extra Programmer etc, da diese bereits on board sind. Ansonsten kannst Du auch ohne Hardware bereits anfangen, da Du ja anfangs in der Simulationswelt lebst und erst zu einem späteren Zeitpunkt auf die Hardware wechselst. Dann fällt es Dir auch leichter, eine Größenabschätzung vorzunehmen, da Du die Funktionalität bereits weitestgehend implementiert hast. Aber wie schon geschrieben, wird für Deine Aufgabe der Platz kein Problem darstellen.
Marvin K. schrieb: > Ich entwickle gerade einen Schrittmotor-Impusgeber der Rechtecksignale > von bis zu 50kHz erzeugen und Zählen muss. Ich würde so eine Aufgabe mit einem MachXO2 erledigen, denn damit bekomme ich eine echte Single-Chip-Lösung ohne externen Oszillator und aufwändige Stromversorgung hin. Cartman schrieb: > Lass am Anfang die Finger von "Softcores" Ein Softcore ist in etwa die ineffizienteste Art, einen µC aufzubauen. Für deutlich über 95% der Fälle dürfte gelten: wenn ich eine Aufgabe mit einem Softcore lösen kann, dann kann ich das auch billiger mit einem µC von der Stange. Marvin K. schrieb: > A Nach welchen Kriterien wählt man einen FPGA aus? > Bei einem AVR sind es z.B. Taktgeschwindigkeit, IO-Pins, Timer-Anzahl > usw. Beim FPGA ist es in etwa das selbe: es muss groß genug sein, es muss schnell genug sein und genug von allem haben, was das Design braucht. Ob ein Anfänger nun ein AMD(Xilinx) oder ein Intel(Altera) oder ein Lattice FPGA nimmt, ist halb so wild, denn alle Hersteller kochen hier in etwa mit dem selben Wasser. Die Lernschritte sind die gleichen. Und dann gleich noch eines: fang ganz vorne an bei der blinkenden LED. Wenn du bis ins Detail verstanden hast, was da passiert (Stichwort: off-by-one), dann geh langsam Schritt für Schritt weiter. Du wirst (wie jeder andere vor dir) auf die Nase fallen, wenn du 2 Schritte auf einmal machst.
Gustl B. schrieb: > Ich würde aktuell etwas mit Xilinx 7er Serie nehmen. Und das Ganze nur für einen "Schrittmotor-Impulsgeber" ? Hab grad mal bei Mouser nachgesehen: Die Preise für sowas gehen dort bei etwa 16..17 € los, die andere Seite ist eher open end. Und es kommt mir durchaus etwas eigentümlich vor, wenn jemand von einem AVR gleich zu einem FPGA wechseln will. Irgend ein kleinerer 32 Bitter für (derzeit) so etwa 3 € würde das problemlos erledigen. Was also bleibt? Die Not, etwas nur mit einem FPGA realisieren zu können jedenfalls nicht. Da bleibt nur noch Hobby und Weiterbildung. Und da zählen keine betriebswirtschaftlichen Überlegungen, sondern nur, wieviel Geld man für's Hobby ausgeben darf, ohne daß die Gattin die Stirn runzelt. Ich würde da eher erstmal rein theoretisch herangehen, wenn keine wirklich sinnvolle Anwendung bzw. Bedarf vorliegt. Also von der Programmiersprache bis zur Datei, die ins Konfigurations-Flash kommt. Und dazu nachschauen, was man da als Programmiergeschirre benötigt und wieviel das kostet. Danach richtet sich die Wahl des Herstellers. Und wenn es für's Hobby ist, dann auch danach, ob man einen geeigneten Bestücker im Bekanntenkreis hat für BGA oder nicht. W.S.
Mir wäre es auch lieber es nur mit einem AVR zu lösen, aber bisher hat jeder gesagt das sei nicht machbar, oder nur unter sehr spezifischen Bedingungen. Aktuell habe ich einen ATxmega196A3, welchen würdet ihr den empfehlen, wenn es ohne FPGA sein soll ? Problematisch ist aktuell das die CPU nicht damit hinterher kommt, die Schritte zu zählen und zeitgleich Berechnungen für die Frequenzänderung auszuführen, ich lasse die CPU gerade auf 25MHz laufen (hatte keinen 32MHz Quarzt). Sobald mehr als 2 Eingänge laufen, werden zu viele Schrittimpulse erzeugt, weil die CPU die Interrupts/Impulse verpasst. Und zu den FPGAs: Ich hab hier ein Entwiklungsboard gefunden, das einige IO-Pins besitzt, und noch ein par Schalter und Lampen. https://www.reichelt.de/basys-3-artix-7-fpga-trainer-board-digil-410-183-p243337.html?&nbc=1 Es hat einen Xilinx Artix-7 FPGA. Ich denke das währe ganz gut geeignet, würde aber gerne noch eine zweite Meinung einholen. Bevor ich das kaufe, werde ich mir sowieso wie vorgeschlagen erstmal ein Buch zu VHDL zulegen. Aber wenn das wirklich mit einem AVR umsetzbar ist, würde ich mit FPGAs doch nochmal warten bis dieses Projekt abgeschlossen ist.
:
Bearbeitet durch User
Marvin K. schrieb: > Aktuell habe ich einen ATxmega196A3, welchen würdet ihr den empfehlen, > wenn es ohne FPGA sein soll ? TI Sitara mit den PRUs (z. B. auf dem Beagle Bone Black bzw. Green) Raspberry Pico mit den programmable I/O state machines Infineon (Cypress) PSoC ...
Achja, unser aller Lieblingsthema. Fuer schnelle PWM und Zaehleraufgaben, wo viel Leistung und entsprechende Betriebssicherheit eine Rolle spielt, macht ein FPGA Sinn (wir haben so eine Sache mit vernetzten billig produzierbaren Spartan6-Brettern erschlagen). Von AVR wuerde ich jetzt persoenlich absehen, v.a. weil man sich auf 8 Bittern generell gut mit nicht-atomaren effekten ins Knie schiessen kann. Die Unkenrufe gegen SoC/Softcore on-chip kann ich kaum nachvollziehen, da man mit diesen Loesungen deutlich schneller zum Ziel kommt und das ganze System inkl. Software simulierbar wird, somit einfach zu debuggen und verifizierbar. Den Core und die passende DMA-Engine sollte man sich allerding gut aussuchen, da gebe ich aber keine Tips mehr zu ab :-) Ansonsten: STM32 schon evaluiert?
Strubi schrieb: > Die Unkenrufe gegen SoC/Softcore on-chip kann ich kaum nachvollziehen, > da man mit diesen Loesungen deutlich schneller zum Ziel kommt und das > ganze System inkl. Software simulierbar wird, somit einfach zu debuggen > und verifizierbar. > Den Core und die passende DMA-Engine sollte man sich allerding gut > aussuchen, da gebe ich aber keine Tips mehr zu ab :-) Kann ich zwar nachvollziehen, aber nicht für einen Anfänger. Da gibt es zu viele Fallstricke. Ich kenne die Randbedingungen nicht, aber es hört sich stark danach an, dass ein potenterer Controller das Problem alleine lösen kann. STM32 wurde schon genannt, ich würde nach einem Cortex M4 schauen.
Christoph Z. schrieb: > Fpgakuechle K. schrieb: >> Actel (jetzt microsemi?) > > Du wirst alt. Die heissen jetzt Microchip :-) > https://www.microsemi.com/applications/motor-control Ja, das liegt wohl in der Familie, meine Grosseltern haben sogar Tausend Jahre Reich komplett überlebt ;-) -- Es gibt noch einige Möglichkeiten mehr, eine PWM zu erzeugen, der Klassiker ist wohl Rechteck mit nachgeschalteten Schmitt-Trigger: https://www.strippenstrolch.de/1-3-17-opv-als-PWM-Generator.html Die Schaltung der Schaltschwelle könnte man per Digital Poti machen. der 555 kann auch seinen beitrag leisten: https://www.elektronik-kompendium.de/public/schaerer/pwm555.htm oder klassisches TTL-Grab Statt FPGA geht auch CPLD quasi als Companion, der Controller muß halt nicht alles alleine machen, es genügt wenn er die eigentlichen Generatoren controlliert. Natürlich gibt es auch dedizierte PWM-Chips. Oder man nimmt mehrere controller, die man zentral synchronisiert. Damit vereinfacht sich das Task-scheduling pro mikrocontroller. Letzlich steht vor dem Coding der Systementwurf - welche parallele Prozesse müssen laufen, wohin wird kommuniziert, welche fehlzustände sind unbedingt aufzulösen. Wenn das Konzept steht, ist die konkrete Implementierung schon fast zwangsläufig.
http://land-boards.com/blwiki/index.php?title=Cyclone_II_EP2C5_Mini_Dev_Board Schau mal diese Boards an.
Es gibt mittlerweile gute offene toolchains für lattice und xilinx. Die würde ich jederzeit der aufgeblasenen herstellersoftware vorziehen. f4pga.org
Nimm doch einen RasPi Pico Prozessor. Der hat 2 CPUs und dazu noch 8 programmierbare Pin State-Machines. Kostet fast nichts und ist gut erhältlich. Wenn es dann doch ein FPGA sein soll, stellt sich die Frage ob du später ein eigenen Print machen willst und den FPGA Chip benötigst. Dann wirst du sehen, dass weder aktuelle Xilinx noch Intel noch Lattice FPGAs mit genügend Pins lieferbar sind. Eine Alternative ist Efinix, deren Chip man bekommt, und es gibt das günstiges Xyloni Demo/Entwicklungsboard. Ausserdem würde ich jedem Anfänger dazu raten mit Verilog anzufangen, nicht mit VHDL, das ist so viel einfacher und logischer. Andi
Andi schrieb: > Wenn es dann doch ein FPGA sein soll aus Interesse, mit der Absicht später mehr damit zu machen! Aber sicher nicht wegen dieser Anwendung. Wenn das zuviel für einen modernen AVR sein sollte (was ich nicht glaube) ist es allemal besser, sich statt in FPGAs in die ARM-Technik einzuarbeiten. Damit ist man zukünftig wesentlich flexibler.
Lust L. schrieb: > ist es allemal besser, sich statt in > FPGAs in die ARM-Technik einzuarbeiten. Damit ist man zukünftig > wesentlich flexibler. Nope, controller durch einen anderen conroller ersetzen bringt kaum was an flexibilität. Flexibel wird man mit der Anzahl an beherrschten Interface/Peripherals. Und insbesonders wenn man diese Peripherals auch selbst entwerfen/adaptieren kann. aber manche scheitern schon daran eine header-datei selbsr anzupassen, wenn ein neuer Baustein ein paar controlbits mehr mitbringt.
Ein STM32F407 hat dafür auch genug Power, incl. Rampen berechnen im Interrupt und Display ansteuern:https://youtu.be/poZjMwRAcH8 Ansonsten macht grbl oder eine 3D-Drucker Hardware doch genau so was, Befehle über die serielle (beim Smoothieboard auch per Ethernet) empfangen und mehrere Achsen steuern, einfach per G-Code.
Marvin K. schrieb: > Timer-Anzahl usw. hm, wenn jemand nach der Zahl der Timer in FPGAs fragt, dann kann ich nur datzu raten, sich mal ganz grundsätzlich mit Digitaltechnik und programmierbarer Lokig auseinander zusetzen. Schon allein das Lesen des WIKI-Artikels in den ich und anderen Zeit reingesteckt haben, erledigt vorne weg 3 hier gemachte Annahmen in diesem thread über FPGAs und was man damit macht und wie ... Cartman schrieb: > orteil bei Intel/Altera: Die JTAG/Programmieradapter sind > ausgesprochen guenstig zu bekommen Die Chinaduplikate beim XI kosten auch nur 15,- :-)
:
Bearbeitet durch User
Marvin K. schrieb: > Aber wenn das wirklich mit einem AVR umsetzbar ist, würde ich mit FPGAs > doch nochmal warten bis dieses Projekt abgeschlossen ist. Also für dich sieht die Alternative so aus: entweder AVR oder wenn das nicht reicht, dann ein FPGA. Hmm... bei dieser Perspektive hast du noch so einiges an Lernstoff vor dir. Wenn es dir jedoch eher um das Erlernen des Umganges mit programmierbarer Logik geht, dann fang lieber ohne dein o.g. Projekt mit dem Lernen an. Du kannst dir das Leben etwas leichter (und billiger) machen, wenn du für's Erste ein paar CPLD's benutzt. Vom Programmieren her - egal ob mit Verilog oder VHDL - ist das gleich, aber die CPLD's haben zumeist den Konfigurationsspeicher bereits mit drinnen auf dem Chip und das erspart dir die Hürde, einen seriellen Flash richtig an ein FPGA zu basteln oder dir ein teures Eval-Board zu kaufen und dich dann an allem zu orientieren, was da sonst noch auf dem Eval-Board drauf ist. Bei der Gelegenheit kommt mir ein Bastel-Vorschlag: den ULA aus dem ZX-Spectrum durch ein CPLD ersetzen und damit einen ZX Spectrum basteln. Da kann man dann deutlich sehen, ob das klappt und es hat dann sogar noch einen nostalgischen Spiele-Nutzen. W.S.
Boris schrieb: > Es gibt mittlerweile gute offene toolchains für lattice und xilinx. Die > würde ich jederzeit der aufgeblasenen herstellersoftware vorziehen. > > f4pga.org Ahja, symbiflow is now f4fpga. Aendert nichts daran, dass das immer noch etwas mehr verspricht, als es ist. Nennen sollte man eigentlich yosys, was ein beachtlich effektives Werkzeug geworden ist. Nichtsdestotrotz ist es eigentlich erst gerade seit einigen Wochen (offiziell) mit den Memory-Inference-Reparaturen vernuenftig fuer neuere Architekturen (ECP5) nutzbar. Zum Lernen ist es nett, da man in die Synthese 'reingucken' kann. Aber gegen die timing-optimierenden Mapper von Synplify kommt es nicht an, d.h. fuer ernstes High-Speed muss man haendisch optimieren, was man mit klassischem VHDL schon mal vergessen kann.
Nimm doch einen Parallax :-) Oder wie hieß die andere Firma mit dem X welche so "spezial" uC anbietet?
Wenn ich genaues Timing brauche, dann baue ich öfter FPGAs ein. Also eine normale kleine CPU (meist ein kleiner Arm), und dazu ein passendes FPGA. Beide kommunizieren über SPI, das FPGA bekommt seine 'Anweisungen' und regelt dann alleine weiter. Bei den FPGAs reicht dann oft eine kleines, mit wenig LUTs (<5000). Manchmal ist ein Spartan schon zu gross, dann wirds ein ICE von Lattice. Mit dieser Trennung bin ich ganz gut gefahren. Wenn man weiss, was man darin regeln möchte, kann man den FPGA-Code synthetisieren. Dann bekommt man mit wieviele LUTs benötigt werden. Danach wird eine FPGA-Version gewählt.
No Y. schrieb: > Nimm doch einen Parallax :-) Du meinst einen Propeller. Den gibt es ja netterweise als open source in Verilog. > Oder wie hieß die andere Firma mit dem X welche so "spezial" uC > anbietet? Meinst du XMOS? Sind aber weniger bekannt für Motoren und PWM sondern mehr für Audio, I2S, Ethernet AVB,...
Ne es ging darum, dass er ggf. auf den FPGA verzichten kann. Mit einem Propeller oder mit einem XMOS uC (hier ging es darum, dass die ja auch uC mit vielen Cores haben) kann er für jeden seiner Kanäle einen eigenen Core "exklusiv" abstellen der sich nur um den einen Kanal kümmert.
Die ganzen Vorbehalte gegenüber Softcores kann ich nicht so ganz nachvollziehen. Wenn man sich an die durch das Entwurfswerkzeug der Wahl empfohlenen Cores hält, dann kann man diese recht einfach integrieren. In der Xilinx-Vivado-Welt wäre das dementsprechend ein Microblaze oder ein ein Microblaze MCS. Wenn man sich dann auch noch das Gerüst für den benötigten AXI-Peripherieblock mit dem entsprechenden Wizard generieren lässt, dann hat man schon einmal eine sehr ordentliche Grundlage. Mein Tipp: den generierten Block nicht als separaten IP-Block verwenden, sondern die generierten Quellen als sog. HDL-Module direkt im Blockdesign einbinden. Dann kann nämlich alles in einem zusammenhängenden Projekt bearbeiten und erspart sich den Aufwand mit separaten IP-Projekten. Das Debugging eines Microblaze funktioniert auch ganz passabel, d.h. die gemeinsame Nutzung einer JTAG-Verbindung für das Laden des FPGA-Bitstreams, das Hardware-Debugging mittels ILA und Software-Debugging mittels Vitis/GDB.
Schau dir doch mal die ICEbreaker FPGA's an, ich denke diese sind hervorragend für den Einstieg geeignet. Zudem gibt es gute Open-Source Tools dafür, was im VLSI Bereich eher selten ist. (https://1bitsquared.com/products/icebreaker)
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.