¿El pin de reinicio en MCP23S17 debe 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 dispositivos o concentradores USB necesitan un tiempo de reinicio estricto para responder a las solicitudes del host a tiempo. Si el período de restablecimiento es demasiado largo, es posible que no se pueda enumerar. Si no puede satisfacer este tiempo con un "sistema menos que en tiempo real" como un Raspberry PI, lo hace muy difícil.

Si no existe tal limitación, ciertamente la conectaría. He presenciado un caso en el que un fabricante de un producto DSP complejo no conectó una línea de reinicio a su conjunto de chips RF. Desafortunadamente, el firmware del chipset (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 usuario final, reiniciar nuestro sistema completo. Finalmente, presionamos al fabricante para que retirara todos nuestros módems a una placa de hardware más nueva que tenía la línea de reinicio conectada (+ su corrección de firmware). A fin de cuentas, fue un esfuerzo muy costoso para nosotros y para ellos solucionar este problema.

Puede ser un ejemplo extremo, pero se podría haber evitado si hubieran conectado el pin de reinicio en primer lugar. No es que les faltara E / S, supongo: la CPU host era un Cortex m4 potente en un paquete BGA, en un diseño digital por lo demás relativamente mínimo.

Lamentablemente, no conozco 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 se requiera un reinicio manual del dispositivo y la conexión del pin nRESET a un GPIO lo permitiría.