Ja, für einen Schuss ins Blaue würde ich jetzt nicht woanders Chips auslöten.
Aber da ja eh Kühlkörper drauf sind, kann ja ein Versuch mit einem Ventilator/Lüfter nicht schaden, um zu gucken, ob der Rechner dann länger durchhält.
Ja, für einen Schuss ins Blaue würde ich jetzt nicht woanders Chips auslöten.
Aber da ja eh Kühlkörper drauf sind, kann ja ein Versuch mit einem Ventilator/Lüfter nicht schaden, um zu gucken, ob der Rechner dann länger durchhält.
Ich meine mal gehört zu haben, dass die 407 Assy besonders zickig ist, was das PLA-Timing angeht. Vielleicht ist die PLA schon gut gealtert und läuft minimal aus dem Timing, wenn die ein bisschen warmgelaufen ist.
Hast Du zufällig eine andere PLA bzw. einen (vernünftigen) PLA-Ersatz da?
Hast Du alternativ die Möglichkeit, die Temperatur der PLA etwas länger kühl zu halten? Provisorisch einen alten CPU-Kühlkörper mit etwas Wärmeleitpaste draufpatschen?
Ist nur ins Blaue geraten, natürlich.
Da die Signale des User-Ports über Pinleiste erreichbar sind, dürfte es kein Problem sein, ein WiFi-Modem draufzupappen. Wäre dann sogar hübsch intern.
Nun, ist ja nur ein Vorschlag, um den Tape-Port weiter herauszuführen, wenn der Platz für den ursprünglichen Platinenstecker für andere Dinge gebraucht wird - das ist schon verdammt viel Platz für die sechs Pins. Mit etwas wie Mini-DIN bekäme man da vermutlich halbwegs problemlos (Mini-)HDMI und Micro-USB herausgeführt. Vielleicht gibt es auch etwas mechanisch stabileres als gerade Mini-DIN - und sei es eine abgewinkelte doppelreihige Pinleiste.
Für Joysticks, deren Kabel ja schonmal mechanisch belastet und ad-hoc verlegt werden, stelle ich mir Mini-DIN tatsächlich etwas wackelig vor - ob das bei der Datasette des C16 schon nervig war, müssten mal Leute mit C16-Erfahrung schildern.
edit: Der Datasettenport ließe sich z.B. über einen 6-poligen gewinkelten Wannenstecker, wie z.B. auf Bitte melde dich an, um diesen Link zu sehen. zu sehen, platzsparend herausführen. Günstig, halbwegs robust, mechanisch vermutlich ausreichend stabil, ohne Einsatz von Gewalt verpolungssicher. Nicht unbedingt schön, aber u.U. ein Kompromiss zu "entweder - oder".
Wenn man Platz für neue Ports braucht: Wie wäre es damit den Tape-Port als Mini-DIN Buchse wie beim C16 auszuführen? Gibt ja sogar fertige Adapter, um herkömmliche Datasetten anzuschließen...
edit: Hmm... die Abmessungen von Mini-DIN (z.B. Bitte melde dich an, um diesen Link zu sehen. ) sind so ca. 14 mm breit, 13 mm hoch. Bin mir nicht sicher, ob die Aussparung im Gehäuse hoch genug ist, da die Platine ja mittig in der Aussparung liegt. Aber die Grundidee, sich einen platzsparenden Connector zu suchen und bei Bedarf einen Adapter anzustöpseln, bleibt ja.
Ui, klar, ein Bustreiber wäre natürlich eine saubere Lösung - einen Widerstand bräuchte man aber doch, um !OE schwach gegen Masse zu ziehen, damit der nicht rumfloatet, wenn kein Programmer angestöpselt ist. ![]()
Ansonsten habe ich endlich das gemacht, was ich längst hätte tun sollen: Einfach mal ein bisschen simuliert, was bei meiner Skizze oben denn so passiert, auch wenn es eigentlich trivial ist:
Bitte melde dich an, um diesen Anhang zu sehen.
Wer hätte es gedacht: Im Falle einer Buskollision gewinnt der stärkere Treiber... Captain Obvious und so ![]()
Danke euch für den Input!
Bleiben wir also mal bei deinem Ansatz. Ich würde CS vomProgrammerpin evtl. in einen neuen FPGA-Pin einspeisen und
mit diesem dann in der Flashphase die restlichen SPI-Pins
Hi-Z setzen. Nachteil: Du verlierst einen FPGA-Pin und darfst
um Gottes Willen nicht Flashen, wenn ein fremdes Design
geladen ist.
Eine interessante Idee mit dem Extra-Pin, um dem FPGA mitzuteilen, er soll sich mal abklemmen.
Sofern ich die Widerstände wie in der Skizze habe, dann sollte doch eigentlich auch bei Fremd-Designs nichts wirklich Schlimmes passieren: Der Programmer übernimmt de-facto den Bus und der FPGA liest Blödsinn und ggf. landen seine Schreibzugriffe im Nirvana - aber zumindest dürfte keine Hardware bei drauf gehen. Das ist zumindest das, was ich hoffe ![]()
Hallo,
das ist eigentlich eine Frage für ein Elektronikforum - aber hier scheinen ja genügend Kundige antreffbar zu sein und ich empfinde die Community hier einfach als angenehmer als das, was ich in dem einen oder anderen deutschen Elektronikforum schonmal mitlesen musste... insofern mich bitte sanft und liebevoll darauf hinweisen, wenn das Thema hier gar nicht reinpasst.
Ich bastel ja gerne an FPGA-Zeugs (siehe Bitte melde dich an, um diesen Link zu sehen.) und habe für diese billigen ~20 Euro FPGA Boards ("ep2c5 mini board", z.B. Ebay) eine Platine entworfen, die 512Kx8 SRAM, SPI-ROM (nun, eigentlich ist es ja Flash) und ein paar Pins für eine UART-Schnittstelle vorsieht:
Bitte melde dich an, um diesen Anhang zu sehen.
Die Idee ist, beim Poweron/Reset den SRAM mit den Daten aus dem SPI-ROM zu initialisieren, damit anschließend der Softcore im FPGA mit vernünftigen (Programm-)Daten loslegen kann. Platine habe ich fertigen lassen und zusammengelötet - und funktioniert.
Ich habe vorgesehen, den SPI-ROM entweder in einen Sockel zu packen (U2) oder auf die Platine selbst zu löten (U3). Im ersteren Falle würde man dann den SPI-ROM zum Programmieren von der Platine ziehen, im zweiten Fall würde man über den Sockel die Programmierung vornehmen - dann müsste ich aber die ganze Platine vom FPGA-Board herunternehmen, da die Leitungen direkt durchverbunden sind und ich die Signale des Programmers nicht einfach so auf den FPGA loslassen will (es ist i.d.R. keine gute Idee, an ICs, die nicht mit Versorgungsspannung versorgt werden, über die Signalleitungen was reindonnern zu lassen) und der Programmer auch nicht die 3,3 Volt-Schiene des FPGA-Boards befeuern soll.
(Eine dritte Möglichkeit wäre natürlich, einen Programmer in den FPGA zu laden und dem dann z.B. über UART die Daten reinzureichen, dazu hatte ich aber bisher keine Lust.)
Für eine eventuelle Weiterentwicklung möchte ich aber eigentlich das Teil über In System Programming (ISP) beschreiben - also SPI-ROM drauflöten, rauf auf das FPGA-Board und dann über eine Programmierpinleiste die Daten draufpumpen. Hier muss man natürlich aufpassen, dass nicht versehentlich sowohl Programmierer wie auch FPGA mit voller Kraft in entgegengesetzter Richtung an derselben Leitung ziehen - da verliert u.U. der weniger robuste und hat anschließend einen GPIO weniger.
Ist es prinzipiell vertretbar, das wie folgt zu lösen?
Bitte melde dich an, um diesen Anhang zu sehen.
Für R würde ich sowas wie 1K vorsehen - dann fließen im schlimmsten Fall 3,3 Milliampere zwischen Programmer und FPGA, was sowohl Programmer wie auch FPGA locker verkraften dürften. Ein Tauziehen müsste der Programmer im Zweifel immer gewinnen.
Das Ganze soll insbesondere auch dann funktionieren, wenn der FPGA läuft, damit ich den nicht dauernd von der Spannungsquelle abstöpseln muss - deshalb kann auch weiterhin das Board den SPI-ROM mit Energie versorgen. Soll auch der Programmer Energie liefern dürfen, dann müsste ich eine Schottky-Diode für VCC vorsehen, um zu verhindern, dass das FPGA-Board über den Programmer gespeist wird. Dann habe ich da aber im Normalbetrieb einen Spannungsabfall auf der Versorgungsleitung des SPI-ROM und die Datensignale vom FPGA hätten auf einmal ein höheres Spannungsniveau als VCC am SPI-ROM. Das Datenblatt des SPI-ROM erlaubt "nur" VCC+0,4 Volt als "Absolute Maximum Rating", was mit einer einer gut gewählten Schottky-Diode einzuhalten sein müsste - aber ich kann gut damit leben, wenn ich nur bei betriebsbereitem FPGA-Board den SPI-ROM beschreiben kann.
Habe ich da irgendwo einen fatalen Fehler in meinen Überlegungen, oder passt das vermutlich soweit? Danke!
Statt Dir ne neue Komplettplattform zuzulegen, schau lieber ob dein Board noch ne höhere CPU verkraftet.
LGA 1155 endet wohl bei Core i7 3770K, 3,5 bis 3,9 GHz.
Wenn er jetzt schon ein i7 2600(k) hat, dann liegt er ja schon bei 3,4 bis 3,8 GHz. Umrüsten würde dann nichts bringen.
edit:
Wenn es ihm um Softwareentwicklung/Compilerzeit geht, dann ist Bitte melde dich an, um diesen Link zu sehen. vielleicht ganz interessant. Moderne Plattformen können da die Performance gegenüber einem i7 3770K verdoppeln.
Bitte melde dich an, um diesen Link zu sehen.
Lad Dir da mal ne ältere Version runter, die noch Cyclone 2 z.B. unterstützt (13.1 müsste gehen, wenn ich mich recht entsinne). Kost nix!
Ich glaube der Cyclone II geht nur bis 13.0sp1. Damit traktiere ich meine Cyclone II Boards.
Für die Funktion der Sockel ist das egal - erhöht lediglich das Risiko, dass irgendjemand später mal die Bausteine falsch herum einsetzt.
Ich würde die Maschine vermutlich so lassen. Sauber machen, ggf. versuchen den Gilb zu mildern. Für mich würde die Kiste nicht "originaler" werden, wenn ich erhaltene Originalteile großartig tauschen müsste, mit Labeltransplantation (weil soll ja "Original" sein) etc. - die Maschine hat gelebt und der Erstbesitzer hat die Maschine jetzt nicht gerade gnadenlos verbastelt. Nutz doch die Schalter für was nützliches ![]()
edit: Nur zur Sicherheit - das wäre nur mein Vorgehen, weil ich persönlich es interessanter fände, die Kiste als "Zeitdokument" zu erhalten. Wer es interessanter findet, solche Maschinen wieder in den "Auslieferungszustand" zu bringen, der kann das natürlich auch versuchen. Ich persönlich finde den aber bereits gut genug dokumentiert. Ansichtssache.
Ich glaube die 0,5µs/cm Zeitbasis sind ein starker Indiz dafür, dass das keine 50 Hz Einstrahlung ist ![]()
Das ist eine Welligkeit, die ganz typisch für Schaltregler ist. Die Peaks zwischendrin zeigen an, wann der Schalttransistor umgeschaltet wird.
Das dürfte normaler Schaltregler-Ripple sein. Für mich sieht das wie ~10mV peak-to-peak aus. Sofern hier kein Profi vehement widerspricht: Ist normal und passt.
Oje, erst jetzt gesehen...
Deshalb auch von mir die besten Wünsche!
Glückwünsch zum wunderbaren Projekt!
Drücke die Daumen, dass es ab jetzt alles schön smooth weitergeht mit dem bring-up!
Sofern Zugriffe auf das Dateisystem gecacht werden (und das werden sie heutzutage praktisch immer), dann *muss* man das Dateisystem sauber aushängen. Dieses Problem ist nicht umgehbar, egal welches Betriebssystem. Moderne Dateisysteme (mit Journaling) lassen sich i.d.R. nach einem unsauberen Abziehen dennoch wieder einhängen (die erkennen, dass was im Busch ist und versuchen sich selbst wieder geradezuziehen anhand des Journals), aber das verhindert nicht, dass halb geschriebene Dateien auch nachher nur halb geschrieben sind.
Wer nicht sauber aushängt, erhält keine Garantie über den Zustand von Dateien, für die zum Zeitpunkt des Abziehens noch Schreiboperationen ausstehend waren.
Hui, interessanter Verlauf! Meine Aussage "Luxus" fusst darauf, dass das Datenblatt ja explizit sagt, dass meistens ein "22µF ceramic" reicht und auf die Annahme, dass die damit die Nennkapazität meinen - und das habe ich verdoppelt. Wie ich aber selber messen kann, tut ein low-ESR Elko der Qualität der Ausgangsspannung doch ganz gut, da hätte man also noch mehr tun können.
Danke für die Hinweise, diesen Link erstmal zu den Lesezeichen hinzugefügt ![]()
Zu den Kondensatoren: Das Datenblatt hat da eigentlich ziemlich entspannte Anforderungen:
Eingangskondensator: "For most applications, a 4.7μF ceramic capacitor is sufficient" - ich habe da einen mit 22µF (wie in deren Schaltungsbeispiel)
Ausgangskondensator: "For most applications, a 22μF ceramic capacitor will be sufficient." - ich habe da einen mit 47µF (wie in deren Schaltungsbeispiel)
Da bin ich also jeweils durchaus im Luxus - nützt natürlich alles nichts, sollte das Layout nichts taugen ![]()