Electronic – How to select a DSP chip for ECG/EMG signals

If I was asked to look at DSP products, I would look at the architecture. The hardware architectures for DSP processors are more varied than for general purpose processors.

1. Word Length. As you mentioned, your source data is 24-bits. So, unless you are able to lose some fidelity, you will need a DSP that can handle 24-bits data at least.
2. Fixed/Floating Point. You will need to look at your algorithms to see if floating-point hardware is needed or if it can be entirely implemented in fixed-point. Not all DSPs can do floating-point in hardware.
3. Addressing Modes. You are dealing with buffers all the time. While DSPs have circular addressing modes, some have more advanced modes that are able to chain memory blocks together or flip memory blocks in hardware and more. I would say that this is the most critical architecture aspect for a DSP.
4. Special Instructions. Every DSP has specialised instructions. At the minimum, they will have a MAC instruction. However, some have far more esoteric ones which may benefit your application.
5. Data Paths. Some DSPs have unique data paths, or even multiple datapaths, which allow different data streams to be manipulated separately or combined together, in hardware.
6. Execution Units. Most DSPs have many parallel execution units that can perform different things at the same time - e.g. multiply, add and shift different registers at the same time.

Then, looking at the algorithms that need to be coded, I would select a DSP architecture that is easier to use to implement the algorithms.

If you just want to detect spikes, you don't need much processing power. You can easily make a analog circuit that holds the spike high level for a little while to give a processor a chance to detect it at the next periodic A/D reading. Or, the circuitry could detect the spike and drive a interrupt pin of the processor so that it can do whatever you want it to do immediately.

A brute force approach would be present the signal at the right amplitude and impedance to a A/D input of the processor, then do everything in firmware from there. Some of the dsPIC 33F can sample at 1 MHz or more, but you didn't give any specifics to know whether that is good enough or not. Such a processor would take a few 100 mW to run at full speed. Note that you only get 40 instruction cycles per reading at 1 MHz sample rate. That's enough to just detect a spike. If subsequent readings aren't needed for a while as you process the spike (whatever that means), then this would work.

If the spikes are really short, you can preceed the A/D with a analog spike-stretcher. Something like this:

A short positive spike comes in and causes C1 to be charged up. Even if the spike goes away immediately after, the voltage on C1 will stay high and decay with a time constant of 10 µs, which is a half-life of 7 µs. If you don't need to detect another spike for a few µs after one, then this sort of spike-stretcher relaxes the sample requirements on the processor.

The actual decay time and impedances will likely need to be adjusted to your particulars.

Update:

It is now apparent you are trying to measure characteristics of low bandwidth signals. "Low" being relative to what modern microcontrollers can easily measure and digest. In this case you don't need any fancy external analog circuitry other than to present the right amplitude and impedance to the processor A/D input. You can sample the signal at let's say 2 kHz rate with analog filters that start rolling off at maybe 300 Hz. With that kind of setup, the sample stream is guaranteed not to miss any features. And, at 500 µs/sample, there should be plenty of time do peak detection and other processing.

This is really not that hard a problem, unlike what it appeared you were originally asking about.