Robotrontechnik-Forum

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

Willkommen Gast!

Robotrontechnik-Forum » Technische Diskussionen » Projektidee: ESP32-basiertes Modul für WiFi+ROM/Disk/HDD-Emulation etc. » Themenansicht

Autor

Thread - Seiten: -1-

000
20.06.2024, 19:21 Uhr
Dresdenboy

Hallo zusammen,

beim Grübeln, wie ich eine Entwicklung von ASM-Programmen auf dem BIC effizient angehen könnte (Crossassembler, instant assemble&run, debugging, etc.) dachte ich mir, dass hierfür möglicherweise ein Modul mit einem ESP32-µC darauf der ideale kostengünstige u. dennoch leistungsfähige Ansatz wäre.

Beim Einschalten könnte sich der µC als alles mögliche ausgeben, u.a. auch ein ROM mit direkter Code-Ausführung (hier müsste der ESP Adressen einlesen und Daten liefern.. das könnt ihr euch ja alles denken) oder ein FDC mit Disk-Image zum Laden versch. Software.

Die Daten, die hier benötigt werden, würden über eine WiFi-Kommunikation mit einem kleinen Server bereitgestellt werden oder im ESP32-Flash-Speicher vorliegen.

Es sind natürlich noch ein paar Fragen zu klären (TTL-Pegel-Umsetzer, nutzbare Pins, braucht man Multiplexing, Stromversorgung beim Einschalten, Bootvorgang, etc.).

Aber erst einmal die Frage an die Experten: Klingt das machbar?

P.S.: Den Atmel AVR schließe ich hier aus - sowohl wegen Leistung, als auch Konnektivität. Ich kenne ihn übrigens noch von einem Anti-Schnarch-Kissen-Projekt in einem Startup an der Uni Rostock vor 20 Jahren (Oh Gott, wie die Zeit vergeht!), wo ich iFFT u. a. darauf implementiert habe.

--
___________________________________
Demoscene-Produktionen: 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 20.06.2024 um 19:26 Uhr von Dresdenboy editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

001
21.06.2024, 10:12 Uhr
HeikoS

Hast Du schon mal einen ESP als RAM/ROM für einen 8-Bitter programmiert ? Ist eine gute Idee, geht das vom Timing her beim ESP? Die sind ja sehr schnell.

Grüße, Heiko

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

002
21.06.2024, 12:21 Uhr
Dresdenboy

@Heiko:
In diesem Kontext habe ich den ESP32 noch nicht genutzt, aber ein paar ESP-Sachen (8266 und 32) habe ich schon in der Vergangenheit gemacht und hier auch einige rumliegen. Da ich mir aus Democoding-Gründen auch schonmal den Xtensa-Befehlssatz (und auch RISC-V) interessehalber angeschaut habe, würde ich mich auch nicht vor Routinen mit genauem Zeitverhalten fürchten, falls man da mit C und einem Compiler dazwischen an Grenzen stößt.

Andererseits sind die Chips, wie du schon sagst, sehr schnell. Meine Recherchen haben ergeben, dass es ESP-Module gibt, wo die GPIOs im zweistelligen MHz-Bereich geschaltet werden können. Und selbst bei Modulen mit Kostenoptimierung oder was auch immer an der Stelle sind noch mehrere MHz möglich, was für den Zweck immer noch reichen könnte.

Und da auf dem µC kein OS läuft, hätte man alles unter Kontrolle oder sollte die verbleibenden Unzulänglichkeiten mit wenig externer Logik lösbar sein - von der eh notwendigen 3.3V<->5V-Geschichte mal abgesehen.

Ich habe auch nach schon existierenden ähnlichen Projekten für andere Computer geschaut, und z.B. diese hier gefunden:
Auf ARM Cortex-Basis für C64:
https://github.com/SensoriumEmbedded/TeensyROM
2 ESP32-basierte Projekte für Apple II:
https://www.applefritter.com/content/esp32-softcard-apple-ii
https://www.applefritter.com/content/apple2idiot-card-esp32
--
___________________________________
Demoscene-Produktionen: 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 21.06.2024 um 12:23 Uhr von Dresdenboy editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

003
21.06.2024, 17:05 Uhr
Ordoban

So vom Gefühl her würde ich sagen dass der ESP32 das schaffen müsste. 2 x 270MHz ist schon flott, auch wenn der nicht immer bei jedem Takt einen Befehl macht.

Ob die Anzahl der GPIO's ausreicht, hängt vom ESP-Modell und vom BIC-Bus ab. Grob durchgezählt komme ich auf 32 nutzbare IO's bei S3-WROOM ohne PRAM. Es gibt da aber zum Teil fiese Fallen mit GPIO-Pins, die für Spezialaufgaben reserviert sind.

Die ESP's sind inoffiziell 5V-Tolerant. Das Thema hatten wir bei dem VGA-Konverter schonmal:
https://www.robotrontechnik.de/html/forum/thwb/showtopic.php?threadid=21380 Beitrag 212

Zitat:

MarioG77 schrieb
Hi Sven,

Viele Diskussionen, aber ja...
https://ba0sh1.com/2016/08/03/is-esp8266-io-really-5v-tolerant/

Der CEO von Espressif hat es selbst gesagt. Weil Bastler aber 5V auf den Spannungseingang gejagt haben, hat man diese Aussage wohl aus den Datenblättern entfernt.

Meiner hat es bisher überlebt.
...

Stromversorgung beim Einschalten jaaaaaa, gibst Spannung drauf, und dann läuft der los...
Bootvorgang Bootvorgang vom BIC könnte interessant werden. Der ESP braucht so 1-3 Sekunden zum Starten. In der Zeit will der BIC bestimmt auch schon sein ROM haben. Eventuell müsste der ESP das Reset-Signal vom BIC halten, bis der fertig mit booten ist.
--
Gruß
Stefan

Dieser Beitrag wurde am 21.06.2024 um 17:08 Uhr von Ordoban editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

004
23.06.2024, 15:49 Uhr
Dresdenboy

Ich habe auch mal weiter recherchiert, auf beiden Seiten.

Die Startup-Zeit eines ESP32 hängt von vielen Faktoren, aber auch oft eher generösen Einstellungen ab. Je nachdem könnten es auch 0,5 s oder weniger sein.

Ich lese mich derweil in versch. Datenblätter ein, natürlich TGL 32721, aber auch zum TXS0108E (8b bidirektionaler Pegelumsetzer: Link)

Mit den Pins (v.a. alle möglichen Steuersignale +16b Adressen und 8b Daten) wird es aber dennoch eng. Evtl. können hier ein Multiplexer-Chip und ein paar Latches helfen. Aber da lasse ich mich gern beraten bzw. finde entspr. Lösungen irgendwo.
--
___________________________________
Demoscene-Produktionen: 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.06.2024 um 15:50 Uhr von Dresdenboy editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

005
23.06.2024, 17:10 Uhr
Ordoban

Es ist ja schon seit einiger Zeit der ESP32P4 angekündigt. Der soll viel mehr IO's haben und noch schnellere CPU's. Wenn der raus kommt werde ich so etwas ähnliches für MMS16 planen.
--
Gruß
Stefan

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

006
24.06.2024, 08:41 Uhr
A.S.

Moin, oder mal hier schauen

https://github.com/robinhedwards/A8PicoCart

Hier hat man einen Raspberry Pico (China Clone mit mehr Anschlüssen & mehr Speicher als der "Normale" glaube ich) für ein ROM Modul herangezogen. Geschwindigkeit und Anschlüsse des Pico genügen.

Wlan fehlt bei diesem Model, aber vielleicht kann man im ersten Schritt auch erst einmal darauf verzichten. Im Gegenzug bietet dieser Pico 16MB Speicher der über USB "beladen" werden kann. Und allg. ist der Aufbau & Teilebedarf mehr als überschaubar.

VG

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

007
24.06.2024, 16:42 Uhr
Dresdenboy

Zitat:

A.S. schrieb
Moin, oder mal hier schauen

https://github.com/robinhedwards/A8PicoCart

Hier hat man einen Raspberry Pico (China Clone mit mehr Anschlüssen & mehr Speicher als der "Normale" glaube ich) für ein ROM Modul herangezogen. Geschwindigkeit und Anschlüsse des Pico genügen.

Wlan fehlt bei diesem Model, aber vielleicht kann man im ersten Schritt auch erst einmal darauf verzichten. Im Gegenzug bietet dieser Pico 16MB Speicher der über USB "beladen" werden kann. Und allg. ist der Aufbau & Teilebedarf mehr als überschaubar.

Hi,

ja, so ein Multi-ROM-Modul hatte ich letztens auch - ich glaube für C64 - mal entdeckt und auch andere nette Geräte, wie z.B. Tapuino. Aber mein Hauptanwendungsfall soll gerade die live-Austauschbarkeit von ROM-Inhalten (oder respektive emulierten Disketten, RAM-Inhalten oder so) sein, womit ich einen schnellen Build/Assemble - Upload - Run - Zyklus ggf. auch mit Remote-Debugging-Möglichkeit hinbekommen möchte.

Von solchen Projekten ohne WiFi kann man sicher aber auch etwas lernen - z.B. ECU-Fähigkeiten, Teilschaltungen, Implementierungen. Und natürlich lässt sich andere Funktionalität (Spielesammlung usw. im Modul) auch nicht so schwer implementieren, sofern das Grundgerüst einmal steht.

Zitat:

Ordoban schrieb
Ob die Anzahl der GPIO's ausreicht, hängt vom ESP-Modell und vom BIC-Bus ab. Grob durchgezählt komme ich auf 32 nutzbare IO's bei S3-WROOM ohne PRAM. Es gibt da aber zum Teil fiese Fallen mit GPIO-Pins, die für Spezialaufgaben reserviert sind.

[...]

Es ist ja schon seit einiger Zeit der ESP32P4 angekündigt. Der soll viel mehr IO's haben und noch schnellere CPU's. Wenn der raus kommt werde ich so etwas ähnliches für MMS16 planen.

Der S3 soll bis 45 nutzbare GPIOs haben, wovon wohl einige für's SPI genutzt werden. Hattest du das so ähnlich wie er hier gezählt? https://forum.espuino.de/t/die-gpios-des-esp32-welche-eignen-sich-fuer-was/684.

Auf dem BIC-Bus habe ich 43 Signale gezählt. Ich kann erst einmal ein Mapping machen und schauen, was schonmal geht.

Zwischendurch hatte ich auch einen lustigen Blitzgedanken: Warum nicht 2 ESPs nehmen (dann gingen auch etwas kleinere)?

Natürlich müsste man die in einer Art Master-Slave-Konfiguration sich untereinander abstimmen lassen, aber theoretisch sollte es gehen.

Der P4 kann dann gern irgendwann als Erlöser auftreten. Bis das Ganze soweit ausgereift ist, wird es diese ESP-Variante günstig in großen Mengen geben.
--
___________________________________
Demoscene-Produktionen: 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 24.06.2024 um 16:52 Uhr von Dresdenboy editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

008
24.06.2024, 20:23 Uhr
Dresdenboy

Für die GPIO-Erweiterung braucht man offenbar addressable latches, die gäbe es z.B. als 1x8 (74xxx259) oder 2x4 bit (74xxx256) Varianten mit 5 bzw. 4 nötigen Pins für die Ansteuerung.
--
___________________________________
Demoscene-Produktionen: 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

009
24.06.2024, 20:46 Uhr
Ordoban

Ich meine nicht den nackigen S3-Chip oder ein Prototypboard, sondern ein WROOM-Modul.
GPIO's für Modelle mit SPI-RAM: 4,5,6,7,15,16,17,18,8,3,9,10,11,12,13,14,21,47,48,45,38,39,40,41,42,44,43,2,1 = 29
Zusätzlich für Modelle ohne SPI-RAM: + 35,36,37 = 32

Ich bin gerade für den VGA-Konverter das Wlan-Streaming zu realisieren. Es ist zum verzweifeln. Sobald das Wlan etwas macht, zerkloppt das den Sampleprozess. Der verpasst dann Interrupts vom Zeilenanfang. Also: Wlan und zeitkritische Dinge auf dem ESP32 gleichzeitig => ganz große Grütze.
--
Gruß
Stefan

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

010
24.06.2024, 21:27 Uhr
Ordoban

Als GPIO-Erweiterung lässt sich so ziemlich alles nutzen was D-Flipflops und Tree-State hat. Das Problem dabei ist die Geschwindigkeit.

Eine Frage wäre, ob die 43 Signale vom BIC-Bus wirklich alle gebraucht werden. Ich kenne den BIC nicht, aber ich stelle mir das als ein generischer Z80-Bus vor: 16 Adressen, 8 Daten, eine Handvoll Steuersignale. Braucht man wirklich alle Steuersignale? Sicher nicht. Alle 16 Adresssignale? Kommt auf die Größe des Adressfensters an. Vielleicht 10? Der Rest dann über TTL-Logik als CS-Signal.

Ich verstehe die Überlegung, warum ein reiner ROM-Emulator nicht das Ziel ist. Einen großen µC könnte man auch als IO-Emulator oder als Debugger nehmen.

Ich bin mir nicht mehr so sicher ob der ESP32 hierfür das Richtige ist. Eventuell wäre ein STM32 passender.
--
Gruß
Stefan

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

011
24.06.2024, 21:34 Uhr
Dresdenboy

Zitat:

Ordoban schrieb
Ich meine nicht den nackigen S3-Chip oder ein Prototypboard, sondern ein WROOM-Modul.
GPIO's für Modelle mit SPI-RAM: 4,5,6,7,15,16,17,18,8,3,9,10,11,12,13,14,21,47,48,45,38,39,40,41,42,44,43,2,1 = 29
Zusätzlich für Modelle ohne SPI-RAM: + 35,36,37 = 32

Alles klar. Damit kommt man nicht gerade weit.

Zitat:

Ordoban schrieb
Ich bin gerade für den VGA-Konverter das Wlan-Streaming zu realisieren. Es ist zum verzweifeln. Sobald das Wlan etwas macht, zerkloppt das den Sampleprozess. Der verpasst dann Interrupts vom Zeilenanfang. Also: Wlan und zeitkritische Dinge auf dem ESP32 gleichzeitig => ganz große Grütze.

Ohje. Gut zu wissen. Ich werde mal auch zu dem Zeitverhalten recherchieren. Für meinen Use Case wäre ggf. dann während des Bereitstellen von Daten als Modul das WLAN abzuschalten (bis zum nächsten Reset oder so).
--
___________________________________
Demoscene-Produktionen: 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

012
24.06.2024, 23:27 Uhr
Bert

Zitat:

Ordoban schrieb
Eventuell wäre ein STM32 passender.

Busteilnehmer mit STM32 am Z80-Bus habe ich probiert.

Das funktioniert rein in Software nicht wirklich.
1. Versuch war /RD auf Interrupt, aber die Latenz war schon zu hoch, um überhaupt den Adressbus vernünftig einlesen zu können.
2. Versuch war ständig den AB zu pollen, aber auch da kann man nicht ernsthaft schnell genug auf eine (oder gar mehrere) Adresse reagieren.

Evtl. kann man irgendwie noch was mit /WAIT oder /BUSRQ hintricksen, aber ich bin dann Richtung FPGA mit zusätzlichen Pegelwandlern gegangen.

Viele Grüße,
Bert

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

013
25.06.2024, 07:28 Uhr
Andre.as

Ein CPLD(XC95___XL) oder FPGA ist die besser Wahl.

In meinem KC85 Modul verbrauche ich 105 vom 117 IO-PINs um alles zu realisieren.

Schönen Tag
Andreas

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

014
25.06.2024, 11:15 Uhr
Dresdenboy

@Bert:
Welches STM32-Board bzw. welcher µC war das? Bei Interrupts scheint nach meiner Recherche v.a. das Sichern/Wiederherstellen der Register schon viel Zeit zu fressen.

In die Richtung gehen auch Hinweise bei anderen Projekten. Z.B. wird bei https://github.com/ytmytm/teensy64 auch darauf hingewiesen, dass keine Interrupts genutzt werden, sondern alles in busy wait loops lief. Hier wäre nochmal spannend, auf welche Probleme du beim STM32 gestoßen warst.

Wo wir bei Teensy sind: Das hier ist auch spannend: https://github.com/SensoriumEmbedded/TeensyROM

@Andre.as:
Das ist schon eine sehr hohe Zahl. Woran liegt das? Unterschiedliche Pins für Input und Output statt bidirektional?

Wie könnte da die Anbindung an eine über PC updatebare "ROM"-Quelle aussehen?
--
___________________________________
Demoscene-Produktionen: 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

015
25.06.2024, 13:48 Uhr
HeikoS

Das Projekt TeensyROM ist sehr interessant ! Der ARM-Prozessor läuft normal mit 600 MHz und wird dort auf 816 MHz übertaktet. Wahrscheinlich kommt man dann in Regionen, wo das Nachbilden von RAM/ROM möglich wird.

Viele Grüße, Heiko

Dieser Beitrag wurde am 25.06.2024 um 13:49 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

016
25.06.2024, 14:07 Uhr
Dresdenboy

@Heiko:
Ja, davon kann man sicher auch lernen. Was mich interessiert: Zeitverhalten ARM-Outputs. Wenn statt 270 MHz XTensa Cores auch noch 400 MHz RISC-V Cores kommen mit entspr. IO-Peripherie-Zeitverhalten, helfen hier sicher auch nur ein paar genaue Tests weiter (Microbenchmarking), um die Fähigkeiten genauer zu ermitteln.

Wenn es schon in Richtung FPGA oder CPLD wg. der Timings gehen muss, würde ich das aber mit ESP32 zwecks WLAN-Kommunikation kombinieren. Der µC kann dann auch auf etwas entspanntere Weise mit dem FPGA/CPLD kommunizieren oder einfach ein RAM befüllen.
--
___________________________________
Demoscene-Produktionen: 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

017
25.06.2024, 15:55 Uhr
Bert

Zitat:

Dresdenboy schrieb
Welches STM32-Board bzw. welcher µC war das? Bei Interrupts scheint nach meiner Recherche v.a. das Sichern/Wiederherstellen der Register schon viel Zeit zu fressen.

WIMRE ein STM32F4 mit 168 MHz. Die IOs können jedoch nicht mit der vollen Taktfrequenz laufen und die werden auch erst einsynchronisiert.

Grüße,
Bert

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

018
25.06.2024, 16:07 Uhr
felge1966
Default Group and Edit

@Dresdenboy
Die für mich interessante Frage ist aber, suchst du jemanden, der dir das entwickelt oder hast du da schon Erfahrungen und erforderlice Fähigkeiten?

Gruß Jörg
--
http://felgentreu.spdns.org/bilder/jacob120.gif

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

019
25.06.2024, 16:56 Uhr
Dresdenboy

@Bert:
Danke für die Infos.

@Jörg
Das meiste, v.a. die Software und prototypische HW kann ich großteils selbst angehen (bis auf Faktor Zeit vllt.). Für komplexere HW-Fragen oder ein späteres PCB könnte ich Hilfe gebrauchen.

Gruß,
Matthias
--
___________________________________
Demoscene-Produktionen: 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 25.06.2024 um 16:57 Uhr von Dresdenboy editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

020
28.06.2024, 00:11 Uhr
Dresdenboy

Kleines Update:

Ich bin immer noch am Einlesen. Der einfachste Use-Case (ROM-Emulator) sollte mit überschaubarer Komplexität machbar sein. Der K1520-Bus hat ja die passenden Steuersignale, wo über /WAIT u. andere Mechanismen ggf. eine kleine Verzögerung des µC kein Problem darstellen sollte. Vllt. lässt sich die WiFi-Seite u. der ROM-Emulator gut über die 2 Kerne trennen. Und so könnte es auch klappen, dass man ein ROM-Update auf den ESP32 schickt und dieser dann über /RESET den Rechner startet. Korrigiert mich, falls ich mir das falsch vorstelle.

Als "ROM" können auch die Adressleitungen als INPUT und Datenbits fest als OUTPUT gesetzt werden, was möglicherweise weniger Probleme mit Level Shiftern wie einem TXS0108E bereitet, weil Richtungswechsel je nach Bustakt ein ungünstiges Timing für den Chip aufweisen könnten.

Während einige µC-Familien zwar leichter und ohne große Umstände schnelle GPIO-Transferraten erreichen, liegt es beim ESP32 wohl an den verschiedenen High- bis Low-Level Möglichkeiten, die Pins anzusteuern, mit entspr. Leistungsdaten. Ich kann da noch mal Benchmarks posten, wo sich jemand die Varianten angeschaut hat. Und für hohe Datenraten bzw. auch parallele Verarbeitung über GPIOs scheinen I2C bzw. SPI ("Octal-SPI") am geeignetsten zu sein.

Inspiration bzgl. hoher Datenraten gibt es hier v.a. durch LED-Matrix- oder LCD-Screen-Ansteuerungsprojekte bzw. auch VGA-Signalgeneratoren. Allerdings müssen diese ja nur in eine Richtung kommunizieren.

Gruß,
Matthias
--
___________________________________
Demoscene-Produktionen: 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

021
28.06.2024, 06:43 Uhr
Ordoban

Du könntest das Ganze auch mit einem externen S-RAM aufbauen. Etwa so:

ESP32 und Ziel-Computer können beide über Bustreiber/Register mit Tree-State auf diesen S-RAM zugreifen.
--
Gruß
Stefan

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

022
28.06.2024, 21:35 Uhr
Dresdenboy

@Stefan:
Interessantes Konzept! Das könnte man angehen, wenn es mit einer einfacheren Schaltung nicht klappt.

Beim ESP32-P4 fiel mir jetzt erst auf, dass der ohne WiFi ist. Und es gäbe auch ein Arduino R4 WiFi, wo ein ESP32-S3 schon mit drauf hängt, aber da stehen nur wenige GPIOs zur Verfügung.
--
___________________________________
Demoscene-Produktionen: 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

023
07.07.2024, 15:28 Uhr
Dresdenboy

Als mögliche Alternative zu einer nicht zu komplexen Schaltung habe ich mir auch das Arduino-ähnlichee Mega2560 R3 + WiFi angesehen, wo ein ESP8266 direkt integriert ist. Darüber ginge auch Over The Air Update. Und im Gegenzug zu einem neueren, ARM-basierten Board, arbeitet ersteres noch mit 5V GPIOs.

Das wäre auch noch eine interessante Option, sofern die 16 MHz reichen, um den Bus entspr. anzusteuern. Nachteilig wäre natürlich auch die Bauform. Da wäre man mit ESP32 u. ein paar kleinen Chips deutlich besser dran.

Kleiner Überblick: https://www.codeproject.com/Articles/5284042/A-Tour-of-the-Arduino-Mega-2560plusWiFi-R3
--
___________________________________
Demoscene-Produktionen: 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 07.07.2024 um 15:29 Uhr von Dresdenboy editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

024
17.07.2024, 12:11 Uhr
Dresdenboy

Ich habe nun weitere Bauteile sowie einen 4ch Oszi bekommen. Dank einiger Rabattaktionen war auch obige Mega2560 R3 + WiFi Platine für 3,68 € dabei (falls mal Experimente mit 5V-GPIOs nötig sind) sowie versch. Varianten von ESP32-S3-Boards, um mir die prototypische Kabelsteckerei zu erleichtern.

Bzgl. der Machbarkeit auf ESP32 hat sich gezeigt, dass mit High Priority Interrupts (mit sehr kurzem Code u. ohne großes Register Saving) sogar eine Lösung ohne Busy Wait Loop denkbar wäre, da die Antwortzeit auf den ext. Interrupt gerade einmal 325 ns beträgt, siehe Endergebnis hier:
https://haydendekker.medium.com/esp32-interrupts-can-only-do-200khz-56f8dbb6a61c
Vielleicht wäre das auch etwas für euch, Stefan und Bert?

Ansonsten wäre auch eine einfache Lösung, auf einem der 2 Cores mit Busy Wait Loop zu arbeiten, wie schon oben irgendwo erwähnt.
--
___________________________________
Demoscene-Produktionen: 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

025
17.07.2024, 16:09 Uhr
robbi
Default Group and Edit

Ich habe immer "bewundert", wenn man nach 1990 auf irgendeinen amerikanischen "Traktor" eine Wartburgkarosserie geschraubt hat und dann von einem tollen Wartburg philosophierte.

Duck und weg...
--
Schreib wie du quatschst, dann schreibst du schlecht.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

026
17.07.2024, 16:27 Uhr
Dresdenboy

Zitat:

robbi schrieb
Ich habe immer "bewundert", wenn man nach 1990 auf irgendeinen amerikanischen "Traktor" eine Wartburgkarosserie geschraubt hat und dann von einem tollen Wartburg philosophierte.

Duck und weg...

Keine Sorge, ich plane hier nicht den FPGA-basierten KC mit 80 MHz U880 und 24b-Grafik analog zu vielen neuen 8-bit-Projekten.

Wenn, dann ist das vmtl. nur für SW-Entwickler interessant.

Es könnte erst einmal nur ein "SoftROM" oder "WEPROM" (WiFi-erasable PROM) oder "REPROM" (Remotely Erasable PROM) werden.
--
___________________________________
Demoscene-Produktionen: 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 17.07.2024 um 16:48 Uhr von Dresdenboy editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

027
18.07.2024, 17:01 Uhr
Ordoban

Zitat:

robbi schrieb
Ich habe immer "bewundert", wenn man nach 1990 auf irgendeinen amerikanischen "Traktor" eine Wartburgkarosserie geschraubt hat und dann von einem tollen Wartburg philosophierte.

Eine Wartburgkarosserie auf einem Traktor-Fahrwerk stell ich mir lustig vor. Also: warum nicht? Wenn jemand Spass dran hat?! Und wenn der das auch noch hinkrigt, dann muss ich sagen: Respekt!

Zitat:

Dresdenboy schrieb
Es könnte erst einmal nur ein "SoftROM" oder "WEPROM" (WiFi-erasable PROM) oder "REPROM" (Remotely Erasable PROM) werden.

Was hälst du von so etwas?: https://www.mouser.de/ProductDetail/Renesas-Electronics/7134SA55JG8?qs=sGAEpiMZZMuIiYGg9i1FDAJk0KabRu5gF%252BlEB2FSzgc%3D
Das ist ein Dual-Port SRAM (4Kx8, 5V). Die kann man von zwei Seiten aus unabhängig lesen und schreiben. Also an einer Seite der BIC und an der anderen Seite der ESP32. Das sollte recht unproblematisch funktionieren. Leider sind die etwas klein und etwas teuer.
--
Gruß
Stefan

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

028
18.07.2024, 18:57 Uhr
Bert

Da braucht man m.E. keinen Dual-Port-RAM.
Alle ROM-Emulatoren, die ich bisher gesehen habe, hatten normalen SRAM. Der externe (Schreib-)Zugriff hat Vorrang.
Im Moment des Updates ist der betreffende Speicher sowieso als inkonsistent zu betrachten und nicht sinnvoll lesend zu nutzen.

Viele Grüße,
Bert

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

029
18.07.2024, 19:57 Uhr
Ordoban

Das wäre dann das Prinzip aus #021. Das braucht einiges mehr an IC's.
--
Gruß
Stefan

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

030
19.07.2024, 01:27 Uhr
Dresdenboy

Ganz so viele ICs wollte ich ja gar nicht haben.

In #002 gibt es auch Projekte ohne RAM-Bausteine. Das war auch so meine Idee, das entspr. Busverhalten nachzubilden.
--
___________________________________
Demoscene-Produktionen: 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

031
04.08.2024, 18:51 Uhr
Dresdenboy

Ich habe jetzt auch mal ein Bild gezeichnet, wie ich mir das in Stufe 0 als ROM mit TXS0108E vorstellen kann. Falls das ESP-Modul wirklich noch 5V-tolerant ist, könnten die Ax-Leitungen auch direkt angebunden werden. In Gegenrichtung (als Data bei Read Request) könnte vllt. auch ein einfacher 74LS24x reichen, welcher die 3.3V des ESP32 am Input als High erkennt.

Um ungünstige Zustände auf den Leitungen zu vermeiden, sollen einige der Kontrollsignale entspr. verknüpft werden, um den Bustreiber nur dann zu aktivieren. Hier wäre auch noch das schon erwähnte künstliche /WAIT-Signal denkbar, welches bei Zugriff erst einmal auf L gesetzt wird, bis der ESP32 soweit ist und Daten bereitstellen konnte, wo er dann /WAIT kurzzeitig auf H setzen könnte. Der Aufwand lohnt sich aber nur, wenn es auch nötig wird.

(im ESP32-Kasten sind oben und unten die 2 Cores dargestellt)

Ansonsen organisiere ich mir gerade mein neues kleines Elektronik-Labor zusammen (ich fing dieses Jahr bei fast 0 an, will auch nicht auf Arbeit ins Labor - außer zum Kollegenaustausch) und sortiere gerade das gesamte Dachgeschoss neu, während Frau und Kind auf Kur sind. Und den dörflichen Computertreff muss ich auch mal wiederbeleben.

In KiCad habe ich nun auch angefangen, die Schaltung zu bauen.

VG,
Matthias
--
___________________________________
Demoscene-Produktionen: 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 04.08.2024 um 18:52 Uhr von Dresdenboy editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

032
06.08.2024, 10:15 Uhr
Dresdenboy

Ich habe mal mit dem ESP32-S3 etwas herumgespielt. Dazu erzeugte ich an einem Pin ein 2 MHz PWM-Signal (per Generator, hellblaue Kurve im Oszi-Plot), verband den Pin mit einem GPIO-Input, warte in einer Schleife darauf, dass dieser auf High geht, setze dann einen 3. Pin auf High und nach ein paar Zyklen wieder auf Low (gelbe Kurve).
Schematischer Aufbau:

Oszi-Plot:

Die Latenz mit Warteschleife schwankt zw. ca. 120 und 180 ns.

VG,
Matthias
--
___________________________________
Demoscene-Produktionen: 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

033
06.08.2024, 17:13 Uhr
Ordoban

Welche Zugriffsmethode für die GPIO's verwendet das?
In meiner bisherigen Erfahrung ist die schnellste Methode die driver/dedic_gpio.h
Damit lassen sich bis zu 8 GPIO's direkt in ein Spezial-Register eines Cores routen.

Hattest du bei deinem Versuch schon das Wlan aktiv? Hattest du mal nach Aussetzern gesucht?

Gerade wenn du das Gerät zum Entwickeln und debuggen am BIC nehmen willst, muss es absolut zuverlässig sein. Am Ende suchst du einen Fehler im BIC-Programm, aber der eigentliche Fehler liegt im Debugger...
--
Gruß
Stefan

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

034
07.08.2024, 20:30 Uhr
Dresdenboy

Zitat:

Ordoban schrieb
Welche Zugriffsmethode für die GPIO's verwendet das?
In meiner bisherigen Erfahrung ist die schnellste Methode die driver/dedic_gpio.h
Damit lassen sich bis zu 8 GPIO's direkt in ein Spezial-Register eines Cores routen.

Hattest du bei deinem Versuch schon das Wlan aktiv? Hattest du mal nach Aussetzern gesucht?

Ich nutze GPIO.out_w1(s/c) und GPIO.in. Wenn ich den Code disassembliere, sieht der auch kompakt aus. Natürlich sind da ein paar memw dazwischen, um die Reihenfolge sicherzustellen. Das könnte man zw. out_w1s und out_w1c vermutlich einmal weglassen.

Ich habe das erst ohne und dann mit WLAN angeschaut. Ohne sind da ab und zu schon eingestreute Lücken von ca. 5-6 µs. Mit WLAN gab es dann mehr Störphasen, die etwas länger sind. Aber die habe ich noch nicht genauer vermessen.

Ich denke, dass man mit den kleinen Lücken klarkommt (z.B. über ein automatisches /WAIT-Signal). Falls man das bei WLAN-induzierten Unterbrechungen macht, kommt es darauf an, wie lang diese andauern könnten. Ggf. wäre eine /WAIT-Automatik dann schlecht für den RAM-Refresh.

Ansonsten könnten die WLAN-Bus-Zugriffe durch ein entspr. Vorgehen, wann es genau genutzt werden soll, vermieden werden. Z.B. in einer kurzen Zeitlücke nach einem Reset (wenn sich das Modul erst einmal als ROM "initialisieren" liess) oder durch den Nutzer getriggert.

Zitat:

Gerade wenn du das Gerät zum Entwickeln und debuggen am BIC nehmen willst, muss es absolut zuverlässig sein. Am Ende suchst du einen Fehler im BIC-Programm, aber der eigentliche Fehler liegt im Debugger...

Richtig. Erst einmal wird es ohne Debuggen gehen (nur als ROM), aber wenn das kommt, dann ist es natürlich, wie du sagst.

Erste Tests werde ich aber mit einzelnen Z80 oder U880 machen. Da gibt es schon viele entspr. Projekte mit Pi Pico (hat ja sehr interessante programmierbare GPIO-Logik in den PIOs), PIC, Arduino, Teensy, STM32 usw.

VG,
Matthias
--
___________________________________
Demoscene-Produktionen: 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

035
09.08.2024, 11:25 Uhr
Dresdenboy

Ich habe auch mal geschaut, ob einer der zwei Ultra Low Power Prozessoren hierbei unterstützen könnte, da die trotz des niedrigen Taktes evtl. ungestörter auf GPIO-Pins reagieren könnten. Das würde evtl. nochmal etwas diskrete Logik einsparen. Nach den ersten Level-Shifter-Tests (Spannungsverläufe bei Open Collector) schaue ich mir das mal genauer an. Wie ich im ESP32 TRM las, können einige Ausgangs-Pins sogar intern auf andere Eingangs-Pins geroutet werden, allerdings ohne weitere logische Verknüpfung. Ich konnte nur noch nicht finden, ob GPIO-Pins ohne ABP-Peripheral-Beteiligung zugreifbar sind.

@Ordoban: Vermutlich weißt du da schon mehr als ich.

Nebenbei habe ich auch mir weiter angeschaut, was mit dem Pico so ginge und ob die PIOs hier helfen könnten. Also dachte ich mir, ich bestelle mal einen und sehe mir so die Modelle mit/ohne WiFi und den Pico 2 hier an:
https://www.raspberrypi.com/documentation/microcontrollers/pico-series.html

Da stellt sich heraus, dass letzterer wohl erst gestern vorgestellt wurde.

Ich bin gespannt.

Nachtrag: "Der 10 Cent teurere RP2350B im QFN80-Gehäuse hat 48 GPIO-Pins, von denen sich acht für ADC konfigurieren lassen, und 24 PWM-Einheiten."
https://www.heise.de/news/Raspberry-Pi-Pico-2-mit-Mikrocontroller-RP2350-Staerkere-ARM-Kerne-und-RISC-V-9827575.html
Wir hatten oben ja schon das Thema GPIO-Anzahl. Aber für viele Projekte mit 6502 oder Z80 scheinen die Pins des normalen Pico auch zu reichen.

VG,
Matthias
--
___________________________________
Demoscene-Produktionen: 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 09.08.2024 um 13:31 Uhr von Dresdenboy editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

036
09.08.2024, 17:42 Uhr
Ordoban

Zitat:

Dresdenboy schrieb
@Ordoban: Vermutlich weißt du da schon mehr als ich.

Ja, diese Funktion ist gut versteckt. Siehe TRM Kap "1.6.9 GPIO Control Instructions", S.60

Quellcode:


#include "driver/dedic_gpio.h"
#include "hal/dedic_gpio_cpu_ll.h"
#include "driver/gpio.h"

#define SET_GPIO(v) asm volatile ("EE.SET_BIT_GPIO_OUT " #v);
#define CLR_GPIO(v) asm volatile ("EE.CLR_BIT_GPIO_OUT " #v);

    const int gpios[4] = {PIN_NUM_OUT1, PIN_NUM_OUT2, PIN_NUM_OUT3}; 
    dedic_gpio_bundle_handle_t test_bundle = NULL;   
    dedic_gpio_bundle_config_t bundle_config = 
    {
        .gpio_array = gpios,
        .array_size = 3,
        .flags = 
        {
            .out_en = 1,
        },
    };
    dedic_gpio_new_bundle(&bundle_config, &test_bundle);

    while(1)
    {
        SET_GPIO(1)
        SET_GPIO(2)
        CLR_GPIO(3)
    }

Der Vorteil davon ist, dass dafür nicht der relativ langsame IO-Bus benutzt wird, sondern die GPIO's direkt mit core1 verbunden sind. Nachteil ist, dass das auf 8 GPIO begrenzt ist.

Zitat:

Nebenbei habe ich auch mir weiter angeschaut, was mit dem Pico so ginge und ob die PIOs hier helfen könnten. Also dachte ich mir, ich bestelle mal einen und sehe mir so die Modelle mit/ohne WiFi und den Pico 2 hier an:
https://www.raspberrypi.com/documentation/microcontrollers/pico-series.html

Da stellt sich heraus, dass letzterer wohl erst gestern vorgestellt wurde.

Ich hatte mir auch mal den RP2040 angeguckt. Der IO-Kontroller ist ein echt interessantes Konzept. Für uns wäre das aber nicht so gut geeignet: zum Prozessor hin produziert der einen linearen Datenstrom. Daraus eine RAM-Zugriff zu bauen dürfte unmöglich sein.
--
Gruß
Stefan

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

Seiten: -1- [ Technische Diskussionen ]