Hello, Guest the thread was called23k times and contains 482 replays

last post from 0xdeadbeef at the

250466+ oder der Versuch ein klassisches Board etwas zu optimieren

    Na ja, die einzelnen Produktionsschritte sind vollautomatisch, aber irgendwelche Hanseln mit Papiermützen stehen daneben und überwachen die Maschinen, räumen Werkstücke rein und raus, fahren sie zur nächsten Maschine usw.

    Wie auch immer: die Produktion hat überraschend schnell angefangen. Vermutlich weil die Platinen so riesig sind und man nicht warten mußte, genügend kleine Platinen in einen "Nutzen" zusammenzustückeln.

    Deshalb hoffe ich im Augenblick, daß die Platinen vielleicht wirklich (wie derzeit angekündigt) am Montag fertig sind. Das wäre wahnsinnig schnell für den Preis. Dienstag ist das Werk wegen irgendeines Feiertages geschlossen, aber wenn ich Glück habe, sind die Platinen dann schon verschickt. Aber selbst Mittwoch wäre noch sehr flott.

    Auf jeden Fall müssen sie bis Anfang Oktober aus China raus sein, denn dann macht dort alles für mindestens eine Woche dicht. Und eigentlich hätte ich sie gerne bis zum 4.10., denn dann müßte ich Zeit haben, eine davon in Betrieb zu nehmen.

    Quote from 0xdeadbeef

    die Produktion hat überraschend schnell angefangen. Vermutlich weil die Platinen so riesig sind

    Mit genau der Begründung hätte ich eher erwartet, dass es etwas dauert, bis man Platz für den Auftrag irgendwo dazwischen frei bekommt, die fahren garantiert eine Grundlast mit eigenen Projekten resp. als Auftragsfertiger mit festen Mengen.


    Aber letztlich egal, Hauptsache die tun was ;-)


    Du hast mich übrigens grad auf ne Idee gebracht: so ne große UND komplexe PCB hab ich noch nie mit meiner LPKF-Platinenfräse gefräst, muss mal schaun, ob ich noch eine doppelseitige A3 Roh-Platine rumliegen habe, der Maschinentisch ist A3+, d.h. da passt das locker drauf...


    Das Dumme an selbstgefrästen PCBs ist immer nur das Duko-"Nieten" oder verlöten, das ist echte Sklavenarbeit... Es gibt zwar so Leitpasten, die man in die Vias schmieren kann und dann thermisch aushärten lässt, aber die leiten nicht ideal, d.h. für Versorgungssignale sind die überhaupt nicht geeignet und wenn man nahe dran rumlötet gehen die auch gern mal hopps... Und chemisch/galvanisch verzinnen ist ne Riesensauerei, das habe ich schon länger aufgegeben, denn dann könnte man auch gleich noch belichten, entwickeln und ätzen (anstelle des Isolationsfräsens), wenn man eh schon zig Bäder mit Naß-Chemie dann rumstehen hat...



    Wenn man die PCB selbst layoutet und weiß, die wird inhouse gefräst, dann schaut man natürlich auch drauf, möglichst viele Dukos mit den Pins zu erschlagen oder gleich ein paar Drahtbrücken mit einzubauen, dafür aber den Rest umso einfacher gestalten zu können...

    Also das Board hat ~1600 Pins und zusätzlich um die tausend Vias. Ich habe alleine ca. 400 Vias manuell gesetzt, um die oberen und unteren Masselayer zu verbinden. Das ist definitiv kein Board, das man selbst fertigen will.

    Dagegen wirken die originalen Board mit ihren wenigen riesigen Durchkontaktierungen charmant altertümlich.

    Und mal ehrlich: bei den heutigen Preise lohnt sich die Herstellung nicht mehr wirklich, außer man braucht einen Prototypen am gleichen Tag. Und speziell bei SMD-Bauteilen ist Lötstopplack schon extrem hilfreich.

    Habe gerade gesehen, daß es in der Statusübersicht auch Links auf Videos gibt, wie dieser Produktionsschritt so aussieht.

    Also damit sind wir schon durch:


    Drilling:

    https://jlcpcb.com/video/2.Drilling.mp4


    Copper Deposition:

    https://jlcpcb.com/video/3.CopperDeposition.mp4


    Leider scheint es das dann für Samstag gewesen zu sein, aber Montag geht es dann weiter...

    Es war ja von Anfang an angekündigt, daß die Fertigung am Montag fertig wird. Schaun wir mal. Wie gesagt ist Dienstag Feiertag wegen eines Mondfests oder sowas, also kann es natürlich sein, daß es Mittwoch wird. Wäre aber auch noch super.

    Aber ich bin ja wie gesagt eh schon positiv überrascht, wie schnell meine doch recht großen und relativ komplexen Gerber in Produktion gegangen sind.

    Zumindest vom bisherigen Handling finde ich JLCPCB besser als SEED Studio und Elecrow, wo ich meine China-Platinen bisher bestellt hatte.

    Also OK, die scheinen doch mehr oder weniger rund um die Uhr zu arbeiten. Ist bei einer solchen Anlage natürlich auch irgendwie sinnvoll.



    Image the outer layers

    https://jlcpcb.com/video/4.%20Imagetheouterlayers.mp4


    Pattern Plating

    https://jlcpcb.com/video/5.PatternPlating.mp4


    Bin nur erstaunt über den eklatanten Mangel an Papiermützen ;)

    So, die Produktion ist seit 18Uhr oder so abgeschlossen, aber es sieht wohl so aus, als würden die PCBs wegen dieses Mondfests erst am Mittwoch in den Versand gehen.


    Ansonsten wird es langsam Zeit, sich über die Mikrocontrollersteuerung Gedanken zu machen. Ich habe dazu zwei Header vorgesehen.

    Auf dem Microcontrollerstecker liegen 10 Signale:


    TOD: 50/60Hz Takt

    IRQ: IRQ-Leitung

    EXROM: EXROM für Hard Reset

    INTRST: Resetleitung

    SID_A5_SEL: Adreßauswahl SID

    SID_A8_SEL: Adreßauswahl SID

    Kernal A13: Adreßauswahl Kernal

    Kernal A14: Adreßauswahl Kernal

    Kernal A15: Adreßauswahl Kernal

    JoySwap: Joystick Swap


    Die ersten beiden Signale sind Eingänge, die man nicht unbedingt braucht.

    Die letzten 8 Signale sind Ausgänge, die alle bei Bedarf auf Masse gezogen werden müssen (Open Drain, externe Pullups im C64).


    Der zusätzliche Tastatur-Header hat insgesamt 17 Pins: Je 8 Spalten und Zeilen sowie eine eigene Leitung für Restore. Im Prinzip braucht man nicht alle Zeilen und Spalten, aber ich hätte gerne die Freiheit, die Joystickumschaltung auf Restore+J oder so zu legen und die Kernalumschaltung auf Restore+1/2/3/4/5/6/7/8 oder so.


    Ich würde außerdem gerne eine zweifarbige LED ansteuern, um Sachen wie die die Kernalumschaltung, und den Joystickswap rudimentär anzuzeigen. 5 mal blinken links für Kernal Nr. 5, an/aus recht für Joystickswap oder so.

    Damit wären wir bei mindestens 17 Eingängen und 10 Open-Drain-Ausgängen.


    Die naheliegendste Lösung wäre ein oller AVR Mega oder sowas mit 5V-Versorgung und genügend Pins, aber ich werde "aus Gründen" einen anderen Weg nehmen. Weil ich seit zehn Jahren oder so privat nur noch 32bit Arm-Controller von NXP benutzt habe, werde ich einen kleinen LPC8xx und einen 16bit-Portexpander benutzen. Weil ich damit bisher am meisten gemacht habe und 90% des Quellcodes direkt übernehmen kann, wird der Microcontroller wohl ein LPC824 werden und für den Port-Expander habe ich einen MCP23S18 (SPI, Open-Drain-Ausgänge) im Auge.


    Der LPC8xx übernimmt die SPI, 2 Ausgänge (INTRST + EXROM), 8 Tastatureingänge, den Restore-Eingang und eventuell spaßeshalber IRQ und TOD (obwohl ich noch keine Ahnung habe, was ich damit mache).

    Der Port Expander übernimmt die anderen 8 Tastatureinänge, die 6 Open-Drain-Ausgänge für SID, Kernal, Joyswap und die zwei Ausgänge für die zweifarbige LED.

    Damit kann man die ganze Tastatur abfragen und anhängig von Tastaturkombinationen Resets auslösen, den Kernal umschalten, die SID-Adressen umschalten (zumindest Dual Mono/Stereo) und die LED(s) blinken lassen.

    Beim Powerup würde ich sofort die Resetleitung runterziehen, die letzte Konfiguration aus dem NVRAM lesen, die entsprechenden Konfigurationspins runterziehen und dann erst den Reset freigeben.


    So ganz zu Ende gedacht habe ich das noch nicht, aber die Idee ist, daß eine längliche Platine auf den beiden Header sitzt. Auf der Platine wären im Wesentlichen nur der LPC824, der MCP23S18, ein 3.3V LDO und ein paar passive Elemente (Widerstände für die Eingänge und Kondensatoren für den LDO und die ICs). Und natürlich der Header für die zweifarbige (Gehäuse-)LED. Ich stelle mir ca. 8x3cm oder so vor. Also relativ klein und flach. Die Platine würde senkrecht auf den beiden Header stecken.


    In einer zukünftigen Luxusversion könnte man sich vorstellen, einen größeren Mikrokontroller und Matrixschalter zu benutzen, um Tastastur- oder Joystickeingaben zu simulieren. Aber das ist definitiv kein Ziel für dieses Jahr.

    Macht bei so vielen Tastenkombi's nicht auch ein Display Sinn? Mit LED Blinkcodes weiß man nach drei Monaten Nichtbenutzen dann nix mehr anzufangen :). Also mir ginge es so.

    "Was heute noch wie ein Märchen klingt,kann morgen Wirklichkeit sein.Hier ist ein Märchen von übermorgen.Es gibt keine Kupferka­bel mehr,es gibt nur noch die Glasfaser und Terminals in jedem Raum.Man siedelt auf fernen Rech­nern.Die Mailboxen sind als Wohnraum erschlossen.Mit heute noch unvorstellbaren Geschwindigkeiten durcheilen Computerclubs unser Da­tenverbundsystem.Einer dieser Com­puterclubsist der CCC.Gigantischer Teil eines winzigen Sicher­heitssystems,das die Erde vor Bedrohungendurchden Gilb schützt.Begleiten wir den CCC und seine Mitglieder bei ihrem Patrouillendienst am Rande der Unkenntlich­keit. CCC'84 nach ORION'64"

    Quote from 0xdeadbeef

    Damit kann man die ganze Tastatur abfragen und anhängig von Tastaturkombinationen Resets auslösen, den Kernal umschalten, die SID-Adressen umschalten (zumindest Dual Mono/Stereo) und die LED(s) blinken lassen.

    Meinst Du mit "ganze Tastatur abfragen" aktiv abfragen, also ein Port wählte eine Spalte oder Zeile aus, der andere schaut als Eingang, was durchkommt, sprich welche Taste gedrückt ist?


    Und wie verhinderst Du, die Tastatur zeitlich genau parallel zum C64 abzufragen? Unsynchronisiert freilaufend sehe ich als worst case die betroffene CIA in Gefahr aber auf jeden Fall bekommst Du dann sporadisch irgendwelche Zeichen in den C64 eingelesen, die Du da sicher nicht haben willst ;-/


    Also auf die Abfrage des C64 "lauern", sprich IRQ on Change auf den von den CIAs als Ausgang bestromten Leitungen und dann wahlweise warten, bis der C64 fertig ist, oder die Steilvorlage nutzen und gleich mitlesen am anderen Port ...


    Ob ein SPI-Portexpander dafür dann sinnvoll ist, wenn es darum geht, auf ca. 10 µs genau jeweils die Pegel abzufragen, nachdem ein IRQ rein kam, das wage ich zu bezweifeln, aber ok, der LPC taktet natürlich schon deutlich schneller, aber dann wirst Du dort auf Assembler gehen müssen, wenigstens für die IRQ-Routine...


    Hat der LPC nicht genug Pins, um das alles intern zu machen oder läuft der nur an 3V3 (also ohne 5V I/O-Toleranz?) *) und Du scheust den Aufwand mit den vielen Pegelwandlern?



    edit: Idee: Du findest raus, auf welche Flanke des TOD-Signals hin der C64 den IRQ startet und nimmst die andere Flanke, dann bist Du mit Deiner Abfrage weitmöglichst von der des C64 entfernt... Rein auf restore zu triggern (musst ja auch noch entprellen...) und dann sofort abfragen birgt wie gesagt die Gefahr, mit der Abfrage des C64 zu kollidieren... Da macht es vermutlich mehr Sinn, wirklich NUR auf TOD zu triggern und dann restore und falls "true" auch die Matrix abzufragen. Durch die feste Abfragefrequenz lässt sich dann auch einfach entprellen...



    *) OT: Darum setze ich bis heute auf die Microchip PIC Familie, die skaliert auch mit 5V ordentlich hoch und hat verdammt viele HW-Goodies, die anderswo in Assembler-Orgien ausarten... Nur die PSoCs von Cypress sind da noch besser aufgestellt, aber das sind schon arge Exoten...

    Also im Prinzip bin ich ein großer Fan von Displays, aber das Hauptproblem ist halt, daß die Platine in einem geschlossenen Gehäuse sitzen soll. Selbst mit transparentem Gehäuse wäre das Display kaum ablesbar, ansonsten müßte man Löcher ins Gehäuse schneiden oder Kabel raushängen lassen.

    Kann man natürlich alles machen, aber ich will im Augenblick nur eine möglichst elegante, nicht-invasive Lösung. Und da ist eine zweifarbig blinkende Gehäuse-LED halt die naheliegendste Lösung. Und ich will ja keine Morsecodes oder so ausgeben ;)


    Ich dachte an sowas wie: Restore halten und 1-8 drücken: auf Kernal 1-8 umschalten. Wenn man die Restore-Taste losläßt, gibt es einen Reset und die eine Farbe blinkt 1-8 mal, um anzuzeigen, was man ausgewählt hat. Wenn man im Betrieb Restore + K drückt, wird der Blinkcode für den aktuellen Kernal wiederholt. Wenn man Restore+J drückt, wird der Joystickport umgeschaltet und die andere LED/Farbe zeigt den Zustand an. Oder so.


    Über die SID-Umschaltung und deren Anzeige habe ich mir noch keine richtigen Gedanken gemacht. Aber es gibt ja vier Adressen, also würden sich die Funktionstasten anbieten. Also z.B. Restore+Funktionstaste um eine der vier Adressen auszuwählen und Restore+S, um den jetzigen Zustand (1..4) per Blinkcode anzuzeigen.

    Dann gehört der "Affengriff" natürlich auch dazu ^^. Wer will schon HardReset:thumbup:

    "Was heute noch wie ein Märchen klingt,kann morgen Wirklichkeit sein.Hier ist ein Märchen von übermorgen.Es gibt keine Kupferka­bel mehr,es gibt nur noch die Glasfaser und Terminals in jedem Raum.Man siedelt auf fernen Rech­nern.Die Mailboxen sind als Wohnraum erschlossen.Mit heute noch unvorstellbaren Geschwindigkeiten durcheilen Computerclubs unser Da­tenverbundsystem.Einer dieser Com­puterclubsist der CCC.Gigantischer Teil eines winzigen Sicher­heitssystems,das die Erde vor Bedrohungendurchden Gilb schützt.Begleiten wir den CCC und seine Mitglieder bei ihrem Patrouillendienst am Rande der Unkenntlich­keit. CCC'84 nach ORION'64"

    Ruudi:

    Ich gebe zu, daß ich das mit der Tastaturabfrage nicht völlig zuende gedacht habe. Ich hatte gehofft, daß ich die Tastatur belauschen kann, indem ich alle Zeilen- und Spaltenpegel permanent auslese. Ich hatte für die kleine Lösung nicht vor, aktiv irgendwelche Pegel anzulegen.Wobei nach meinem Verständnis die CIAs auch nur gegen Masse ziehen können und interne Pullups haben. Insofern würde ich, wenn überhaupt, nur gegen Masse ziehen können.

    Und ja, der Portexpander ist auch deswegen angedacht, weil die 3.3V-Microcontroller in der Regel nur dann 5V-tolerant sind, wenn sie spannungsversorgt sind. Einzige Ausnahme: die echten Open-Drain-Pins (I2C). Die Eingänge machen mir dabei weniger Sorgen als die Ausgänge. Ich bräuchte also eine ganze Menge externer Transistoren für die zu schaltenden Ausgänge.

    Quote from 0xdeadbeef

    elbst mit transparentem Gehäuse wäre das Display kaum ablesbar, ansonsten müßte man Löcher ins Gehäuse schneiden oder Kabel raushängen lassen.

    Aber der C64 hat doch schon ein Display, in dessen Inhalt du deine anzuzeigenden Dinge einblenden könntest...

    Öhm. Du willst, daß ich mich für einen Kernalumschalter in das Videosignal einschleife? Also sorry, aber dazu wird es sicher nicht kommen.

    Also eigentlich bin ich bin mit meiner Blinklösung zufrieden. Über ein optionales I2C-OLED-Display kann man sicher diskutieren. Ist eher eine Frage der freien Pins.

    Über das Abfangen der Tastendrücke muß ich nochmal nachdenken. Was gehen müßte, wäre während des Drückens der Restore-Taste einen eigenen kleinen Tastaturscan zu machen. Auf Masse ziehen kann ich ja. Eventuell müßte man das mehrfach machen, um Kollisionen mit einem auf dem C64 laufenden Tastaturscan rauszufiltern. Um die Wahrscheinlichkeit dafür einzuschränken, könnte man eventuell den IRQ-Pin benutzen. Aber wie gesagt: so richtig durchdacht habe ich das noch nicht.

    Quote from 0xdeadbeef

    Ich bräuchte also eine ganze Menge externer Transistoren für die zu schaltenden Ausgänge.

    ULN2803 = acht lowside Driver bis 500mA, UDN2981 = 8 Hiside-Driver entsprechend, gibt es seit Mitte der 70er Jahre, auch unter anderen Kürzeln (MIC etc), immer noch eine gute Lösung und erst recht in einem Retro-Projekt...


    Die CIA kann sehr wohl auch aktiv Hi schalten, hat halt kaum FAN-OUT, aber genau das macht es ja so gefährlich für diesen Baustein, der ist leicht "überstimmt" durch externen Pegel mit mehr Power dahinter...


    Und da man nie weiß, was die Applikation oder auch ein Absturz so alles in die CIA reinschreibt, wäre ich vorsichtig mit aktiven Pegeln, daher ja der Vorschlag "belauschen", aber das wiederum erfordert ein exaktes Timing, da der Kernal die Leitungen des CIA (nach einer generellen Abfrage, ob irgendwas gedrückt ist) nacheinander und einzeln durchschaltet, um die gedrückte Taste dann eindeutig zu identifizieren und so gegebenenfalls auch gleichzeitige Mehrfachdrücke erkennen kann...


    Das ist ein relativ komplexer Vorgang (wenn man darauf extern triggern und reagieren will...), der auch je nach der Anzahl der gedrückten Tasten mal kürzer mal länger dauert, daher haben sich die Entwickler von Tastaturadaptern ja auf die (schweineteuren und inzw. teils schwer verfügbaren) Schaltmatrix-ICs zurückgezogen...


    zu der 3V3 Problematik:


    Die Bestromung deines Controllers kannst Du doch durch Festeinbau auch sicherstellen, Längswiderstände von ein paar hundert Ohm in den Portleitungen schaden auch selten und steigern die Überlebenschance im Falle eines Falles erheblich. Oder hast Du Angst, allein der Einschaltvorgang könnte da zu was führen? Bis 3V3 ist ja alles ok, d.h. kannst Du ja den C64 mit nem Powerwatchdog oder schlicht einem selbst setzenden Flipflop (das der LPC dann zurücksetzt, wenn er selbst bereit ist) im Reset halten, dann sind auch die CIAs hochohmig...

    Quote from 0xdeadbeef

    Eventuell müßte man das mehrfach machen, um Kollisionen mit einem auf dem C64 laufenden Tastaturscan rauszufiltern.

    Tja, der C64-Kernal filtert aber nicht, d.h. bekommst Du zumindest im Falle einer gedrückten Taste dann am C64 eine Fehl- oder Doppelerkennung, was im Falle eines nachfolgenen Reset zwar nicht stört, aber die angedachte Abfrage während des Betriebs kannst Du maximal über längeres Halten der Restore-Taste realisieren, alles Andere führt (ohne aufwändige Elektronik zw. Tastatur und C64-tastaturanschluss) zu Erkennungen auch seitens des C64 und somit Eingriffen in die Applikation oder unschöne Zeichen am Prompt...


    Und die im obigen edit: erwähnte abwechselnde Flankensteuerung funktioniert nur solange, bis ein Programm, wie z.b. der Tiny-Prommer die CIA-Ports an Joystick und Tastatur zweckentfremdet oder meinetwegen auch eine Joystickroutine die schlampig implementiert und Pegel dauerhaft setzt...


    jetzt kannst Du argumentieren, dass Du ja nur dann die Kombi drückst, wenn Du wirklich umschalten willst und dazu notfalls auch aus dem Programm rausgehen kannst, aber was, wenn Dein LPC eben solche Aktivitäten wie joystickabfrage etc. stört oder gar daraus Aktionen wie Neustart ableitet?