Hallo, ich stehe vor einem Problem: Es sollen zwei Eingänge (TTL) mit verschiedenen, per GPIB Befehlen kombenierbaren Logiken abgefragt und weiterbehandelt werden. An 1 bis 8 Ausgängen sollen dann verschiedene Aktionen stattfinden. Beispiel: wenn IN1 steigende Flanke und IN2 = LO, dann OUT1 100µS warten (LO), 500µS HI, 300µS warten (LO), fertig. wenn IN2 fallende Flanke, OUT 3 100µS(LO),300µS(HI),10µS(LO),fertig wenn IN1 und/oder IN2 steigende Flanke, OUT5 1000mS HI,1000mS(LO) usw. Das muss allerdings alles paralell laufen! Ich habe EINE abfrage und das Timing bereits mit einem ATMEGA32 hinbekommen, aber in der Abarbeitungszeit kann er ja nicht gleichzeitig andere Routinen erledigen. Daher die Frage, würde das in einem PLD funktionieren? (ich denkke schon) und wie könnte man dem PLD die gewünschte config der delays/ontimes/offtimes von einem µC "übergeben"? Ich habe nicht sooo viel Erfahrungen mit VHDL, habe bislang erfolgreich Adressdecoder und Rom Mapper für einen 80er Jahre 8 Bit Rechner geschrieben. Vielleicht gibt es ja auch bereits einen programmierbaren Chip der sowas könnte? Wäre dankbar für Tips. Gruß, Wolfram.
:
Bearbeitet durch User
Wolfram F. schrieb: > Ich habe EINE abfrage und das Timing bereits mit einem ATMEGA32 > hinbekommen, aber in der Abarbeitungszeit kann er ja nicht gleichzeitig > andere Routinen erledigen. Kommt drauf an, mit welcher Granularität, mit welchem Jitter, er das machen muss. Müssen das z.B. genau 10,000 µs (mit kleinem 's', sonst wäre das ein Leitwert mit "milli Siemens" und "mikro Siemens"(*)) sein, oder dürfen das auch mal 9 oder 11 µs sein? Und natürlich darf in dem Code in keinster Weise irgendein wait() oder sleep() vorkommen. > Vielleicht gibt es ja auch bereits einen programmierbaren Chip der sowas > könnte? Kommt wie gesagt ein wenig auf den erlaubten Jitter an... > Daher die Frage, würde das in einem PLD funktionieren? (ich denkke > schon) Normalerweise dürfte das sogar in ein geräumig mit Flipflops ausgestattetes CPLD passen, denn die nötigen Zähler fressen die dort rar gesäten Makrozellen weg wie nichts. Allerdings gibt es nur noch wenige, die 5V TTL können. Xilinx hat schon mal nichts mehr. Und die alten Atmel-Microchip-CPLDs tun sich mit der alten Toolchain schwer. Insofern wäre ein kleines FPGA vom Schlage MachXO mit seinem internen Oszillator vermutlich genau das, was hier gebraucht wird... ;-) > wenn IN2 fallende Flanke, OUT 3 100µS(LO),300µS(HI),10µS(LO),fertig Wenn der OUT 3 sowieso normalerweise Low ist, warum musst du dann zum Schluss noch 10µs warten? (*) https://de.wikipedia.org/wiki/Siemens_(Einheit)
:
Bearbeitet durch Moderator
die Genauigkeit darf ca. +/- 2.5µs betragen. die 3 Zeiten delay,ontime,offtime sollen verzögerung bis zum einschalten, einschaltdauer und inaktivität sein, also in den 10µS offtime sollen die Eingänge ignoriert werden.
Wolfram F. schrieb: > die Genauigkeit darf ca. +/- 2.5µs betragen. Auch bei den ms-Zeiten? Oder dürfen die Zeiten prozentual um 25% abweichen? > die 3 Zeiten delay,ontime,offtime sollen verzögerung bis zum > einschalten, > einschaltdauer und inaktivität sein, also in den 10µS offtime sollen die > Eingänge ignoriert werden. Wenn also In2 in der "Totzeit" eine fallende Flanke hat, soll mit dem Out3 bis zur nächsten fallenden Flanke vom In2 nichts passieren?
Lothar M. schrieb: >> die Genauigkeit darf ca. +/- 2.5µs betragen. > Auch bei den ms-Zeiten? Oder dürfen die Zeiten prozentual um 25% > abweichen? die sollten im 5µs Bereich bleiben. > >> die 3 Zeiten delay,ontime,offtime sollen verzögerung bis zum >> einschalten, >> einschaltdauer und inaktivität sein, also in den 10µS offtime sollen die >> Eingänge ignoriert werden. > Wenn also In2 in der "Totzeit" eine fallende Flanke hat, soll mit dem > Out3 bis zur nächsten fallenden Flanke vom In2 nichts passieren? Genau.
Wolfram F. schrieb: > Genau. Dann sieht das nach einer netten kleinen Fingerübung für einen Lattice MachXO2, oder einer spannenden Aufgabe für einen AVR aus. Ich würde selbstredend den MachXO2 nehmen. Da weiß ich vorher schon, dass es hinterher garantiert auf Bruchteile von µs genau realisierbar ist und laufen wird. Und wenn einer der 8 Ausgangskanäle das tut, was er soll, dann sind die restlichen 7 ein kleiner Klacks, denn dann muss die Komponente "Verzögerungsautomat mit 3 Zeiten" einfach 8 mal instantiiert werden und fertig... ;-)
aber wie kann man die zeiten und die Kombinationen, die ja frei wählbar sein sollen, vom µC an das FPGA/PLD übergeben? Die angegebenen Zeiten sind ja nur Beispiele, und die verknüpfungen ebenfalls. Die können auch mehrfach sein...
:
Bearbeitet durch User
Wolfram F. schrieb: > aber wie kann man die zeiten und die Kombinationen, die ja frei wählbar > sein sollen, vom µC an das FPGA/PLD übergeben? Dafür würde ich eine SPI Schnittstelle nehmen. Und durch diese Forderung "Speichern von Vergleichswerten" ist jetzt zwingend ein FPGA nötig, denn CPLD haben nicht genügend Flipflops dafür. Wenn dann z.B. eine Granularität von 1µs genommen wird, kann mit 3x 24 Bit Registern jede der drei Zeiten von 1µs bis zu 16777215µs, also fast 17s eingestellt werden. > Die angegebenen Zeiten sind ja nur Beispiele, und die verknüpfungen > ebenfalls. Die können auch mehrfach sein... Dann muss die In1+2 Auswertung eben auch per Flags konfigurierbar gemacht werden. Dafür wäre dann ein Konfigurationsbyte nötig, das dann für jeden Kanal z.B. so aussieht:
1 | Register "trigger" |
2 | Bit 7 6 5 4 3 2 1 0 |
3 | In2....... In1....... |
4 | | | | '-> 1 = In1 beachten / 0 = In1 nicht auswerten |
5 | wie In1 | | '----> 1 = Flanke / 0 = Pegel |
6 | | '-------> 1 = High,Rise / 0 = Low,Fall |
7 | '----------> Reserve |
Für die 3 Fälle aus dem Eröffnungspost sieht die Konfiguration der Kanäle dann so aus: Wolfram F. schrieb: > wenn IN1 steigende Flanke und IN2 = LO, dann OUT1 100µS warten (LO), > 500µS HI, 300µS warten (LO), fertig. trigger = 0001 0111 bin = 0x17 delay = 100 dez ontime = 500 dez offtime = 300 dez > wenn IN2 fallende Flanke, OUT 3 100µS(LO),300µS(HI),10µS(LO),fertig trigger = 0011 0000 bin = 0x30 delay = 100 dez ontime = 300 dez offtime = 10 dez > wenn IN1 und/oder IN2 steigende Flanke, OUT5 1000mS HI,1000mS(LO) trigger = 0111 0111 bin = 0x77 delay = 1000000 dez ontime = 1000000 dez offtime = 0 dez Das wäre dann die zweite Fingerübung... ? Insgesamt müssen dann per SPI also 8x 10 Bytes (pro Ausgang 3x3 Bytes für die Zeiten plus 1 Byte für die Triggerbedingung) zur Konfiguration übertragen werden. Gleichzeitig könnten dann noch "kostenlos", weil SPI ja zeitgleich bidirektional ist, irgendwelche internen Zustände des FPGAs zurückgemeldet werden. Wolfram F. schrieb: > wenn IN1 und/oder IN2 steigende Flanke Eine gleichzeitige Flanke gibt es in realer Hardware nicht, deshalb ist das "und" hier unnötig (bzw. eigentlich unmöglich).
:
Bearbeitet durch Moderator
danke dir, das sind gute denkanstösse! Werde da mal ein paar Tage mir das durch den Kopf gehen lassen. Cool wäre noch, wenn der µC dann auch gleich mit ins FPGA kommt, aber dafür reichen meine Kenntnisse lange nicht aus.
Wolfram F. schrieb: > Cool wäre noch, wenn der µC dann auch gleich mit ins FPGA kommt Dann wird halt das FPGA sehr groß und sehr teuer. Ein Softcore-µC im FPGA ist mit das Ineffizienteste, was man machen kann. Wenn das FPGA "sowieso" drauf und "viel zu groß" ist, dann kann man das schon machen. Aber man muss dann eben die Analoggeschichten, die so ein µC mitbringt (ADC, Oszillator, Brownout, Komparator...) extern an den Prozessor im FPGA anflanschen. Bisher war die billigste Lösung (auch in Hinsicht auf Wartbarkeit und Softwaredesign) noch immer: optimaler µC + kleinstmögliches FGPA.
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.