Pulldowns sind nicht ganz so einfach wie Pullups. Mal sehen.
Bitte melde dich an, um diesen Link zu sehen.
Es gibt 295 Antworten in diesem Thema, welches 49.570 mal aufgerufen wurde. Der letzte Beitrag (
Pulldowns sind nicht ganz so einfach wie Pullups. Mal sehen.
Bitte melde dich an, um diesen Link zu sehen.
Bitte melde dich an, um diesen Link zu sehen.
So in der Art meinte ich das...
Ich war ja nicht vollkommen untätig, und so habe ich mal geschaut, wie viel Platz wir auf der Platine brauchen. Hätte ich wohl nicht tun sollen ![]()
Wir müssen uns was ausdenken, denn viel Platinenplatz ist teuer.
SMD ist wohl nicht drin, hm?
crasbe
Edit: Wir müssen auch PLCC einsetzen, wenn auch mit Sockeln.
Ich war ja nicht vollkommen untätig, und so habe ich mal geschaut, wie viel Platz wir auf der Platine brauchen. Hätte ich wohl nicht tun sollen
Wir müssen uns was ausdenken, denn viel Platinenplatz ist teuer.
SMD ist wohl nicht drin, hm?
SMD passt zu so einem Projekt ja gar nicht... PLCC ist schon grenzwertig, für das ROM aber noch OK. Alles andere sollte DIP bleiben.
Wieviel Platz hast du denn ausgrechnet?
Ausgerechnet habe ich noch nichts, aber ich habe mal alle Chips auf ein Board geworfen.
So sieht das dann etwa aus: Bitte melde dich an, um diesen Link zu sehen.
Die Schieberegister werden wohl noch rausgeworfen und die W65Cxx-Chips enger gepackt.
Was würde dagegen sprechen - wenn möglich - , den einen oder anderen Logichip in einem AVR zusammenzufassen? Einen AVR mit der nötigen Firmware zu beschreiben ist nicht schwer, das "Programmiergerät" besteht im einfachsten Fall aus einem Parallelportstecker und ner Handvoll Widerständen. Sollte für jeden, der nen Lötkolben halten kann, ne Sache von 10 Minuten sein.
Ich glaube, dass der AVR nicht schnell genug sein wird um die Logik nachzubilden. Ich will ja mit einer Taktfrequenz von 8 MHz arbeiten. Wenn ich den AVR mit 16MHz takte, habe ich 2 Takte um das auszuwerten. Selbst, wenn man nur PortB zu PortD übertragen muss, ist man bei mindestens 2 Takten.
Die andere Methode wäre ein CPLD. Dann hätte man keine Sorgen über Platzbedarf oder soetwas. Ich halte den XC9572 von Xilinx für geeignet. Er wäre billiger als der Platinenplatz für die Logikchips.
Man könnte außerdem einfach Register bauen und Speicherlayouts umschalten usw usf.
Der Nachteil ist eben, dass das keine Standardlogik ist, die man an jeder Ecke bekommt. Ich würde aber die Möglichkeit einbauen, dass der CPLD vom AVR aus (wenn der AVR nicht vom CPLD verschluckt wird) beschreibbar ist.
MfG.
crasbe
Die meisten programmierbaren Logikchips lassen sich ja über meist sehr simpel gestrickte Programmieradapter beschreiben, sollte also eigentlich nix gegen sprechen.
Ausgerechnet habe ich noch nichts, aber ich habe mal alle Chips auf ein Board geworfen.
So sieht das dann etwa aus: Bitte melde dich an, um diesen Link zu sehen.
Die Schieberegister werden wohl noch rausgeworfen und die W65Cxx-Chips enger gepackt.
Ich hatte die Planung so in Erinnerung, dass der AVR auf eine extra Karte sollte die bei Bedarf angesteckt wird... und der Rest müsste deutlich enger zu machen sein, auch wenn man nur eine doppelseitige Platine hat.
Was würde dagegen sprechen - wenn möglich - , den einen oder anderen Logichip in einem AVR zusammenzufassen?
Viel zu langsam, schon bei 1 MHz... Ausserdem kannst du nicht viel sparen. Die eigentliche Logik sind ein paar TTLs (74LS00, 74LS02, 74LS04, 74LS05 und vielleicht ein 74LS125 plus die 74LS138 ). Wenn du dir das genau anschaust wirst du sehen, dass das Problem nicht Logikterme sondern Pins sind.
Programmierbare Logikbausteine a la GAL mag ich nicht, ist nur wieder eine Zeitbombe und nicht von jedem programmierbar.
Ich wollte eigentlich keinen GAL einsetzen, sondern einen CPLD. CPLDs sind insofern von Vorteil, dass man sie auch mit dem AVR flashen kann. Dann kann man einfach mal die Logikterme ändern und eine Programmierumgebung hat man idr. auch schon.
Einen kleineren Mikrocontroller als den ATMega1284P würde ich nicht einsetzen, da man einerseits die zwei UARTs braucht, als auch der viele Programmspeicher. Es muss ja einiges rein in das kleine Ding.
Mich stört der FT232RL in SMD etwas, da das nicht jeder löten kann. Es gibt aber leider keinen vergleichbaren Chip in non-SMD und eine Adapterplatine von SSOP auf DIL wäre auch alles andere als rentabel. Allein die kostet mehr als der Chip ansich und außerdem kostet es Platinenplatz.
Vielleicht kann man die Rolle des FT232 noch in den CPLD packen. Dann hätte man viele Chips weg.
Die Kommunikation CPLD <-> AVR würde mit dem SPI-Modul des AVRs gestalten, da dieses in Hardware implementiert ist und man so keine Rechenzeit dafür verschwenden muss. Außerdem braucht SPI wenig Pins.
Einen Wannenstecker für ISP würde ich vorsehen, falls der Bootloader crasht oder solche Geschichten. Der AVR wird dann über den Bootloader von dem Programm aus mit Daten gefüttert. Danach kommt der CPLD und dann Flash und SRAM.
Ich werde mich wohl mal ransetzen und mich ein wenig in VHDL einfuchsen.
MfG.
crasbe
Ich wollte eigentlich keinen GAL einsetzen, sondern einen CPLD. CPLDs sind insofern von Vorteil, dass man sie auch mit dem AVR flashen kann. Dann kann man einfach mal die Logikterme ändern und eine Programmierumgebung hat man idr. auch schon.
Wobei genau dieses nicht nötig ist. Es gibt keinen Grund die Logikterme zu ändern, oder willst du die Basisadressen der I/O-Chips und Banking-Register verschieben? Alles andere kannst du nicht ändern ohne die Funktion zu verhindern. Ebenso wie ein GAL ist ein CPLD eine Zeitbombe da es sich die Programmierung auch nur ein EEPROM/Flash-Zellen merkt die eine begrenzte Lebensdauer haben. Mit TTLs kannst du die Schaltung auch in 20 Jahren noch aufbauen (vorausgesetzt du bekommst den 6502 noch), aber bekommst du das CPLD (nicht vergessen +5V!) dann noch? Eher nicht, also gar nicht erst dran denken.
Mit CPLD hast du ausserdem die gesamte Logik in einem Klotz. Bei TTLs kann man aus dem Schaltplan was lernen. Beim CPLD sieht man nur einen Klotz mit vielen Leitungen, aber kann nicht mehr einfach Signale verfolgen und dabei lernen wie das alles zusammenpasst.
Zitat
Einen kleineren Mikrocontroller als den ATMega1284P würde ich nicht einsetzen, da man einerseits die zwei UARTs braucht, als auch der viele Programmspeicher. Es muss ja einiges rein in das kleine Ding.
Ich persönlich brauche den AVR und Schieberegister gar nicht sobald ein Monitorprogramm mit Binary-Upload über RS232 im ROM ist. Sowas passt in 2 KB des ROMs, mit etwas Luxus sind es maximal 4 KB.
Zitat
Mich stört der FT232RL in SMD etwas, da das nicht jeder löten kann. Es gibt aber leider keinen vergleichbaren Chip in non-SMD und eine Adapterplatine von SSOP auf DIL wäre auch alles andere als rentabel. Allein die kostet mehr als der Chip ansich und außerdem kostet es Platinenplatz.
Gut... Den FT232 weglassen und dafuer einen MAX232 (in DIP) drauf und eine echte RS232 verbauen.
Nicht vergessen, das soll ein Nostalgie-System werden... sowas baut man mit der dazu passenden Logik auf.
Wobei genau dieses nicht nötig ist. Es gibt keinen Grund die Logikterme zu ändern, oder willst du die Basisadressen der I/O-Chips und Banking-Register verschieben? Alles andere kannst du nicht ändern ohne die Funktion zu verhindern. Ebenso wie ein GAL ist ein CPLD eine Zeitbombe da es sich die Programmierung auch nur ein EEPROM/Flash-Zellen merkt die eine begrenzte Lebensdauer haben. Mit TTLs kannst du die Schaltung auch in 20 Jahren noch aufbauen (vorausgesetzt du bekommst den 6502 noch), aber bekommst du das CPLD (nicht vergessen +5V!) dann noch? Eher nicht, also gar nicht erst dran denken.
Das ist in der Tat ein Punkt, den man bedenken muss. Allerdings ist es häufig so, dass die 3,3V CPLDs einen 5V-toleraten Eingang haben, sodass man nur eine 3,3V Stromquelle benötigt.
Also jetzt nicht sooo das Problem. Außerdem könnte man die Logikgleichungen als Papierdokumentation beilegen, um dann in der dunklen Zukunft den CPLD nachbrennen zu können.
ZitatMit CPLD hast du ausserdem die gesamte Logik in einem Klotz. Bei TTLs kann man aus dem Schaltplan was lernen. Beim CPLD sieht man nur einen Klotz mit vielen Leitungen, aber kann nicht mehr einfach Signale verfolgen und dabei lernen wie das alles zusammenpasst.
Es ist die Frage, wer dabei etwas lernen soll. Wir alle hier lernen bei diesem Projekt eine Menge und das ist auch gut so. Aber $Endanwender wird sich kaum mit der Logik beschäftigen (wollen).
ZitatIch persönlich brauche den AVR und Schieberegister gar nicht sobald ein Monitorprogramm mit Binary-Upload über RS232 im ROM ist. Sowas passt in 2 KB des ROMs, mit etwas Luxus sind es maximal 4 KB.
Auch das ist ein Argument. Wenn man den ATMega und die Bauteile drumherum weglässt, spart man viel Platz auf der Platine, der sowieso schon sehr begrenzt ist.
Andererseits verliert man den Luxus des Debuggings. Man kann den ATMega auf eine Zusatzkarte legen, wo er dann seine Arbeit verrichten kann.
Dazu müssten wir allerdings den Schaltplan etwas umbauen bzw überdenken, da im Moment der UART an den ATMega sendet und der über USB an den PC.
Wenn man den ATmega als Option einbaut, bräuchte man zwei Verbindungen. Einmal RS232 für den UART und einmal USB für den ATMega.
ZitatGut... Den FT232 weglassen und dafuer einen MAX232 (in DIP) drauf und eine echte RS232 verbauen.
Zur Not könnte ich bei einer Sammelbestellung den FT232 bereits auf die Platine löten. Das mit RS232 ist immer so eine Sache, da RS232 ausstirbt und die Dongles kosten auch wieder 5€.
ZitatNicht vergessen, das soll ein Nostalgie-System werden... sowas baut man mit der dazu passenden Logik auf.
Ich hatte es bisher weniger als Nostalgie-System gesehen, sondern mehr als modernen Einplatinencomputer...
Wegen der Platine: Ich war wieder etwas am Routen und das ist dabei rum gekommen: Bitte melde dich an, um diesen Link zu sehen.
Die WDC-Chips und der Flash-Speicher sind verdrahtet. Das SRAM bereitet mir etwas kopfzerbrechen da die Adress und Datenleitungen etwas atypisch angeordnet sind.
KiCAD ist auch etwas zickig und buggig beim Layouten. Sei es, dass man 10 mal klicken muss, bis eine Leiterbahn gelöscht ist oder solche Späße...
Eine schöne Nacht noch,
crasbe
Es ist die Frage, wer dabei etwas lernen soll. Wir alle hier lernen bei diesem Projekt eine Menge und das ist auch gut so. Aber $Endanwender wird sich kaum mit der Logik beschäftigen (wollen).
Dann stellt sich aber die Frage für was das ganze denn gemacht wird.
Endanwender sehe ich da keine, aber als Lernmittel ist es wohl brauchbar um sich mal auf die untere Ebene der Datenverarbeitung zu begeben.
Dann stellt sich aber die Frage für was das ganze denn gemacht wird.
Es soll Leute geben, die machen das als Hobby.
Bei Hobbys greift die Sinnfrage bekanntlich nicht.
Btw. dieses Prinzip gefällt mir auch: Bitte melde dich an, um diesen Link zu sehen. . Eine Bus-Platine die alle weiteren Karten aufnehmen kann.
Auch das ist ein Argument. Wenn man den ATMega und die Bauteile drumherum weglässt, spart man viel Platz auf der Platine, der sowieso schon sehr begrenzt ist.
Andererseits verliert man den Luxus des Debuggings. Man kann den ATMega auf eine Zusatzkarte legen, wo er dann seine Arbeit verrichten kann.
Dazu müssten wir allerdings den Schaltplan etwas umbauen bzw überdenken, da im Moment der UART an den ATMega sendet und der über USB an den PC.
Wenn man den ATmega als Option einbaut, bräuchte man zwei Verbindungen. Einmal RS232 für den UART und einmal USB für den ATMega.
Nein, es reicht eine... Wenn der AVR auf einer Zusatzkarte sitzt, kann man, so man ihn nicht will, dort einfach eine kleine Platine mit MAX232 dranstricken. Das geht kurz mal auf Lochraster.
Zitat
Zur Not könnte ich bei einer Sammelbestellung den FT232 bereits auf die Platine löten. Das mit RS232 ist immer so eine Sache, da RS232 ausstirbt und die Dongles kosten auch wieder 5€.
Von der RS232 wird das schon seit Jahren behauptet. Es ist eher so, dass sie wiederkommt weil man sie noch braucht und eine RS232 als Interface so schoen einfach zu realisieren ist. Selbst die kleinen Microcontroller (AVR 2313) haben eine on die.
Zitat
Ich hatte es bisher weniger als Nostalgie-System gesehen, sondern mehr als modernen Einplatinencomputer...
Da würde man eine andere CPU verwenden und dafür gibt es schon jede Menge Systeme auf AVR-Basis und anderem, in jeder Preis- und Leistungsklasse. Allerdings dort eben ohne nachvollziehbare Logik und in SMD.
Zitat
Wegen der Platine: Ich war wieder etwas am Routen und das ist dabei rum gekommen: Bitte melde dich an, um diesen Link zu sehen.
Die WDC-Chips und der Flash-Speicher sind verdrahtet. Das SRAM bereitet mir etwas kopfzerbrechen da die Adress und Datenleitungen etwas atypisch angeordnet sind.
Der 16550 ist in PLCC? Wie kommts? Wenn möglich sollte DIP verwendet werden. Wegen des RAM, das ist auch nur eine Erweiterung der Pinbelegung des 62256 und 628128, ich sehe dort nichts atypisches.
Btw. dieses Prinzip gefällt mir auch: Bitte melde dich an, um diesen Link zu sehen. . Eine Bus-Platine die alle weiteren Karten aufnehmen kann.
Er benutzt leider GALs...
Er benutzt leider GALs...
Ich meinte das _Prinzip_ ! - Man könnte es aufteilen: CPU-Board mit Adresslogik, I/O-Karte (incl. RS232) und eine Memory-Card. Der ganze Kram wird dann auf ein Bus-Board gesteckt, auf dem auch die Stromversorgung untergebracht wird.
Durch das Splitting hat man dann allerdings sehr hohe Kosten, wenn man die Leiterplatten anfertigen lassen muss.
Der 16C550 kostet in DIL das doppelte.
Deswegen habe ich ihn in PLCC-Ausführung eingeplant.
Der 16C550 kostet in DIL das doppelte.
Deswegen habe ich ihn in PLCC-Ausführung eingeplant.
Interessant... PLCC im Sockel ist immer so eine Sache, braucht spezielles Werkzeug um den Chip da wieder rauszubekommen und macht gerne Probleme mit den Kontakten (Siehe Agnus im Amiga). Deshalb hätte ich das gerne vermieden.