Best Analog Signal Processing Method with the C2000 or Stellaris MCU

Hi Robert,

Your best bet for C2000 internal ADC is F28335, which has a 12.5 MSPS ADC (@12-bits).  If you want to use an external ADC, F28335 is also probably a good bet, as it has an XINTF (parallel external memory) interface.

In an oscilloscope application, I think you will want to use an external crystal? Piccolo class devices do have an internal oscillator, but the accuracy is 1% over temperature. This would directly add 1% error to all frequency / pulse width measurements and would similarly distort any frequency domain measurments.   

I am not sure if I follow the need for external asynchronous RAM; all C28x devices should have enough RAM to hold at least a couple 400-600 sample waveforms? 

Thanks for the advice!

I didnt know anything about the parallel external memory interface. I will look after!

I did not calculate with the oscillator error but now clear I should use an external oscillator. And what do you suggest for clock generating? Clock generator IC, PLL, VCO?

Last time when I tried to capture 500 sample I filled an array with a for cycle which read the port with every sampleclock with the follow instructions:

array[i]  =  GpioDataRegs.GPADAT.all;   // the 8 bit ADC digital out is connected to GPIO0-GPIO7

and I found that quite slow. I think if I use FIFO ram it could sample faster then the MCU can process the reading.

Most C28x devices have two pins, X1 and X2, where you can connect a crystal directly.  You may also need some load capacitors in the low pF range; consult the datasheet for whatever crystal you select.  As an example for F28335, you can find the controlCARD schematics, which includes a crystal resonator, in ControlSUITE in .\~controlCARDs\CC2833xHWdevPkg\F28335controlCARD HWDevPkg ZJZ [R2.2].  

The internal RAM on the C28x is 0-wait state (can be accessed at max CPU speed).  I don't think there is any way to get external RAM to operate effectively faster than this, especially considering the maximum I/O toggle rate for the device is about 25MHz.    

Your time may be better spent looking at what the compiler is generating for your memory move.  Changing the compiler optimization level may help.  You could also try re-structuring the array indexing as a pointer de-reference (possibly with auto-increment to step through the array) to see if the compiler generates something better (worst case, you can hand-write the assembly).  For internal ADC, if you aren't already, set multiple ADC result registers to capture the same channel, then copy all the conversion results at the same time - this will effectively unroll the memory movement loop and may reduce spin-wait time (search the forum for "ping-pong" sampling).   

Great post! :)

Can you explain why just about 333 kHZ is the sampling frequency with the follow 'bit-bang' code?

for(i=0;i<sample;i++){

                array[i]  =  GpioDataRegs.GPADAT.all;    //reading the 8bit parallel AD

                GpioDataRegs.GPATOGGLE.all = 0x10000;
                GpioDataRegs.GPATOGGLE.all = 0x10000;
}

The CPU runs at 60MHz (TMS320F28027).
Does the GPIO toggling slows down the procedure or is there any background "quasi parallel" process what I dismissed? ( I used sample codes to initialize the CPU to 60 MHz, init the SCI to 115200)

And does the TMS320F28027 has DMA module?
I dindt find anything about that.

I found the problem. I am writing the code to the FLASH. And the Flash is much more slower then RAM. So I check the RAM and I can get 4,3 MHz squarewave with the same code.

But I have problems with the code size. CCS says it does not fit to the RAM if I add the initialization of SCI.

Robert,

I usually put all time-critical code into RAM (or more correctly move it from FLASH to RAM early in initialization).  I then put all initialization code, rarely used routines, etc into FLASH and run them from FLASH.

---

A good example of this is the following controlSUITE example:
\controlSUITE\device_support\f2802x\v129\DSP2802x_examples_ccsv4\flash_f28027\

InitFlash found in the linked file "DSP2802x_SysCtrl.c" is moved from flash to ram via the following pragma.  This assumes that ramfuncs is defined in the linker command file and that ramfuncs is actually moved in the main code.  Both are done in the specified project.
#pragma CODE_SECTION(InitFlash, "ramfuncs");

All this is talked about in more detail at the following:
\controlSUITE\device_support\f2802x\v129\doc\controlSUITE_DSP2802x_HeaderFiles_Quickstart_Readme.pdf


Thank you,
Brett

Thanks!

Your comment help me soo much! :) I wrote the code and tomorrow I will test it. I hope it will works as I want.

I dont know why but when I wanted to import the project It did not find any headers... I spent a lot of time to figure out how to bring it to work. And still I did not like the C2000 MCUs as MSP430 MCUs. It is soo much easier to do that what I want. I believe that the ControlSuite is easy to use, but for who? :D

Sometimes I feel very lost on TI site or when I browse some documents. There are a lot of informations what I dont need and I never find that what I need... Just when I looking after for 2-3 days maybe... But the forum is great I always find an answer for my questions. I appriaciate that!  :)

Robert,

One note on importing projects: many of our projects are linked in such a way that choosing the 'Copy project into Workspace' option (or something similarly worded) will break some of the linking when importing in a project.  I believe that unchecking this option may help you as you are using C2000's examples.

Our documentation is something that that we are always working on.  controlSUITE in particular was a response to the specific problems that you've mentioned: an inability to find what is needed. If you have any feedback, we will be glad to take it into future consideration.


Thank you,
Brett