One thing you'll eventually learn is that you can't design a solution to a problem until you define the problem.

One thing you have to determine is the size of the data you'll be processing. If you're going to be processing data that changes in 8-bit units, or in completely random units, you can probably do the job with an 8-bit MCU. If the data you have to process changes at a 100 KHz rate, then your MCU can probably process the data at 1 microsecond per instruction, which is the rate at which the "standard" 805x MCU's operate. Now, there are faster versions, as a review of the discussions in this forum will amply demonstrate, but you do need to know how much data you have to process per unit of time, and a rate of nominally ten instruction cycles per unit of data is about the minimum.

If you have more than 8 bits of input data to process, then you probably need a 16 or 32-bit MCU, or you need an 8-bit MCU with a proportionally larger ratio of instruction cycles per unit of data.

There are 32-bit, e.g. ARM, CPU's that cost about what a mid-range 8-bit MCU costs. There are 16-bit MCU's in that range as well. It's really up to you to figure out what your project requirements are.

A "safe" way to approach the problem might be to consider the following: (1) What components will I need if I use MCU "XYZ?" (2) How readily available are the required components? (3) How easily can I implement the circuitry needed to accomplish my required task? (4) What software tools will I need? (5) How will I accomplish the firmware development? (6) Do the associated costs fit my budget?

If you think an 8-bit MCU can handle the job, then perhaps the easiestand safest way to proceed will be to use the fastest available MCU in the class e.g. use the fastest 805x or 68HC16 or ARM that you can (a) afford, (b) obtain, (c) implement. Of course, the easiest implementation path is to procure an "evaluation board" with adequate features to support your requirements. Don't forget that processing your inputs may require some signal conditioning hardware, so be sure there's a large enough place to put it.

Don't lose sight of the fact that you can't solve a problem until you define it, and until you clearly define the meaning of "solve."

RE