¿Debe el pin de reinicio en MCP23S17 ir a un GPIO?

Yo diría que sí en este caso.

Puede que no tenga sentido hacer esto siempre, porque algunos conjuntos de chips, como concentradores o dispositivos USB, necesitan un tiempo de reinicio estricto para responder a las solicitudes del host a tiempo. Si el período de reinicio es demasiado largo, es posible que no pueda enumerar. Si no puede satisfacer este tiempo con un "sistema de tiempo inferior al real" como un Raspberry PI, lo convierte en un gran desafío.

Si no existe tal limitación, sin duda lo conectaría. Presencié un caso en el que un fabricante de un producto DSP complejo no conectó una línea de reinicio a su conjunto de chips de RF. Desafortunadamente, el firmware del conjunto de chips (fuera de su control) se bloquearía en algún momento y no podría obtener una solución del proveedor. La solución para la recuperación fue apagar y encender el módem. Esto significó para nosotros, como usuarios finales, apagar y encender nuestro sistema completo. En última instancia, presionamos al fabricante para que retirara todos nuestros módems a una placa de hardware más nueva que tenía conectada la línea de reinicio (+su corrección de firmware). A fin de cuentas, fue un esfuerzo muy costoso para nosotros y para ellos arreglar esto.

Puede ser un ejemplo extremo, pero todo podría haberse evitado si hubieran conectado el pin de reinicio en primer lugar. No es que les faltara E/S, supongamos: la CPU anfitriona era un potente Cortex m4 en paquete BGA, en un diseño digital relativamente mínimo.

Desafortunadamente, no estoy al tanto de los tiempos de reinicio del conjunto de chips de RF, puede haber sido una limitación. Sin embargo, vale la pena considerar si el control del software puede garantizar un poco más de "seguridad" en la corrección de errores en el futuro.

¿Posiblemente? Puede haber situaciones en las que sea necesario reiniciar manualmente el dispositivo y conectar el pin nRESET a un GPIO lo permitiría.