Robotrontechnik-Forum

Registrieren || Einloggen || Hilfe/FAQ || Suche || Mitglieder || Home || Statistik || Kalender || Admins

Willkommen Gast!

Robotrontechnik-Forum » Technische Diskussionen » Experimentier-Karte für A71x0 » Themenansicht

Autor

Thread - Seiten: -1-

000
20.10.2025, 16:44 Uhr
Ordoban

Mein nächstes Projekt wird eine Art Universal/Prototyp/Experimentierkarte für A7150/A7100.
So etwa stelle ich mir das vor:

Zentral sitzt ein mittelgroßer CPLD. In den gehen alle Bus-Signale, und der übernimmt alle zeitkritischen Aufgaben.
Im CPLD können auch schon einfache I/O-Aufgaben realisiert werden. Für komplexere Aufgaben würde ich einen ESP32 vorsehen. Den würde ich so an den CPLD anschließen, dass ein Oktal-SPI-Bus möglich ist.
Die restlichen Pins des ESP32 und des CPLD werden an ein Lochraster-Feld geführt, und können für beliebige eigene Aufbauten benutzt werden.

Als CPLD würde ich Xilinx XC95144XL oder XC95288XL nehmen. Die sind zwar schon lange abgekündigt, aber die sind immer noch für relativ kleines Geld zu haben, und die sind direkt 5V-TTL-Kompatibel. Gibt es etwas, was gegen diesen CPLD spricht?
Die für die Programmierung dieser CPLD notwendige Software "Xilinx ISE Design Suite" wird auch seit 2013 nicht mehr weiterentwickelt, aber immerhin ist die 2020 so angepasst worden, dass die auf Windows 10/11 läuft.
Zum übertragen des CPLD-Programms kann ein JTAG-Adapter benutzt werden. Ich werde aber auch versuchen, die JTAG-Programmierung über den ESP32 zu machen. Das spart Adapter und Kabelsalat.

Das hier ist der erste Entwurf als "normal breite" MMS16-Karte.

Darauf ist viel Platz für eigene Schaltungen, die sitzt mechanisch stabil im Rechner, und man kann ein Slotblech anschrauben. (Ähhm... ja... die Löcher dafür fehlen noch)
Die Nachteile dieser breiten Version sind, dass die in der Herstellung etwas teuerer wird, und die nur für den MMS16-Bus benutzt werden kann.

Es wäre auch eine schmale Variante möglich. Die könnte dann nicht nur links auf den MMS16-Bus, sondern auch rechts auf KGS,- oder KES-Bus gesteckt werden. (Für KES/KGS-Bus braucht es natürlich ein anderes CPLD-Programm).
Nachteil der schmalen Version ist, dass für eigene Schaltungen weniger Platz sein wird. Das Reinstecken einer schmalen Platine ist immer etwas fummelig, und die sitzt dann ganz schön wacklig in der Führungsschiene.

Wurdet ihr eher die schmale oder die breite Version bevorzugen?

Da auf Lochraster-Aufbauten schnell mal ein Kurzschluss passieren kann, habe ich eine Fein-Sicherung vorgesehen. Ist das OK, oder lieber eine Poly-Fuse nehmen?

Habt ihr Erfahrung mit doppelseitigen Lochrasterplatinen? Ich könnte mir vorstellen, dass durch das Kupfer im Loch die Lötaugen nicht so schnell abfallen, aber das Ablöten und Ändern der Schaltung schwieriger wird.
--
Gruß
Stefan

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

001
20.10.2025, 19:23 Uhr
Enrico
Default Group and Edit

Zitat:

Ordoban schrieb
....

Habt ihr Erfahrung mit doppelseitigen Lochrasterplatinen? Ich könnte mir vorstellen, dass durch das Kupfer im Loch die Lötaugen nicht so schnell abfallen, aber das Ablöten und Ändern der Schaltung schwieriger wird.

Ist mir beides noch nicht so schnell passiert.
--
MFG
Enrico

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

002
20.10.2025, 19:47 Uhr
Ordoban

Zitat:

Enrico schrieb
Ist mir beides noch nicht so schnell passiert.

Ich hab nen ganzen Haufen einfacher Hartpapier-Platinen, auf denen schon mehrere Generationen von Bahn-Lehrlingen zu lange und zu heiß rumgelötet haben (ja, die hab ich in meiner Lehrzeit in Gutenfürst "privatisiert"). Da fehlen oft schon viele Lötaugen.
--
Gruß
Stefan

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

003
20.10.2025, 20:15 Uhr
Dresdenboy

Wie wären hier die 5V u. 3,3V-Teile mit der Anwenderlogik verknüpfbar? Wären da noch Pegelwandler nötig?

Und wäre ein Pico 2 oder nur ein RP2350 mit vielen und mittlerweile 5V-toleranten GPIOs sowie den 3 PIO-Blöcken eine Option?

VG,
Matthias
--
___________________________________
Produktionen im Rahmen der "The Computer Art Community" (Demoszene): https://demozoo.org/sceners/64936/, YT-Kanal: https://www.youtube.com/@4lpha0ne/videos
Programmierung seit '86 in BASIC: KC85/3, C64, A1200, PC | ASM: LC-80, C64, KC87, A1200, NeoGeo, PC, Mega 65, µC | Turbo Pascal: BIC, PC | C: RS/6000, Alpha, PC, µC | C++, Java, Javascript, Rust, Lua, Perl, PHP u.a. auf PC
HW: LC-80, BIC A5105 komplett, KC87, KC85/2-4, KCC, C64s, C16, Plus/4s, A500s, A1200, Mega 65, ESP32s, RasPis, PCs, Laptops, MR 610, ...

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

004
20.10.2025, 20:51 Uhr
Ordoban

Der CPLD und der ESP32 laufen beide mit 3,3V.
Der CPLD ist offiziell 5V-tolerant, und der ESP32 ist es inoffiziell (das Thema hatten wir schonmal).
Normale 5V-TTL Eingänge kommen mit 3,3V-Ausgängen zurecht.
Man kann hier also ohne Pegelwandler auskommen.
Edit:
Problematisch könnte es werden wenn man modernere IC's für die Anwenderschaltung nehmen möchte. SDRAMs haben zum Beispiel oft 1,xV Pegelspannungen, für die sind unsere 3,3V-Pegel schon zu viel.

Ob der Pico 2 oder RP2350 eine Option sind weiß ich nicht. Als Ersatz für den ESP32 vielleicht. Als Ersatz für den CPLD vermutlich nicht - wir reden hier über ca. 50 I/O's allein für den MMS16 Bus.
--
Gruß
Stefan

Dieser Beitrag wurde am 20.10.2025 um 21:02 Uhr von Ordoban editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

005
21.10.2025, 14:03 Uhr
Dresdenboy

Gut, das mit 3,3V-Spannung u. 5V-Toleranz macht Sinn.

Da hat sich beim RP2350 auch etwas getan, da dieser nun offiziell laut Doku bis 5,5V tolerant ist - ab Stepping A4. Dazu hat der Chip 48 GPIOs, was für dich natürlich nicht reichen würde, wenn man keine Zusatzlogik möchte.

Ein Vorteil der RP2350s ist, dass über die PIOs ein unterbrechungsfreies, von den Kernen unabhängiges I/O-Handling mit IRQs und DMA möglich ist. Und programmierbar wären diese direkt von den Cores.

Soll der CPLD z.B. auch Daten für den BUS von/zum ESP32 schieben?

VG,
Matthias
--
___________________________________
Produktionen im Rahmen der "The Computer Art Community" (Demoszene): https://demozoo.org/sceners/64936/, YT-Kanal: https://www.youtube.com/@4lpha0ne/videos
Programmierung seit '86 in BASIC: KC85/3, C64, A1200, PC | ASM: LC-80, C64, KC87, A1200, NeoGeo, PC, Mega 65, µC | Turbo Pascal: BIC, PC | C: RS/6000, Alpha, PC, µC | C++, Java, Javascript, Rust, Lua, Perl, PHP u.a. auf PC
HW: LC-80, BIC A5105 komplett, KC87, KC85/2-4, KCC, C64s, C16, Plus/4s, A500s, A1200, Mega 65, ESP32s, RasPis, PCs, Laptops, MR 610, ...

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

006
21.10.2025, 17:31 Uhr
Ordoban

Zitat:

Dresdenboy schrieb
Dazu hat der Chip 48 GPIOs, was für dich natürlich nicht reichen würde, wenn man keine Zusatzlogik möchte.

Könnte grad so reichen, wenn ich auf ein paar Signale wie zum Beispiel Interrupts und Busmaster verzichte.

Zitat:

Ein Vorteil der RP2350s ist, dass über die PIOs ein unterbrechungsfreies, von den Kernen unabhängiges I/O-Handling mit IRQs und DMA möglich ist. Und programmierbar wären diese direkt von den Cores.

Die I/O-Prozessoren sehen auf den ersten Blick cool aus. Wenn man dann über konkrete Aufgaben nachdenkt, dann stößt man damit aber sehr schnell an harte Grenzen.

Zitat:

Soll der CPLD z.B. auch Daten für den BUS von/zum ESP32 schieben?

Aber sicher doch! Du denkst jetzt bestimmt: "MMS16-Busttakt 5MHz.... SPI-Bustakt max 50MHz.... Serialisierungsverhältnis 40:8... Reaktionszeit des ESP32.... -----> das wird vom Timing niemals hinkommen.". Das ist richtig.
Aaaaber: der MMS16-Bus hat eine Besonderheit. Der Busmaster wartet bei jedem Transfer, bis die betreffende Karte den Empfang oder Versenden der Daten mit dem XACK-Signal bestätigt hat.
Und was passiert wenn keine Karte antwortet, weil der Port nicht benutzt wird? Die KES als Busmaster wartet bis jemand den Reset drückt, und die ZVE als Busmaster hat ein Monoflop mit ein paar Millisekunden als Timeout. Paar Millisekunden klingt erstmal nicht viel - für einen Computer ist das eine Ewigkeit. Für den ESP32 reicht das allemal.
Klar wird das nicht die Monster-Mega-Performance bringen. Muss es auch nicht.
--
Gruß
Stefan

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

007
22.10.2025, 12:31 Uhr
Dresdenboy

Zitat:

Ordoban schrieb
Die I/O-Prozessoren sehen auf den ersten Blick cool aus. Wenn man dann über konkrete Aufgaben nachdenkt, dann stößt man damit aber sehr schnell an harte Grenzen.

Das dachte ich auch erst für mein Modulprojekt für den BIC, v.a. mit nur 32 gemeinsamen Befehls-Slots für 4 State Machines in einem PIO-Block. Das klingt wenig. Klar, eine RAM- oder ROM-Emulation ist da natürlich problemlos denkbar. Aber andere, gleichzeitig emulierte Komponenten? Für den ESP32 hatte ich ja ein paar Messungen gemacht und die Auswirkungen der WiFi-Aktivität auf den Bus mit entspr. Behinderung der GPIO-Ansteuerung gesehen. Ein bisschen ginge da mit sehr schnellen GPIO-Interrupts. Das habe ich aber erst einmal nicht weiter verfolgt.

Und dann wäre noch der kleine Befehlsspeicher. Aber da habe ich mich ja erst letztens mal "aufgeschlaut" und sehe viel Potenzial. V.a. dank der hohen Flexibilität der PIO-Instruktionen, als auch der Möglichkeit, über verschiedene Wege inkl. DMA in den Befehlsspeicher noch zusätzlichen PIO-Code auszuführen, wie ich letztens lernte. Man könnte m.W. sogar PIO-Befehle über die GPIOs einspeisen.

Ein weiterer Aspekt ist die Möglichkeit der Priorisierung der Bus-Aktivität und auch die Anbindung der Cores. Das geht sauber zu konfigurieren. Und am Ende hängt es ja eh von der grundsätzlichen Architektur des SoCs ab.

Hier hatte ich ein paar Links in einer Antwort an dich zum VGA-Adapter gelistet:
https://www.robotrontechnik.de/html/forum/thwb/showtopic.php?threadid=21380#261173

Zitat:

Ordoban schrieb

Zitat:

Dresdenboy schrieb
Soll der CPLD z.B. auch Daten für den BUS von/zum ESP32 schieben?

Genau. S.o. mein Hinweis zum WiFi. Meine Lösungsidee dafür war übrigens so ähnlich: ein Wait-Signal zu generieren, solange der ESP32 verhindert ist. Aber eigentlich wollte ich z.B. ein ROM emulieren, was jetzt ein konsistentes Zeitverhalten zeigen sollte, wenn ich auch zeitkritische Programme ausführen möchte.
Hier gibt es ja auch ein spannendes ROM-Ersatz-Projekt sowohl auf STM32- als auch RP2350-Basis, was hier u.a. (besser siehe Kanal) gezeigt wird: https://www.youtube.com/watch?v=Zy8IMe6fMI4

VG,
Matthias
--
___________________________________
Produktionen im Rahmen der "The Computer Art Community" (Demoszene): https://demozoo.org/sceners/64936/, YT-Kanal: https://www.youtube.com/@4lpha0ne/videos
Programmierung seit '86 in BASIC: KC85/3, C64, A1200, PC | ASM: LC-80, C64, KC87, A1200, NeoGeo, PC, Mega 65, µC | Turbo Pascal: BIC, PC | C: RS/6000, Alpha, PC, µC | C++, Java, Javascript, Rust, Lua, Perl, PHP u.a. auf PC
HW: LC-80, BIC A5105 komplett, KC87, KC85/2-4, KCC, C64s, C16, Plus/4s, A500s, A1200, Mega 65, ESP32s, RasPis, PCs, Laptops, MR 610, ...

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

008
22.10.2025, 19:33 Uhr
Ordoban

Zitat:

Dresdenboy schrieb
Das dachte ich auch erst für mein Modulprojekt für den BIC, v.a. mit nur 32 gemeinsamen Befehls-Slots für 4 State Machines in einem PIO-Block. Das klingt wenig. Klar, eine RAM- oder ROM-Emulation ist da natürlich problemlos denkbar. Aber andere, gleichzeitig emulierte Komponenten? Für den ESP32 hatte ich ja ein paar Messungen gemacht und die Auswirkungen der WiFi-Aktivität auf den Bus mit entspr. Behinderung der GPIO-Ansteuerung gesehen. Ein bisschen ginge da mit sehr schnellen GPIO-Interrupts. Das habe ich aber erst einmal nicht weiter verfolgt.

Und dann wäre noch der kleine Befehlsspeicher. Aber da habe ich mich ja erst letztens mal "aufgeschlaut" und sehe viel Potenzial. V.a. dank der hohen Flexibilität der PIO-Instruktionen, als auch der Möglichkeit, über verschiedene Wege inkl. DMA in den Befehlsspeicher noch zusätzlichen PIO-Code auszuführen, wie ich letztens lernte. Man könnte m.W. sogar PIO-Befehle über die GPIOs einspeisen.

Ein weiterer Aspekt ist die Möglichkeit der Priorisierung der Bus-Aktivität und auch die Anbindung der Cores. Das geht sauber zu konfigurieren. Und am Ende hängt es ja eh von der grundsätzlichen Architektur des SoCs ab.

Ich denke ich werde bei der Kombination CPLD+ESP32 bleiben. Den CPLD schon deshalb, weil weder der ESP noch der RP auch nur annähernd genug I/O's haben. Den ESP kenne schon recht gut, bei dem RP müsste ich von vorn anfangen. Das ist aber keine endgültige Entscheidung. Man kann schließlich jederzeit jeden beliebigen Mikrokontroller auf den Lochrasterteil braten. Da muss man sich nur eine passende Interface-Logik ausdenken und die in den CPLD wünschen.

Zitat:

Hier hatte ich ein paar Links in einer Antwort an dich zum VGA-Adapter gelistet:
https://www.robotrontechnik.de/html/forum/thwb/showtopic.php?threadid=21380#261173

Es ist ja nett von dir mögliche Alternativen zu zeigen. Aber der VGA-Adapter ist fertig. Er funktioniert. Nicht perfekt, aber "Good enough for the Girls we date". Ein Technologiewechsel zum RP würde heißen mit der Entwicklung komplett von vorn zu beginnen.

Zitat:

Bei einem Wait müsstest du das entweder sofort setzen wenn du von Adresse und Busoperation her zuständig bist, und das Löschen wenn der RP/ESP die Bus-Opersation verarbeitet hat. Hier ist immer noch die Gefahr dass das Wait zu langsam kommt. Oder du müsstest das Wait pauschal setzen, wenn der RP/ESP gerade mal wieder abgelenkt ist. Das bremst/rüttelt den Host unnötig durch, verringert aber die Gefahr für "Bus-Unfälle".
Zum Glück funktioniert der MMS16 genau andersrum. Da wartet das System auf langsame Geräte.
Und gegen Busunfälle (wenn der RP/ESP das Timing verkackt) schützt der CPLD. Über die einstelligen Megaherz-Zahlen lacht der nur.

Zitat:

Hier gibt es ja auch ein spannendes ROM-Ersatz-Projekt sowohl auf STM32- als auch RP2350-Basis, was hier u.a. (besser siehe Kanal) gezeigt wird: https://www.youtube.com/watch?v=Zy8IMe6fMI4

VG,
Matthias

Ein interessantes Video. Da sieht man aber auch die Nachteile des RP: braucht nen ganzen Haufen Zusatzbauteile, ist durch die Bauform deutlich schwerer zu löten, und ist bei der 5V-Toleranz ganz schön knapp am Tot (er nennt da 5,5V als absolutes Maximum). Der nutzt da auch nicht den I/O-Koprozessor. Für diese Anwendung sehe ich auch nicht was der nutzen könnte.
--
Gruß
Stefan

Dieser Beitrag wurde am 22.10.2025 um 19:36 Uhr von Ordoban editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

009
23.10.2025, 12:01 Uhr
Dresdenboy

Zitat:

Ordoban schrieb
Ich denke ich werde bei der Kombination CPLD+ESP32 bleiben. Den CPLD schon deshalb, weil weder der ESP noch der RP auch nur annähernd genug I/O's haben. Den ESP kenne schon recht gut, bei dem RP müsste ich von vorn anfangen. Das ist aber keine endgültige Entscheidung. Man kann schließlich jederzeit jeden beliebigen Mikrokontroller auf den Lochrasterteil braten. Da muss man sich nur eine passende Interface-Logik ausdenken und die in den CPLD wünschen.
[...]
Es ist ja nett von dir mögliche Alternativen zu zeigen. Aber der VGA-Adapter ist fertig. Er funktioniert. Nicht perfekt, aber "Good enough for the Girls we date". Ein Technologiewechsel zum RP würde heißen mit der Entwicklung komplett von vorn zu beginnen.

Das macht ja auch Sinn. Meine Intention ist nur, dass mal auf mögliche Alternativen geschaut werden könnte, da ich mir mit einem ähnlichen Ziel wie diese Karte, nur eben für den K1520-Bus, auch entspr. Plattformen angeschaut habe.

Deinen Punkte bzgl. ausreichend I/O-Fähigkeiten und auch vorhandener Erfahrung kann ich nur zustimmen. Erst recht bei schon abgeschlossenen Projekten wie dem VGA-Adapter. Ein Wechsel des SoC lohnt sich nicht als reine Beschäftigungstherapie. Hier hatte ich das überhaupt nur erwogen, weil das Thema mal von Klaus angesprochen wurde (hatte ich mit zitiert) und sich einiges getan hat. War da nicht ein Problem mit dem Speicher, um WiFi+VGA gleichzeitig zu betreiben oder zu flashen? Aber das wäre auch nur eher ein Nice to have.

Zitat:

Das waren auch meine Bedenken. Die existieren aber nur, da ich WiFi (oder auch BT) nutzen möchte, was sporadisch den Bus belegen würde. Ohne das wäre es einfach, da der ESP sonst ohne Störung in einem Loop oder per schnellem IRQ arbeiten kann, wie auch alle ähnlichen Projekte (mit Teensy, STM32, Atmega etc.).

Zitat:

Das DIP-24-Format des One ROM als Platine ist natürlich herausfordernd. Und obwohl der RP2350 vom Boardhersteller verbaut wird, gibt es ab und zu Probleme. Aber das kommt auf das Projekt an.

Warum er PIOs nicht nutzt, habe ich noch nicht gehört (vllt. überhört beim Nebenbei-Hören), aber evtl. deshalb, da er vom STM32 kommt und das da nicht so gemacht hat. Dann ist die Änderung von C-Code einfacher wenn es so auch funktioniert, als der Einstieg in die PIO-Programmierung. Der ROM-Nutzfall ist da auch trivial.

Ein komplexeres Bus-Signal-Spiel mit mehreren statusabhängig zu ändernden Signalen sowie einzuhaltendem Zeitverhalten mit genauen Delays wäre eher etwas für PIOs.

VG,
Matthias
--
___________________________________
Produktionen im Rahmen der "The Computer Art Community" (Demoszene): https://demozoo.org/sceners/64936/, YT-Kanal: https://www.youtube.com/@4lpha0ne/videos
Programmierung seit '86 in BASIC: KC85/3, C64, A1200, PC | ASM: LC-80, C64, KC87, A1200, NeoGeo, PC, Mega 65, µC | Turbo Pascal: BIC, PC | C: RS/6000, Alpha, PC, µC | C++, Java, Javascript, Rust, Lua, Perl, PHP u.a. auf PC
HW: LC-80, BIC A5105 komplett, KC87, KC85/2-4, KCC, C64s, C16, Plus/4s, A500s, A1200, Mega 65, ESP32s, RasPis, PCs, Laptops, MR 610, ...

Dieser Beitrag wurde am 23.10.2025 um 12:04 Uhr von Dresdenboy editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

Seiten: -1- [ Technische Diskussionen ]