[Rumgucker]

Programmierung geht problemlos. Nun konnte ich auch endlich die Verdrahtung (Schalter, LEDs, Ausgänge) per Programm prüfen lassen. Fehlerfreie Arbeit

Doku ist auch in Arbeit. Es nähert sich dem Abschluss.

Dann muss ich aber noch mal ein wenig mit Xilinx rumdaddeln. Hab schon wieder viel vergessen (oder verdrängt? )

[christianw.]

Großartig.

Warum keinen Tiefsetzsteller für den 7805? Gibts fürn Euro, kann ich dir auch schicken für umme.

[Rumgucker]

Ach nö. Ist doch schon alles zugeschraubt und läuft tadellos.

Einzig die 5 Meter lange Parallelleitung macht ab und an mal Fehlprogrammierungen. Beosnders bei längeren Programmierfiles. War ja klar, dass das nicht so ganz hinhauen kann. Geht aber ausreichend, dass es mich nicht nervt.

Vielleicht muss aber doch noch mal irgendwann der Laborrechner das Dingens konfigurieren. Dazu müsste ich aber noch wesentlich besser - sozusagen im Schlaf - mit Xilinx umgehen können.

[Rumgucker]

So... nun will ich mal was Sinnvolles mit der Kiste anstellen. Immer nur Lämpchen laufen lassen und Taster abfragen ist ja nicht so prickelnd.

Zur Zeit brauche ich gerade keinen Multikanal-Patterngenerator, woran ich eigentlich bei der Erstellung immer gedacht hatte.

Der große Unterschied eines CPLDs im Vergleich zu einem Controller ist die Möglichkeit, zeitkontinuierlich Daten zu verarbeiten. Wir haben zwar Taktgeneratoren - wir benötigen sie aber nicht.

Mit einem CPLD könnte man also die gesamte digitale Steuerung eines SNTs oder D-Amps durchführen. Inkl. Brückensignale, Totzeiten, Pulsbreitenbegrenzung und haste-nicht-gesehen. Im Vergleich zu den Möglichkeiten eines CPLDs sind unsere bisherigen PWM-Modulatoren sehr primitiv.

Mit einem CPLD könnte man Puls-für-Puls die Ströme und die Spannungen in der Endstufe überwachen. Und mit dem von mir verwendeten Pollin-Board könnte man sogar Ereignisse kommunizieren, denn es hat ein kleines Userinterface, viel RAM und eine serielle Schnittstelle.

Auf einem festen Takt basierende Projekte sind also nicht die Domäne des CPLDs. CPLDs sind "anders". Und dieses "Anderssein" muss genutzt werden.

[woody]

Joa... klingt doch vielversprechend
Aber ich glaube du brauchst gute und schnelle AD-Wandler dafür...

[Rumgucker]

...und was ist "dafür"?

Schwebt Dir ein konkretes Projekt vor?

[woody]

Zitat:Original geschrieben von Rumgucker


Mit einem CPLD könnte man Puls-für-Puls die Ströme und die Spannungen in der Endstufe überwachen. Und mit dem von mir verwendeten Pollin-Board könnte man sogar Ereignisse kommunizieren, denn es hat ein kleines Userinterface, viel RAM und eine serielle Schnittstelle.

[Rumgucker]

Das war ein Beispiel.

Aber ich hab zur Zeit keine Endstufe in Arbeit.

[woody]

hab ich ja auch nicht behauptet

[Rumgucker]

Zitat:Original geschrieben von christianw.
Warum keinen Tiefsetzsteller für den 7805? Gibts fürn Euro, kann ich dir auch schicken für umme.

Ich guck mir gerade SR7805 an. Die bringen ja nur 500mA. Ich brauch 540mA...

Aber Danke für Dein Angebot...

BTW: ich konnte die Temperatur des 7805 auf 60°C drücken (T_amb=25°C) und der Trafo bleibt auch kühler. Ich hab einfach vor den Trafo primär zwei 33V Suppressoren anti-in-Reihe geschaltet. Das musste ich tun, weil mein Ferroresonanz-Stabi mit bis zu 240V daherkommt und der Trafo schon deutlich bei 230V in die Sättigung kommt (der kam noch aus Zeiten, wo man 220V hatte...)

Dazu hab ich dann noch Lüftungslöcher ins Gehäuse gemacht... so richtig mit Kaminwirkung.

Die Hitze kommt ja auch nur, wenn das Tablet nachlädt. Ansonsten stirbt der 7805 fast den Kältetod.

[Rumgucker]

Die Kaminwirkung ist gut gelungen. Sowohl Trafo als auch 7805 erreichen beide nur knapp 40°C, also +15C über Luft. Bei voller Stromaufnahme. Bin restlos glücklich.

[Rumgucker]

Hier gehts weiter. Ein IMHO ideales Projekt für den Graukasten-CPLD:

http://include.php?path=forum/showthread...entries=71

[Rumgucker]

Ich denke, dass 'C' unverzichtbar in der Softwareentwicklung ist. Und ich denke, dass 'VHDL' unverzichtbar in der Hardwareentwicklung ist.

Die Funktionsweise eines doppeleurokartengroßen TTL-Chipgrabes in wenigen Zeilen Code.Das ist schon bestechend.

Ich finde es nur schade, dass man sich nicht gleich vom Start weg an die 'C'-Syntax gehalten hat. Denn die Übergänge zwischen Soft- und Hardware-Programmierung könnten dann wesentlich fließender gestaltet werden. Besonders die objektorientierte Programmierung hätte grandios zur Hardware gepasst.

Aber damit muss man nun wohl leben....

[woody]

Und wie sollte OOP in Hardware zur Laufzeit umgesetzt werden?

[Rumgucker]

OOP hat mehrere Eigenschaften. Wenn nicht alle optimal unterstützt werden, so ist das nicht schlimm.Meine ersten OOP-Berührungen waren reine Precompiler, die einen ganz normalen C-Code produzierten. 30 Jahre her. Etwas vor "Smalltalk".

[Rumgucker]

Xilinx-ISE und ich haben eben große Verbrüderung gefeiert. Wir mögen uns mehr und mehr

Mir ist es gelungen, ohne große Tricks das netzbekannte und lästige Wegoptimieren von Laufzeitsystemen zu unterbinden, die für Xilinx "unlogisch" erscheinen.

Direkt und selektiv gesteuert aus dem Schaltplan.

Die Fachleute empfehlen für solche Dinge die Anwendung von "KEEP"-Attributen, was aber eher nicht zu funktionieren scheint und auch im Schaltbild IMHO nicht geht.

Morgen simulier ich meine Lösung. Hoffentlich kommt dann nicht das böse Erwachen....

[Rumgucker]

Teilsieg!

Ich kanns ohne Wegoptimierung synthetisieren und sogar ein wenig simulieren. Nur beim ersten Pegelsprung wird Xilinx "ISim" dann hysterisch....

Aber das löse ich auch noch!