Hier ist noch einmal eine etwas andere Idee...
Wie waere es mit einem CPC-"Hat" (MX4 Connector) der 2 oder 3 Steckplaetze hat:
- einer fuer STM32 "the blue pill" boards - die sind extremsts billigst
- 1 oder 2 Steckplaetze fuer Mikroelektronika click! boards - mikroBUS kann I2C, SPI, UART, ...
https://www.amazon.com/Vanpower-STM32F103C8T6-Minimum-Development-Arduino/dp/B074QKP9ZL
https://www.mikroe.com/click
Das Board waere nicht nur extrem guenstig, da der M3 @ 72 Mhz(!) Cortex schnell genug ist, um z.B. Addressdekodierung etc. in Software zu machen. Also kein CPLD oder anderes Geklingel erforderlich. Evtl. Level-Wandler, aber das ist es dann auch schon - dass PCB hat also fast keine Bauteile.
Das haette folgende Vorteile:
- extrem guenstig
- gute IDE fuer STM32-Programmierung
- nur USB Kabel zum Programmieren erforderlich
- billig genug, dass man 5 oder mehr STM32 einfach vorprogrammiert "rumliegen" lassen kann, und einfach Plug&Play mit dem entsp. click! board; die STM32 haben natuerlich den Treiber fuer das entsp. click!-Board drauf
- keine langjaehrigen Hardware-Entwicklungszeiten mehr; ein SDCard-Speicher fuer den CPC benoetigt nur Software/Firmware-Entwicklung, die Boards gibt es ja schon!
- die Treiber (HEX oder C-Source) fuer die STM32 kann man einfach oniine fuer die Community zur Verfuegung stellen
- Vielfalt - es gibt click! Boards fuer jeden erdenklichen Zweck!
- jeder wird zum Hardware-Entwickler: CPC-Hardware-Entwicklung = Treiber-Programmierung
- Qualitaet - die verwendeten Boards (click! und STM32) werden von echten Hardware-Entwicklern / Profis gemacht, nicht von Hobbyisten
Also was ich gerne hätte, ware ein Mother X6, also mit 6 MX4 Steckplätzen. Bei 4 kriege ich nicht alles drauf. Nur so eine Idee. :)
Dazu noch 2 Klick-Boards (oder passen da auch 3 hin?) wäre natürlich super gut. Aber irgendwer muss dafür auch Treiber schreiben.
Ich habe 11 Steckplätze, und mit Adapter sogar 13. Also ein MX13 Clobe :zunge0020:
Naja, hab beim 2x Mother X4 dann auch acht Steckplätze, da hängt dann noch die Dobbertin HD20 dran. :smiley027:
Also, @almasys und @tfm sind dabei richtig?
Natuerlich machen wir auch PIN Header fuer UART, SPI, I2C drauf.
Und meinetwegen 10 MX4 Steckplaetze. (oder waren es 20) ;D
Mir schwebt ein GitHub OpenSource Projekt vor. Anders als LS3 sind alle Sourcen der Firmware verfuegbar. Jeder kann Treiber schreiben.
Fuer einige SPI / I2C Module wird man sicherlich eine Kommunikation / einen Treiber vom CPC aus machen koennen (ueber IO). Fuer andere Module wird das nicht moeglich sein (Epson Speech Board).
In beiden Faellen haben wir eine Loesung: entweder ueber generische I2C SPI Funktionen in der Firmware, oder direkt in C Programmieren auf dem STM32.
Fuer UART stellt sich das Problem natuerlich nicht, da die Protokolle so einfach sind. SPI / I2C ist nen anderes Kaliber (fuer den Epson Chip muss ich ersteinmal ein 32 KB "Programm" in den Chip ueber SPI laden! das waere nichts fuer den CPC... also besser im STM32 implementieren).
Na ja, scheint so zu sein dass sich die Begeisterung dafuer doch in Grenzen haelt.
Am Ende will ja einfach jeder selber lieber mit nem MCU am CPC rumbasteln, kann ich gut verstehen.
Dann arbeite ich erstmal an einem anderen Projekt.
Vielleicht ist die Zeit noch nicht reif. Das erinnert mich an Tot0's Idee mit den Cartridges, hat vor ein paar Jahren niemanden interessiert. Und jetzt kommen die Spanier groß damit raus.
Manchmal brauchen die Menschen länger um sich an "etwas zu gewöhnen", als Visionär solltest Du die Idee trotzdem bitte nicht ganz aufgeben. :)
Quote from: TFM on 21. September 2019, 12:43:35
Vielleicht ist die Zeit noch nicht reif.
Ich mache USART, SPI, und I2C Header auf dieser Board mit drauf, zudem 4 GPO und 4 GPIs:
https://cpcwiki.de/forum/index.php/topic,968.0.html
Und die Firmware Open Source. Werde auch entsp. generische Funktionen zum Zugriff auf UART, SPI, I2C in die Default Firmware einbauen. Dann kann jeder machen was er will. Kommt im Dezember (spaetestens). Zu
Wahrscheinlich finden einige Leute die click! Boards zu teuer. Ich werde das trotzdem irgendwann machen. (Naechstes Jahr)
Also, Speak&SID hat GPIO, SPI, I2C, UART, wie versprochen. Siehe PIN Header im Bilder. Jetzt muss ich nur noch die Firmware fit machen - bisher habe ich generische GPIO und UART / Serielle Funktionien drin. I2C und SPI muss noch. Aber da das Projekt Open Source sein wird (bald), kann man ja auch einfach selbst I2C und SPI in die Firmware brennen. Und Kommunikation mit dem CPC (in beide Richtungen) ist ja schon drin in der Firmware.
Der C Source der Firmware ist jetzt online.
https://github.com/lambdamikel/Speak-SID
Jeder, der SPI oder I2C haben will, kann es sich einfach selbst einbauen - oder warten, bis ich "generische" I2C und SPI CPC API-Funktionen eingebaut habe. Ich werde wahrscheinlich wieder die Uhr als I2C Demo, und vielleicht SDCard Reader als SPI Demo verwenden. UART / Serielle Schnittstelle und GPIO funktionieren ja schon, und entsp. CPC API-Funktionen sind schon drin in der Firmware. Außerdem hat der ATMega 8536 noch ca. 60 % Flash frei... also jede Menge Platz für eigene Funktionen.
In Bezug auf CPC IO gibt es also nichts, was man mit Speak&SID nicht realisieren könnte (klar, Sachen wie ROM/RAM Expansion und Z80 Interrupts etc. gehen damit nicht, aber alles andere schon).
Naja, RAM/ROM Karten gibt es ja auch schon zur Genüge. :)
Kann der LS3 das eigentlich auch? (Ja, für die Firmware ist kein Platz mehr nehme ich an, aber nur mal prinzipiell gefragt) :)
Vielleicht mache ich den Sourcecode für LS3 ja auch Open Source... oder lade eine alternative Firmware hoch die Open Source ist (vielleicht ohne den Epson Firmware code). Dann wäre wieder jede Menge Platz in der Firmware.
Der Mikrobus Steckplatz könnte dann für ein anderes 5V SPI Device verwendet werden. Oder einfach per Dupont Kabel abgreifen.
Na und I2C und UART sind ja ebenfalls an Board... bei Dir allerdings mit MP3 und RTC verbaut. Auslöten und Header rein ;)
Also, ja klar, das geht auch alles mit LS3. GPIO geht nicht. Also Digital Input geht nicht (Output schon, s. LEDs).
Mal eine verwegene Frage:
Könnte so ein STM32 die vollständige Kontrolle über den Bus übernehmen und man es wie einen Z80-DMA-Chip die Byte-Transfers übernehmen lassen?
Mich täte mal interessieren, was für Auswirkungen es auf das System und Spiele hätte, wenn Blocktransfers mit 1Byte pro Takt erfolgen würden.
Das Verwegene wäre:
Wäre es theoretisch möglich so ein Teil parallel zur CPU am Bus lauschen zu lassen, ob grade ein Blocktransfer stattfinden soll und es übernimmt in dem Fall die Kontrolle und die Arbeit, ohne dass man es extra, wie die Z80-DMA, dazu ermutigen müsste?
Quote from: LambdaMikel on 11. November 2019, 20:41:57
Vielleicht mache ich den Sourcecode für LS3 ja auch Open Source... oder lade eine alternative Firmware hoch die Open Source ist (vielleicht ohne den Epson Firmware code). Dann wäre wieder jede Menge Platz in der Firmware.
Die Firmware für LS3 und auch für Speak&SID sind inzwischen Open Source.
Damit gibt es keinen Bedarf mehr für dieses Projekt, und jeder kann die bereits existierenden Hardwarelösungen für I2C, SPI, UART nutzen.
Damit beende ich meine Serie von CPC-Projekten bis auf unbestimmte Zeit und wünsche Euch eine gute Weihnachtszeit und ein gutes neues Jahr 2020! Für mich wird es das Jahr der Software werden.
Bis demnächst mal wieder.