Forum: FPGA, VHDL & Co. Unterschiedlicher Programmier-Datenstrom beim FPGA


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von VHDL (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,
ich bin absoluter Neuling im Bereich der FPGA Programmierung / 
Beschreibung.

Eine Sache hat mich jedoch gerade neugierig gemacht. Ein Arbeitskollege 
hat erzählt, dass die Generierung eines Datenstroms von zwei identischen 
VHDL Beschreibungen immer unterschiedlich aussieht. D.h. es gibt keinen 
Determinismus für den Datenstrom?! Kann mir das jemand erklären? Warum 
wird der Datenstrom nicht deterministisch erzeugt? Welche Faktoren sind 
ausschlaggebend für die Erstellung des Datenstroms?

Vielen Dank :)

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
VHDL schrieb im Beitrag #6079731:
> Ein Arbeitskollege hat erzählt, dass die Generierung eines Datenstroms
> von zwei identischen VHDL Beschreibungen immer unterschiedlich aussieht.
Definiere "Datenstrom".


BTW: mit "immer" und "nie" bin ich aus Erfahrung arg vorsichtig. Wenn 
das auch nur ein einziges Mal nicht stimmt, dann stehe ich nämlich 
schön blöd da.. ;-)

von Vancouver (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Einige Schritte bei der Erstellung des Bitfiles (z.B. das Place&Route) 
sind Heuristiken. Das bedeutet z.B. sie beginnen mit einer zufälligen 
Anfangsplatzierung und versuchen diese dann iterativ zu verbessern, bis 
bestimmte Constraints erfüllt sind.
Dabei können abhängig vom zufalligen Anfangsplacement bei verschiedenen 
Druchläufen unterschiedliche (aber gleich gute) Ergebnisse herauskommen. 
Das ist bei jeder Art von komplexen Optimierungsproblemen so, z.B. 
liefern auch PCB-Autorouter gerne mal bei jedem Durchlauf ein anderes 
Ergebnis.

von Manche lernens nie (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
VHDL schrieb im Beitrag #6079731:
> Warum
> wird der Datenstrom nicht deterministisch erzeugt?


Schlag nach:
"Traveling sales man"
"Simulated anealing"
"Place & Route"

sonst stirbst Du dumm.

von Markus F. (mfro)


Bewertung
0 lesenswert
nicht lesenswert
Durch Vorgabe eines Seeds kann man durchaus dafür sorgen, daß zweimal 
hintereinander dasselbe rauskommt.

von VHDL (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Manche lernens nie schrieb:
> sonst stirbst Du dumm.

Du solltest nicht von dir auf andere schließen.

von Manche lernens nie (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
VHDL schrieb im Beitrag #6079762:

> Du solltest nicht von dir auf andere schließen.

Mach ich nicht, weil dann müsste ich alle für schlau halten; schlau 
durch eigene Recherche und Denkvermögen.

von Christoph Z. (christophz)


Bewertung
0 lesenswert
nicht lesenswert
Markus F. schrieb:
> Durch Vorgabe eines Seeds kann man durchaus dafür sorgen, daß zweimal
> hintereinander dasselbe rauskommt.

Kann ich bestätigen für Lattice. Zwei P&R Durchläufe ohne Änderung des 
Codes/Constraints/Seeds/Tool Version liefern ein identisches Bitfile.

Entsprechend kann/soll man auch am Seed rumdrehen, wenn das Timing nur 
knapp verfehlt wird.

Da ich nicht mehr mit Lattice arbeite sollte ich diesen Versuch bei 
Gelegenheit mal wiederholen.

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
VHDL schrieb im Beitrag #6079731:
> Eine Sache hat mich jedoch gerade neugierig gemacht. Ein Arbeitskollege
> hat erzählt, dass die Generierung eines Datenstroms von zwei identischen
> VHDL Beschreibungen immer unterschiedlich aussieht. D.h. es gibt keinen
> Determinismus für den Datenstrom?! Kann mir das jemand erklären? Warum
> wird der Datenstrom nicht deterministisch erzeugt? Welche Faktoren sind
> ausschlaggebend für die Erstellung des Datenstroms?

Das Gegenteil ist der Fall, die Erzeugung des Bitfiles (Datenstroms) ist 
sogar hochgradig deterministisch! Das ist sogar aeusserst wichtig, da 
komplexe Designs auch komplexe CI Prozesse durchlaufen. Wenn dieser 
Vorgang nicht deterministisch waere, dann wuerde man nie ans Ziel 
kommen.

Was jedoch passieren kann, ist dass schon kleine Aenderungen der HDL 
Files, grosse Auswirkungen am Bitfile verursachen koennen (da gibt es 
dann so komisch Faelle wie: ich hab doch nur das Signal umbenannt und 
nun passen die Timings nicht mehr). Z.B. bei Xilinx ist das mit ISE noch 
der Fall, da die einzelnen Slices erstmal pseudo-zufaellig (zumindest 
lokal) verteilt und geroutet werden und anschliessend ueberprueft wird 
ob die Timing Contraints eingehalten wurden.

Ist das nicht der Fall, erhaelt man entsprechende Fehlermeldung und hat 
die Chance eine neue zufaellige Platzierung der Elemente vorzunehmen in 
der Hoffnung dass die Timings beim naechsten Durchgang hinhauen. Der 
Seed mit dem der Pseudozufall erzeugt wird nennt sich im Falle von 
Xilinx ISE "Placer Cost Table".

Kleiner Hinweis: Vivado verfolgt diesen Ansatz nicht mehr, da mit 
groesseren FPGAs dieser Ansatz immer unperformanter (bzgl. P&R Zeiten) 
wird.

Dein Bitstream haengt demnach von drei Dingen ab:

1.) Der HDL an sich.
2.) Dem Seed (Placer Cost Table).
3.) Den entsprechenden Workflow Settings.

Sind diese drei Dinge mit jedem Durchlauf identisch, kommt auch immer 
ein identische sBitfile heraus. Eine Ausnahme gibt es jedoch - waere 
auch zu schoen wenn nicht. ;-)

Du hast z.B. bei Xilinx die Chance nach der Erzeugung des Bitfiles 
nachtraeglich Daten zu manipuleiren, z.B. den Inhalt von Block-RAM 
Elementen oder dem User Access Speicherbereich. Mit beidem hast du 
natuerlich via Post-Processing die Moeglichkeit die Bitstreams zu 
manipulieren.

: Bearbeitet durch User
von Manche lernens nie (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Tobias B. schrieb:

> Dein Bitstream haengt demnach von drei Dingen ab:
nein, nicht nur
>
> 1.) Der HDL an sich.
> 2.) Dem Seed (Placer Cost Table).
> 3.) Den entsprechenden Workflow Settings.

es fehlen:
   ) timing constraints
   ) ziel-Typ (Fpga-familie, Speedgrad, pining)
   ) gespeicherte Ergebnisse vorheriger Läufe (incremental compile)

Wobei unterschiedlicher Bitsream nicht unbedingt geändertes 
Designverhalten bedeudet. Wenn bspw. eine Periode von 10ns constrained 
ist, ist es wurscht, ob die realisierte Route zwischen 2 FF, 2,3,4 oder 
9 ns benötigt.Gelegentlich werden auch Pfade auf "dont core 
constrained", da ist die Signallaufzeit völlig uninteressant.

Und das ist auch bei normalen Programmiersprachen so, das gleicher Code 
unterschiedlich umgesetzt wird, insbesonders wenn die Befehlsreihenfolge 
wurscht ist. Manche CPU's machen sich das zu nutze, in dem sie gleichen 
Code zur Laufzeit unterschiedlich abarbeiten ("Out-of-order-Execution"
dt. "Ohne-Befehl-Erschiessung") ;-)

von Weltbester FPGA-Pongo (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Tobias B. schrieb:
> Du hast z.B. bei Xilinx die Chance nach der Erzeugung des Bitfiles
> nachtraeglich Daten zu manipuleiren,

Zu welchem Zweck?

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Weltbester FPGA-Pongo schrieb im Beitrag #6098393:
> Zu welchem Zweck?

Um z.B. eine Revision Nummer oder das Datum ins Bitfile zu packen.

von Tobias N. (technick2)


Bewertung
0 lesenswert
nicht lesenswert
Tobias B. schrieb:
> Weltbester FPGA-Pongo schrieb im Beitrag #6098393:
>> Zu welchem Zweck?
>
> Um z.B. eine Revision Nummer oder das Datum ins Bitfile zu packen.

Diese Idee habe ich hier doch schon gelesen:
Beitrag "Vivado Version im BIT file checken und ändern - Checksumproblem?"

... doch erschließt sich mir nicht der Sinn. Das geht doch auch vor dem 
Auslösen des Bit-File-Erstellens?

Besonders im hiesigen Fall.

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Tobias N. schrieb:
> ... doch erschließt sich mir nicht der Sinn. Das geht doch auch vor dem
> Auslösen des Bit-File-Erstellens?

Nicht unbedingt, z.B. wenn du die SVN Revision Nummer oder den Git Hash 
ins Bitfile schreiben moechtest um Code und Bitfile eindeutig 
zuzuordnen. Da hast du ein klassisches Henne - Ei Problem.

Ebenso das Datum und Uhrzeit, gerade wenn die mal ein groesseres Design 
hast, das auch mal ueber Nacht durchlaeuft, ist das ganz praktisch.

von chris (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Vielleicht beinhaltet der Datenstrom einen Kopierschutz, der auch eine 
Zufallskomponente enthält.

von Weltbester FPGA-Pongo (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Tobias B. schrieb:
> Nicht unbedingt, z.B. wenn du die SVN Revision Nummer oder den Git Hash
> ins Bitfile schreiben moechtest um Code und Bitfile eindeutig
> zuzuordnen. Da hast du ein klassisches Henne - Ei Problem.
Wozu muss eine SVN-Nummer in das Bit-File? Die SVN Nummer wird vergeben, 
wenn man eincheckt und landet im Source Code an den vordefinierten 
Plätzen. Genauso kann man ein BIT in SVN hosten.

Niemend muss die SNV Nummer durch die Design-Files managen. Das 
Aufsuchen der richtigen RePo Version geschiet ja im Recherchefall nicht 
dadurch, dass man alle BitFiles durchgeht und dort die Nummer findet, 
sondern man sucht einmal im ReRo mit einem Schritt alle zugehörigen 
Files.

Tobias B. schrieb:
> Ebenso das Datum und Uhrzeit, gerade wenn die mal ein groesseres Design
> hast, das auch mal ueber Nacht durchlaeuft, ist das ganz praktisch.
Das Bitfile wird zuletzt, meistens binnen <Min erzeugt und geschrieben. 
D.h. Erzeugung und Schreiben liegen nicht weit auseinander.

Es ist also nicht nötigt, das in der anderen Richtung auch noch zu 
verzeigern.

Das ist sogar ein Problem:

Die einfachverzeigerung  verträgt sich bestens mit den 2stufigen 
Vorgehensweise:

1) Sourcen abschließen, Einchecken und im SVN eine Version für die 
Sourven erhalten.

2) Implementierung A mit Bedingungen 1 anwerfen und einen FPGA für 
Plattform 1 bekommen. Bitfile erzeugen und einchecken

3) Implementierung B mit Bedingungen 2 anwerfen und einen anderen FPGA 
für andere Plattform erzeugen und einchecken.

Damit ist in jedem branch / trunk immer exakt definiert, welches Bitfile 
in SVN exisitert und es ist klar, welche Version die Quelle für diese 
Implementierung ist.

Es gibt also nicht etwas allemöglichen Bitfiles auf der Platte von denen 
man nicht weiß, welchen Status sie haben. Irgendwo auf der Platte 
exisitente, die nicht im SVN eingecheckt sind, gelten auch nicht als 
Release sondern sind experimental.

Die Vorgehensweise, dass aus den Designfiles zu machen ist eine 
schlechte und schlampige Technik, die von Hackern und unaufgeröumten 
Programmierern gepfelgt wird.

Der saubere Weg ist, ein klares Anforderungsprofil für ein Spektrum der 
Gerätefunktionen zu haben, diesem eine Releaseversion zuzuordnen und 
diese sowohl aktiv (manuell oder per script) in allen Sourcen für C und 
VHDL und dem USER Code des FPGA einzutragen. Die automatisch vergebenen 
Versionsnummern, die dann aus dem RePo kommen, werden entsprechend 
nachgetragen, sind aber selber für sich nicht relevant. Fortlaufende 
Nummern taugen da eh nicht richtig für.

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Weltbester FPGA-Pongo schrieb im Beitrag #6104740:
> Wozu muss eine SVN-Nummer in das Bit-File? Die SVN Nummer wird vergeben,
> wenn man eincheckt und landet im Source Code an den vordefinierten
> Plätzen. Genauso kann man ein BIT in SVN hosten.
>
> Niemend muss die SNV Nummer durch die Design-Files managen. Das
> Aufsuchen der richtigen RePo Version geschiet ja im Recherchefall nicht
> dadurch, dass man alle BitFiles durchgeht und dort die Nummer findet,
> sondern man sucht einmal im ReRo mit einem Schritt alle zugehörigen
> Files.

Solche Aussagen sind sau gefaherlich und werden meist von Leuten 
getroffen, die nicht wirklich Expertise haben.

Es gibt nunmal Workflows in denen dieses Feature Gold wert ist und es 
gibt Workflows in denen ich darauf verzichten kann. Ich als User habe 
die Entscheidung ob ich es brauche und benutze oder ob ich es links 
liegen lasse.

Pauschale Aussage der Form "braucht kein Mensch" sind einfach nur 
schwach und inkompetent.

von Weltbester FPGA-Pongo (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Tobias B. schrieb:
> Es gibt nunmal Workflows

Das sind aber schlechte und undurchdachte workflows. In umfängliche 
Beschreibung einer Lieferkomponenten (und das ist ein FPGA-Bit-file) 
wird von oben in der Versionsverwaltung und Projektverwaltung her 
verwaltet und induziert. D.h.

- es gibt erst ein (change-)request, d.h. erst die Definition dessen, 
was die neue Funktion sein soll

- dann gibt es einen (aktualisierten) Komponentenentwicklungsplan

- danach erst gibt es ein Datum, und eine Versionsnummer für die neue SW

- dann wird es gebaut, übersetzt und verifiziert

- spätestens jetzt gibt es einen Testplan und eine Referenz auf das 
FPGA-files

(An dieser Stelle liegt also eine SW-Versionsnummer vor!)

- dann wird ein bit-file gemacht

- dann wird es getestet

- dann wird der Testplan abgehandelt und bestätigt

- dann gibt es eine Freigabe und gfs eine Releaseversion

- dann wird das im RePo und SAP oder sonstwo abgelegt und der Produktion 
übergeben

So steht es sinngemäß in praktisch allen formellen Anforderungen für 
Softwareentwicklung in den einschlägigen Brachen, die nicht gerade 
Consumer-Gebastel sind.

Wahrscheinlich arbeiten aber nach wie vor viele FPGA-Entwickler in 
Bastelbuden oder sie sehen FPGA-HW nicht als SW-Entwickler.

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Das Leben ist nunmal nicht perfekt und ebenso sind Entwicklungsprozesse.

Wenn ich einen CI Prozess habe der mit jedem Commit den Git Hash oder 
die SVN Revision Nummer ins Bitfile einbrennt, dann kann ich zu JEDER 
Zeit sicherstellen, dass ich JEDEM Bitfile eindeutig den Source Code 
Stand zuordnen kann.

Wenn sich Geraete im Feld befinden und der Servicetechniker oder Kunde 
einen Fehler berichtet, dann bin ich froh er kann mir die entsprichende 
Revision Nummer mitteilen. Dann weiss ich zumindest schonmal ob der 
Fehler bereits bekannt ist und das Gerate nur ein Update braucht oder ob 
der Fehler neu ist.

Auch ich finde dass Entwicklungsprozesse eine gewisse strenge brauchen, 
moechte aber nicht wissen wieviele Firmware Staende in Geraete sind, 
welche am definierten Prozess vorbeigeschleust wurden. Das passiert 
nunmal, manchmal durch unachtsame Entwickler, manchmal durch Druck von 
oben. Die Gruende sind auch egal, die Welt ist nunmal nicht perfekt, 
jedoch habe ich mit diesem Werkzeug die Chance jederzeit das Bitfile 
EINDEUTIG dem Source Code zuordnen zu koennen. Auserdem schliesst das 
den Flow von dir in keinster Weise aus, ist halt ein Werkzeug und in 
vielen Faellen soetwas wie ein Sicherheitsfallschirm.

Und ob ich oder sonst wer dieses Feature nutzen moechte oder nicht, soll 
doch bitte das Entwicklungsteam entscheiden und nicht der "Weltbester 
FPGA-Pongo" vom uC.net Forum. ;-)

: Bearbeitet durch User
von Blechbieger (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Weltbester FPGA-Pongo schrieb im Beitrag #6104789:
> - dann gibt es eine Freigabe und gfs eine Releaseversion

Wenn du die Releaseversion erzeugst durch Ändern der Sourcen und neu 
übersetzt ist das ein komplett anderer Bitstream als der den du getestet 
hast. Wenn man für den Versionsstring nachträglich nur den Inhalt von 
Speicherblöcken ändert kann man immerhin argumentieren dass sich das 
Zeit- und Temperaturverhalten nicht ändert.

von VHDL hotline (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Weitere Anwendungsfälle für das Ändern von Speicherinhalt nach 
Synthese/PAR zum Erzeugen verschiedener Bitstreams:

- uC-Softcore Programm (mit eigenem svn/git repo)
- geräteindividuelles kryptographisches Material

von Weltbester FPGA-Pongo (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Blechbieger schrieb:
> Wenn du die Releaseversion erzeugst durch Ändern der Sourcen und neu
> übersetzt ist das ein komplett anderer Bitstream als der den du getestet
> hast.

Richtig, und wenn man das tut, gab es einen Grund dafür. Also haben wir 
ein req change, eine neue Version, neue Beschreibung, aktualisierten 
Testplan und eine Projektfreigabe für die Änderung, BEVOR das Ganze 
angegangen wird.

Man kann also genau so verfahren, wie oben beschrieben.

VHDL hotline schrieb im Beitrag #6105151:
> Weitere Anwendungsfälle für das Ändern von Speicherinhalt nach
> Synthese/PAR zum Erzeugen verschiedener Bitstreams:
> - uC-Softcore Programm (mit eigenem svn/git repo)
Das steckt aber nicht im BIt-File (?)

> - geräteindividuelles kryptographisches Material
Das gehört nicht ins BIT-File, sondern in eine gerätespezifischen 
Bereich eines EPROMs inklusive Sicherung gegen Auslesen und Verwenden.

von Duke Scarring (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Weltbester FPGA-Pongo schrieb im Beitrag #6106000:
>> - uC-Softcore Programm (mit eigenem svn/git repo)
> Das steckt aber nicht im BIt-File (?)
Bei mir schon.

Duke

von VHDL hotline (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Weltbester FPGA-Pongo schrieb im Beitrag #6106000:
> Blechbieger schrieb:
>> Wenn du die Releaseversion erzeugst durch Ändern der Sourcen und neu
>> übersetzt ist das ein komplett anderer Bitstream als der den du getestet
>> hast.
>
> Richtig, und wenn man das tut, gab es einen Grund dafür. Also haben wir
> ein req change, eine neue Version, neue Beschreibung, aktualisierten
> Testplan und eine Projektfreigabe für die Änderung, BEVOR das Ganze
> angegangen wird.

Du hast ihn glaube ich falsch verstanden. Es geht darum, den 
quasi-finalen Stand zu testen, und wenn der fehlerfrei ist schreibt man 
so etwas wie "final" in die Version. Das ist also die einzige Änderung, 
und diese führt zu einer Änderung des Bitstroms, da die Syn/PAR-Tools 
auch bei kleinen Änderungen manchmal viel anders machen (je nachdem ob 
die Version in FF oder RAM gespeichert ist, mal mehr mal weniger). Man 
hat also nicht den finalen Bitstrom getestet.

Weltbester FPGA-Pongo schrieb im Beitrag #6106000:
> VHDL hotline schrieb im Beitrag #6105151:
>> Weitere Anwendungsfälle für das Ändern von Speicherinhalt nach
>> Synthese/PAR zum Erzeugen verschiedener Bitstreams:
>> - uC-Softcore Programm (mit eigenem svn/git repo)
> Das steckt aber nicht im BIt-File (?)

Wo sonst?

Weltbester FPGA-Pongo schrieb im Beitrag #6106000:
>> - geräteindividuelles kryptographisches Material
> Das gehört nicht ins BIT-File, sondern in eine gerätespezifischen
> Bereich eines EPROMs inklusive Sicherung gegen Auslesen und Verwenden.

Das ist zu pauschal. Erstens eine Frage des benötigten 
Sicherheitsniveaus, zweitens eine Frage des Anwendungsszenarios.

von Markus F. (mfro)


Bewertung
0 lesenswert
nicht lesenswert
VHDL hotline schrieb im Beitrag #6106381:
> ... Es geht darum, den
> quasi-finalen Stand zu testen, und wenn der fehlerfrei ist schreibt man
> so etwas wie "final" in die Version. Das ist also die einzige Änderung,
> und diese führt zu einer Änderung des Bitstroms, da die Syn/PAR-Tools
> auch bei kleinen Änderungen manchmal viel anders machen (je nachdem ob
> die Version in FF oder RAM gespeichert ist, mal mehr mal weniger). Man
> hat also nicht den finalen Bitstrom getestet.

Keine Ahnung, wie Xilinx das macht, aber bei Altera kann man (zumindest 
nach meinem Wissen) "offiziell" an einer einmal erzeugten Config nichts 
mehr ändern.

Was man kann (und da spricht aus meiner Sicht wenig dagegen) ist, die 
.mif- (memory initialization file, also irgendwelche ROM-Daten) Dateien 
ändern und mit dem (ansonsten nicht veränderten) Ergebnis der Synthese 
neu assemblieren (das setzt natürlich voraus, dass man auch wirklich mit 
den - ansonsten eher unhandlichen - .mif Dateien umgeht).

Damit sind lediglich die ROM-Inhalte modifiziert (ein Datum oder eine 
SCM-Kennung läßt sich so einfach "unterschieben"), das Design aber 
ansonsten unverändert.

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Markus F. schrieb:
> Damit sind lediglich die ROM-Inhalte modifiziert (ein Datum oder eine
> SCM-Kennung läßt sich so einfach "unterschieben"), das Design aber
> ansonsten unverändert.

Bei Xilinx das gleiche Prinzip. Zusaetzlich gibt es noch das User Access 
Feld. Das ist ein dedizierter (kleiner) ROM in dem man noch ein paar 
Daten ablegen kann, bzw. der IDE sagen kann dass es nach jedem Bitfile 
Build da automatisch etwas reinschreibt, wie z.B. das Build Datum.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.