mikrocontroller.net

Forum: FPGA, VHDL & Co. Warum "flickert" die Power LED meines CPLD XC9572XL Xilinx DevBoards?


Autor: Michael Wessel (michael_w738)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Liebe Leute,

vorab gesagt - ich bin Anfaenger!

Problem-Beschreibung: ich habe 2 dieser CPLD Dev-Boards

https://www.openimpulse.com/blog/products-page/pro...

zusammengeschaltet, und es kommt zu eigenartigen Effekten, die ich mir 
nicht recht erklaeren kann.

Board 1 hat die Rolle eines Addressdekoders - eine 16 Bit-Addresse vom 
Z80 wird dekodiert, und 2 Ausgaenge des CPLDs zeigen an, ob es ein Read 
IORequest oder ein Write IORequest vom Z80 ist.

Diese 2 Ausgaenge des Boards gehen dann in Board 2, das als eine Art 
Input-Output-Buffer arbeitet. Sobald es also READ oder WRITE vom 1. CPLD 
bekommt, tut es entweder ein zuvor gespeichertes / "gelatchtes" Byte auf 
den Z80 Datenbus, oder es speichert / "latched" das aktuelle Byte vom 
Z80 Datenbus.

Soweit so gut.


Nun, beide Boards haben einen 5V-Eingang fuer Steckernetzteile. 
Zunaechst hatte ich jedes Board mit eigenem Stecknetzteil versorgt, und 
nur GND der beiden Boards mit dem Z80 Ground verbunden, und das fuehrte 
zu den wildesten Problemen. U.a. habe ich mit den LEDs auf dem 2. Board 
die Input-Bytes angezeigt, und das fuehrte zu wildem Blinken der LEDs, 
selbst wenn gar kein IORequest vorlag!

Dann dachte ich - nun, viellecht statt 2 Steckernetzteile fuer die 
DevBoards, einfach die 5V  vom Z80-Computer nehmen, und 5V -> 3.3V 
Spannungswandler eingebaut, Kabel an die 3.3 V Input der beiden 
DevBoards, und GND, und natuerlich auch GND an den Z80, fertig. Das hat 
das wilde Blinken der Test/Debugging-LEDs beseitigt, und es 
funktionierte dann auch zu 90%. Allerdings kommt es immer noch zu 
eigenartigen Fehlern.

Diese verbleibenden Fehler fuehren komischerweise auch dazu, dass die 
Power-LEDs der DevBoards flickern... und das verstehe ich ehrlich gesagt 
ueberhaupt nicht. Warum flickern die? Im Schaltplan zu den DevBoards

https://www.openimpulse.com/blog/wp-content/upload...

sieht man, dass die nur zwischen GND und 3.3 liegen, also gar nichts mit 
einem CPLD IO Port zu tun haben. Wie koennen die flickern? Ist die 
Spannungsversorgung irgendwie instabil? Der Effekt tritt auch nur dann 
auf, wenn es tatsaechlich IORequests auf der richtigen Addresse gibt, 
wenn also der 2. CPLD angesprochen wird. Ansonstent flickeren die 
Power-LEDs der DevBoards nicht.

Das Ganze haengt an einem Z80-Computer mit 2 A 5V Steckernetzteil; ich 
kann mir beim besten Willen nicht vorstellen, dass das 
unterdimensioniert ist.

Es ist eigenartig! Kommt irgendjemand das Problem bekannt vor, oder hat 
Ideen zur weiteren Eingrenzung des Problems? Vielleicht sind diese 
DevBoards nicht wirklich dafuer gedacht, dass man sie so 
zusammenschaltet, und ihnen eine "selbstgestrickte" 3.3 V Spannung 
zukommen laesst? Ich habe uebrigens auch Siebkondensatoren hinter und 
vor dem Spannungswandler etc. Das machte keinen Unterschied im 
Verhalten.

Danke und mfG
Michael

: Bearbeitet durch User
Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael W. schrieb:
> Wie koennen die flickern? Ist die Spannungsversorgung irgendwie instabil?
Das ist die absolut einzige Möglichkeit,

> und 5V -> 3.3V Spannungswandler eingebaut
Was für einen und wozu? Die Boards haben doch eigene Spannungsregler.

Zeig doch mal ein Foto, wie du das womit verdrahtet hast...

Michael W. schrieb:
> Der Effekt tritt auch nur dann auf, wenn es tatsaechlich IORequests auf
> der richtigen Addresse gibt, wenn also der 2. CPLD angesprochen wird.
> Ansonstent flickeren die Power-LEDs der DevBoards nicht.
Evtl. hast du da einen Buskonflikt, der eine Baustein treibt high, der 
andere low und in der Summe wird der Regler überlastet.

: Bearbeitet durch Moderator
Autor: Michael Wessel (michael_w738)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Lothar M. schrieb:
> Michael W. schrieb:
>> Wie koennen die flickern? Ist die Spannungsversorgung irgendwie instabil?
> Das ist die absolut einzige Möglichkeit,


Aha. Ok, ich gucke mir das mal mit dem Oscilloscope an.


>> und 5V -> 3.3V Spannungswandler eingebaut
> Was für einen und wozu? Die Boards haben doch eigene Spannungsregler.

Ja, aber wie gesagt, wenn ich entweder beide mit Steckernetzteil 
versorge, kommt es zu dem Problem dass das 2. Board "halluziniert" und 
meint, es wuerde Input vom 2. Board bekommen, obwohl auch die Logic 
Probe alles auf Low sieht... und mit einem Steckernetzteil, und dem 2. 
Board an 3.3 V PIN des ersten (sodass beide vom gleichen Steckernetzteil 
versorgt werden) ist dieses Problem behoben, allerdings flickert dann 
ebenfalls die Power LED.

> Zeig doch mal ein Foto, wie du das womit verdrahtet hast...

OK, ist aber wild! Anbei.

Autor: Michael Wessel (michael_w738)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar M. schrieb:
> Michael W. schrieb:
>> Der Effekt tritt auch nur dann auf, wenn es tatsaechlich IORequests auf
>> der richtigen Addresse gibt, wenn also der 2. CPLD angesprochen wird.
>> Ansonstent flickeren die Power-LEDs der DevBoards nicht.
> Evtl. hast du da einen Buskonflikt, der eine Baustein treibt high, der
> andere low und in der Summe wird der Regler überlastet.

Interessant. Ja, der 1. CPLD ist nur kombinatorische Logic, der 2. hat 2 
8Bit bidirektionale Busse, einen zum Z80, einem zum ATMega 644, die 
werden in den Tristate-Zustand versetzt je nachdem, ob READ, WRITE vom 
1. CPLD, or WRITE2, READ2 vom ATMega 644 kommt.

Der 2. CPLD (der simuliert sozusagen 2 74LS374 Flipflops, mit 2 Takt und 
2 OE Eingaengen), hat always @(posedge <PIN>) (fuer <PIN>=READ/ WRITE/ 
READ2/ WRITE2).

Zu den BIldern - der CPLD rechts im Bild, der den Spannungswandler in 
der Naehe hat, ist der Address-Dekoder. Der CPLD links ist der "Flipflop 
Emulator".

: Bearbeitet durch User
Autor: Michael Wessel (michael_w738)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
PS Der Regulator ist ein 3.3V 950 mA LD1117V33, LD33V. Er bekommt 5 V 
vom Z80.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael W. schrieb:
> PS Der Regulator ist ein 3.3V 950 mA LD1117V33, LD33V. Er bekommt 5 V
> vom Z80.
Genau solche Dinger sitzen doch eh auf den CPLD Boards. Werden die 
übrigens warm angesichts der Rückwärtsspeisung?

Autor: Michael Wessel (michael_w738)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar M. schrieb:
> Michael W. schrieb:
>> PS Der Regulator ist ein 3.3V 950 mA LD1117V33, LD33V. Er bekommt 5 V
>> vom Z80.
> Genau solche Dinger sitzen doch eh auf den CPLD Boards. Werden die
> übrigens warm angesichts der Rückwärtsspeisung?

Gute Frage, sind auf der Unterseite, muss ich mal nachschaeuen! Gerochen 
hab' ich nix :D

Du meinst, die 3.3 V und GND Pins auf den CPLD Boards sind nur als 
Ausgaenge gedacht, und nicht, damit man mehrere "Zusammenketten" kann, 
mit nur einer Stromversorgung (denn dann waere ja mindestens 1 Regulator 
in diesem Sinne  "rueckwaertsgespeist", wenn der Strom vom anderen 
Regulator kommt - in meinem Falle sind sogar beide rueckwaertsgespeist, 
ja).

Ich habe auch gehoert, dass man nicht mehr als einen Spannugnsregler 
"parallel" haben kann, da die sonst evtl. oszillieren und sich 
"gegenseitig regulieren". Daher die Idee, beide Wandler zu umgehen, und 
sicherzustellen, dass beide CPLDs von einem Wandler gespeist werden, der 
extern ist.

: Bearbeitet durch User
Autor: Michael Wessel (michael_w738)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
PS Vielleicht sollte ich die BOards so manipulieren, dass ich die 
eingebauten Regler entferne, dann gibt es keine (potentiellen Probleme 
durch) RUeckwaertsspeisung mehr?

: Bearbeitet durch User
Autor: Sigi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Den Regler auszubauen ist eine Möglichkeit, aber
zwei Regler (bei Dir vlt. zwei verschiedene)
parallel laufenzulassen sollte man nicht (es
gibt Boards, bei denen lassen sich die Regler
vom Rest trennen, ist hier aber nicht so).

Ich hatte auch so ein Board, lief viele Jahre
problemlos, bis ich es "überprogrammierte".

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael W. schrieb:
> Ich habe auch gehoert, dass man nicht mehr als einen Spannugnsregler
> "parallel" haben kann, da die sonst evtl. oszillieren und sich
> "gegenseitig regulieren".
So lange du von den beiden erzeugten 3,3V nur die "Massen" miteinander 
verbindest, geht das völlig problemlos. Ich habe in meinen Designs 
locker mal 7 Spannungen (von 24V bis runter zu 0,8V) die nur die Masse 
gemeinsam haben.

> Daher die Idee, beide Wandler zu umgehen, und sicherzustellen, dass beide
> CPLDs von einem Wandler gespeist werden, der extern ist.
Allerdings versetzt du damit eben die beiden schon verbauten Wandler in 
einen Zustand, der im Datenblatt so nicht vorgesehen ist: am eingang 
keine Spannung, aber am Ausgang schon...

: Bearbeitet durch Moderator
Autor: Michael Wessel (michael_w738)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar M. schrieb:
>> Ich habe auch gehoert, dass man nicht mehr als einen Spannugnsregler
>> "parallel" haben kann, da die sonst evtl. oszillieren und sich
>> "gegenseitig regulieren".
> So lange du von den beiden erzeugten 3,3V nur die "Massen" miteinander
> verbindest, geht das völlig problemlos. Ich habe in meinen Designs
> locker mal 7 Spannungen (von 24V bis runter zu 0,8V) die nur die Masse
> gemeinsam haben.

Das hatte ich ja auch so gesehen / gemacht - in der 1. Version hatten 
beide DevBoards separates Steckernetzteil, und nur alle GNDs verbunden 
(auch mit Z80). Das führte dann allerdings dazu, dass das 2. CPLD der 
Meinung war, bei einem Low-Pegel vom 1. CPLD am Eingang irgendwelche 
Flanken zu erkennen, und das führte zum LED-Blinken von D2 - D5. Wie 
gesagt, die Logic Probe war der Meinung, dass das Signal vom 1. CLPD in 
den 2. CLPD eine konstante 0 / Low war... Das konnte ich mir nur damit 
erklären, dass die Spannungspegel vom 1. CLPD irgendwie nciht korrekt 
vom 2. CLPD interpretiert werden konnten. Da ein solches Signal zum 
"Latchen" eines Bytes vom Z80 Datenbus führt, und ich die Bytes (obere 
oder untere 4 Bit) mit den LEDs D2-D5 auf dem Board visualisiere, sah 
ich die die ganze Zeit wild blinken, obwohl keine Flanken getriggert 
wurden.Ich habe das oben mit "halluzinieren" des 2. CLPDs beschrieben.

Es scheint also so zu sein, dass eben nicht nur die Massen miteinander 
verbunden werden, sondern "indirekt" über die "Pin-Verbindung" des 
Triggers vom 1. zum 2. CLPD auch die Spannungen ? Und das führt dann zum 
Oszillieren....

: Bearbeitet durch User
Autor: Michael Wessel (michael_w738)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar M. schrieb:
>> Daher die Idee, beide Wandler zu umgehen, und sicherzustellen, dass beide
>> CPLDs von einem Wandler gespeist werden, der extern ist.
> Allerdings versetzt du damit eben die beiden schon verbauten Wandler in
> einen Zustand, der im Datenblatt so nicht vorgesehen ist: am eingang
> keine Spannung, aber am Ausgang schon...

Ja, ich werde die Dinger einfach auslöten... hoffe, das behebt die 
Fehler, Vielen Dank an alle für die ganzen Tipps, echt super!

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael W. schrieb:
> Das hatte ich ja auch so gesehen / gemacht - in der 1. Version hatten
> beide DevBoards separates Steckernetzteil, und nur alle GNDs verbunden
> (auch mit Z80). Das führte dann allerdings dazu, dass das 2. CPLD der
> Meinung war, bei einem Low-Pegel vom 1. CPLD am Eingang irgendwelche
> Flanken zu erkennen
Achtung, du liegst falsch!
Es war nicht die Versorgung aus 2 Quellen, sondern der tolle 
Drahtverhau, der durch diese Doppelversorgung natürlich noch schlimmer 
war. Und weil du durch Entfernen der Netzteile den Drahtverhau etwas 
reduziert hast, "funktioniert" das Ganze "besser"...

Das Geflacker der LEDs hat aber grundlegend andere Ursachen. Evtl. ist 
einer der Steckbrettkontakte ausgeleiert --> mal genauer nachmessen, 
denn deine LED ist ja auch nur ein "binäres Messinstrument" für die 
Versorgung.

> Es scheint also so zu sein...
Du hattest doch geschrieben, Zugriff auf ein Oszi zu haben. Miss damit 
mal verschiedene GND-Pegel deiner Schaltung gegeneinander. Ja, richtig: 
Masseklemme an Masse und den Tastkopf an die Masse eines anderen, 
entfernteren Bauteils. Was siehst du dann?

Michael W. schrieb:
> hoffe, das behebt die Fehler
Ich würde da statt ausschließlich mit Hoffnung auch mal etwas 
systematischer vorgehen. Nur einen Fehler, dessen Ursache man kennt, 
kann man sinnvoll behandeln. Und du kennst die Ursache offenbar noch 
nicht.

: Bearbeitet durch Moderator
Autor: Sigi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar M. schrieb:
> Das Geflacker der LEDs hat aber grundlegend andere Ursachen.

Die Ursache sollte doch schon längst geklärt sein,
es ist das Parallelschalten der Regler. Den Rest
kann man erst nach einem Blick in die Sources
(HDL+Pin-Constraints) klären.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sigi schrieb:
> Die Ursache sollte doch schon längst geklärt sein,
> es ist das Parallelschalten der Regler.
Da ist doch nach meiner Interpretation derzeit gar nichts parallel 
geschaltet. Und wenn ich mir diesen vogelwilden Drahtverhau genauer 
anschaue, geht das alles über den einen Regler auf dem Steckbrett. Dem 
fehlen natürlich auch noch die Kondensatoren am Ein- und Ausgang, die im 
Datenblatt samt Kommentar zu finden sind:
8.2.1
Design Requirements
The device component count is very minimal, employing two resistors as part
of a voltage divider circuit and an output capacitor for load regulation.
A 10-μF tantalum on the input is a suitable input capacitor for almost all applications.

: Bearbeitet durch Moderator
Autor: Achim S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael W. schrieb:
> Das hatte ich ja auch so gesehen / gemacht - in der 1. Version hatten
> beide DevBoards separates Steckernetzteil, und nur alle GNDs verbunden
> (auch mit Z80). Das führte dann allerdings dazu, dass das 2. CPLD der
> Meinung war, bei einem Low-Pegel vom 1. CPLD am Eingang irgendwelche
> Flanken zu erkennen, und das führte zum LED-Blinken von D2 - D5. Wie
> gesagt, die Logic Probe war der Meinung, dass das Signal vom 1. CLPD in
> den 2. CLPD eine konstante 0 / Low war...

das klingt genau nach der sinnvollen Verbindung der Boards.

Wenn das 2. CPLD-Board dabei irgendwelche Flanken zu erkennen glaubt, 
dann hat es vielleicht einfach recht. Dein 1. CPLD als kombinatorischer 
Adressdekoder kann Glitches liefern. Vielleicht reagiert dein zweites 
CPLD auf diese.

Wenn deine Logik-Probe keine Glitches erkennt liegt es vielleicht nur 
daran, dass die Glitches für die Logik-Probe zu schmal sind (mit welcher 
Frequenz tastet die Logic-Probe ab)? Das zweite CPLD reagiert ggf. auf 
schmalere Glitches, die deine Logic-Probe übersieht.

Autor: Michael Wessel (michael_w738)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Achim S. schrieb:
> Michael W. schrieb:
>> Das hatte ich ja auch so gesehen / gemacht - in der 1. Version hatten
>> beide DevBoards separates Steckernetzteil, und nur alle GNDs verbunden
>> (auch mit Z80). Das führte dann allerdings dazu, dass das 2. CPLD der
>> Meinung war, bei einem Low-Pegel vom 1. CPLD am Eingang irgendwelche
>> Flanken zu erkennen, und das führte zum LED-Blinken von D2 - D5. Wie
>> gesagt, die Logic Probe war der Meinung, dass das Signal vom 1. CLPD in
>> den 2. CLPD eine konstante 0 / Low war...
>
> das klingt genau nach der sinnvollen Verbindung der Boards.
>
> Wenn das 2. CPLD-Board dabei irgendwelche Flanken zu erkennen glaubt,
> dann hat es vielleicht einfach recht. Dein 1. CPLD als kombinatorischer
> Adressdekoder kann Glitches liefern. Vielleicht reagiert dein zweites
> CPLD auf diese.
>
> Wenn deine Logik-Probe keine Glitches erkennt liegt es vielleicht nur
> daran, dass die Glitches für die Logik-Probe zu schmal sind (mit welcher
> Frequenz tastet die Logic-Probe ab)? Das zweite CPLD reagiert ggf. auf
> schmalere Glitches, die deine Logic-Probe übersieht.

Ich werde demnaechst mal mit dem Oskar nachsehen.

Habe diese Logic Probe:
https://www.amazon.com/Elenco-Electronics-LP-560-L...

Captures pulses to 25ns(20MHz)

Unwahrscheinlich, da der Z80 mit 4 MhZ getaktet ist... wuesste nicht, 
was das schnellere Glitches verursachen koennte - aber vielleicht 
instabile Spannungsversorgung o.ae., ja. Nachgucken ist besser! Werde 
ich machen.

Autor: Michael Wessel (michael_w738)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar M. schrieb:
> Und wenn ich mir diesen vogelwilden Drahtverhau genauer
> anschaue, geht das alles über den einen Regler auf dem Steckbrett. Dem
> fehlen natürlich auch noch die Kondensatoren am Ein- und Ausgang, die im
> Datenblatt samt Kommentar zu finden sind:

Ja, am Eingang habe ich allerdings einen Kondensator (ist schlecht zu 
sehen auf dem Bild, aber der ist zwischen GND und VCC vom Z80 oben), und 
ich hatte versuchsweise auch mal einen an den Ausgang gesteckt, hatte 
aber keine Auswirkungen auf Stabilitaet.

Autor: Michael Wessel (michael_w738)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar M. schrieb:
> Michael W. schrieb:
>> hoffe, das behebt die Fehler
> Ich würde da statt ausschließlich mit Hoffnung auch mal etwas
> systematischer vorgehen. Nur einen Fehler, dessen Ursache man kennt,
> kann man sinnvoll behandeln. Und du kennst die Ursache offenbar noch
> nicht.

Ja, Hoffnung ist das falsche Wort... ich bin halt Anfaenger und habe 
verschiedene Arbeitshypothesen, die ich versuche durchzuarbeiten. Und 
mit Eurer Hilfe kann ich einige als wahrscheinlicher oder 
unwahrscheinlicher bewerten, was sehr hilfreich ist!

Autor: --- (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Der "Drahtverhau" wird nie zuverlaessig irgendwas dekodieren
oder latchen. So langsam ist ein Z80 nicht, als das ein so
"schlamperter" Aufbau stabil laufen wuerde.

Dem Spannungsregler fehlen die Abblockkondis, die Leitungen
zum Quarz sind zu lang, ... und die Massefuehrung ist ein
Witz, da bunt und quer verteilt.

Mit den ausgeloeteten Spannungsreglern wird es die CPLDs auch
bald grillen.


So wird das nuex...

Autor: Michael Wessel (michael_w738)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sigi schrieb:
> Lothar M. schrieb:
>> Das Geflacker der LEDs hat aber grundlegend andere Ursachen.
>
> Die Ursache sollte doch schon längst geklärt sein,
> es ist das Parallelschalten der Regler. Den Rest
> kann man erst nach einem Blick in die Sources
> (HDL+Pin-Constraints) klären.

Es ist meine derzeit favorisierte Hypothese. Ich kann die 
Verilog-Sourcen heute Abend mal posten.

Autor: Michael Wessel (michael_w738)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
--- schrieb:
> Der "Drahtverhau" wird nie zuverlaessig irgendwas dekodieren
> oder latchen. So langsam ist ein Z80 nicht, als das ein so
> "schlamperter" Aufbau stabil laufen wuerde.

Ich geben zu bedenken, dass aehnliche Drahtverhaue


Youtube-Video "Emic 2-Based Amstrad SSA-1 Speech Synthesizer Emulation for CPC 464"

bereits bestens mit den beiden 74LS374 Flipflops und einem GAL22V10 
funktioniert haben; diese Drahtverhaue sind auch nur Prototypen, die ich 
dann in PCBs ummuenze, s. z.B. hier fuer den vorherigen Drahtverhau:

http://www.cpcwiki.eu/forum/amstrad-cpc-hardware/n...

Aber es stimmt, das ist mein erstes CPLD-Projekt, und diese scheinen 
etwas empfindlicher zu sein als meine bisherigen Komponenten.

Ich habe die Kabel und das Breadboard natuerlich auch unter Beobachtung 
/ in Verdacht. Ich werde die CPLDs mal etwas besser zusammen bringen und 
die Leitungen kuerzen.

Autor: Michael Wessel (michael_w738)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Michael W. schrieb:
> bereits bestens mit den beiden 74LS374 Flipflops und einem GAL22V10
> funktioniert haben; diese Drahtverhaue sind auch nur Prototypen, die ich
> dann in PCBs ummuenze, s. z.B. hier fuer den vorherigen Drahtverhau:

Anbei mal die GAL22V10 + Flipflops basierte Version, die ebenfalls als 
Drahtverhau begann :-)

Aber ich stimme voll und ganz zu dass ich den Aufbau aufraeumen und 
verbessern sollte, und kuerzere Leitungen! Allerdings glaube ich nicht, 
dass es das Problem loest.

Der Sinn der ganzen CPLD-Uebung hier ist lediglich, zu sehen, ob ich die 
beiden Flipflops aus dem Design entfernen kann, und GAL22V10 + Flipflops 
in ein groesseres CPLD kombinieren kann. Da ich kein groesseres CPLD 
DevBoard finden konnte, muss ich hier leider fuer den Drahtverhau 2 
kombinieren. Die sich dabei ergebenden Problem haette ich warhscinelich 
gar nicht, wenn ich ein groessers CPLD haette, das genuegend IOs haette. 
S. auch meine andere Frage nach dem DevBoard fuer einen groesseren CPLD.

: Bearbeitet durch User
Autor: Michael Wessel (michael_w738)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
--- schrieb:
> Mit den ausgeloeteten Spannungsreglern wird es die CPLDs auch
> bald grillen.


Bratwurst oder Leberkaese? :D

Autor: Sigi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael W. schrieb:
> Ich habe die Kabel und das Breadboard natuerlich auch unter Beobachtung
> / in Verdacht. Ich werde die CPLDs mal etwas besser zusammen bringen und
> die Leitungen kuerzen.

Wie ich ja Oben schon schrieb hatte ich dasselbe Board,
dazu wie bei Dir eine Menge Dupont-Kabel. Beim Board
gab's nie Probleme (korrekter Code und Pin-Alllokation
vorausgesetzt), Probleme gibt's aber immer wieder bei
den Dupont-Kabel (Online/China). Ab und an brechen
Kabel und übertragen Signale nur sporadisch, für GND
sollte man deshallb immer mehrere Adern/Kabel bzw. ein
dickes Kabel/Draht nehmen.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael W. schrieb:
> Ja, am Eingang habe ich allerdings einen Kondensator (ist schlecht zu
> sehen auf dem Bild, aber der ist zwischen GND und VCC vom Z80 oben)
Der Kondensator gehört nicht in Richtung E-Werk, sondern auf 
Millimeterabstand an den Regler...

Michael W. schrieb:
> und kuerzere Leitungen! Allerdings glaube ich nicht, dass es das Problem
> loest.
Aber es schadet mit Garantie nicht. Im Besonderen die Masse muss 
unbedingt stabil und verlässlich sein. Wie gesagt: GND gegen GND messen

Autor: Michael Wessel (michael_w385)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
OK, habe also die CPLD-Spannungsregler sauber entfernt / ausgelötet 
(ging einfach!), den externen Spannungsregler sauberer aufgebaut, die 
3.3 V und GNDs sauber mit kurzen und doppelten Kabeln verbunden (die 
CPLD Boards haben dafür PINs in doppelter Ausführung, auf jeder 
"Seite"!), die Breadboard GND und 5V-Schienen ebenfalls "doppelt" 
verkabelt. Ergebnis - immer noch Flackern der Power-LEDs, und zwar von 
beiden CPLDs. Alle Kabel sind stramm und bombenfest, das Breadboard ist 
einwandfrei.

Ich denke jetzt, es muss ein Bus-Konflikt sein, dass ich auf den Z80-Bus 
schreibe, wenn ich nicht schreiben sollte... und die CPLDs erkennen das 
irgendwie und regeln sofort runter. Das führt zum Flackern der 
Power-LEDs, und ich kann das auch im Lautsprecher des CPCs als 
"Knacksen" hören, wenn ich den Verstärker voll aufdrehe.

Bratwurst oder Leberkäse vom CPLD-Grill gibt's leider noch nicht. 
Entgegen aller Erwartungen bleibt das alles sehr schön kühl :-)

: Bearbeitet durch User
Autor: Michael Wessel (michael_w385)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael W. schrieb:
> Ich kann die
> Verilog-Sourcen heute Abend mal posten.

Address-Dekoder:
 
module Main(

  i_IORQ,
  i_RD,
  i_WR,
  
  iADR, 
  
  oSPEECH_WRITE, 
  oSPEECH_WRITE_ATMEGA, 
  oSPEECH_READ  
  
);

input [15:0] iADR; 
input i_IORQ; 
input i_RD; 
input i_WR; 

output oSPEECH_WRITE; 
output oSPEECH_WRITE_ATMEGA; 
output oSPEECH_READ;  

wire iorq = ~ i_IORQ; 
wire iord = ~ i_RD; 
wire iowr = ~ i_WR; 

wire read = iorq & iord; 
wire write = iorq & iowr; 

wire ssa_adr = iADR[15:0] == 16'hFBEE; 
wire ls_adr = iADR[15:0] == 16'hFBEE; 

wire internal_read  = ( ssa_adr | ls_adr ) & read;
wire internal_write = ( ssa_adr | ls_adr ) & write; 

wire oSPEECH_WRITE = internal_write; 
wire oSPEECH_WRITE_ATMEGA = internal_write; 

wire oSPEECH_READ = internal_read;  

/*
always @(*) 
begin
  if (oSPEECH_WRITE) 
    sr_led <= 4'b0011; 
  else if (oSPEECH_READ)
    sr_led <= 4'b1100; 
  else
    sr_led <= 4'b1111;
end 
*/
  




NET "i_IORQ"    LOC = "p23" ;
NET "i_WR"      LOC = "p22" ;
NET "i_RD"      LOC = "p21" ; 

NET "iADR<0>"   LOC = "p27" ; 
NET "iADR<1>"   LOC = "p28" ; 
NET "iADR<2>"   LOC = "p29" ; 
NET "iADR<3>"   LOC = "p30" ; 
NET "iADR<4>"   LOC = "p18" ; 
NET "iADR<5>"   LOC = "p16" ; 
NET "iADR<6>"   LOC = "p14" ; 
NET "iADR<7>"   LOC = "p13" ; 
NET "iADR<8>"   LOC = "p36" ; 
NET "iADR<9>"   LOC = "p37" ; 
NET "iADR<10>"   LOC = "p38" ; 
NET "iADR<11>"   LOC = "p39" ; 
NET "iADR<12>"   LOC = "p40" ; 
NET "iADR<13>"   LOC = "p41" ; 
NET "iADR<14>"   LOC = "p42" ; 
NET "iADR<15>"   LOC = "p43" ; 

NET "oSPEECH_READ"            LOC = "p5" ; 
NET "oSPEECH_WRITE"           LOC = "p3" ; 
NET "oSPEECH_WRITE_ATMEGA"    LOC = "p2" ; 

endmodule




FlipFlop-Emulator:
 
module Main(

  iDECODER_READ,
  iDECODER_WRITE,
  iCLOCK, 
  
  ioCPC_DATA, 
  ioATMEGA_DATA, 
  
  iREAD_LATCHED_CPC_DATA,   
  iLATCH_ATMEGA_DATA,   
  
  oLED  
  
   );

inout [7:0] ioCPC_DATA; 
inout [7:0] ioATMEGA_DATA; 

input iDECODER_READ; 
input iDECODER_WRITE; 
input iCLOCK; 

input iREAD_LATCHED_CPC_DATA; 
input iLATCH_ATMEGA_DATA; 

output [3:0] oLED;

reg [3:0] sr_led =  4'b1111;

reg [7:0] cpc_data_in = 0; 
reg [7:0] atmega_data_in = 0; 

assign oLED = sr_led; 

assign ioCPC_DATA    = iDECODER_READ  ? atmega_data_in : 8'bz; 
assign ioATMEGA_DATA = iREAD_LATCHED_CPC_DATA ? cpc_data_in : 8'bz;  

// when out &fbee, byte -> store in cpc_data 
always @(posedge iDECODER_WRITE ) 
begin
    cpc_data_in <= ioCPC_DATA; 
end
  
always @(posedge iLATCH_ATMEGA_DATA) 
begin
    atmega_data_in <= ioATMEGA_DATA; 
end

endmodule



NET "iDECODER_READ"           LOC = "p18" ;
NET "iDECODER_WRITE"          LOC = "p21" ;
NET "iCLOCK"                  LOC = "p19" ; 

NET "iREAD_LATCHED_CPC_DATA"  LOC = "p22" ; 
NET "iLATCH_ATMEGA_DATA"      LOC = "p23" ; 

NET "ioCPC_DATA<0>"   LOC = "p39" ; 
NET "ioCPC_DATA<1>"   LOC = "p38" ; 
NET "ioCPC_DATA<2>"   LOC = "p37" ; 
NET "ioCPC_DATA<3>"   LOC = "p36" ; 
NET "ioCPC_DATA<4>"   LOC = "p30" ; 
NET "ioCPC_DATA<5>"   LOC = "p29" ; 
NET "ioCPC_DATA<6>"   LOC = "p28" ; 
NET "ioCPC_DATA<7>"   LOC = "p27" ; 


NET "ioATMEGA_DATA<0>"   LOC = "p13" ; 
NET "ioATMEGA_DATA<1>"   LOC = "p12" ; 
NET "ioATMEGA_DATA<2>"   LOC = "p8" ; 
NET "ioATMEGA_DATA<3>"   LOC = "p7" ; 
NET "ioATMEGA_DATA<4>"   LOC = "p6" ; 
NET "ioATMEGA_DATA<5>"   LOC = "p5" ; 
NET "ioATMEGA_DATA<6>"   LOC = "p3" ; 
NET "ioATMEGA_DATA<7>"   LOC = "p2" ; 


NET "oLED<0>"  LOC = "p34"  ;
NET "oLED<1>"  LOC = "p33"  ;
NET "oLED<2>"  LOC = "p32"  ;
NET "oLED<3>"  LOC = "p31"  ;




I denke, es gibt noch ein Problem im Verilog-Code vom 
FlipFlop-Emulator... wie gesagt, Bus-Konflikt wahrscheinlich.

Das ist mein 1. Verilog-"Programm".

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael W. schrieb:
> und die CPLDs erkennen das irgendwie und regeln sofort runter.
Da "regelt" nichts, sondern der eine Busteilnehmer schaltet im 
Fehlerfall seine Bus-Pins nach Plus, der andere schaltet seine Pins nach 
Minus und es fließt dadurch mehr Strom, als der Spannungsregler abkann. 
Wird der eigentlich warm?

> immer noch Flackern der Power-LEDs, und zwar von beiden CPLDs.
Alles andere wäre überaus kurios. Denn die hängen ja beide an der selben 
Spannung.

Aber wie gesagt: miss einfach mal mit dem Oszi mal entlang deiner 
Versorgungskette, wie diese Spannungseinbrüche aussehen, und ob die 
zusammen mit irgendeinem anderen Signal kommen...

Autor: Michael Wessel (michael_w385)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael W. schrieb:
> I denke, es gibt noch ein Problem im Verilog-Code vom
> FlipFlop-Emulator... wie gesagt, Bus-Konflikt wahrscheinlich.

Was aber eigentlich unmöglich ist... der CPC / Z80-Datenbus wird also 
mit dem Inhalt von atmega_data_in Register "beschrieben", wenn 
iDECODER_READ high ist.
assign ioCPC_DATA    = iDECODER_READ  ? atmega_data_in : 8'bz; 

Sonst ist der ioCPC_DATA "inout" Bus im Tristate mode (8'bz).

Einen Konflikt könnte es nur geben, wenn das iDECODER_READ "zu spät oder 
zu träge" kommen würde, wenn also der IOREQ & IORD from Z80 schon 
"vorbei" wäre. Das würde den Bus jammen. S. Address-Dekoder:
wire iorq = ~ i_IORQ; 
wire iord = ~ i_RD; 
wire iowr = ~ i_WR; 

wire read = iorq & iord; 
wire write = iorq & iowr; 

wire ssa_adr = iADR[15:0] == 16'hFBEE; 
wire ls_adr = iADR[15:0] == 16'hFBEE; 

wire internal_read  = ( ssa_adr | ls_adr ) & read;
wire internal_write = ( ssa_adr | ls_adr ) & write; 

wire oSPEECH_WRITE = internal_write; 
wire oSPEECH_WRITE_ATMEGA = internal_write; 

wire oSPEECH_READ = internal_read;  


oSPEECH_READ vom Address-Dekoder CPLD kommt als iDECODER_READ im 
FlipFlop-Emulator an.

Da niemals gleichzeitig iord und iowr gelten kann vom Z80 aus, kann ich 
mir eigentlich keinen Reim darauf machen, warum das den Bus jammen 
könnte... sind die CPLDs wirklich so träge?

Autor: Michael Wessel (michael_w385)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar M. schrieb:
> Michael W. schrieb:
>> und die CPLDs erkennen das irgendwie und regeln sofort runter.
> Da "regelt" nichts, sondern der eine Busteilnehmer schaltet im
> Fehlerfall seine Bus-Pins nach Plus, der andere schaltet seine Pins nach
> Minus und es fließt dadurch mehr Strom, als der Spannungsregler abkann.
> Wird der eigentlich warm?

Überhaupt nicht - Cool like a cucumber.

>> immer noch Flackern der Power-LEDs, und zwar von beiden CPLDs.
> Alles andere wäre überaus kurios. Denn die hängen ja beide an der selben
> Spannung.
>
> Aber wie gesagt: miss einfach mal mit dem Oszi mal entlang deiner
> Versorgungskette, wie diese Spannungseinbrüche aussehen, und ob die
> zusammen mit irgendeinem anderen Signal kommen...

OK. Mache ich.

Oder evtl. habe ich einfach einen schlechten CPLD? Ich habe 
sicherheitshalber noch mal so ein Bord bestellt... dauert aber, bis es 
kommt.

Autor: Michael Wessel (michael_w385)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael W. schrieb:
>> Minus und es fließt dadurch mehr Strom, als der Spannungsregler abkann.

Der Spannungswandler ist ja auch ein ziemlicher Oschi, verglichen mit 
den winzigen Dingern die ich ausgelötet habe...

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael W. schrieb:
> verglichen mit den winzigen Dingern die ich ausgelötet habe...
Die waren allerdings auf einem FR4-Kühlkörper montiert.

Michael W. schrieb:
> Oder evtl. habe ich einfach einen schlechten CPLD?
Rätst du noch oder misst du schon?

Autor: Michael Wessel (michael_w738)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar M. schrieb:
> Rätst du noch oder misst du schon?

OK, ich hatte meinen "Richard Feynman"-Moment (die Episode, wo er Radios 
repariert durch blosses Nachdenken... gemessen wurde da nix - nicht dass 
ich mich mit Feynman vergleich will... dafuer bin ich dann doch zu 
bescheiden ;-) )

Ich habe einmal den ATMega 644 aus dem Aufbau entfernt, und lediglich 
Adress-Dekoder CPLD und  FlipFlop-Emulator CPLD laufen lassen. Dabei 
latched der Flipflop-Emulator nun das Byte vom CPC / Z80-Bus bei IOREQ & 
WRITE, und gibt es zurueck auf den Z80 / CPC Datenbus bei IOREQ & READ 
(natuerlich auf der dekodierten IO-Adresse ausschliesslich) - ein "Echo" 
sozusagen.
  

assign ioCPC_DATA    = iDECODER_READ  ? atmega_data_in : 8'bz; 
assign ioATMEGA_DATA = iREAD_LATCHED_CPC_DATA ? cpc_data_in : 8'bz;  

// when out &fbee, byte -> store in cpc_data 
always @(posedge iDECODER_WRITE ) 
begin
    cpc_data_in <= ioCPC_DATA; 
end
  
// always @(posedge iLATCH_ATMEGA_DATA) 
// Test without ATMega: 

always @(posedge iDECODER_READ ) 
begin
    atmega_data_in <= cpc_data_in; 
end

DAs ganze ist also einfach ein Echo.
Dazu mein BASIC-Testprogramm:
10 a=round(rnd(1)*255)
20 out &fbee,a
30 b=inp(&fbee)
40 if a<>b then print a;:print b
50 goto 10

Das fuehrte bisher immer zum Flickern der Power-LEDs und Fehlern (wenn 
auch nur sporadisch, aber haeufig genug!)

Zudem habe ich die Leitung "iDECODER_WRITE" zum ATMega 644 entfernt, da 
dieser ebenfalls darauf triggert (er muss ja wissen, wann es was zu tun 
gibt). Nun triggert er also nicht mehr.

Ergebnis - nicht ein einziger Fehler in 30 Minuten, kein Flickern mehr, 
keine IO-Fehler / Byte-Differenzen im Echo! Laeuft bombenstabil.

Es liegt also irgendwie an der Interaktion zwischen dem ATMega 644-Bus 
und dem CPLD. Ich werde mir die Signale mal mit dem Logic-Analyzer 
aufschluesseln / anschauen. Anscheinend gibt es da ein 
Sychronisationsproblem.

Koennte es evtl. sein, dass die CPLD-Signalpegel nicht 100% kompatibel 
sind mit dem ATMega 644?

Es hat also alles nichts mit Spannungswandlern, GND, Kabellaengen oder 
Wacklern zu tun. Reines ATMega / CPLD Bus- oder Synchronisationsproblem.

: Bearbeitet durch User
Autor: Michael Wessel (michael_w738)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael W. schrieb:
> Es hat also alles nichts mit Spannungswandlern, GND, Kabellaengen oder
> Wacklern zu tun. Reines ATMega / CPLD Bus- oder Synchronisationsproblem.

Weiss einer, was passiert, wenn sowohl ATMega pins auf INPUT geschaltet 
sind, und CPLD im Tristate-Modus ist? Ist das eine problematische 
Kombination? Tristate fuer den ATmega gibt es ja leider nicht...

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael W. schrieb:
> Koennte es evtl. sein, dass die CPLD-Signalpegel nicht 100% kompatibel
> sind mit dem ATMega 644?
Das steht im Datenblatt und ich kann es bestätigen: sie sind es, das 
CPLD ist 5V tolerant. Ist eigentlich noch immer Ratestunde?

> Das fuehrte bisher immer zum Flickern der Power-LEDs
Dann hast du ja eine tolle Möglichkeit, endlich mal zu messen.

Ein Tipp, wenn du auch ohne Messen weiter herumbasteln willst: mach mal 
in den Bus zwischen die beteiligten Komponenten Widerstände rein. 100 
Ohm dürften genügen. Dann kommt ein Buskonflikt nicht mehr so hart 
durch, sondern wird durch die Widerstände abgeschwächt.

Und dann könntest du auch links und rechts der Widerstände messen, was 
da auf dem Bus los ist. Aber was sage ich: schon wieder "messen"...

Michael W. schrieb:
> Feynman ... die Episode, wo er Radios repariert durch blosses Nachdenken...
> gemessen wurde da nix
Ist das in der Nähe der Passage, wo er schreibt: "Ich kaufte mir ein 
Milliamperemeter und verwandelte es in ein Voltmeter mit verschiedenen 
Skalen..."?
Und noch eins zum Thema "Urban Legends": Einstein war nicht schlecht in 
Mathe... ;-)

: Bearbeitet durch Moderator
Autor: Michael Wessel (michael_w738)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar M. schrieb:

>> Das fuehrte bisher immer zum Flickern der Power-LEDs
> Dann hast du ja eine tolle Möglichkeit, endlich mal zu messen.
>
> Ein Tipp, wenn du auch ohne Messen weiter herumbasteln willst:

Mal eine Frage - was soll durch das Messen denn eigentlich 
herausgefunden werden? Ist es nicht sinnvoller, einen evtl. Buskonflikt 
durch Beobachtung mit einem Logic Analyzer zu analysieren und sich die 
ATMega Software anzusehen, ob diese evtl. Synchronisationsprobleme hat?

Das es ein elektrisches Problem gibt, weiss ich doch schon. Inwiefern 
hilft mir Deine Messerei denn beim Beheben des Problemes, bekomme ich 
daduch auch nur ein BIt an Information, dass ich nicht ohnehin schon 
habe? Evtl. fehlt mir da Deine Denke bzw. ich verstehe das nicht ganz.

> in den Bus zwischen die beteiligten Komponenten Widerstände rein. 100
> Ohm dürften genügen. Dann kommt ein Buskonflikt nicht mehr so hart
> durch, sondern wird durch die Widerstände abgeschwächt.
>
> Und dann könntest du auch links und rechts der Widerstände messen, was
> da auf dem Bus los ist. Aber was sage ich: schon wieder "messen"...

Das (Widerstaende) ist ein guter Tipp - allerdings wuerde ich da eher 
den Logic-Analyzer nehmen.

> Michael W. schrieb:
>> Feynman ... die Episode, wo er Radios repariert durch blosses Nachdenken...
>> gemessen wurde da nix
> Ist das in der Nähe der Passage, wo er schreibt: "Ich kaufte mir ein
> Milliamperemeter und verwandelte es in ein Voltmeter mit verschiedenen
> Skalen..."?

Nein, das ist die Episode, wo er durch Nachdenken darauf gekommen ist, 
dass die Roehre vom Vorverstaerker zu langsam aufheizt, und dass der 
Hauptversaerker schon warm war und Rauschen verstaerkte, und er hat die 
Roehren einfach getauscht.

Ich bezweifele ja nicht den Sinn des Messens... aber Messen kann 
vernuenftige Arbeitshypothesen und Plausibilitaets-Checks durch 
Nachdenken doch nicht ersetzen. Und es scheint mir hier keine 
Information zu liefern, die ich nicht schon habe. Logic Analyzer 
erscheint mir sinnvoller?

Sorry ich will ja nicht schwierig sein, ich will nur verstehen wie ihr 
"Elektronik-Genies" so denkt und solche Fehler analysiert. Ich bin ja 
sehr dankbar fuer die Hilfestellung hier!

Autor: Michael Wessel (michael_w738)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar M. schrieb:
> Und noch eins zum Thema "Urban Legends": Einstein war nicht schlecht in
> Mathe... ;-)

Oh, das beruhigt mich jetzt, ich war eigentlich ganz gut in Mathe :D

Autor: Michael Wessel (michael_w738)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael W. schrieb:
> vernuenftige Arbeitshypothesen

Aeh, Raten meine ich :D

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael W. schrieb:
> Mal eine Frage - was soll durch das Messen denn eigentlich
> herausgefunden werden?
Ob die Ursache solche Buskonflikte sind. Denn es ist eben nicht 
normal, dass durch eine Software die Versorgung zusammenbricht.

> Ist es nicht sinnvoller, einen evtl. Buskonflikt
> durch Beobachtung mit einem Logic Analyzer zu analysieren und sich die
> ATMega Software anzusehen, ob diese evtl. Synchronisationsprobleme hat?
Nein. Nicht bevor man nicht sichergestellt hat, dass es eben kein 
Buskonflikt ist.
Denn so ein LA zeichnet ein überaus binäres Bild seiner Umwelt. Der 
taugt bestenfalls, später irgendwelche Protokoll- oder Timingfehler 
aufzudecken.

> Ich bezweifele ja nicht den Sinn des Messens... aber Messen kann
> vernuenftige Arbeitshypothesen und Plausibilitaets-Checks durch
> Nachdenken doch nicht ersetzen.
Vernünftige Annahmen kann man nur auf sinnvollen Abbildern der Physik 
machen. Und dafür muss man messen. Wenn es auch ohne Messung ginge, 
warum gibt es dann Firmen, die solche Geräte bauen und davon leben 
können?

> allerdings wuerde ich da eher den Logic-Analyzer nehmen.
Durch die Widerstände geht das sogar wieder, weil du dann siehst, ob 
rechts und links unterschiedliche Pegel hast.

Ich nehme für solche Fälle einfach ein Oszilloskop und einen Tastkopf 
und sehe mir dei Datenleitungen an. Wenn da neben high und low auch noch 
ab&zu ein "Zwischending" auftritt, dann habe ich Buskonflikte. Und das 
kann ein LA eben nicht darstellen.

> Nein, das ist die Episode, wo er durch Nachdenken darauf gekommen ist,
> dass die Roehre vom Vorverstaerker zu langsam aufheizt, und dass der
> Hauptversaerker schon warm war und Rauschen verstaerkte, und er hat die
> Roehren einfach getauscht.
Ja, die kenne ich auch. Und da hat er eben den Fehler nicht durch 
"Nachdenken" herausgefunden, sondern durch 70% "Glück" und 30% 
"Herumbasteln".

Aber über dieses Stadium bist du bei deiner Schaltung schon lange weg. 
Denn "Herumgebastelt" hast du ja unnötigerweise schon.

Ich auf jeden Fall bin mir sicher, dass ich mit meiner Vorgehensweise 
die Ursache des Fehlers schon gefunden hätte. Das war schon ein paar 
mal der Fall...  ;-)

Autor: Michael Wessel (michael_w738)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar M. schrieb:
> Michael W. schrieb:
>> Mal eine Frage - was soll durch das Messen denn eigentlich
>> herausgefunden werden?
> Ob die Ursache solche Buskonflikte sind. Denn es ist eben nicht
> normal, dass durch eine Software die Versorgung zusammenbricht.

OK, das verstehe ich! Wuesste zwar nicht, was es sonst sein koennte... 
ja, ich werde das ueber Wochenede mal machen und dann hier posten.

Danke fuer diese Erlaeuterungen, sehr hilfreich!

Autor: Michael Wessel (michael_w385)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke nochmal an alle, die geholfen haben.

Es funktioniert jetzt. I habe den bidirektionalen 8bit breiten IO-Bus 
zwischen CPLD und ATMega 644 in 2 getrennte input / output Busse 
aufgesplittet. Das macht die Synchronisation ueberfluessig, und die 
Software auf dem ATMega einfacher.

Zudem hatte ich einen daemlichen Programmierfehler - ich habe auf 
ATMega-Seite in meinem "Echo-Testprogramm" fuer den Kommunikationstest 
doch tatsaechlich die Pins mittels "PIND = output" "beschrieben", statt 
korrekterweise "PORTD = output" zu nehmen! Also kein Wunder, dass es zu 
Bus-Konflikten kam und es nicht funktionierte... Da hatte ich das 
Breadboard aber schon auf getrennte Busse geaendert, als ich das 
bemerkte, insofern weiss ich nicht, ob ausschliesslich dieser 
Programmierfehler fuer das Flickern der Power-LEDs / den Buskonflikt 
verantwortlich war. Nun, getrennte Input/Output-Busse ist ohnehin die 
sauberere Loesung IMHO. Kein Flickern mehr, und keine Uebertragungs- / 
Synchronisations-Probleme mehr.

Und - ich hatte tatseachlich auch ein defektes Kabel!! Und einen 
umgebogenen Pin am ATMega... einen Wackler auf Datenbus-Seite. Die Augen 
werden halt doch etwas schlechter mit zunehmenden Alter. All diese 
kleinen Problemchen summieren sich, und machen die Fehlersuche / das 
Prototyping mit Breadboards manchmal etwas frickelig. Nun, davon lassen 
sich Bastel-Freunde wie ich einer bin nicht entmutigen ;-)

Also, es funktioniert jetzt alles, nochmals vielen Dank fuer die 
Anregungen,

Gruss,
Michael

: Bearbeitet durch User
Autor: Michael Wessel (michael_w385)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
So sieht der Drahtverhau jetzt aus. Funktioniert einwandfrei.

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.

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