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

010
26.10.2025, 17:50 Uhr
Ordoban

Hier der aktuelle Stand. Ich habe mich für die schmale Variante entschieden, man kann aber jederzeit noch leere Fläche ranpappen.

--
Gruß
Stefan

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

011
05.11.2025, 19:16 Uhr
Ordoban

Die Genossen der VR China haben geliefert:

Gleich bestückt. Den CPLD zu löten ging erstaunlich gut. Das hier ist ein gebrauchter IC, den hab ich von Einer Platine aus der Schrott-Box runtergeföhnt. Als Flussmittel das gute alte Kolophonium in Spiritus - Sieht ziemlich unsauber aus aber lötet gut.

Mit Isopropanol gereinigt sieht das schon besser aus.

Den CPLD zu brennen hat auch geklappt, zumindest mit exteren JTAG-Programmer und einem Beispielprogramm.

Als nächstes kommt dann ein richtiges CPLD-Programm, und dann werde ich das Dingens auch mal in den 7150 stecken.
--
Gruß
Stefan

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

012
06.11.2025, 10:36 Uhr
Ordoban

Jea! Ein einfaches I/O-Register funktioniert!

Test mit dem DOS-Debugger:

Am Logik-Analyzer:

Das hier ist das CPLD-Programm:

--
Gruß
Stefan

Dieser Beitrag wurde am 06.11.2025 um 10:38 Uhr von Ordoban editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

013
06.11.2025, 11:30 Uhr
Dresdenboy

Sehr schön! Es ist spannend, auch die einzelnen Schritte mitzuverfolgen und z.B. mal das CPLD-Programm nachzuvollziehen.

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

014
12.11.2025, 19:21 Uhr
Ordoban

Als nächstes ist der ESP32 dran. Wie erocdraH_XAM es so schön vorgemacht hat, hab ich Video vom löten des ESP's gemacht. Das ist mein allererstes Youtube-Video, also erwartet nicht zu viel...

https://youtu.be/rQVi1_qqad8
--
Gruß
Stefan

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

015
23.11.2025, 08:58 Uhr
Ordoban

Mein aktueller Schritt ist es, den ESP32 zum JTAG-Adapter zum Programmieren des CPLD zu machen. Das gestaltet sich jedoch unerwartet schwierig.
Die Programmier-Software für den CPLD (Xilinx ISE) hat extra dafür das "Xvc-Plugin". Dieses Plugin verbindet sich über TCP, und das Protokoll ist öffentlich, gut dokumentiert und seeeehr einfach.
Das Problem ist: dieses Modul ist verbuggt. Wenn man das ohne den Parameter "disableversioncheck=true" ausführt, dann stürzt das ab, ohne vorher ein einziges Byte gesendet oder empfangen zu haben.
Mit diesem Parameter verbindet es sich mit dem ESP32, und macht ständig zwei kurze Abfragen. Obwohl diese Abfragen laut Protokoll korrekt ausgeführt und beantwortet werden, ist das Xvc-Plugin damit nicht zufrieden. Es erlaubt nicht den Start des Programmiervorgangs. Wenn man das Programm gezielt das JTAG scannen lässt, dann wird der CPLD korrekt erkannt. Ich habe eine ganze Weile hin und her probiert, und diesen Ansatz vorläufig aufgegeben.

Mein zweiter Ansatz ist eine JTAG-Software "OpenOCD". Das kann über das "remote-bitbang" Protokoll Verbindung mit dem ESP32 aufnehmen. Das funktioniert, aber unglaublich langsam, und sehr umständlich. Da kann ich auch bei dem wackligen Paralellport-Programmer bleiben.

Der dritte Ansatz ist die Remote-Adapter-Funktion des Xilinx ISE. Die ist normalerweise dafür gedacht, das Programmier-Kabel an einen zweiten PC anzustecken. Dort wird dann ein Relais-Programm ausgeführt, und die Programmierung vom Haupt-PC wird dann über TCP gemacht. Das funktoniert auf diese Weise gut, also nicht so verbuggt wie das Xvc-Plugin. Das blöde ist, dass das Protokoll dafür nicht öffentlich dokumentiert ist. Es gibt eine Open-Source-Variante des Relais.Programms, aber das ist für eine sehr alte Version des Xilinx ISE, und funktioniert mit der letzten Version nicht mehr. Ich habe mir mit dem Wireshark schon den TCP-Datenstrom angesehen. Das Protokoll sieht umfangreich aus, aber man kann Datenstrukturen erkennen. Das Protokoll zu reverse-engineeren und im ESP32 neu zu implementieren scheint also machbar, wird aber sehr viel zeitaufwändiger als mir lieb ist.

Jetzt bin ich unentschlossen wie ich weiter mache. Das Xvc-Plugin debuggen? Das remote-bitbang mit OpenOCD optimieren? Oder das Remote-Adapter-Protokoll reversen?

Kennt sich jemand von euch mit dem Xilinx ISE aus?
Hat jemand eine Idee was ich noch probieren könnte?
--
Gruß
Stefan

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

016
24.11.2025, 08:10 Uhr
Bert

Zitat:

Ordoban schrieb
Kennt sich jemand von euch mit dem Xilinx ISE aus?

Jein. Ich hab zwar jahrelang mit verschiedenen Xilinx-FPGA und CPLD gearbeitet, aber nahezu immer mit dem teueren Xilinx-Programmer. Bei den späteren Platinen ist der Programmer mit drauf und es gibt eine passende USB-Buchse.

Um ein FPGA selber zu konfigurieren gab es früher die XAPP058:
https://www.mikrocontroller.net/attachment/20584/xapp058.pdf

Hier hat das schon mal jemand auf einen AVR-Controller portiert:
in ASM:
https://www.mikrocontroller.net/topic/31391
in C:
https://www.mikrocontroller.net/articles/FPGA_Konfiguration_mit_AVR_Butterfly
--
Viele Grüße,
Bert

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

017
24.11.2025, 17:02 Uhr
Ordoban

Zitat:

Bert schrieb

Zitat:

Ordoban schrieb
Kennt sich jemand von euch mit dem Xilinx ISE aus?

Oh, das ist interessant! Das benutzt XSVF-Files, also so ähnlich wie die OpenOCD-Methode, nur ohne den Zwischenschritt mit dem OpenOCD. Das schiebt die Datei in einem Stück zum Kontroller: damit hat die Latenz vom WLAN nicht so viel Einfluss auf die Geschwindigkeit. Es gibt sogar eine Referenz-Implementation von Xilinx in C.

Diese Methode werde ich auf jeden Fall ausprobieren.
Vielen Dank für den Tip!

Zitat:

Hier hat das schon mal jemand auf einen AVR-Controller portiert:
in ASM:
https://www.mikrocontroller.net/topic/31391
in C:
https://www.mikrocontroller.net/articles/FPGA_Konfiguration_mit_AVR_Butterfly

Schöne Beispiele. Ich werd mich aber eher an den Code von Xilinx halten.
--
Gruß
Stefan

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

018
25.11.2025, 21:18 Uhr
Ordoban

Ich habe jetzt den XSVF-Beispielcode von Xilinx auf den ESP32 portiert.
Das hat direkt beim ersten Versuch sofort ein "success" ausgegeben. Hab ich mich erst gefreut, und bin dann stutzig geworden. So schnell? Hab ich debuggt: der bricht direkt nach den ersten 2 Kommandos ab. Stellt sich raus, dass in der XSVF-Datei ein Kommando enthalten ist, das in der xapp058.pdf nicht beschrieben ist.
Ahja, die PDF ist von 2004, und die XSVF ist mit einem Programm von 2013 erstellt. Die bei Xilinx haben also das XSVF-Format weiterentwickelt. Gibt es eine neuere xapp058.pdf? Google fragen!
Ja gibt es: https://docs.amd.com/v/u/en-US/xapp058 von 2017. Da drin ist auch die aktuelle Beispielcode-Datei verlinkt. In der hab ich dann gesehen, dass ich dieses Kommando ignorieren kann.
Und siehe da: das Flashen auf den CPLD klappt! Mit 6 Sekunden für dieses Mini-Projekt zwar nicht superschnell, aber immerhin deutlich besser als der Paralellport-Programmer. Und der Code ist noch absolut nicht optimiert. Da geht noch einiges.

Welche Zeit ist denn zum Programmieren von so einem CPLD realistisch? Wenn ich die 6s auf einen vollen CPLD hochrechne, dann komme ich grob über den Daumen auf 30s. Damit kann ich gut leben.

Was noch fehlt ist eine Möglichkeit die XSVF-Datei in den ESP32 zu schaffen. Zum Testen habe ich die Datei fest in das ESP32-Programm eingebunden. Ich denke mal, ich werde das per HTTP-Upload machen. Einen Webserver wollte ich in den ESP32 eh einbauen.
--
Gruß
Stefan

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

Seiten: -1- [ Technische Diskussionen ]