Hallo zusammen, vor gut 10 Jahren stellte ich hier meinen Umbau eines HP3478A Tischmultimeters vor, bei welchem das batteriegepufferte CMOS-SRAM durch eine AVR-MCU "emuliert" wurde: Beitrag "HP3478A: SRAM durch ATmega48 ersetzt" Nachdem ein zweites HP3478A hier seit Jahren auf diesen Umbau wartet, nutzte ich die Gelegenheit, um Schaltung und Leiterplatte grundlegend zu überarbeiten: Die MCU ist nun ein ATtiny417 im 24-beinigen VQFN Gehäuse, der auch für 20MHz Taktfrequenz keine externe Beschaltung benötigt. Das Layout ist sehr einfach: Port C0--C3 sind mit der unteren Hälfte des Datenbus' verbunden, Port B mit dem Adressbus und die obere Hälfte von PortA mit den Steuersignalen CE2,OD, /CE1 und R/W. Programmiert wird die MCU über die UPDI-Schnittstelle, die auf drei Pads geführt ist. Die Abgleichdaten des HP3478A liegen in gepackter Form im EEPROM des ATtiny417, jeweils zwei Nibbles in einem Byte, wobei das mit der kleineren Adresse im unteren Nibble liegt. Beim Einschalten kopiert das C-Programm der MCU die Daten aus dem EEPROM in ihr SRAM und springt eine Assemblerfunktion an, welche mit den Daten im RAM arbeitet, wobei Schreibzugriffe diese aktualisieren. Einen Reset des HP3478A erkennt die MCU daran, dass CE2 auf low geht und springt dann zurück in das C-Programm. Wurden die Daten aktualisiert, so werden die veränderten Bytes in das EEPROM der MCU geschrieben. Die Daten aus dem batteriegepufferten CMOS-SRAM können über die GPIB-Schnittstelle ausgelesen werden, siehe: Beitrag "Re: Alte 6502/Z80-Systeme:Ohne CPU betreibbar zum Batterie-RAM Auslesen?" -- und auf diesem Weg dann auch in die "RAM-Emulation" geschrieben werden, wobei sich der Frontplattenschalter "CAL ENABLE" in senkrechter Stellung befinden muss. Noch ein Hinweis für die Verifizierung der Daten: Das HP3478A prüft regelmäßig, ob es Schreibzugriff auf das SRAM besitzt, indem des die RAM-Adresse 0 abwechselnd mit 0 oder 16 (hex. F) beschreibt. In dem zitierten Thread aus dem EEVBLOG-Forum findet sich auch eine Analyse des Formats der Abgleichdaten. Damit können diese in die Werte Offset und Gain zurückverwandelt werden. Somit ist es möglich den Abgleich des HP3478A anzupassen. Da ich von den winzigen Leiterplatten viel zu viele herstellen ließ, biete ich hiermit an, ein paar unbestückte Exemplare kostenlos abzugeben, solange mein Vorrat reicht. Selbstverständlich übernehme ich keinerlei Gewährleistung und schließe eine Haftung für Schäden kategorisch aus! Der Einbau dieser Hardware erfolgt ausschließlich auf eigenes Risiko. Einen Reparatur-, Bestück-, Programmier- oder Einbauservice kann und will ich nicht anbieten, ebenso biete ich keinen Support. Die Firmware wurde in zwei Modellen des HP3478A erfolgreich getestet (Datecode der verbauten ICs: 1983 und 1988). Eine Garantie, dass die Schaltung in sämtlichen hergestellten HP3478A funktioniert, kann ich jedoch nicht abgeben! Die Leiterplatte kann entweder in 70771 Echterdingen abgeholt werden oder gegen Zusendung eines ausreichend frankierten und adressierten Rückumschlags zugesendet werden, wobei ich darum bitte, zuvor per PM nachzufragen, ob noch Leiterplatten vorhanden sind, denn das Angebot gilt nur solange, wie mein Vorrat reicht, was m.E. selbstverständlich sein sollte. :-/ Das Hexfile mit der Firmware für den ATtiny417 sende ich per eMail zu. Dafür bitte eine PM mit der eigenen eMail-Adresse übermitteln. Hexfiles für die pinkompatiblen MCUs ATtiny817, --1617 oder --3217 kann ich erzeugen, aber nicht testen. Vermutlich passen auch ATtiny807 und ATtiny427, jedoch kann ich das nicht testen. Nachtrag: Im EEVBLOG-Forum findet sich ein nettes Skript, welches den "Calibration data string" eines HP3478A auf Korrektheit der Prüfsummen testet und dann die Werte für Offset und Gain berechnet: https://www.eevblog.com/forum/repair/hp-3478a-how-to-readwrite-cal-sram/msg5426804/#msg5426804 Grüßle, Volker P.S.: Da wir hier in Deutschland sind, bitte ich darum, in der PM expizit zu erwähnen, dass mein Haftungsausschluss akzeptiert wird und der Einsatz von Leiterplatte und Firmware auf eigenes Risiko erfolgt.
Angehängte Dateien:
-
RamEmu3478A_Layout.jpg
140 KB -
RamEmu3478A_pcb.jpg
160 KB -
RamEmu3478A.jpg
190 KB
:
Verschoben durch Moderator
OK, wenn man Spaß daran hat, solch ein RAM mit einem Controller zu ersetzen, dann verstehe ich das. Aber notwendig ist das nicht. Die Kalibrierwerte, die in dem RAM liegen, kann man per GPIB auslesen. Ich vermute, du weißt dass auch? Und wenn dann die Batterie nach > 30 Jahren mal den Geist auf gibt, lötet man eine neue ein und spielt die Kalibrierwerte per GPIB wieder ein. Sehe ich als einfacher an.
Hallo, 900ss schrieb: > Sehe ich als einfacher an. Mit passendem GPIB-Adapter mag das ja einfach sein, aber was macht man wenn wenn man keinen Adapter hat? rhf
Roland F. schrieb: > aber was macht man wenn wenn man keinen Adapter hat? Man nimmt sich Kais USBTMC: Beitrag "Sammelbestellung USBTMC Adapter. Interesse?" (oder Hans' Prologix-Version, aber da fummele ich gerade noch ein paar pull requests duch Pymeasure durch dafür) Anyway, wenn du dir Volkers Beitrag durchgelesen hättest, wüsstest du, dass der Zugriff auf die Kalibrierdaten über GPIB ohnehin Voraussetzung für das ganze Projekt ist, denn nur damit bekommt man sie aus dem SRAM heraus und in den AVR dann wieder rein.
Jörg W. schrieb: > Zugriff auf die Kalibrierdaten über GPIB ohnehin Voraussetzung für das > ganze Projekt ist, denn nur damit bekommt man sie aus dem SRAM heraus > und in den AVR dann wieder rein. Nö, ich glaube da hat mal einer die Daten über den Bus des SRAMs mitgelesen. Aber mit GPIB ist es viel einfacher. Sowas mit dem AVR zu machen ist eine schöne "Übung" aber es geht halt einfacher.
:
Bearbeitet durch User
900ss schrieb: > Nö, ich glaube da hat mal einer die Daten über den Bus des SRAMs > mitgelesen. Ja, ist halt noch riskanter, denn dann hast du keinen "Kalibrierung erlaubt"-Schalter mehr, der die Daten schützt. Volker hatte jedoch ganz explizit auf die GPIB-Methode verwiesen, um an die nötigen Daten zu gelangen.
Jörg W. schrieb: > Ja, ist halt noch riskanter Das stimmt. Jörg W. schrieb: > Volker hatte jedoch ganz explizit auf die GPIB-Methode verwiesen, um an > die nötigen Daten zu gelangen. Das wusste ich nicht. Dann ist so ein AVR als Ersatz wirklich nur noch "weil es funktioniert". Aber wenn jemand Spaß daran hat das mit AVR zu lösen, dann kann man nichts sagen ;)
900ss schrieb: > (...) Dann ist so ein AVR als Ersatz wirklich nur noch > "weil es funktioniert". Aber wenn jemand Spaß daran hat das mit AVR zu > lösen, dann kann man nichts sagen ;) OMG, kannst Du Dir nicht vorstellen, dass andere Menschen vielleicht andere Prioritäten setzen als Du? Nein, ich habe keine Lust alle paar Jahre die Batterie in meinen beiden HP3478A zu kontrollieren oder noch besser "ganz schnell" eine Ersatzbatterie zu organisieren und diese einzulöten, wenn ich dringend eine Messreihe aufnehmen sollte, denn ich halte mir meine Messgeräte nicht zum Selbstzweck. Auch wage ich zu bezweifeln, dass eine Ersatzbatterie nochmals so lange durchhält wie die originale, denn die Flussmittelreste, die beim Austausch der Batterie anfallen, sind nach meiner Erfahrung hygroskopisch, was deren Lebensdauer reduziert. Ich habe eine zuverlässige Lösung für mich gefunden. Der Zeitaufwand war weitgehend unerheblich und ich konnte auch noch ausloten, ob der "freundliche Chinese" eine solche Leiterplatte zuverlässig fertigen kann. Das Projekt war also eine Mischkalkulation und glücklicherweise bist Du nicht mein Controller. :-) Grüßle, Volker
Volker B. schrieb: > kannst Du Dir nicht vorstellen, dass andere Menschen vielleicht andere > Prioritäten setzen als Du? Nein, Doch, habe ich sogar mehrmals geschrieben. Jeder wie er mag. Ich habe lediglich eine andere Möglichkeit gezeigt. Ich kontrolliere die Batterie nie in meinen Geräten. Wenn sie zufällig genau dann den Geist aufgibt, wo es "wichtig" ist, na ja..... ich verdiene da kein Geld mit. Also "dringend" ist das nichts. Wenn eine neue eingelötete Batterie dann nur 10 Jahre halten sollte.... schulterzuck. Aktuell sind noch die Originale verbaut. Volker B. schrieb: > Das Hexfile mit der Firmware für den ATtiny417 sende ich per eMail zu. Das ist mir schon suspekt. Weshalb steht hier nicht der Sourcecode und die Platinendaten zum selber fertigen. Ist doch keine Raketentechnik um da so ein Geheimnis drum zu machen. Aber ich würde es eh nicht nutzen. Nur weil du dein Projekt hier vorgestellt hast. Volker B. schrieb: > und glücklicherweise bist Du nicht mein Controller. :-) Ja, glücklicherweise ;)
:
Bearbeitet durch User
900ss schrieb: > Volker B. schrieb: >> Das Hexfile mit der Firmware für den ATtiny417 sende ich per eMail zu. > > Das ist mir schon suspekt. Weshalb steht hier nicht der Sourcecode und > die Platinendaten zum selber fertigen. Weil ich das Projekt nicht hier veröffentlicht habe, sondern in "µC & Elektronik". > Ist doch keine Raketentechnik um da so ein Geheimnis drum zu machen. > Aber ich würde es eh nicht nutzen. Nur weil du dein Projekt hier > vorgestellt hast. Da kann ich nur Dich zitieren: > Ja, glücklicherweise ;) Mein Code, meine Regeln. Grüßle, Volker
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.