Linux-Computer mit interaktiver Geschwindigkeit aus nur drei 8-Pin-Chips

• Mit dem Ziel eines zu Hause zusammenbaubaren Minimalcomputers wurde ein System mit Debian Linux, vi, gcc und make realisiert, das mit 8 MB RAM und etwa 1 MIPS auskommt und nur aus 8-Pin-Bauteilen besteht
• Das finale Board besteht aus STM32G031, 8 MB SPI-PSRAM und einer PL2303GL-USB-Seriell-Bridge mit insgesamt 3 Chips; durch die Beschränkung auf 8-Pin-Gehäuse stehen jedoch nur 6 nutzbare I/O-Leitungen zur Verfügung
• Der Mangel an Pins ist die zentrale Schwierigkeit des Designs: RAM nutzt normales SPI, die SD-Karte 1-bit SDIO mit gemeinsam genutzten RAM-Pins, und UART-Senden wird per Bit-Banging umgesetzt
• Softwareseitig wird ein vorhandener auf ARMv6M-Assembler basierender MIPS-Emulator wiederverwendet, und ein 8-KB-Bootloader aktualisiert die Firmware über FIRMWARE.BIN im FAT-Dateisystem der SD-Karte
• Der STM32G031 wird mit VOS0 über die offiziellen 64 MHz hinaus übertaktet und bootet Debian mit einer Host-CPU bei 148 MHz in knapp 1 Minute auf etwa dem Niveau eines 1,65-MHz-MIPS-R3000

---

Minimaler Linux-Computer nur aus 8-Pin-Chips

• Ziel ist es, einen kitartigen modernen Computer zu bauen, der sich zu Hause leicht montieren lässt und nur aus 8-Pin-Chips besteht
• Als Mindestmaß für einen modernen Computer gilt, dass Debian Linux, vi, gcc und make lauffähig sind
• Auf Basis früherer Experimente wurden 8 MB RAM und eine 1-MIPS-CPU als Mindestanforderungen für Linux festgelegt
• Als Massenspeicher dient eine SD-Karte, für die Konsolenverbindung wird USB-Seriell verwendet
• Das Board ist klein und rund, oben mit einem USB-C-Steckverbinder an der Platinenkante
• Um die Montage auch für Personen mit kaum Lötpraxis mit einem 45-W-Lötkolben zu ermöglichen, wurden Anzahl der Bauteile und Pins reduziert

Auswahl der Bauteile

• Für die USB-Anbindung wurde PL2303GL gewählt
  • Es handelt sich um eine USB-Seriell-Bridge, die ohne externe Bauteile funktioniert und zusätzlich einen 3,3-V-Reglerausgang mit 100 mA bereitstellt
  • Treiber für die wichtigsten Betriebssysteme sind vorhanden; unter macOS ist eine Installation über den App Store nötig
• Als Alternative wurde eine USB-Implementierung mit ATTINYx5 und V-USB geprüft
  • USB low-speed darf laut Spezifikation keine Bulk-Endpoints nutzen, aber die gängigen Betriebssysteme erzwingen das nicht, daher funktioniert eine ACM-Seriellport-Implementierung dennoch
  • V-USB verbraucht viel CPU-Zeit, Flash und RAM und ist für dieses Projekt daher zu aufwendig
• Als RAM kommt SOIC-8-SPI-PSRAM zum Einsatz
  • ISSI, APMEMORY, Vilsion und andere stellen passende Bauteile her; 8-MB-Bausteine sind über normale Vertriebskanäle erhältlich
  • 16-MB-Chips wurden zwar von mehreren Anbietern angekündigt, scheinen aber tatsächlich nicht lieferbar zu sein
• Als Mikrocontroller wurden PIC16F, RL78, PSoC1, eZ8, S08CPUv2, STM8, MSP430, AVR, PSoC4, MSPM0C, CH32V003, CH570E und die STM32G0-Familie verglichen
• Die endgültige Wahl fiel auf die STM32G031J4M6/STM32G031-Familie
  • Sie bietet einen Cortex-M0+-Kern, offiziell 64 MHz, 32 KB Flash und 8 KB RAM
  • Im 8-Pin-Gehäuse war sie anderen Kandidaten bei Leistung und Speicher überlegen
  • Zwar gab es Bedenken zur Qualität der Errata-Dokumente von STM, doch da das Design nur minimale On-Chip-Peripherie nutzt, war die Wahl vertretbar

Hardware-Design innerhalb von 6 I/O-Pins

• Konsolen-UART

  • UART RX und TX lassen sich nur schwer mit anderen Funktionen kombinieren
  • Wenn RX geteilt wird, können während anderer Vorgänge empfangene Daten verloren gehen; wenn TX geteilt wird, können selbst kurze Low-Pulse auf dem PC wie Zeichen erscheinen
  • Deshalb wurden von den 6 I/O-Leitungen 2 der UART-Konsole zugewiesen
  • Im finalen Pinout wird Pin 8 als USART2 RX verwendet, Pin 7 übernimmt UART TX per Bit-Banging
  • Während des UART-Sendens steht die gesamte Ausführung still, daher wird die möglichst hohe Rate von 115.200 bps genutzt
  • Das Senden eines einzelnen Zeichens dauert etwa 87 Mikrosekunden; da das Board die meiste Zeit nichts ausgibt, ist dieser Ansatz akzeptabel

• RAM-Anbindung

  • SPI-PSRAM unterstützt QSPI, doch dafür wären 6 Pins nötig, was hier nicht möglich ist
  • Dual-SPI könnte ohne zusätzliche Pins doppelt so schnell wie normales SPI sein, wird vom STM32G031 aber nicht unterstützt
  • Selbst per Bit-Banging mit der CPU wäre Dual-SPI nach Einschätzung des Autors schwer schneller als Hardware-SPI in Kombination mit DMA
  • Daher wird das RAM per normalem SPI angebunden, womit alle verbleibenden 4 Pins belegt sind

• SD-Karten-Anbindung

  • Um die SD-Karte im SPI-Modus zu nutzen, wäre ein zusätzlicher Chip-Select-Pin nötig gewesen, der nicht mehr verfügbar war
  • Ein Ansatz, RAM nCS per Inverter als SD-Karten-nCS zu verwenden, verursachte mit manchen Karten Probleme und hätte zusätzliche Bauteile erfordert
  • Auch eine gemeinsame Nutzung des UART-TX-Pins als SD-Karten-nCS mit Tiefpassfilter wurde geprüft, hätte aber UART mit unter 300 bps erfordert und wäre bei langsamen SD-Karten anfällig gewesen
  • Die endgültige Lösung war eine direkte Implementierung des 1-bit-SDIO-Protokolls der SD-Karte
  • RAM nCS wird dabei mit SD CLK geteilt, RAM CLK mit SD CMD und RAM MOSI mit SD DAT
  • RAM-Zugriffe sehen für die SD-Karte wie ein 1-Bit-Idle-Zustand aus, SD-Zugriffe für das RAM wie wiederholtes Auswählen und Abwählen, wodurch der Betrieb sicher möglich ist
  • Allerdings dürfen während einer SD-Transaktion keine RAM-Zugriffe dazwischenkommen, daher sind Multi-Block-Reads/Writes nicht nutzbar
  • Wegen des Pinouts des STM32G031 kann SDIO nicht per Hardware-Block verwendet werden, daher erfolgt der gesamte SD-Zugriff per Bit-Banging
  • Die Assembler-Implementierung erreicht einen Durchsatz von etwa 14 CPU-Zyklen pro Bit

Bootloader und Linux-Boot-Ablauf

• Emulator

  • Der MIPS-Emulator aus dem bestehenden Projekt LinuxCard wird wiederverwendet
  • Der Emulator ist in ARMv6M-Assembler geschrieben und konnte Linux bereits booten
  • Für höhere Geschwindigkeit wurde auch ein MIPS-zu-ARMv6M-JIT geschrieben, aber mit 46 KB Code war er zu groß, und der Geschwindigkeitsgewinn mit nur 6 KB Übersetzungscache war nicht ausreichend, daher wurde er nicht verwendet
  • Die 32 KB Flash des STM32G031 sind in 8 KB Bootloader und 24 KB Hauptcode aufgeteilt

• Bootloader für Firmware-Updates

  • Da keine Debug-Pins freigehalten werden konnten, war ein Bootloader nötig, der die Firmware von der SD-Karte aktualisiert
  • Der Bootloader enthält einen SDIO-Treiber, einen FAT-Dateisystemtreiber, Flash-Schreibcode, Logging sowie Bit-Banging-UART-Sendecode
  • Tatsächlich ist er etwa 6,5 KB groß, belegt wegen der Flash-Blockgröße aber einen Bereich von 8 KB
  • Er sucht auf der SD-Karte nach FIRMWARE.BIN und spielt ein Update ein, wenn die grundlegenden Prüfungen bestanden werden und die Versionsnummer höher ist
  • Das Word bei Offset 16 im Applikationsimage dient als Versionsnummer
  • Das Byte bei Offset 8 im Bootloader ist die Bootloader-Version und wird außer zur Anzeige des Boottexts der Hauptanwendung nicht verwendet
  • Der Bootloader sucht im FAT-Dateisystem außerdem nach Dateien oder Verzeichnissen, deren Name mit CLOCK beginnt
  • Die nachfolgende Zahl wird als Taktfrequenz der Hauptanwendung genutzt; fehlt sie oder liegt sie außerhalb von 32–200 MHz, werden 132 MHz verwendet

• Kartenpartitionen und Kernel-Laden

  • Der Boot-Ablauf ist ähnlich wie der eines PCs aufgebaut
  • Der erste Sektor der SD-Karte wird an den Anfang des RAM gelesen und angesprungen
  • Der Code der ersten Stufe sucht nach einer Partition vom Typ 0xBB, lädt sie nach 0x80001000 und springt dorthin
  • Der Bootloader der zweiten Stufe mountet die als aktiv markierte Partition als FAT16 und lädt die Datei VMLINUX als ELF
  • Die Kernel-Kommandozeile ist im Bootloader eingebettet
  • root ist /dev/pvd3, init ist /sbin/uMIPSinit
  • /dev/pvd1 wird als /boot einzuhängen versucht
  • Die Partitionsreihenfolge des Projekts ist FAT-Partition, Bootloader-Partition, rootfs
  • Da Windows und macOS die erste Partition mounten, lassen sich Dateien bequem über die FAT-Partition hinzufügen und entfernen
  • Auch unter dem gebooteten Linux erscheint diese Partition als /boot

Leistung und Overclocking

• Die offizielle Taktrate des STM32G031 beträgt 64 MHz, aber mithilfe interner Spannungseinstellungen wurde ein höherer Takt ausprobiert
• In der STM-Dokumentation werden VOS2 mit 1,0 V und VOS1 mit 1,2 V beschrieben; mit VOS1 ist jenseits von etwa 75 MHz kein stabiler Betrieb mehr zu erwarten
• Mit der in älteren Dokumenten und Unterlagen zu ähnlichen Chips erwähnten Einstellung VOS0 1,35 V vergrößert sich der Spielraum fürs Overclocking deutlich
• Die meisten Chips laufen gut bei 136 MHz, einige erreichen bis zu 180 MHz
• Da der Flash-Speicher nicht schneller wird, müssen die Flash-Wait-States korrekt verwaltet werden
• Bei einer Host-CPU mit 148 MHz entspricht die emulierte MIPS-CPU ungefähr einem MIPS R3000 mit 1,65 MHz und deaktivierter FPU
• Das System bootet in etwa 1 Minute und vi, make, objdump sowie gcc funktionieren
• Da es sich um ein vollständiges Debian-System handelt, können .deb-Pakete über /boot eingebracht und installiert werden

Zusammenbau und erste Inbetriebnahme

• Montageablauf

  • Designdateien werden bereitgestellt, damit das Board selbst gefertigt werden kann; zugleich wird nach einem Unternehmen gesucht, das Kits verkaufen könnte
  • Die Montage erfolgt in der Reihenfolge SD-Kartensockel, Kondensatoren, Widerstände, STM32G031, PL2303GL
  • R101, R102, R201 und R202 werden zunächst nicht bestückt
  • Zuerst muss der Bootloader in den STM32 geschrieben werden
  • Dazu werden R101 und R201 gebrückt, um die serielle Verdrahtung für den ROM-Bootloader herzustellen
  • Dies geschieht ohne eingesetzte SD-Karte und solange der RAM-Chip noch nicht verlötet ist
  • Nach dem Schreiben des Bootloaders werden die Brücken an R101/R201 entfernt und R102/R202 gebrückt
  • Danach wird ein APS6408- oder VTI7064-RAM-Chip an Position U2 verlötet; damit ist die Hardware-Montage abgeschlossen

• Firmware und erster Boot

  • Die SD-Karte muss mindestens 1 GB groß sein und mit dem bereitgestellten Disk-Image beschrieben werden
  • Das Image enthält einen MIPS-Bootloader der ersten Stufe, einen MIPS-Bootloader der zweiten Stufe, eine Partition mit Linux-Kernel und einer Firmware-Kopie sowie ein Debian-rootfs
  • Wenn FIRMWARE.BIN auf der FAT-Partition liegt, führt der Bootloader beim ersten Start das Selbst-Flashen aus
  • Das serielle Terminal wird auf 115.200 bps, 8N1 eingestellt
  • Beim ersten Start werden STM32-Fuses programmiert; eventuell muss das USB-C-Kabel einmal abgezogen und wieder eingesteckt werden
  • Nach etwa 20 Sekunden beginnen die Linux-Kernel-Bootmeldungen, der vollständige Start dauert ungefähr 1 Minute
  • Da nur 8 MB RAM vorhanden sind, wird als erster Befehl swapon /swapfile dringend empfohlen
  • Das Aktivieren von Swap dauert einige Dutzend Sekunden, danach lassen sich jedoch mehr Programme ausführen

Download-Dateien und Nutzung

• Der Hauptdownload ist uMIPS.8PL.zip
• Das Archiv enthält die für Bau und Betrieb des Boards nötigen Dateien
  • schematics: Schaltpläne
  • gerbers: Gerber-Dateien zur Platinenfertigung
  • srcs: Quellcode für Emulator und Bootloader
  • binaries/SD.img: Image zum Schreiben auf die SD-Karte
  • BOOTLOADER.BIN: Bootloader zum Schreiben auf den Chip während der Montage
  • FIRMWARE.BIN: vorab gebautes Firmware-Image
• Nach dem Booten ist die Standard-Shell sh, bash kann ebenfalls gestartet werden
• Um RAM-Mangel zu vermeiden, empfiehlt es sich, die im Image enthaltene Swap-Datei mit swapon /swapfile zu aktivieren
• Wenn man von einem MCU-Takt von 120 MHz ausgeht, beträgt die effektive CPU-Geschwindigkeit etwa 1,5 MHz
• Das Kompilieren eines einfachen C-Programms mit gcc dauert einige Minuten, funktioniert aber
• Als Beispiele werden Generatoren für Mandelbrot-Bilder mit Gleitkomma- und Festkommaarithmetik in Form von Quellcode und Binärdateien mitgeliefert
• Zu den installierten Werkzeugen gehören vim, make und gcc; zusätzliche Debian-Pakete lassen sich über die gemeinsam genutzte FAT16-Partition der SD-Karte hinzufügen

[GN⁺]

Meinungen auf Hacker News

• Der Teil, in dem nach langem Überlegen, welche Pins mit den drei SDIO-Pins zusammengelegt werden könnten, die Lösung entstand, nCS des RAM als CLK der SD-Karte, CLK des RAM als CMD der SD-Karte und MOSI des RAM als DAT der SD-Karte zu verwenden, ist wirklich ein großartiger Hack.
  Wenn man die möglichen Interaktionen mit den einzelnen Geräten durchgeht, ist auch überzeugend, dass das sicher funktioniert – und es ist allemal Hacker-News-würdig.

  • Die Formulierung „Nach langem Nachdenken war die Lösung offensichtlich“ taugt auch bestens als T-Shirt-Spruch.

• Ich finde es immer ein bisschen schade, dass ein separater Chip für die USB-Anbindung offenbar zur Standardwahl wird.
  USB ist ein viel zu komplexes Protokoll; jenseits eines grundlegenden V-USB-Niveaus für Low-Speed-USB 1.1 wirkt es meist schwierig, ohne spezielle Hardware und einen recht großen Software-Stack auszukommen.
  SPI dagegen ist absurd simpel: Die minimal nötige Hardware ist im Grunde ein Schieberegister, das schnell genug getaktet werden kann.
  Ich vermisse die Zeit, als ältere Desktops und Laptops noch nach außen geführte serielle/parallele Ports hatten, über die solche Low-Level-Kommunikation möglich war.
  Hätte man einfache Peripherie für kurze Distanzen mit UART, I2C und SPI-Multidrop über ein paar Standardtakte und einen einheitlichen Stecker betrieben und datenintensive Geräte wie Monitore oder externe Laufwerke direkt auf IEEE 802.3 Ethernet gesetzt, hätte man vielleicht nicht USB und Ethernet getrennt unterstützen müssen, sondern nur noch den Ethernet-Link.

  • Dass SPI simpel ist, stimmt; es ist ursprünglich ein Protokoll, das mit möglichst wenig Silizium umgesetzt werden sollte, um Transistorbudget zu sparen.
    SPI berücksichtigt viele Komfortfunktionen nicht, die USB bietet, etwa Stromversorgung, Hot-Plugging, Geräteerkennung oder Bitfehler.
    Für Softwareentwickler ist es wertvoll, SPI-Idiome und die Art zu verstehen, wie Hardwaredesigner SPI einsetzen.
    Üblicherweise wird SPI genutzt, um Register von Peripheriegeräten zu füllen, und ist damit von anderer Natur als die High-Level-, asynchrone Kommunikation, die man häufig bei USB oder Ethernet und den Abstraktionsschichten darüber sieht.
    Für SPI-Frames gibt es keinen universellen Standard, aber es gibt idiomatische Muster, und die haben in unzähligen Anwendungen ausgereicht.
  • Das klingt, als wolle man den USB-PHY durch einen Seriell-zu-Ethernet-Wandler und einen Ethernet-PHY ersetzen.
    Realistisch gesehen reichen einfache Protokolle wie SPI und I2C nicht aus.
    Sie sind nicht schnell, nutzen Single-Ended-Signale und sind daher sehr störanfällig, außerdem gibt es keine Fehlerkorrektur.
    Diese Protokolle passen sehr gut zu ihrem vorgesehenen Zweck, nämlich ICs auf einer PCB miteinander zu verbinden; wenn man aber Ports ohne Terminierung nach außen führt, lässt sich kaum etwas garantieren.
    Auch in modernen PCs werden solche Protokolle und Varianten davon häufig verwendet, aber eben als interne Busse.
    Ich habe mir die USB-Spezifikation nicht im Detail angesehen, aber das Hauptproblem beim Bit-Banging dürfte die geforderte Geschwindigkeit sein.
    Ein Mikrocontroller ist nicht schnell genug, um Pins zu toggeln und gleichzeitig das Protokoll zu dekodieren sowie Fehlerkorrektur zu verwalten; dafür braucht man dedizierte Hardware.
    Beim Bit-Banging von I2C kann man auf dasselbe Problem stoßen.
    Mit einer 20-MHz-CPU liegt der maximal erreichbare Takt bei etwa 250 KHz, also nur etwas über der Hälfte der üblichen Maximalgeschwindigkeit von 400 KHz; die 1-MHz-Version ist praktisch unmöglich.
    PHYs gibt es, weil es überwältigend viel günstiger ist, Kommunikationsprotokolle in Hardware auszulagern.
    Andernfalls müsste man die CPU deutlich überdimensionieren, nur um Ressourcen für die manuelle Verwaltung der Kommunikation zu haben; deshalb enthalten moderne Mikrocontroller Hardware für I2C, SPI und serielle Kommunikation.
    Kurz gesagt sind einfache serielle Protokolle wie SPI, I2C und UART eine sehr schlechte Wahl für externe Peripherie.
    Sie lassen sich schwer mit angemessener Geschwindigkeit betreiben und halten langen Kabeln und Störungen nicht stand.
    RS-232 kann man als Ausnahme betrachten, weil es kein UART ist; aber aufgrund der Eigenschaften und des Designs dieser Protokolle kann man sie nicht auf diese Weise verwenden, und wenn man die Spezifikationen so ändern wollte, dass sie das unterstützen, würde man am Ende USB neu erfinden.
  • In der AV-Branche ist RS-232 für Steuersignale zwischen Geräten immer noch König, selbst wenn neue Hardware mehr als 10.000 Dollar kostet.
    Auch Digital-Signage-Displays oder TV-Bildschirme für Konferenzräume bieten oft RS-232, weil es flexiblere Steuerung erlaubt als HDMI-CEC.
    Häufig braucht man keine Bitrate über 9600 bps, und der gängigste Anschluss ist eine 3-polige Schraubklemme mit Tx, Rx und GND.
    In heutigen Installationen steckt meist irgendwo mindestens ein RS232-USB-Adapter, und in großen Räumen wird RS232 über Ethernet gebridged.
    Als ich erstmals in diesen Bereich kam, hat mich das überrascht; aber wenn man bedenkt, dass viele Installationen Jahrzehnte alt sind und Komponenten Stück für Stück ersetzt wurden, ergibt es Sinn.
  • Der Artikel geht zwar ausführlich durch 8-Pin-Chips, lässt aber den sehr beliebten CH32V003 aus.
    Dieser Chip kostet etwa 0,10 Dollar und bietet 2 KB RAM, 16 KB Flash, 48 MHz sowie Betrieb mit 1 CPI.
    Der neue CH570 liegt im SOIC8 ebenfalls bei etwa 0,10 Dollar, hat aber 100 MHz, 16 KB RAM, 256 KB Flash, USB und sogar ein 2,4-GHz-Paketradio; ich habe mir schon ein Entwicklungsboard bestellt.
  • Es gibt viele Mikrocontroller, die als USB-Gerät arbeiten können, aber hier wurden sie wegen der Gehäusebeschränkung ausgeschlossen.

• Für Leute, die das Board selbst bauen wollen, wäre es gut, auch die nötige Leiterplattendicke anzugeben.
  Wenn ich mich richtig erinnere, sind es etwa 0,8 mm; diese Dicke braucht ein „USB-C-Edge-Connector“, damit er in den Stecker passt.

• Ein hervorragender Artikel, aber ich frage mich, ob es deutlich einfacher geworden wäre, wenn man die 8-Pin-Anforderung ein klein wenig flexibler gesehen hätte.
  Schon ein paar zusätzliche Pins hätten die Projektkomplexität stark reduziert, während die Lötzeit wohl nur minimal gestiegen wäre.

  • Dann wäre es überhaupt keine Herausforderung und kein Spaß mehr gewesen.
    Es gibt viele deutlich schnellere Chips mit integriertem USB.
    Auch der Allwinner V3s lässt sich von Hand löten, hat integrierten RAM und bootet Linux nativ sehr gut.
    Der RP2350 wäre ebenfalls eine gute Wahl und bietet ein hervorragendes QSPI-RAM-Interface mit integriertem Cache sowie USB-Unterstützung.

• Es ist fast eher ein Projekt mit nur 2 Chips
  Einer davon ist einfach ein USB-zu-Seriell-IC, und wenn man die SD-Karte nicht mitzählt, sind es mit der SD-Karte wieder 3
  Die Gesamtzahl der Pins ist so gering, dass man Lust bekommt, es im Dead-Bug-Stil aufzubauen

  • Eine Dead-Bug-Version habe ich nicht gebaut; wer das tut, wäre also der Erste
    Ein microSD-auf-SD-Adapter taugt ganz gut als lötbarer microSD-Halter
  • In der SD-Karte selbst steckt ebenfalls ein ziemlich leistungsfähiger Prozessor, vermutlich ein 32-Bit-ARM
    Ein ähnlicher Trick darauf als Ziel wäre wohl auch ein interessanter Hack
  • Den USB-zu-Seriell-IC kann man in das Kabel auslagern, das jemand anders gebaut hat, und ihn dann „nicht mitzählen“; ähnlich wie wenn man die microSD nicht mitzählt

• Technisch ist das ein sehr cooles Projekt, aber es scheint so sehr auf die Spitze getrieben, dass es etwas am Ziel vorbeigeht, ein neues Computer-Kit für Einsteiger zu bauen
  Für Einsteiger macht es keinen großen Unterschied, ob sie SOIC8 oder SOIC28 löten
  SOIC28 ist meiner Ansicht nach ungefähr genauso leicht oder schwer wie SOIC8
  Mit einem größeren Chip ließen sich zumindest einfacher Sound, eine Tastatur und später sogar eine echte Monitorausgabe im VGA-Stil ergänzen, wodurch es ein viel nützlicherer Computer werden könnte
  Die Löt-Schwierigkeit würde kaum steigen, während es eine gute Basis für interessierte Nutzer wäre, um darauf aufzubauen

  • Stimmt
    Wenn du es in diese Richtung bauen willst, kannst du meinen Code verwenden
    Ich habe es so gemacht, weil ich die künstliche Beschränkung auf 8 Pins spannend fand

• Ich verspüre den seltsamen Drang, sogar die Platine wegzulassen und daraus eine Schaltungsskulptur zu machen

  • Wenn man es so baut, sollte auf einem der ICs per Silkscreen „555“ stehen
  • Wäre schön, das zu sehen
    Ich bin kein Künstler oder Bildhauer, deshalb habe ich mich nicht daran gewagt

• Als Speichermedium statt einer SD-Karte 8-Pin-SPI-Flash zu verwenden, wäre niedlich

  • Habe ich mir angesehen, aber dann wird die Art, Dateien hinein- und herauszubekommen, schwierig

• Er sagte, er habe „aus persönlichen Gründen eine Allergie gegen RISC-V“; ich bin neugierig, warum

  • Mir gefällt der Befehlssatz nicht
    Ich will keinen Flamewar starten; es ist nur meine persönliche Meinung, aber eine ziemlich starke
    RISC-V wurde historisch spät genug entworfen, um viel vorhandenes Wissen nutzen zu können, aber meiner Ansicht nach wurde davon kaum Gebrauch gemacht
    Deshalb werden jetzt diverse Erweiterungen vorgeschlagen, um Dinge zu reparieren, die von Anfang an richtig hätten gemacht werden müssen
    Mit immer mehr Ergänzungen nähert es sich erst nach 10 Jahren langsam einer sinnvollen Form
    Auch die Ausrede, es habe eben einen Lernprozess gebraucht, überzeugt mich nicht
    Die nötigen Informationen waren von Anfang an da, und die Fehler waren für die meisten von uns offensichtlich
    Manche Erweiterungen sind nichts weiter als Pflaster auf grundlegende Designprobleme
    shadd2 zum Beispiel ist ein Pflaster für das Fehlen eines vernünftigen Adressierungsmodus für Array-Zugriffe
    Die übliche Antwort darauf ist das Versprechen magischer Instruction Fusion im Core; das wird oft versprochen, aber in der Praxis nicht geliefert
    Vor allem nicht bei den Low-Cost-Prozessoren, die scheinbar das einzige Ziel von RISC-V sind
    Dass Befehle zum Extrahieren und Einfügen von Bitfeldern fehlen, ist ebenfalls ein amateurhafter Fehler, und deshalb gibt es auch eine Erweiterung, die das behebt
    Aber dass solche Funktionen nötig sind, hätte von Anfang an klar sein müssen
    Auch Befehle für bedingte Sprünge anhand bestimmter Bits in einem Register kommen häufig vor und sind eine offensichtliche Funktion, die man von Beginn an hätte berücksichtigen müssen
    Schon eine kurze Analyse moderner Software hätte das gezeigt
    Das Ärgerliche ist, dass die Informationen bereits vorhanden waren
    Man wusste, was moderne Software tut, hat es aber alles ignoriert, und am Ende haben wir im Grunde ein leicht aktualisiertes MIPS-1 bekommen
    Jetzt sind jede Menge Erweiterungen angeflanscht, und die Fragmentierung ist stark geworden
    Man könnte ein einigermaßen vernünftiges Endergebnis wie RV23 anvisieren, aber dafür gibt es keine Hardware; andernfalls muss man auf den kleinsten gemeinsamen Nenner zielen, der überall läuft, aber miserabel funktioniert
    Wenn man RISC-V für echtes High-Performance Computing verwenden will, gibt es noch gravierendere Designprobleme, aber das hebe ich mir für den nächsten Rant auf
    Ein anderer Befehlssatz, der ungefähr zur gleichen Zeit entworfen wurde, hat das Wissen darüber, wie moderne Software aussieht, tatsächlich genutzt, und das Ergebnis zeigt sich: aarch64

• Das Projekt selbst ist ebenfalls sehr cool, aber diese Seite ist auch eine hervorragende Ressource, um Informationen über kleine Mikrocontroller zu bekommen
  Die WLCSP-Familie fehlt zwar, aber sie führt auch zur Seite des MIPS-Emulators für ARM https://dmitry.gr/?r=05.Projects&proj=33.%20LinuxCard, die ziemlich interessant aussieht