Das packt schon ein ein ATmega8 mit 32 Servos:

https://www.roboternetz.de/phpBB2/ze...ag.php?t=24100

Die optimale Lösung sieht IMHO so aus:

Man hängt 4 Portexpander hintereinander und hat so 32 Ports. An jeden dieser Ports (oder einige davon) ein Servo.

Softwaretechnisch: Man aktualisiert im gewünschten Takt (wohl 20kHz-50kHz) die Expander. Bei Verwendung der HW-SPI braucht man ca 27 Takte, um ein Byte rauszukloppen (wegen Software-Overhead der Schleife). Wenn es noch schneller sein soll, könnte man die Schleife aufrollen.

Die 4 Expander parallel zu betreiben wie bei dem Servo-Controller im verlinken Beitrag bringt m.E. nicht viel, das einzige was man davon hat, ist ein Jitter auf den Ausgängen. Wirklich gewinnen tut man da nix... Es ist viel wichtiger, die Ports zuverlässig zu definierten, äquidistanten Zeitpunkten zu aktualisieren.

Selbst wenn man für jedes Servo nen eigenen Port hat, muss man für jedes Pin einen if-else machen und durch Hacks dafür sorgen, daß die Laufzeit unabhängig vom genommenen Zweig bleibt. Ansonsten jitterts. Und schneller ist man damit schwerlich...

Da man zu jedem Tick die Soft-PWM neu berechnen muss, könnte man diese Berechnungen in die Ausgebe-Schleife integrieren, d.h. PWM-Werte berechnen anstatt auf den SPI zu pollen. Evtl ist es besser, die Werte nach(!) der Ausgabe zu berechnen.

Den SPI im IRQ-Modus zu betreiben ist nicht angesagt, denn der ISR-Overhead ist zeitmäßig schon über der Dauer einer Loop-Umdrehung.

Was den g-Sensor angeht: Der liefert was Analoges (liest du via ADC) oder ne PWM (liest du via InCapt), nutzt also die HW-Parallelität voll aus.

Durch geschicktes SW-Design kannst du die IRQ-Respond-Times weiter drücken, vor allem wichtig für den InCapt.