Hallo, ich habe mal den Code vga_text.verilog umgesetzt in
vga_text.vhdl.
Compiliert wird es ohne Fehlermeldung.
Auf dem Vga-Monitor erscheint nichts, er bleibt neutral.
Im RTL-Viewer hängen vsync und hsync in der Luft.
Habe ein Fehler gefunden:
counterymaxed(0) <='1' when countery =
std_logic_vector(to_unsigned(525,countery'length));
wurde geändert, war vorher, stand vorher counterx in der Abfrage.
Aber immer noch das selbe , Monito kein Bild.
Danke.
Gruss
ps: Ist für das DE0.
Sag mal, Peter, was ist so schwer daran zu verstehen, wenn ich sage:
"Nimm einen Integer als Zähler!"
Aber du willst dich offenbar UNBEDINGT mit solchen Ungetümen abquälen:
Aber das kommt dir sicher bekannt vor: an diesem Punkt waren wir schon
ein paar Mal.
peter schrieb:> Auf dem Vga-Monitor erscheint nichts, er bleibt neutral.
Und was macht der Simulator?
Hör mal, was du tust, ist wie Autofahren mit Augenbinde un der Beifahrer
ruft dir zu "rechts!" oder "links!". Du selber fährst aber einfach blind
durch die Gegend...
hmmm.., du hast recht.
Aber wenn ich nachher aus dem Integer wieder einzelne Bits raussuchen
muss zur Kontrolle, dann geht die Umwandlung auch wieder los und das ist
nicht wenig.
Zumal das ROM/RAM dazu kommt.
Danke.
Gruss.
In einer Testbench haue ich auch unbekannte Fehler rein, die mir dann
erzählen, wo der Takt lang geht, obwohl er in der synthese nicht ist.
Da weiss ich dann nicht mehr woran es liegt, Synthese oder Testbench.
Danke.
Gruss
peter schrieb:> In einer Testbench haue ich auch unbekannte Fehler rein, die mir dann> erzählen, wo der Takt lang geht, obwohl er in der synthese nicht ist.
Wo der Takt lang geht, der in der Synthese nicht ist??
Was ist denn das für ein Satz?
Die Synthese macht genau das, was du ihr sagst. Das ist ja kein
Zufallsgenerator, auch wenn es dir vielleicht so vorkommen mag.
Genauso stellt dir der Simulator dar, was du beschrieben hast.
Dass zwischen Simulation und Syntheseergebnis nochmal Welten liegen
können ist klar, aber auch das liegt nicht daran, dass hier
irgendwelcher Hokuspokus passiert.
Aber klar, das ist auch eine Einstellung:
Den Umfang so gering wie möglich halten, dass die Anzahl der
Fehlerquellen so gering wie möglich ist.
Irgendwie werde ich das Gefühl nicht los, dass deine Herangehensweise an
das Thema genau so wirr ist, wie deine Art, dich auszudrücken.
Du kopierst doch nur irgendwelche Codeschnipsel zusammen, ohne zu
wissen, wie sie funktionieren. Und wenn es dann erwartungsgemäß nicht
klappt, bittest du hier um Hilfe.
Warum setzt du dich nicht einfach mal mit den Grundlagen auseinander und
VERSTEHST sie auch?
Ich möchte hier nicht über meine Krankheit sprechen mit dem Gedächtnis.
Hoffe das ihr sie nicht bekommt.
---------------
das Thema genau so wirr ist, wie deine Art, dich auszudrücken.
--------------
Ich hoffe das du das zurück nimmst?
Oder werden Menschen mit Handykap von dir immer beleidigt?
Gruss
peter schrieb:> Ich hoffe das du das zurück nimmst?
Ich hoffe, du meinst das nicht ernst. Man könnte wissen, wenn man all
deine Threads verfolgt hat, dass da mal ewas mit Schlaganfall
aufgetaucht ist (Beitrag "Re: Bezeichnungen bei Componenten und Datenübergabe?").
Wenn man das aber nicht weiß, dann lesen sich deine Posts signifikant
unbelehrbar und arrogant. Aber jetzt wissen wir es ja.
> Oder werden Menschen mit Handykap von dir immer beleidigt?
Hängst du dein Handycap immer dann so raus, wenn es dir gerade so passt?
Ich erinnere dich daran, dass du mich schon ein paar Mal auf äusserst
unfeine Art angegangen bist und ich auch nicht gleich die beleidigte
Leberwurst gespielt habe. Wer austeilt muss auch einstecken können. Und
nicht dem anderen auf die Nase hauen und dann sagen: "Zurückschlagen
gilt nicht, ich bin Brillenträger!"
In Memoriam: Beitrag "Re: VGA Text Mode Problem"
Also, können wir bei der Sache bleiben?
Du solltest dich jetzt unbedingt und vorrangig mit dem Thema Simulation
beschäftigen, dann findest du irgendwelche Verhaltensfehler einer VHDL
Beschreibung ganz leicht selber raus. So wie ich das seinerzeit mit
deinen ersten VGA-Gehversuchen auch gemacht habe:
Beitrag "Re: VGA Text Mode Problem"
peter schrieb:> Ich hoffe das du das zurück nimmst?
Nein, nehme ich nicht zurück.
Denn dass deine Herangehensweise an das Thema in gewisser Weise wirr
ist, wie deine Art, dich auszudrücken, liegt auf der Hand.
peter schrieb:> Oder werden Menschen mit Handykap von dir immer beleidigt?
Das iegt mir fern, jemanden mit Handycap zu beledigen. Im Gegenteil!
Aber woher sollte ich wissen, dass du ein Handycap hast?
Wenn du dich aufgrund einer Erkrankung (offensichtlich ein
zurückliegender Schlaganfall) nicht mehr so klar ausdrücken kannst und
ggf auch Probleme damit hast, dir komplexere Zusammenhänge vorzustellen,
da du dir nicht so viel auf einmal merken kannst, dann tut mir das
wirklich leid.
Aber vielleicht wäre es dann auch angebracht, das gleich zu beginn klar
zu stellen. Dann weiss jeder WARUM du dich etwas, nennen wir es mal
"unstrukturiert" ausdrückst.
Aber gerade DANN solltest du dich mit dem Thema Simulation befassen.
Man kann nicht alles im Kopf "durchspielen". Und bei einer Simulation
sieht man direkt in den Waveforms, wo es klemmt.
Oder sperrst du dich deswegen so dagegen, weil du dann wirklich mal
selber was codieren musst und nicht nur Fertiges mehr oder weniger
planlos zusammenstupfen kannst?
Trau dich doch mal ran an die Materie:
Beschreibe ein UND-Gatter und schreibe eine Testbench dazu.
Wenn du dann Probleme hast, die ans Laufen zu bekommen, sind sicher
genug Leute hier, die dir helfen.
Lothar Miller schrieb:> signal counterx : std_logic_vector (9 downto 0):= (others => '0');> signal countery : std_logic_vector (9 downto 0):= (others => '0');> Sag mal, Peter, was ist so schwer daran zu verstehen, wenn ich sage:> "Nimm einen Integer als Zähler!">> Aber du willst dich offenbar UNBEDINGT mit solchen Ungetümen> abquälen:hsync <='1' when counterx <> std_logic_vector(to_unsigned(655,counterx'length)) or counterx >> std_logic_vector(to_unsigned(751,counterx'length));
Lothar, das Ganze liegt völlig OFFENSICHTLICH an der Schlechtheit der
Programmiersprache. Ja, ich sage nicht HDL, sondern Programmiersprache,
auch wenn jetzt einige das Aufkreischen kriegen.
VHDList unlogisch und darunter leidet ein jeder, der kopfintern
mathematisch denkt. Nimm doch mal bloß den Ausdruck:
signal counterx : std_logic_vector (9 downto 0)
Das ist eine Zahl und kein Bithaufen. Wollte man einen ungeordneten
Bithaufen kreiren, dann müßte die Sprache sowas hergeben:
signal counterx : std_logic_vector (otto,karl,emil,heinz)
Sowas wäre ungeordnet. Aber mit 9 downto 0 vergibt man eine Ordnung, was
gleichbedeutend ist mit geordneten Wertigkeiten der Members dieses
Vektors. So ein std_logic_vector IST deshalb eine Zahl! Ergo sollte es
verdammtnochmal gehen, zu schreiben:
if counterx > 128 then blabla;
oder
while conterx in [655..751] do hsync := 1 else hsync := 0;
Aber VHDL versperrt genau diese Sorte sinnvoller Statements und die
Leute, die mit VHDL sich herumschlagen müssen, suchen verzweifelt nach
irgendwelchen Möglichkeiten, dennoch genau DAS tun zu können, was ganz
offensichtlich getan werden muß - das sollte doch verstehbar sein.
Kurzum, all die ärgerlichen Probleme, die hier immer wieder auftauchen,
rühren von der Miserabilität der verfügbaren Sprachen her. So eine
Programmiersprache (auch eine Hardwareprogrammiersprache) sollte
eigentlich den Programmierern das Leben erleichtern und es ihnen nicht
mit unsinnigen Hakeligkeiten erschweren.
So. Peter hat es nicht verstanden, warum du so imperativ schreibst
"Nimm einen Integer als Zähler!" - und mir geht sowas auch gegen den
Strich, weswegen ich lieber Schematics und Verilog benutze. Aber
eigentlich müßte man die Machete mitten in's VHDL selbst hineinschlagen.
Ich hab da ein nettes Beispiel: jemand hatte mal mit nem FPGA von Altera
ein SDR gebastelt (HF rein, Ton via Ethernet raus). Mit Alteras
Toolchain läuft es durch, mit Xilinx Toolchain nicht, mit Lattices
Toolchain läuft es auch nicht durch. Je nach Toolchain recht
unterschiedliche Syntax-Fehler, die da angemahnt werden - aber alles
VHDL, sollte also - mal abgesehen von Hardware-Spezialitäten -
wenigstens syntaktisch durchgehen. Ist aber nicht.
Diese Diskussion ist anders als die elenden Diskussionen um die
Programmiersprache C, aber sie ist dennoch damit vergleichbar, denn in
beiden Sprachen muß man sich mit unlogischen Festlegungen,
Einschränkungen und Seiteneffekten herumschlagen. Also mit all dem
Zeugs, was man durch logisches Denken garantiert NICHT erfassen kann.
Das ist das Problem.
W.S.
Bitte WAS?
Geh mal in den Elektronikmarkt und kauf dir einen Baustein der eine Zahl
ist. Ja, kauf dir eine Integer oder so ...
In Hardware gibt es keine Zahlen, da gibt es nur Speicherelemente und so
Zeugs. VHDL ist schon so irre zuvorkommen, dass es sowas wie Integer
kennt, du musst also in VHDL keine Vektoren verwenden, wenn dir die
einzelnen Bits egal sind sondern kannst ganz bequem Integer verwenden.
Ich weiß ja nicht welche Sprache dir lieber ist, Java, Phython, Ruby,
... egal, bleibe dabei, das mit der Hardware ist wohl nix für dich.
W.S. schrieb:> signal counterx : std_logic_vector (9 downto 0)>> Das ist eine Zahl und kein Bithaufen.
welche Zahl ist das? Mit Vorzeichen oder ohne? Einer oder
Zweierkomplement, oder sogar dargestellt im Graycode?
W.S. schrieb:> weswegen ich lieber Schematics [...] benutze.
ja, und da kannst du auch viele Leitungen zu einem Bus zusammenknoten
(siehe oben das Signal counterx). Ist der Bus dann auch eine Zahl??
Nur weil die Leute nicht verstehen wollen, was ein FPGA ist und wie man
damit umgehen soll, deswegen ist VHDL schlecht? Meiner Meinung nach ist
VHDL sehr sehr logisch. ein std_logic_vector ist nunmal ein Bit-Vektor.
Da hier keine Informationen hinterlegt sind, welche Zahlen es darstellt,
kann man damit auch nicht rechnen. Für das gibt es eben in der
numeric_std die unsigned und signed Datentypen. Hier ist ganz klar
hinterlegt was bei Addition und Subtraktion passiert, und eben auch, was
bei einem Überlauf passiert.
Will man mit fixed point Zahlen rechnen, gibt es auch wieder eine Extra
Bibliothek, um damit eben rechnen zu könen. Aber schlussendlich landet
alles in einer Logik-Wolke.
Leute die VHDL nicht verstehen, vor allem nach einer langen Zeit, liegt
meiner Meinung nach nur an der Ignoranz sich nicht in ein neues Gebiet
einarbeiten zu wollen. Wenn jemand glaubt C++ zu können, heißt es auch
noch lange nicht, dass er super mit MFC von Microsoft klar kommt. Auch
hier muss man sich erstmal einarbeiten.
Ich liebe VHDL, da es mit den festen Datenstrukturen einfach alles
logisch ist. Ein std_logic_vector ist nur eine Anhäufung von Bits, kann
aber einfach in einen anderen Datentyp umgewandelt werden um zu rechen.
Also wo ist das Problem.
W.S. schrieb:> emand hatte mal mit nem FPGA von Altera> ein SDR gebastelt (HF rein, Ton via Ethernet raus). Mit Alteras> Toolchain läuft es durch, mit Xilinx Toolchain nicht, mit Lattices> Toolchain läuft es auch nicht durch. Je nach Toolchain recht> unterschiedliche Syntax-Fehler, die da angemahnt werden - aber alles> VHDL, sollte also - mal abgesehen von Hardware-Spezialitäten -> wenigstens syntaktisch durchgehen. Ist aber nicht.
Hab ich nicht so ganz verstanden, aber wenn der VHDL Code keine
hardwarenahen Elemente beinhaltet (BlockRAMs, PLLs, DSPs, ...) dann
sollte es auch keine Probleme beim umsetzen geben. Falls ja, dann hält
sich einer der Großen nicht an die VHDL regeln, oder Altera sieht etwas
zu locker, was streng genommen in VHDL ungültig ist. Jetzt darüber zu
schimpfen warum das so ist, wäre es eigentlich interessant zu sehen, an
welcher Stelle es denn konkret hakt! Aber diese Info fehlt dann leider.
W.S. schrieb:> So ein std_logic_vector IST deshalb eine Zahl! Ergo sollte es> verdammtnochmal gehen, zu schreiben:> if counterx > 128 then blabla;
Ist doch einfach: überlade nur den Operator '>' mit einer Funktion, die
dir einen Integer mit einem Vektor vergleicht...
> Wollte man einen ungeordneten Bithaufen kreiren, dann müßte die Sprache> sowas hergeben:> signal counterx : std_logic_vector (otto,karl,emil,heinz)
Definier dir deinen eigenen Datentyp namens "Kumpels", da kannst du die
dann alle problemlos reinpacken...
> Ich hab da ein nettes Beispiel: jemand hatte mal mit nem FPGA von> Altera ein SDR gebastelt ... - aber alles VHDL
Lass doch mal sehen, was da für Fehlermeldungen auftraten...
W.S. schrieb:> Lothar, das Ganze liegt völlig OFFENSICHTLICH an der Schlechtheit der> Programmiersprache. Ja, ich sage nicht HDL, sondern Programmiersprache,> auch wenn jetzt einige das Aufkreischen kriegen.
Gut, dann lassen wir das so stehen. Ich kann eh' nichts dran ändern, ich
bin nicht im Normungsgremium.
> weswegen ich lieber Schematics und Verilog benutze.
Jeder, wie ihm beliebt:
Beitrag "kruder Fehler bei FPGA-Programmierung (ISE WEBpack-Schematic)"Beitrag "Re: SPLD (GAL) - welche Software"
W.S. schrieb:> Das ist eine Zahl und kein Bithaufen. Wollte man einen ungeordneten> Bithaufen kreiren, dann müßte die Sprache sowas hergeben:>> signal counterx : std_logic_vector (otto,karl,emil,heinz)
Geht doch:
counterx <= otto & karl & emil & heinz;
Ein std_logic_vector ist lediglich ein Haufen Bits, die keinerlei
Bedeutung haben. Sie werden halt einfach von n bis m durchnumeriert.
Vielleicht ist dir nicht bekannt, dass man auch schreiben kann:
signal counterx : std_logic_vector (10 downto 1);
Was wäre das dann deiner Meinung nach? Nur gerade Zahlen ohne
Vorzeichen?
Wie ja Gustl schon sagte, kauf dir doch mal einen Integer-Baustein.
Oder ist ein RAM-Baustein, der Fließkommazahlen speichern kann
physikalisch anders, als einer, der Integer speichert?
Dass VHLD dir die MÖGLICHKEIT bietet, diesen Bithaufen als Zahl zu
interpretieren, ist keine Schlechtigkeit der Sprache, nur weil DU die
Logik dahinter nicht verstanden hast.
Mit std_logic_vector zu rechnen ist daher schlicht unmöglich, da
vollkomen UNLOGISCH! Dass manche Synthesetools das unterstützen ist
zugegebenermaßen schlecht! Es sollte kein einziges Tool unterstützen!
Wenn ihr also in eurem dubiosen Projekt sowas aus Unwissenheit gemacht
habt, dann kann es tatsächlich passieren, dass es in der einen toolchain
geht und in der anderen nicht.
Aber auch das liegt nicht an VHDL sondern an der Unfähigkeit desjenigen,
der so einen Code erstellt hat und daran, dass manche Compiler entgegen
der IEEE diese Schlamperei noch unterstützen.
Dasd ist genauso, wie wenn du in C nicht richtig castest und der eine
Compiler macht das, was du dir gedacht hast, und der andere nicht. Dann
liegt das auch nicht an der Schlechtigkeit von C, sondern daran, dass
der Programmierer Regeln missachtet hat.
VHLD ist ziemlich geschwätzig, das stimmt. Und die Typkonvertierungen
sind syntaktisch etwas gewöhnungsbedürftig, auch da muss ich dir recht
geben.
Aber VHDL ist nur dann UNLOGISCH, wenn man nicht in Hardware denkt,
sondern, wie du, mindestens eine Abstraktionsebene darüber.
Wenn ich VHDL code, dann sehe ich vor dem inneren Auge Leitungen,
Register, Multiplexer etc. und keine Zahlen oder Mathematik.
Du schreibst hingegen selbst, dass du mathematisch denkst. Dann läuft
dir Verilog sicher besser rein.
Aber zum Thema UNLOGISCHE Sprache:
Poste doch mal den Verilog-Code für ein Register mit asynchronem Reset
:-)
> signal DATA : std_logic_vector (10 downto 1);
Ist jetzt aber mal nen Datenbus einer CPU! Und die kann da chars,
integer, unsigned und signed integer, und sogar 64 Bit floats drüber
schicken halt jeweils in 8 Bit paketen nacheinander. Warum zum teufel
soll dieser Datenbus irgendeinen Zahlentyp haben!? Das wäre vollkommen
unlogisch!
W.S. schrieb:> Nimm doch mal bloß den Ausdruck:>> signal counterx : std_logic_vector (9 downto 0)>> Das ist eine Zahl und kein Bithaufen.
Nö. Das ist ein Bithaufen.
So wäre es eine Zahl:
1
useieee.numeric_std.all;
2
3
...
4
5
signalcounterx:unsigned(9downto0);
Wenn man das so macht, klappts auch mit der Nachbarin^W Addition und den
Vergleichen...
Duke
Duke Scarring schrieb:> Wenn man das so macht, klappts auch mit der Nachbarin^W Addition und den> Vergleichen...
Aber blöderweise funkt es mit der Nachbarin^W Zuweisung so doch noch
nicht ganz. Das kann dann den geneigten Anfänger wieder gehörig ins
Schleudern bringen... ;-)
W.S. schrieb:> signal counterx : std_logic_vector (9 downto 0)> Das ist eine Zahl und kein Bithaufen.
Mit oder ohne Vorzeichen?
Lothar Miller schrieb:> Mit oder ohne Vorzeichen?
Natürlich OHNE Vorzeichen, denn es sind ja nur die Wertigkeiten
angeführt, in diesem Falle (std_logic_vector (9 downto 0)) also 2^9 bis
2^0. Das ist doch logisch und es steht explizit da!
Ich könnte auch kontern mit der Gegenfrage "welche Wertigkeit hat denn
ein Vorzeichen?"
Aber mal ganz generell:
Schlumpf schrieb:> Ein std_logic_vector ist lediglich ein Haufen Bits, die keinerlei> Bedeutung haben. Sie werden halt einfach von n bis m durchnumeriert.
So. Und nun erkläre mir mal, wozu so ein ungeordneter Haufen Zeugs gut
sein soll? Andersherum: Wenn man mit einem "Ding" aus n einzelnen Bits
NICHT rechnen kann, dann ist dieses Ding unnütz. Die einzige
Verwendung würde ich darin sehen, weniger Schreibarbeit zu haben, da man
anstelle von n Argumenten eine Sammelbezeichnung hinschreiben kann. Aber
das ist lediglich eine Faulheitsangelegenheit.
Schlumpf schrieb:> Vielleicht ist dir nicht bekannt, dass man auch schreiben kann:> signal counterx : std_logic_vector (10 downto 1);> Was wäre das dann deiner Meinung nach? Nur gerade Zahlen ohne> Vorzeichen?
Richtig. von 2^10 bis 2^1
Und für Festkommazahlen für DSP-Zwecke wäre das dann
std_logic_vector (2 downto -16)
Aber.. das alles ist eben nur ein Gedankenexperiment.
In Wirklichkeit ist genau diese Formulierung (x downto y) ein
Entwurfsfehler von VHDL, den es nicht geben sollte.
Wenn dort nur wertigkeitsfreie Aufzählungen a la (karl, otto, hans,
emil) syntaxgerecht hinschreibbar wären, dann wäre das eine Verbesserung
der Sprache - und kaum einer käme auf die Idee, einen std_logic_vector
für irgendwas, das mit Zahlen zu tun hat, überhaupt benutzen zu wollen,
bis evtl. auf wenige Sonderfälle, von denen mir hier aber keiner
einfallen will.
Wer da anderer Meinung ist, sollte sie hier mal darlegen.
Also wozu sollte ein std_logic_vector mit einer (Pseudo)-Wertigkeit (x
downto y) oder auch (y to x) denn überhaupt gut sein?
Ich sag's mal so: Logik besteht eigentlich IMMER aus einzelnen Signalen,
die miteinander verknüpft werden und dann zumeist in Flipflops landen.
Wenn man hingegen zusammengesetzte Signale braucht, dann sind das immer
Zahlen, die mit anderen Zahlen verglichen werden müssen - wie hier bei
einem Horizontalzähler, der eben von 0 bis 1023 zählen können soll und
wo zwischen zwei bestimmten Zählerständen ein Synchronsignal auszugeben
ist. Genau sowas ist der klassische Anwendungsfall für jegliches Zeugs,
was mehr als 1 Bit umfaßt.
Gustl Buheitel schrieb:> Geh mal in den Elektronikmarkt und kauf dir einen Baustein der eine Zahl> ist. Ja, kauf dir eine Integer oder so ...
Das geb ich zurück: Kauf du dir lieber nen Baustein, der ein
Standardlogikvektor ist. Am besten einen (7 downto 0), der ist nicht so
lang und paßt noch auf nen kleinen Einkaufswagen.
Ach ja.. und erkläre dazu mal den Rang-Unterschied zwischen dem 7. und
dem 4. Bit dieses Vektors und warum es downto ist und nicht einfach nur
std_logic_vector(10), wo es doch keine Rangunterschiede zwischen den 10
Bits gibt.
Damit du das begreifst: Eine Formulierung "downto" impliziert die
Vergabe einer Rangordnung, womit es eine Größenrelation zwischen den
Elementen gibt - und genau DAS ist realiter eben NICHT der Fall. Man
könnte sowas ne gezielte Irreführung nennen. Genau DAS ist der
Kernpunkt, auf dem ich hier die ganze Zeit herumhacke.
Lothar Miller schrieb:> statt zu schreiben und zu lesen:> signal counterx : integer range 0 to 1023 := 0;> signal countery : integer range 0 to 1023 := 0;> :> :> hsync <='1' when counterx < 655 or counterx > 751;> vsync <='1' when countery < 489 or countery > 491;
Jahahaha!
Aber schau doch um himmelswillen mal in all diese elendiglichen
Tutorials, Lehrbücher und anderes Zeugs! Das, was einen da zu allererst
angrinst, ist eben dieser unbrauchbare "std_logic_vector". Und folglich
benützen halt alle Leute, die mit VHDL anfangen genau dieses Zeugs,
wollen dann damit das anstellen, was eigentlich zur Aufgabe steht - und
das ist wie hier eben das Vergleichen mit Zahlen und schon warten die
nächsten Tutorials auf, die das langatmige Konvertieren erklären wollen.
Insgesamt geht das alles in die falsche Richtung. Frag dich mal, warum
es soviel Erklärungsbedarf hier gibt. Ich sag's dir: Weil die
Sprachdefinitionen zu verkorkst sind und die Literatur dazu ebenfalls.
Ach ja, auch Zahlen muß man gelegentlich ausgeben, also ein jedes Bit
der Zahl an ein Pin des Chips oder so.
Ich wäre für die restlose Ausrottung von "std_logic_vector" zwecks
Verbesserung von VHDL. Bei der Gelegenheit sollten dann auch sämtliche
nicht synthetisierbaren Bestandteile entfernt werden. Ja, ich weiß,
alles nur mehr oder weniger fromme Wünsche.
Frohes Schaffen wünscht
W.S.
Poste doch bitte den Verilog Code eines Registers mit asynchronem Reset.
Dann diskutieren wir doch darüber zum Thema "Logik" weiter.
Bin gespannt ;-)
W.S. schrieb:> So. Und nun erkläre mir mal, wozu so ein ungeordneter Haufen Zeugs gut> sein soll?
Muss ich das wirklich?
Nun, weil es der tatsächlichen Hardware entspricht. Ein Haufen
Bits/Leitungen eben. Die noch vollkommen unbefleckt ist, was die Daten
angeht, die darüber transportiert werden.
Ich kann die Bits schieben, einzelne Bits invertieren oder verknüpfen,
eine Zahl in Gray-Code darstellen, oder binär oder BCD.. ich bin einfach
FREI, was ich mit dem Bithaufen anstelle.
Wenn dein Horizont aber bei mathematischen Operatoren aufhört, dann ist
das ja ok. Steht dir ja frei, dann Verilog zu verwenden, wenn dir das
besser schmeckt.
Ist doch aber kein Grund, sich hier so aufzublasen, nur weil dir die
Logik hinter VHDL verschlossen bleibt.
W.S. schrieb:> Das geb ich zurück: Kauf du dir lieber nen Baustein, der ein> Standardlogikvektor ist.
Das ist z.B. jeder SRAM/ROM etc.. die Pins heißen D0, D1, D2,..
Ob ich den ROM an einen uC anschließe und die Bits als Zahl
interpretiere, oder als Kommando oder ob ich vielleicht einfach nur die
Adressen anspreche und den ROM als LUT für 8 völlig unabhängige Signale
verwende, ist doch ein Unterschied. Ich könnte z.B. an jedes Bit einen
Aktor anschließen und durch inkrementieren der Adressen eine
Schrittsteuerung machen. Ganz ohne Prozessor, Mathematik und Zahlen..
Das ist logisch, weil ein ROM ein "std_logic_vector" ist, und nicht ein
Haufen "integer".
Aber ich denke, es ist zwecklos, darüber vernünftig mit dir zu reden.
Und vorallem ist es sinnlos.
Du bist der Meinung, dass VHDL die Quelle des Bösen ist. Steht dir zu,
so zu denken, aber dann plärr doch nicht in der Gegend rum, wenn
offensichtlich viele andere da weniger Verständnisprobleme haben als du.
Und zum Abschluss:
Dass der TO Probleme mit HDL hat, liegt sicher nicht daran, dass es VHDL
ist. In Verilog stößt er auch an seine Grenzen.
Also für mich ist
std_logic_vector (9 downto 0)
natürlich eine Dezimalzahl im Bereich von 0 bis 9. Wo das Bit gesetzt
ist, bestimmt den Wert. Und es darf natürlich nur immer 1 Bit gesetzt
sein.
Gustl Buheitel schrieb:> Also für mich ist>> std_logic_vector (9 downto 0)>> natürlich eine Dezimalzahl im Bereich von 0 bis 9. Wo das Bit gesetzt> ist, bestimmt den Wert. Und es darf natürlich nur immer 1 Bit gesetzt> sein.
Grins, etwas verschwenderisch, aber durchaus eine weitere "Verwendung"
für den universell nutzbaren std_logic_vector
:-)
Gustl Buheitel schrieb:> Also für mich ist>> std_logic_vector (9 downto 0)>> natürlich eine Dezimalzahl im Bereich von 0 bis 9. Wo das Bit gesetzt> ist, bestimmt den Wert. Und es darf natürlich nur immer 1 Bit gesetzt> sein.
Made my day!!
Schlumpf schrieb:> Muss ich das wirklich?> Nun, weil es der tatsächlichen Hardware entspricht.> ....> Das ist z.B. jeder SRAM/ROM etc.. die Pins heißen D0, D1, D2,..
Ah.. ja. Probiere das mal mit einem SDRAM, viel Spaß dabei.
Nee, alle solche Daten wie D0, D1, D2 usw. sind geordnete Daten, die
eine vom Hersteller gedachte und oftmals hart codierte Rangordnung
haben. Also D0 ist kleiner als D1 und D1 ist kleiner als D2 usw. Und bei
fast aller Hardware, die es gibt, wirst du die diversen Bits von D0 bis
Dxx oder A0 bis Axx genau in der Ordnung benutzen müssen, wie sich das
der Hersteller gedacht hat - sonst fliegen dir die Probleme um die
Ohren.
Schlumpf schrieb:> Das ist logisch, weil ein ROM ein "std_logic_vector" ist, und nicht ein> Haufen "integer".
Du kannst das gut an einem gewöhnlichen Flashrom ausprobieren: Lies
einfach mal dessen Produkt-ID aus und vergleiche diese mit dem Wert, der
im Datenblatt steht. Da steht eine ZAHL drin und die stimmt mit dem
Bitmuster was du ausliest nur dann überein, wenn du dich an die Ordnung
hältst, also D0 = 2^0, D1 = 2^1 usw.
Sowas ist also ein geordneter Haufen Bits, eben ein Haufen integer.
Kein ungeordneter Haufen. Ist das jetzt etwas klarer?
Eben DAS entspricht der tatsächlichen Hardware. Jedenfalls der Hardware,
die man üblicherweise zu kaufen kriegt.
Abgesehen davon sollte man einen geordneten Haufen Bits mindestens
genauso gut benutzen können wie einen ungeordneten Haufen. Also nochmal
dieselbe Frage:
Schlumpf schrieb:> W.S. schrieb:>> So. Und nun erkläre mir mal, wozu so ein ungeordneter Haufen Zeugs gut>> sein soll?
Oder anders gesagt: Wozu sollte die Ungeordnetheit eines
std_logic_vector gut sein?
Ein geordneter Haufen Bits kann alles was der ungeordnete kann und noch
mehr, nämlich z.B. mit Zahlen verglichen werden, zum Rechnen geeignet
sein und so weiter.
Hannes schrieb:> Achso. Und wie simulierst du dein Design dann?
Mein Design? Die Frage müßte nicht "Wie?" sondern eher "Womit?" lauten -
und das ist zumindest für mich eine völlig ungeklärte Frage.
Gegenfrage: Läßt sich ein Design nur dann simulieren, wenn es nicht
synthetisierbare Teile enthält? Und wie simuliert man dann eines, das
tatsächlich in einen konkreten Chip geladen werden soll und deshalb
tatsächlich NUR synthetisierbares Zeugs enthält?
Also, ich schätze mal, daß die ganze Aufregung in diesem Thread daher
rührt, daß hier völlig unterschiedliche Denkweisen aufeinanderprallen.
Das ist immer so, wenn Leute sich in irgendein Thema so sehr vertieft
haben, daß sie die vorhandenen Unlogiken gar nicht mehr sehen, sondern
selbige als völlig normal und sogar als logisch ansehen. Wenn dann
jemand aus einer anderen Elektronik-Ecke kommt (wie z.B. ich) und den
Finger drauf legt, dann ist Verständnislosigkeit oder sogar hysterisches
Kreischen angesagt, bis hin zu sinnlosen Beiträgen wie diesem:
"Egal, was du für Zeug nimmst, nimm weniger davon! Das macht dich nur
aggressiv und stört offensichtlich dein Denkvermögen."
Nö, mich würde es allenfalls reizen, auf so einen groben Klotz einen
passend groben Keil zu hauen, aber wir wollen ja sachlich bleiben.
Also nochmal kurz gefaßt:
VHDL macht ganz vielen Leuten extreme Schwierigkeiten, weil die meisten
mit sowas wie std_logic_vector anfangen und für ihre Logik eben auch
Vergleiche mit Zahlen benötigen.
Man hätte VHDL auch anders machen können - so, daß es weniger hakelig
ist und den eigentlichen Bedürfnissen derjenigen entgegenkommt, die
diese Programmiersprache benützen wollen. Ist aber nicht und das ist
schlecht.
W.S.
W.S. schrieb:> Das ist immer so, wenn Leute sich in irgendein Thema so sehr vertieft> haben, daß sie die vorhandenen Unlogiken gar nicht mehr sehen, sondern> selbige als völlig normal und sogar als logisch ansehen.
Dann sind wir ja alle froh und dankbar, dass du, unser Messias, uns
endlich die Augen öffnest und zum Licht führst.
Und dank der Erleuchtung, die du bereits erfahren hast, ist es natürlich
völlig abwägig, dass DU irgendwas nicht ganz verstanden hast.
Mir Argumenten kommt man bei dir nicht weiter, da du einfach das Prinzip
nicht verstanden hast und nun versuchst, mit vollkommen wirren
Beispielen, deine eingeschränkte Sichtweise als die "richtige" zu
untermauern.
Dass hier ausnahmlos jeder NICHT deiner Meinung ist, sondern das Prinzip
und den Sinn des std_logic_vector verstanden hat, scheint dich nicht zu
beeindrucken. Die sind halt alle schon betriebsblind in deinen Augen.
Und dass du die nicht synthetisierbaren Elemente aus der Sprache
streichen willst, weil man ja auch ohne diese auskommt, steht ja wohl im
krassen Gegensatz zu einer deiner früheren Äußerungen, dass eine Sprache
das Arbeiten erleichtern soll.
Steht dir natürlich frei, deine Testbench auch synthetisierbar zu
schreiben, wenn du so masochistisch veranlagt bist.
Und was ist jetzt eigentlich mit der Verilog-Beschreibung für das
Register mit asynchronem Reset? Willst du nicht oder kannst du es nicht?
Und weil du immer auf dem Wort "ungeordnet" so rumhackst:
Benutze doch mal dei Suchfunktion deines Browsers und such das Wort
"ungeordnet". Du wirst festestellen, dass keiner, außer dir, dieses Wort
verwendet hat.
Und jetzt hackst du die ganze Zeit darauf herum, dass es keinen Sinn
ergäbe, wenn ein Bithaufen ungeordnet sei. Keiner außer dir hat das auch
jemals behauptet. Daher verstehe ich auch wirklich nicht, warum du
ausgerechnet MICH nach dem Sinn eines ungeordneten Bithaufens fragst.
Frag dich doch selber, denn DU bist derjenige, der behautptet hat, dass
der std_logic_vector "ungeordnet" sei.
Ich habe lediglich gesagt, dass der "Inhalt" noch quasi "bedeutungslos"
ist.
Also z.B. noch keinen Integer oder sonstwas darstellt.
Und das entspricht einfach nun mal der realen Hardware.
Wenn du einen RAM kaufst, dann haben die einzelnen Datenbits noch keine
Bedeutung.
Das Beispiel mit der Schrittsteuerung habe ich ja schon gebracht.
Oder du legst z.B. Messwerte von 4 Geräten in den RAM ab. Dann könnte
das Format so aussehen:
D7..D6 : Messplatz-Nr
D5..D0 : Messwert
Dann kannst du ganz einfach festlegen, dass du D7..D6 als Integer
definierst und D5..D0 als signed.
Zusammen ergibt dann D7..D0 keinen Wert, den man sinnvoll als integer
etc interpretieren oder geschweige denn, damit rechnen kann.
Aber wie gesagt, dass ist nur was für Leute, deren Horizont nicht bei
arithmetischen Funktionen mit Zahlen, die in das Raster 8 Bit, 16 Bit,
32 Bit passen, aufhört.
W.S. schrieb:> VHDL macht ganz vielen Leuten extreme Schwierigkeiten
Namen? Zahlen?
Mir ist Verilog viel zu implizit: viele Sachen sind da "einfach so
festgelegt, und das muss man eben einfach wissen."
Die Sache mit dem "Tick" in der Simulation ist z.B. so eine Sache...
Schlumpf schrieb:> Und was ist jetzt eigentlich mit der Verilog-Beschreibung für das> Register mit asynchronem Reset?
Das, wo der Reset scheinbar auch auf die Flanke sensitiv ist?
Schlumpf schrieb:> Dann sind wir ja alle froh und dankbar, dass du, unser Messias, uns> endlich die Augen öffnest und zum Licht führst.
Danke für die Blumen - aber jetzt gehst du mir ziemlich auf den Nerv.
Anstatt einfach mal ne wirklich EINFACHE Frage sachlich zu beantworten -
womit das ganze Gehadere ein Ende hätte, fängst du an, zu motzen.
Jetzt hab ich fast ein halbes Dutzend mal versucht, die Fragen und
Probleme, die ich habe, paßgerecht an den Mann zu bringen, aber guck mal
deine eigenen Antworten an: Was würdest du meinen, wenn jemand dir genau
so antworten würde?
OK, wenn dir nach Motzen zumute ist, dann laß es sein.
Ja, ich weiß, VHDL ist eben so wie VHDL eben so ist. Das ist genauso wie
bei C (mit dem ich allerdings vor 15 Jahren meinen Frieden gemacht
habe).
Aber bei VHDL wäre mit wirklich guten und praxisgerechten Tutorials und
sinnvollen Dokus weitaus mehr zu erreichen. Das fehlt.
Lothar Miller schrieb:> Namen? Zahlen?
Verkaufszahlen von µC, insbesondere von kleinen PIC's. Ich hatte es wie
viele andere nach dem obsolet werden der GAL's ja auch so gemacht: Ehe
man sich mit VHDL&Co herumschlägt, erledigt man das Problem lieber mit
so nem kleinen µC. Das geht in erstaunlich vielen Fällen und es geht
einfach. Selbst hier in diesem Forum gibt es Auswüchse in Form von
Grafik-LCD-Ansteuerungen per ATmega und so. Warum nicht dafür das
eigentlich besser geeignete Produkt FPGA oder CPLD benutzen? Ja, eben
das Problem, das hineingehackt zu bekommen, was man haben will.
Nochmal: Guck dir die üblichen Verdächtigen bei den VHDL-Tutorials an,
die Schriften, die von Assis an Unis verzapft wurden und so.
Ja, Lothar, DU weißt wohl es besser, aber davon haben die meisten
anderen nix von, die stolpern immer wieder und immer wieder über all die
Hakeligkeiten, die du ganz oben in diesem thread schon genannt hast.
Eben auch über die std_logic_vector's, mit denen man anschließend nen
Vergleich mit einer Zahl machen MUSS weil genau DAS das Ziel ist: if
Pixelnummer>639 then machwas. Mit nem besseren Ansatz wäre das problem
in Luft aufgelöst, aber eben auch der TO dieses Threads ist über genau
DAS gestolpert, was man EBEN IMMER SO gelehrt bekommt. Warum muß ich
mich hier eigentlich so oft wiederholen, bis das endlich begriffen wird?
W.S.
W.S. schrieb:> Ja, Lothar, DU weißt wohl es besser, aber davon haben die meisten> anderen nix von, die stolpern immer wieder und immer wieder über all die> Hakeligkeiten, die du ganz oben in diesem thread schon genannt hast.> Eben auch über die std_logic_vector's, mit denen man anschließend nen> Vergleich mit einer Zahl machen MUSS weil genau DAS das Ziel ist: if> Pixelnummer>639 then machwas. Mit nem besseren Ansatz wäre das problem> in Luft aufgelöst, aber eben auch der TO dieses Threads ist über genau> DAS gestolpert, was man EBEN IMMER SO gelehrt bekommt. Warum muß ich> mich hier eigentlich so oft wiederholen, bis das endlich begriffen wird?
Tja, die Zeiten haben sich halt geaendert. Wo frueher ein paar boolsche
Gleichungen in ein 'Chip' gepasst haben, hast du heute ziemlich
maechtige Komponenten.
Ich habe Ende der 90er (so 1997) mit VHDL angefangen. Damals haben wir
noch die FFs direkt instanziiert, sowas wie 'if clock'event' war ganz
boese (war aber auch Chip-Design mit speziellen Vendor-Libs).
Du beschwerst dich ueber die Sachen wie 'std_logic_vector', 'signed',
'unsigned', das Problem hast du mit Verilog so nicht. Aber VHDL hat den
riesigen Vorteil (vor allem mit der numeric_std), dass es dir im
Sourcetext sagt, was mit so Signalen passieren soll. Ist manchmal nervig
und auch viel Tipparbeit. Aber wenn du einen VHDL Design (der den Namen
halbwegs verdient) von extern bekommst oder du deinen Design nach 1 Jahr
wieder anschauen/aendern/erweitern musst, dann ist dieses Prinzip
verdammt gut.
Lass' dich einfach mal auf VHDL ein, schau nach Beispielen. Und dann
benutze genau das, was du von VHDL verstanden hast. Vereinfachen (also
VHDL ausnutzen) kommt dann spaeter...
---------------------------------
Aber wenn du einen VHDL Design (der den Namen
halbwegs verdient) von extern bekommst oder du deinen Design nach 1 Jahr
wieder anschauen/aendern/erweitern musst, dann ist dieses Prinzip
verdammt gut.
---------------------------------
Hmm..., das hört sich nicht sehr Intelligenz an, eine Sprache nach dem
Vergeßlichkeitsgrad an den Mann/Frau zu bringen. Ich weiss nicht, was an
Verilog nach einem Jahr unübersichtlich werden soll. Die Beschreibung
von Verilog ist durchdacht und logisch nachvollziehbar ohne ein "Wetten
Das" zu veranstalten.
-----------------------------------
Ist manchmal nervig
und auch viel Tipparbeit.
-----------------------------------
Dann Tipp du doch ruhig weiter.
Alte Bäume soll man nicht mehr versetzen.
Gruss
Mir ist da jedes "Sendungsbewusstsein" fremd. Ich kann mit VHDL eine
Schaltung beschreiben, und ich kann das hundertprozentig(!) auch mit
Verilog (man zwinge mich einfach und gebe mir 3 Monate Zeit um die
impliziten Eigenschaften kennen zu lernen). Und sicher könnte ich es
auch mit System-C oder sonstwas.
Der Trick daran ist, dass ich einfach nur eine Sprache brauche, mit der
ich die Schaltung, die ich im Kopf habe, beschreiben kann...
W.S. schrieb:> aber jetzt gehst du mir ziemlich auf den Nerv
Frag nicht, wie du mir auf den Nerv gehst...
W.S. schrieb:> Anstatt einfach mal ne wirklich EINFACHE Frage sachlich zu beantworten -> womit das ganze Gehadere ein Ende hätte, fängst du an, zu motzen.
Sorry, welche Frage hast du denn gestellt? Habe ich wohl offensichtlich
zwischen DEINEM ganzen Gemotze übersehen.
Aber offensichtlich hast DU auch meine mehrfach gestellte Frage nach der
Registerbeschreibung in Verilog übersehen.
Und wenn du mal liest, was du geschrieben hast, dann solltest du
festestellen können, dass DU derjenige bist, der hier nur am motzen ist.
Du motzt über die Schlechtigkeit von VHDL, darüber dass das alles
komplett unlogisch ist für jemanden, der mathematisch denkt, dass das
alles eine elende Diskussion sei, usw
KEINER war bisher hier deiner Meinung und das kannst du offensichtich
nicht ab. Und darum versuchst du jedem hier klar zu machen, dass der
std_logic_vector die Ausgeburt des Bösen sei. Lustig nur, dass
offensichtlich alle hier, außer dir und Peter den Sinn hinter dem Vector
verstanden haben. Sorry, ich muss mich korrigieren. Bei Peter denke ich,
dass es ihm mittlerweile auch klar geworden ist und er den
ursprünglichen Fehler nicht mehr machen wird.
DU bist hier auch derjenige, der hier als einziger behauptet, dass es
ein ungeordneter Bithaufen sei und dann rummotzt, wie bescheuert das
alles sei..
W.S. schrieb:> OK, wenn dir nach Motzen zumute ist, dann laß es sein.
Wann ich es sein lasse, entscheide immer noch ich und nicht du!
W.S. schrieb:> Ehe> man sich mit VHDL&Co herumschlägt, erledigt man das Problem lieber mit> so nem kleinen µC. Das geht in erstaunlich vielen Fällen und es geht> einfach.
Jetzt muss ich aber echt lachen...
Das geht nur, wenn du für deine Aufgabe Zeit hast.. sehr viel Zeit. Oder
kann dein kleiner billiger Mikrocontroller zwei Eingänge in einstelligen
Nanosekunden verunden? Eher nicht, würde ich behaupten.
Und spätestens, wenn er das mit 20 Eingängen geleichzeitig machen soll,
kommt er wohl fürchterlich ins Schwitzen.
Dieser Vergleich ist, mit verlaub, genauso sinnfrei wie deine
Behauptung, dass in einem RAM die Bits eine Ordung haben und diese eben
eine Zahl repräsentieren.
W.S. schrieb:> Verkaufszahlen von µC, insbesondere von kleinen PIC's.
Der Grund, dass weniger FPGAs als µC verkauft werden, liegt also deiner
Meinung nach daran, dass VHDL so eine beschissene Sprache ist?
Jetzt muss ich noch lauter lachen...
Ist dir eigentlich kar, wieviel Silizium man braucht, um ein paar
konfigurierbare VERKNÜPFUNGEN zu realisieren und wieviel Silizium man
braucht, um ein paar Befehle sequenziell abzuarbeiten?
Dieser kleine Unterschied wird wohl eher der Grund dafür sein, dass der
normal denkende Mensch nur dann ein FPGA einsetzt, wenn man es braucht
und alles andere mit einem µC erschlägt und nicht, weil VHDL so schlecht
ist.
Nun, wenn du nach der der Ära der Gals den Schritt von Abel zu VHDL
nicht geschafft hast, dann ist das dein Problem und wenn du mit C
"deinen Frieden" schließen musstest, dann klingt das auch so, als
hättest du dich fürchterlich schwer damit getan.
Kann ja alles sein. Ich habe auch alte Kollegen, die es einfach nicht
mehr schaffen, sich in neue Themen einzudenken. Nimmt ihnen ja keiner
übel. Aber die blöken nicht über die Schlechtigkeit der Dinge rum, die
sie nicht verstehen, sondern halten einfach die Klappe, bevor sie sich
der Lächerlichkeit Preis geben. Aber auch das kann jeder halten, wie er
mag.
Hakligkeiten hat VHDL definitiv. Aber das sind keine Dinge, die man
nicht lernen und verstehen kann.
Das bringt eben jede Programmiersprache oder Beschreibungssprache mit
sich.
Und Tutorials und Bücher gibt es durchaus (inklusive Lothars sehr guter
Seite). Man muss sich nur die Mühe machen, es zu lesen und zu verstehen.
So, du merkst, dass du mir mit deinem haltlosen Geschwätz gehörig auf
den Keks gehst. Und da es definitiv nicht Wert ist, den Blutdruck für
einen Unbekannten, der zu diesem Thema nur Phrasen ins Web schleudert,
hochzutreiben, entscheide ICH jetzt (richtig, nicht DU), dass ich auf
dein Geschwätz zu dem Thema hier nicht mehr reagieren werde.
-------------------------
Ich kann mit VHDL eine
Schaltung beschreiben, und ich kann das hundertprozentig(!)
-------------------------
Eben, das ist der Nachteil bei dir, du bist dadurch gegenüber
Schwächeren total Betriebsblind geworden und reflektierst dein Können
mit flappzigen Antworten auf diesen. Statt eine Sprosse die Leiter
runter zu kommen.
Das hat sich Teilweise auch auf andere hier im Forum übertragen.
Sogenannte Trittbrettfahrer. Aber auch die Studenten die VHDL als
Lehrfach haben, machen sich über dieser Umständlichkeit von VHDL keine
Gedanken.
Gruss
Also für Lernwillige gibt es hier doch echt genügend Angebote schön
gestaffelt von ganz einfach nach schwer.
Und auch wer einigermaßen präzise Fragen stellt und nicht gleich eine
Komplettlösung verlangt bekommt hier sehr brauchbare Antworten.
Ich bin selber noch am Lernen und es wird noch lange dauern, aber das
Forum hier ist eine riesige Hilfe! Danke!
Peter Bierbach schrieb:> Eben, das ist der Nachteil bei dir, du bist dadurch gegenüber> Schwächeren total Betriebsblind geworden und reflektierst dein Können> mit flappzigen Antworten auf diesen.
Peter, meinst du das tatsächlich ernst?
Ich gebe Ratschläge und wenn jemand (du, Peter) die mit aller Gewalt
ignoriert, dann resigniere irgendwann auch ich. Einer meiner ersten
und einer der wiederholten Ratschläge an dich war, den Simulator zu
verwenden. Und: läuft dein Simulator jetzt endlich?
Ich gebe diese Ratschläge in meiner Freizeit. Ich bekomme kein Geld oder
sonst ein Entgelt dafür und auch nur dann&wann ein Dankeschön. Und jetzt
verlangst du noch, dass ich die Leiter runterkomme und dir auf die Füße
trete? Muss ein Autor auch für jeden seiner Leser ein spezielles Buch
nach dessen Wünschen schreiben? Muss ich jede Woche die Grundlagen für
jeden Anfänger wiederkäuen? Erwartest du das für dich?
Lothar, ich bin da voll deiner Meinung.
Das ist ein Forum, wo jeder eine Frage stellen kann. Egal ob ein
Anfänger eine vermeindliche Trivialität noch nicht versteht, oder ein
Fortgeschrittener mit einer komplexen Fragestellung ankommt.
Und dass jemand vielleicht auch mal ne Frage stellt, die er durch
googeln einfach herausfinden könnte, ist normalerweise auch kein
Problem.
Aber völlig unspezifische Fragestellungen, wie das Posten von
kilometerlangem Code und dam lapidaren Satz: "Es tut nicht, warum?"
zeugt schon von der Einstellung einiger hier.
Und wenn man den Leuten dann noch Hilfe zur Selbsthilfe gibt, wollen sie
das einfach nicht wissen und ignorieren es. Sie wollen eine fertige
Lösung auf dem Silbertablett präsentiert bekommen. Und offensichtlich
haben sie auch gar kein Interesse daran, zu verstehen, was sie falsch
gemacht haben, um in Zukunft diesen Fehler nicht noch einmal zu machen.
Und dann gibt es noch diejenigen, die offensichtlich nicht (mehr) über
die geistigen Kapazitäten oder den technischen Background verfügen, um
dieses durchaus komplexe Thema wirklich zu verstehen. Frustrierend ist
dann, wenn man von denen noch beschimpft wird, weil man es ihnen nicht
immer und immer wieder von vorne auf "Sendung mit der Maus"-Niveau
präsentiert.
Lothar Miller schrieb:> Ich gebe diese Ratschläge in meiner Freizeit. Ich bekomme kein Geld oder> sonst ein Entgelt dafür und auch nur dann&wann ein Dankeschön.
Stimmt! Hier mal ein Dankeschön von mir!
berndl schrieb:> Lothar Miller schrieb:>> und auch nur dann&wann ein Dankeschön.> Stimmt! Hier mal ein Dankeschön von mir!
Bittesehr. Aber sooooo war das jetzt nicht gemeint... ;-)
Lothar Miller schrieb:> Aber sooooo war das jetzt nicht gemeint...
Wissen wir, dass das nicht so gemeint war. Aber dennoch darf man hier
durchaus mal danke sagen, wenn sich jemand vorallem mit seiner Website
so viel Mühe gibt, dass man die schon echt als ein "Nachschlagewerk"
bezeichnen kann.