A bottom-up approach to a product makes it difficult to evaluate resource requirements when the product goals are not defined. You might start with some broader questions, such as how the PLC will be used by target customers.
If you add CAN and RS-485, how are these ports used? Will you be implementing common protocols for these ports, for instance Modbus for RS-485 and CANopen or J1939 for CAN? And how will these protocols fit in with the TCP/IP stack? Will you implement tunneling for these high speed ports so they can be accessed from Ethernet? Where do the object dictionaries for these serial port stacks come from?
If so you might want to review existing documentation on how to do this, as it will substantially impact your flash, SRAM and CPU cycle requirements. With an open ended design where this is undefined I would look at an STM32F7 class part for the extra memory and CPU cycles. If you go with the F429 and the code doesn't fit or you run out of SRAM you'll have to start over.
Since it will be in an industrial PLC environment you will need high priority capture capability on your GPIO inputs and low latency on GPIO outputs triggered by events. At the very least you'll need a preemptive RTOS for this, with higher priority levels for critical edge captures. If you also plan to support frequency or counter inputs you'll need a part with several hardware timers to supplement your GPIO array. Same for PWM outputs, especially if you modulate the duty cycle for something like a DC motor.
You'll also need some external storage for the PLC program and data, plus an error log. Again, if this product is to be responsive on a 100MBit enet you'll need a fast interface to page PLC code into SRAM, or to store and forward large datasets. Where are youe MQTT queues going to be stored? You can run out of SRAM very quickly. Look at parts that support QUADSPI interfaces to minimize external flash access times.
If you're looking to support 1Gbit ethernet then you need to look at ARM A class application processors, at least an A7. M class controllers can't handle the potentially high thruput rates.
Above all give some thought to how your TCP/IP stack will be handled. How do you get the IP address, net mask and DNS settings into it? Do you have to support multiple IP addresses? Do you put in a backdoor console with Telnet or something like it? How are you going to test network thruput under best and worst conditions? Will an F429 be able to handle a flood of incoming broadcast packets from a busy (and often misconfigured) customer network, while at the same time reliably capture realtime data?
CAN has it own set of issues. Will you support dual buses, and will it be in redundant mode? Do you know about the object dictionary nightmares that come with J1939? ST has a very good CAN interface if configured properly, especially if you use CANopen as the network protocol. CANopen also has a well-defined standard for tunneling through TCP/IP.
For RS-485 timing can be a major issue if you use Modbus RTU mode. Look for an ST part that supports a programmable IDLE detect time on the USART; it's a critical piece of hardware to get the inter-message gap detect working properly. You might consider implementing the transceiver as a 4-wire interface to monitor your outgoing messages to determine if the differential pair wiring is working. This will also double the workload for the USART handler, since you are verifying outgoing data read back from the wire in real time.
Bridging protocols across multiple networks is a very CPU intensive task and is susceptible to attack if any protocol or bridge conversion isn't implemented with care. Unless I knew the maximum thruput rates for customer configured data across all networks I would not recommend any M4 or M33 class controller. If you do decide to go with an M4 class controller you would be better off with an M33 controller that supports TrustZone, in order to secure your product against attacks from the TCP/IP side.
Jack Peacock
