GPIO Bitbanging mit ATSAMD51G?

Shinner schrieb:

wie groß ist der Overhead bei einem External Interrupt auf dem ATSAMD51G?

Der Werbetext sagt was von 12 Taktzyklen, aber da geht es vor allem um Latenz. Den genauen Ablauf findet man hier: Kapitel B1.5.6 Exception entry behavior im Arm v7-M Architecture ® Reference Manual¹, aber dabei muss man annehmen, dass ein store genau einen Takt braucht. Dazu kommt der return, das dürfte noch etwas länger dauern.

Auf jeden Fall muss alles im RAM laufen, Flash kostet noch jede Menge wait states. Ich glaube, ohne Interrupts hast du eher eine Chance. Vielleicht kann ein Timer per input capture einen DMA Transfer starten, der die Pins kopiert. Wobei man den SYNC doch genau wie die Daten kopieren/abfragen könnte?

[1] https://developer.arm.com/documentation/ddi0403/ee/

Shinner schrieb:

Allerdings: kann diese Rechnung stimmen? wie groß ist der Overhead bei einem External Interrupt auf dem ATSAMD51G? Wie viel von meinen 60 Zyklen geht da allein durch den Interrupt verloren?

Das Problem ist, dass die gesamte Peripherie bei einem ARM-, MIPS oder RISCV-Kern asynchron zum CPU-Takt läuft, und das oft deutlich langsamer. Der Grund ist, dass der CPU-Kern ein zugekaufter Legoblock ist, der über spezielle interne Busse (AHB, APD, AXI,...) mit dem Rest des Chips (RAM, Flash, Peripherie, IO) kommuniziert, und das eben asynchron und unter Umständen mit Waitstates und gestallten Pipelines. Ausnahme ist das sogenannte TCM (Tightly Coupled Memory), das direkt am Prozessor hängt. Nur das läuft synchron mit dem Prozessor und mit der vollen Geschwindigkeit.

Bei 8- und 16-Bittern (z.B. dsPIC33) gibt es keine Trennung zwischen Core und Peripherie, weil da halt beides aus einer Quelle kommt. Die Peripherie ist bei einem dsPIC33 z.B. viel enger an den Kern angebunden und läuft immer synchron, und die SFRs (Special Function Registers) entsprechen vom Zeitverhalten bei einem Zugriff exakt einem Register- oder RAM-Zugriff. Ich hab das jetzt nicht nachgeschaut, aber es würde mich nicht wundern, wenn ein 100MHz dsPIC33CK im IO-Handling deutlich schneller als Dein 120 MHz ATSAM ist und damit auch weniger Jitter aufweist.

Die Betrachtung des Zeitverhaltens ist also viel komplexer als Du es vielleicht denkst.

Ich würde dafür ein kleines FPGA nehmen (z.B. ein Lattice MachXO, die sind einfach zu handhaben, brauchen nur 3.3V und haben internes Konfigurationsflash), und damit Dein Signal in irgendwas umsetzen, das der Prozessor direkt verarbeiten kann, z.B. I2S, SPI oder 8-bit breiten FIFO. Das ist dann absolut deterministisch, und das ist wichtig hier.

fchk