[QUE]Recommend for hardware of my project.

[biomed12]

Dear members,

I am working on a project now. The project is mcu based. Very basically, It is a medical signal processing board which have usb and internet connection feature. So, there are two main jobs in there.

1- signal processing(digital filter algorithms and adc process etc..)
2- peripheral tasks(lcd, TCP communication, USB etc..)

I thought to use 2 MCU for project. For first, dsPIC30f3014 and for second, 18f4550. But I am not sure for using these devices. Because, I feel it like an unnecessary hardware component consumption... On the other side, I think I should use a MCU apart from 18f4550 because sampling rates will be high(about 2000 samples per second).

What do you think about it dear members, especially who are related to signal processing areas.

Thanks.

[frnando]

If you're on Microchip families, why not use a PIC32? You can have ethernet and usb connection on the same chip, and a lot of horsepower (MIPS) and memory to deal with signal processing, and no worries about inter-chip communications.

[baybay]

All of them are microchip's product but they are very different MCUs. especially PIC32 and other pic series. Since, PIC32 builts arround MIPS core. PIC32's architecture is very different and also instruction set is very different.
 
I don't have any information about PIC32's signal processing capabilities but ARM Cortex-M4 and M7 have very strong DSP capabilities.

Cortex-M7's pipelines are "superscalar" pipeline. I think Cortex-M7 MCUs (atmel or stm32f7 series) are good solution..

[Checksum8]

If you can go 3 volts the Dspic33ep family is a good choice and use an external usb IC like
this for example

http://www.ftdichip.com/Products/ICs/FT600.html

Or pic32, microchip has a DSP library for this family.

[Sideshow Bob]

Is this a one of/small series  hardware project? If it is I would perhaps look into Raspberry pi. But not saying that is the only solutions. A Dspic also sounds like an good idea by all means. Anyway I wold perhaps go for 16 bit AD and not using the internal 10 or 12 bit ADC. I would also have used an isolated USB port like this http://www.analog.com/media/en/technical-documentation/data-sheets/ADuM4160.pdf they do offer an eval board http://www.analog.com/media/en/technical-documentation/user-guides/UG-043.pdf

[biomed12]

Is this a one of/small series  hardware project? If it is I would perhaps look into Raspberry pi. But not saying that is the only solutions. A Dspic also sounds like an good idea by all means. Anyway I wold perhaps go for 16 bit AD and not using the internal 10 or 12 bit ADC. I would also have used an isolated USB port like this http://www.analog.com/media/en/technical-documentation/data-sheets/ADuM4160.pdf they do offer an eval board http://www.analog.com/media/en/technical-documentation/user-guides/UG-043.pdf

Which component do you recommend as a 16-bit adc IC?

Posted on: September 22, 2016, 05:17:08 17:17 - Automerged
Some members says consistently for using PIC32s but I dont know anything about it and its architecture. Also I don't have enough time to learn it.

[Sideshow Bob]

Which component do you recommend as a 16-bit adc IC?

Posted on: September 22, 2016, 05:17:08 17:17 - Automerged
Some members says consistently for using PIC32s but I dont know anything about it and its architecture. Also I don't have enough time to learn it.

That will depend on many factors. Like is the input uni or bipolar, input signal range and many others. number of inputs and conversions speed. To mention a few. You must tell us much more about your project and what you plan to do. You seem to be quite new at this. Are you a student

[Signal]

digital filter algorithms and adc process etc..

There are two main factors you should define about your DSP after defining desired algorithm: acceptable delay, and amount of calculations. These factors are somehow connected through selection of algorithms and ability of chosen hardware.

For example, if there is no control loop in your application and all you need is to pass conditioned data to host then some buffering and thus block implementation of algorithm could be more effective on certain processor, while needs more memory. Buffering (especially using DMA) helps in case both DSP and control/interface tasks run on single processor.

Contrary, if your application needs DSP in control loop then usually you need as short delay as you can achieve, so no block processing - each new sample is processed individually. In that case a stable interrupt latency is also important, that leads to proper processor selection (I'd say rather dsPIC/PIC24 than MIPS32).

Without certain numbers that characterize your project you can not get certain answers - just spherical cow in vacuum. Your "etc.." is not specific enough.

[bigtoy]

I'd be looking at Cortex-M4 parts. They give you DSP instructions, floating point, etc. Specifically take a look at some of the Freescale (now NXP) Kinetis parts. A number of them have 16-bit ADCs on them, ethernet ports, and so on. You should be able to find some parts there which satisfy your needs of CPU power and peripherals.

[bobcat1]

PIC  microcontrollers are very limited for DSP processing although the company trying to show they are
most of the algorithm written for DSP processing in PIC was written in assembly language, which point to processing power limitation
I recommend you to switch to ARM processor (M4 or M7) who provide optimize algorithm written in C language far more easy to use and understand in compare to algorithm written in assembly language, where you can use Mathlab to generate floating point coefficients and directly add them to the c code where in PIC you will need in most cases convert them to fixed point in other to use them

All the best

Bobi

[biomed12]

There are two main factors you should define about your DSP after defining desired algorithm: acceptable delay, and amount of calculations. These factors are somehow connected through selection of algorithms and ability of chosen hardware.

For example, if there is no control loop in your application and all you need is to pass conditioned data to host then some buffering and thus block implementation of algorithm could be more effective on certain processor, while needs more memory. Buffering (especially using DMA) helps in case both DSP and control/interface tasks run on single processor.

Contrary, if your application needs DSP in control loop then usually you need as short delay as you can achieve, so no block processing - each new sample is processed individually. In that case a stable interrupt latency is also important, that leads to proper processor selection (I'd say rather dsPIC/PIC24 than MIPS32).

Without certain numbers that characterize your project you can not get certain answers - just spherical cow in vacuum. Your "etc.." is not specific enough.

Signal, you are always wanting from me "more details, more details..." but, as I said I am a last class student and trying to learn somethings for practical.. In meantime you behave me like I am a professional person on signal processing or its hardware. If I know these things you mention about, I could do everything myself and do not distrupt people with stupid questions.



Posted on: September 25, 2016, 06:07:35 18:07 - Automerged

That will depend on many factors. Like is the input uni or bipolar, input signal range and many others. number of inputs and conversions speed. To mention a few. You must tell us much more about your project and what you plan to do. You seem to be quite new at this. Are you a student

Yep. I am very very new. On the other bad side, In no lecture noOne did not mentioned about how realized a digital filter. I am collecting some informations and studying advanced level C Programming language nowadays... 

[nPn]

dsPIC does have "real" DSP computing features like zero-delay looping (the hardware handles decrementing loop counter and hides the latency), dual ported memory, saturating fixed-point arithmetic (including multiplier), circular addressing. That lets you program very tightly controlled predictable filter, controllers, etc in assembly and gives you much more performance than you expect from MHz count.

But it's always easier to write C for faster chips (even weak Cortex-M3s are much faster) and let the C compiler figure out how to run it fast.