Hui, seeehr konstruktive Antworten hier. Wenn man für parallele Peripheriebausteine Daten- und Adressbus braucht, hat man traditionell Prozessoren statt Controller verwendet, aber nicht, weil es immense Vorteile hat, sondern weil Controller schlicht und einfach nicht dafür gedacht waren, Prozessoren zu ersetzen. Trotzdem besteht bei sehr vielen Controllern nach wie vor die Möglichkeit, sonst frei definierbare I/O-Ports, die alle möglichen Funktionen (A/D, UART, I2C...) haben können, als Adress- und Datenbus umzukonfigurieren. Man sollte sich dabei natürlich im Klaren sein, dass man viele der Funktionen, die den Controller zu dem machen, was er ist, abschaltet. Daher sollte man abwägen: braucht man einen bestimmten parallelen I/O-Baustein (zB ein IEC-Bus-Controller, hab ich noch nicht mit SPI gesehen), kann man ja mal versuchen, einen Controller zu finden, wo er sich anschliessen lässt, ohne allzu viele der controlletypischen Funktionen lahmzulegen, wenn man täglich zB AVRs programmiert und dann einmal ein System mit paralleler Peripherie aufbauen muss, ist es sicher zeitsparend, auch hier einen Controller als Prozessor zu missbrauchen. In allen anderen Fällen würde ich immer zu einem Controller neigen und zusehen, dass ich gerade keine parallelen Bausteine anschliessen muss. Wenn ich "richtig rechnen" muss und dabei noch viel RAM brauche, wäre ein Prozessor am Zuge, wobei heutige Prozessoren (ARM zB) auch schon controllerähnliche Züge annehmen, neben den parallelen Bussen für RAM, Flash und Peripherie sind SPI und I2C häufig auch schon drin.