Kurz ma ne frage (die sparte für Denkstützen)

Seiten: 1 | 585 | 586 | 587 | 588 | 589 | 590 | 591 | 592 | 593 | 594 | (595) | 596 | 597 | 598 | 599 | 600 | 601 | 602 | 603 | 604 | 618
Zurück zur Startseite

shaun

07.07.13 19:39

Die Verbindung gehört natürlich an die Linie drunter, wo es zum Vcc vom Proz geht.

Ich ging davon aus, dass es ein kommerzielles Gerät ist, und bei denen habe ich mehr als einmal erlebt, dass die Adress- und/oder Datenleitungen irgendwo vertauscht waren, was dann im EPROM natürlich entsprechend abgebildet wurde.
Entweder um das Reverse Engineering zu erschweren, oder einfach (das ist im Fall von nur 2-3 verdrehten Leitungen wahrscheinlich) weil in der Serienplatine ein Layoutfehler war. Oder, das aber eher als theoretische Mäglichkeit, weil der Layouter zu faul war, es sauber zu machen.

Die Frage nach dem Disassemblieren war auch durchaus so gemeint.
Je intelligenter Compiler oder auch Assembler werden, desto eher optimieren die mal was weg. Compileroptimierung ist das TuneUp-Utility für Programmierer. Auf den ersten Blick schneller, auf den zweiten findet aber keiner mehr die Fehler.
Bei Assembler hält sich die Problematik natürlich in Grenzen, bei C-Compilern schaue ich öfter mal in den Output, wenn etwas nicht so richtig läuft.

Letztlich ist es doch so, der Proz sieht nicht, was Du dem Assembler gegeben hast, sondern was am Ende vom EPROM an seinen Beinchen anliegt.

Was passiert denn konkret mit den Daten über 0x4000 - Du schriebst ja, dass dort Texte liegen. Wird da was Falsches angezeigt, oder hängt sich die Ausgaberoutine ganz weg, weil das 0x00 am Ende fehlt oder oder ... nur um eine Idee zu bekommen, was er da anstellt. Wenn dort Zeichen aus dem Codebereich kommen, liegt es nahe, dass A14 doch noch unterbrochen ist und statt 0x4000++ 0x0000++ gelesen wird.


andreas6

07.07.13 19:40

Hallo,

ich habe mal den Analysator bestückt (das ist eine langwierige Hiwi-Arbeit) und eingeschaltet - noch geht er:



Am Eprom des Akkumasters sieht ein "kleines" Programm (< 0x4000) ziemlich normal aus. Oben A0 bis A14 auf A0 bis B5 mit /CE auf B7, unten Daten auf C0 bis C7:





Das müsste ich nun noch mal für ein "großes" Programm machen. Dummerweise ist das Anklemmen des Eproms mit den vielen Einzelklemmen sehr mühsam. Mal sehen, ob in dem Zentner Zutaten auch ein fertiger 28-Pin-Dil-Adapter ist.

MfG. Andreas


shaun

07.07.13 19:43

Naja das funktionierte ja auch. Interessanter wäre zu sehen, ob A14 zuckt, wenn Du von dort liest...

andreas6

07.07.13 19:55

Hallo,

shaun:
Die Verbindung gehört natürlich an die Linie drunter, wo es zum Vcc vom Proz geht.

korrekt, ist auch dort dran, eben noch mal gemessen.

Ich ging davon aus, dass es ein kommerzielles Gerät ist, und bei denen habe ich mehr als einmal erlebt, dass die Adress- und/oder Datenleitungen irgendwo vertauscht waren, was dann im EPROM natürlich entsprechend abgebildet wurde.

Das ist hier nicht der Fall. Ohne Benutzung der obersten Adressleitung geht dort alles 1:1 durch. Die oberste Leitung ist gemessen und für gut befunden worden.

Was passiert denn konkret mit den Daten über 0x4000 - Du schriebst ja, dass dort Texte liegen. Wird da was Falsches angezeigt, oder hängt sich die Ausgaberoutine ganz weg, weil das 0x00 am Ende fehlt oder oder ... nur um eine Idee zu bekommen, was er da anstellt.

Es passiert schlicht gar nichts, zumindest nichts sichtbares. Im init wird u.a. das Lcd mit Text beschickt, die Leds aus gemacht etc. - alles Dinge, die nicht mehr stattfinden.

MfG. Andreas

ferdimh

07.07.13 20:05

Hast du mal den Inhalt des EPROMs verifiziert? Ich erinnere mich an meinen Programmer, der intern mit einem Puffer arbeitet, und unter einem bestimmten Satz Bedingungen (ich meine, man musste dafür eine "überlange" Datei laden) intern ungültige Daten hält, ins EPROM brennt und gegen eben diese ungültigen Daten verifiziert.

andreas6

07.07.13 20:13

Hallo,

der Eprom gilt zunächst als fehlerfrei. Der alte Eprom-Brenner kann noch deutlich größere Eproms und er macht ein echtes Verify.

MfG. Andreas

shaun

07.07.13 20:46

> Es passiert schlicht gar nichts, zumindest nichts sichtbares. Im init wird u.a. das Lcd mit Text beschickt, die Leds aus gemacht etc. - alles Dinge, die nicht mehr stattfinden.

Liegen denn über 0x4000 nun nur Datenbereiche (Texte), oder doch Code? Denn wenn dort Texte liegen, die zum Display geschickt werden, müsste ja zumindest Quark geschickt werden, oder bestenfalls 0xFF, oder aber die Ausgaberoutine hängt sich an irgendwas auf.

andreas6

07.07.13 21:10

Hallo,

da oben liegen nur Daten, konkret Texte. Der Code liegt deutlich darunter.

Ich habe gerade mal die Zutaten durchsucht, es sind keine 28er Testclips dabei! Dafür reichlich 40er - Frechheit! So einen habe ich an die bunten Leitungen gesteckt, 1:1 von der bisherigen Kontaktierung übernommen. Wenn der Eprom ganz leicht gesteckt ist (das war er die bisherigen 390 Male auch nur), komme ich mit dem 40er Testclip gut drauf. Die vorhandenen Chipsockel sind leider für eine mechanische Aufstockung ungeeignet, weil entweder zu breit mit quer liegenden Pins oder Präzisionssockelstreifen, so richtig billige Fassungen habe ich nicht. Leider schlug der erste Test fehl, das Programm läuft. Noch mal im Brennprogramm nachgeschaut - 0x3fe5 ist noch zu wenig. Noch ein paar alte Calls reaktivieren...

MfG. Andreas


shaun

07.07.13 21:12

Naja aber dann müsste man es doch testweise so hingebastelt bekommen, dass die Hexcodes der vom Proz gelesenen Bytes ausgegeben werden, wenn sich anderweitig nicht verstehen lässt, was da passiert. Oder halt mit dem Analyzer mitschneiden, wo ein entsprechender Zugriff wirklich landet.

andreas6

07.07.13 21:20

Hallo,

zunächst mal letzteres - das ist alles fertig bestückt. Ich habe noch drei alte Aufrufe mit Parametern rein genommen, dann musste ich wieder bei über 0x4000 landen.

MfG. Andreas


2takt_raser

08.07.13 12:08

Und ich wieder

Was bedeutet denn die Bezeichnung z.B. 10k/w bei Kühlkörpern, oder besser was muss ich für einen haben, wenn ich ~3-4W an Wärme aus einem To-220 gehäuse kühlen will ?

Gruß

ferdimh

08.07.13 12:17

10 K/W bedeutet, dass sich der Kühlkörper um 10 Kelvin erwärmt, wenn du 1 Watt Wärme reinheizt.
Ergo wird ein Transistor mit 4Watt Verlustleistung den Kühlkörper auf 40K (=40°C) über Lufttemperatur erwärmen (das wäre ok, außer du baust das Ding in ein enges Gerät ein, wo die Luft schon 50°C hat). Da der Wärmeübergang zum Transistor auch einen Widerstand hat, sollte ein Kühlkörper nicht über 90°C heiß werden.

Sascha

08.07.13 12:25

10K/W ist der Wärmewiderstand. Der Kühlkörper wird um 10°C wärmer als die Umgebung wenn er 1W abführen muss. Bei 4W sind es dann 40°C über Umgebung. Du musst allerdings noch den Wärmewiderstand Juction-Case des Transistors dazurechnen. Dieser liegt meist im Bereich 1,5K/W. Zusammen also 11,5K/W. Wenn der Transistor nun 4W verballert, wird der Chip also 46°C wärmer als die Umgebung. Bei derzeit üblichen 30°C Umgebungstemperatur sind das also 76°C Chiptemperatur. Passt also.

2takt_raser

08.07.13 12:41

Danke !

avion23

08.07.13 14:19

Hi Andreas,

probier doch mal das funktionierende 4k Programm zu verwenden und Daten, die auf dem LCD o.ae. ausgegeben werden, dahinter zu schreiben.

Wenn es dann nicht funktioniert:
Das 4k Programm zweimal hintereinander schreiben. Also in 0 - 4k und in 4k - 8k. Wenn es dann noch funktioniert das zweite 4k Programm so abaendern, dass du es erkennen kannst (ID auf dem LCD).
Damit kannst du erkennen, ob der Bereich 4k - 8k wieder auf den 0 - 4k Bereich gemapt wird.

Zurück zur Startseite
Seiten: 1 | 585 | 586 | 587 | 588 | 589 | 590 | 591 | 592 | 593 | 594 | (595) | 596 | 597 | 598 | 599 | 600 | 601 | 602 | 603 | 604 | 618