This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

C6711 capabilities

Good day

I'm just starting to get  into using the DSP field and was tasked to program a condition monitoring application for it (in simulink).  I was given the C6711 hardware to peform this on, though. Sadly, at the time I confess I didn't know enough about the field to make a sound judgement and took a colleague's word that the hardware would be capable of performing this task.

Now that it's time to start to implement the algorithms, I'm worrying about several aspects of the hardware:

Sensor compatibility - It seems as though the device is designed for audio applications primarily.  Not condition monitoring, I need to use an accelerometer.

Execution time - As far as I could ascertain, the device processes the data in real time, but I require the device to make a measurement, store the data, process the data and give an output. I'm aware of the possibility of using frames, but my version of Simulink does not support frame-based data in the embedded matlab function block.  Only sample based data.

Memory - Typically, the application requires 15s of data (sampling frequency of 8kHz - maximum of the device, might just be enough). If I read the specsheats correctly, the device has a memory in the kB range.  This will undoubtedly be too little.

At least it does have LED lights, which would be perfect for the output.

Any opinions about my assesment of the siutation would be very helpfull.  I'd like to get my facts straight before taking this matter up with my superior, so that we can decide what to do next. As I said, my knowledge of the field is still not ideal..

Many thanks

Rudi

  • Rudi Kroch said:

    I'm just starting to get  into using the DSP field and was tasked to program a condition monitoring application for it (in simulink).  I was given the C6711 hardware to peform this on, though. Sadly, at the time I confess I didn't know enough about the field to make a sound judgement and took a colleague's word that the hardware would be capable of performing this task.

    With a positive attitude, I am sure you will succeed, impressing both your superior and your colleague.

    Rudi Kroch said:

    Sensor compatibility - It seems as though the device is designed for audio applications primarily.  Not condition monitoring, I need to use an accelerometer.

    The C6711 may have been originally targeted for audio applications, but it will very likely be superb for your application, too. The McBSP is very flexible and can connect to a variety of serial-protocol devices. Otherwise, the EMIF is capable of interfacing to an asynchronous memory-like interface.

    What do you need to match to connect your accelerometer? Does it use a parallel or serial interface? Will it connect directly to either of these ports, or will you need to add an adapter of some type.

    There are companies like Link Research that make adapter boards for TI DSP EVMs. These can include other connectors or just prototyping area to allow you to add some simple CPLD, if needed, in order to get your accelerometer connected.

    But this is all just part of the fun of engineering, figuring out how to connect one thing to another. At least it is the first part of the fun process.

    Rudi Kroch said:

    Execution time - As far as I could ascertain, the device processes the data in real time, but I require the device to make a measurement, store the data, process the data and give an output. I'm aware of the possibility of using frames, but my version of Simulink does not support frame-based data in the embedded matlab function block.  Only sample based data.

    At an 8KHz sample rate, you have 15-30K instruction cycles to do your "process the data" step, depending on the speed of your processor. If this is not enough, then you need to optimize the algorithm or get a faster DSP. If your output is an LED, you do not really need to be generating highly complex results at an 8KHz output rate. And monitoring an accelerometer probably does not require more processing performance than you have available. But with what little I know about it, I cannot say that for sure. But I will give you a 99% chance of success anyway.

    Rudi Kroch said:

    Memory - Typically, the application requires 15s of data (sampling frequency of 8kHz - maximum of the device, might just be enough). If I read the specsheats correctly, the device has a memory in the kB range.  This will undoubtedly be too little.

    If your "C6711 hardware" is the DSK, it comes with 16MB of SDRAM. That will store 2000 seconds of 8KHz samples of bytes. You might want to move the data in/out of internal memory in smaller blocks during processing, but try it with the data all stored in SDRAM first. The cache might make it work just fine for you.

    Rudi Kroch said:

    At least it does have LED lights, which would be perfect for the output.

    Any opinions about my assesment of the siutation would be very helpfull.  I'd like to get my facts straight before taking this matter up with my superior, so that we can decide what to do next. As I said, my knowledge of the field is still not ideal..

    My opinion is that you have listed all of the correct categories to be concerned with. Now you must fill in all the detail before you will know what works. We have a huge variety of DSPs and MicroControllers, it is absolutely true that you will be able to do this with something from the TI product line. My gut feeling is that the C6711 will easily do the job, but you will know for sure once you get the details figured out on the hardware interface and the software requirements.

    Good luck!

  • Many thanks for your reply.  It's much appreciated.
    Rudi Kroch said:

    Execution time - As far as I could ascertain, the device processes the data in real time, but I require the device to make a measurement, store the data, process the data and give an output. I'm aware of the possibility of using frames, but my version of Simulink does not support frame-based data in the embedded matlab function block.  Only sample based data.

    RandyP said:

    At an 8KHz sample rate, you have 15-30K instruction cycles to do your "process the data" step, depending on the speed of your processor. If this is not enough, then you need to optimize the algorithm or get a faster DSP. If your output is an LED, you do not really need to be generating highly complex results at an 8KHz output rate. And monitoring an accelerometer probably does not require more processing performance than you have available. But with what little I know about it, I cannot say that for sure. But I will give you a 99% chance of success anyway.

    In the mean time, I've come to grips with all the points I made apart from the workflow of the dsp. I'm unsure if I'm misunderstanding you here of if you might have misunderstood me. The workflow of the application is as follows, pardron if everthing is not strictly relevant. It's included for the sake of background info.
    You take a 15s measurement of vibration data with an accelerometer.  With the 15 secs of data, 8 sections are extracted (there is an overlap of the data sections). Magnitude FFTs are obtained for the 8 sections and averaged (spectral averaging, basically). Then, further analysis is done on the averaged PSD (identifying peaks, harmonics, sidebands, etc). Based on the results of the analysis, one of the three onboard LEDs are activated.
    This implies that instead of a continuous data stream coming into the processor, getting processed and the output given, the entire 15s of data needs to be processed as a whole and in its entireity at once. Logic tells me that to do this, the entire 15s of data needs to be measured and stored in the memory first and then processed as a whole afterwards according to what I described above. Am I correct with this analogy?
    All the applications I've come across involves a real time workflow.  As the data comes in, it gets processed, and the result is sent to the output port. It is a continuous flow of data through the dsp. And exactly this is my concern. I'm unsure if the dsp is only capable of working in real time? Or can it be programmed to measure and store the data first and then process it as a whole?
    Pardon the persistance, but I find this quite concerning.
    Many thanks
    Rudi
  • The speed of the DSP and the 8 parallel processing elements of the DSP make it capable of working on a sample-by-sample basis for many applications. But there are a very large number of applications in which the processing is done on a block of samples - the processing can be more efficient in this case, or just more practical. In fact, most applications that involve an FFT would be based on block sampling.

    If the block of samples can be processed before the next block has been stored, the processing can be considered "real time". There is a longer latency in this case, but if the data processing can keep up with the input data rate then you will still be real time, as opposed to losing data or storing the data for processing much later.

    The EDMA will be very helpful to you by storing each sample of data into the 15s buffer. You may be using 2 of those so that one can be filling while the other is being processed. The EDMA might be useful for copying blocks of data from the 15s buffers to internal memory for processing, but the cache might also be adequate for this.

    The EDMA can be programmed to send an interrupt to the DSP when the buffer is filled so that the processing may begin.

    But no matter how you implement the data capture portion of the project, the DSP will be very capable of counting off the number of samples until you are ready to start processing, then processing the bulk data exactly as you wish.