Frequency analyzer built from the new Stellaris Launchpad

[bluehash 1,581]

Well, with 5.3, the CCS guys changed around a bunch of tool names, including the tms470 compiler that is used for the Stellaris line (they now call it the ARMv5 compiler).  That's why you're seeing the "Please install the ARMv5.0 Compiler" message... if it were just that my project was using a newer version of the tms470, CCS would still let you import, but give you a warning.  Since my project is using a compiler with both a different version and a different name from the one you have, it's outright not letting you import the project.  I'll push an update sometime today or tomorrow with the compiler set to the tms470... in the meantime, you can try poking around the .project files in the ccs directory to see if you can find out where the compiler is declared and switch that to whatever you're using.

That's something new to me. I've always wondered whats wrong with my compiler when i get those messages since upgrading to 5.3.

[EuphonistiHack 0]

Nice! Make sure you add it to the POTM.

I'm not sure what you mean by this... what is the POTM?

 

</newbie>

[CorB 64]

I am now simply upgrading to CCS5.3. Next job is to get Lars's LCD working on StellarisTI with your code. After that is done I will first see if I can get normal audio showing on the LCD as a spectrum and then step up to ultrasonics.

 

regards

CorB

 

EDIT: I always forget that upgrading CCS isnt something that takes 5 minutes ... now allready more than 1 hr plouging through all kinds of stuff that needs to be updated/installed. 

[CorB 64]

Hi

 

CCS5.3 installed and I have started working on the code. I see that the Olimex boosterpack uses the same convention as Lars's LCD, it uses SPI and uses MSP430 pin 1.4 = Stellaris J1.6 as the CS pin it seems.

 

Reading through the documentation of the LED_equalizer code I saw this:

 

 

//  Olimex J1

//  Pin 1 - Vcc = J1[1] - VBUS

//  Pin 6 - SR_LATCH = PA4 - GPIO

//  Pin 7 - SR_SCK      = PB4 - SSI2Clk

//

//  Olimex J2

//  Pin 1 - GND = J1[2] - GND

//  Pin 7 - SR_DATA_IN  = PB7 - SSI2Tx

 

According to me this isnt par with the documentation of the Stellaris launchpad:

 

PIN J1.6 on Stellaris is not PA4 but PE5

and

PIN J2.7 isnt SSI2Tx, so you probably are using J2.6 which is PB7 and SSI2Tx.

 

Can you confirm this ?

 

For ease of use Ive put a template below I will be using to keep track of the connections I am using for the launchpad. This often is easy when checking an old piece of code with HW attached.

 

//             ______________________

//            |                      |

//       VCC  |J1.1              J2.1| GND

//            |J1.2  pb5   pb2   J2.2|

//            |J1.3  pb0   pe0   J2.3|

//            |J1.4  pb1   pf0   J2.4|

//            |J1.5  pe4   xxx   J2.5|

//  glcd-cs   |J1.6  pe5   pb7   J2.6|<-------| glcd-MISO

//  glcd-CLK  |J1.7  pb4   pb6   J2.7|------->| glcd-SOMI

//            |J1.8  pa5   pa4   J2.8|

//            |J1.9  pa6   pa3   J2.9|

//            |J1.10 pa7   pa2  J.210|

//            |                      |

//             ----------------------

 

 

cheers

CorB

 

 

 

 

 

[bluehash 1,581]

I'm not sure what you mean by this... what is the POTM?

 

</newbie>

Np...it's the Project of the Month Contest.

[CorB 64]

Thumbs up for this board !! Using the SPI was (at least compared to the time spend trying on the C2K platform) on the Lars' LCD really simple. PORT E_pin5 is the CS line and the other lines (CLK and TX) are the same as in the original code.

 

The initialisation of the SPI for Lars' LCD is:

void
InitHWSSI()
{
	//
	// Initialize the pins we will need for communication with the LCD over SPI
	//
	ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_SSI2);
	ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOE);
	// CS ENABLE
	GPIOPinTypeGPIOOutput(GPIO_PORTE_BASE, GPIO_PIN_5);
	// CS LOW
	GPIOPinWrite(GPIO_PORTE_BASE, GPIO_PIN_5, 0);

	ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOB);
	GPIOPinConfigure(GPIO_PB4_SSI2CLK);
	GPIOPinConfigure(GPIO_PB7_SSI2TX);
	GPIOPinTypeSSI(GPIO_PORTB_BASE, SSI_CLK | SSI_TX);
	//
	// Configure SSI2
	//
	SSIConfigSetExpClk(SSI2_BASE, SysCtlClockGet(), SSI_FRF_MOTO_MODE_0,
					   SSI_MODE_MASTER, SysCtlClockGet()/2, 16);

	//
	// Enable the SSI module.
	//
	SSIEnable(SSI2_BASE);

}

 

 

 

The new SPIWrite Routine to write to the LCD looks like this (in library glcd_hwSPI).

void SPIWrite(uint16_t command, uint16_t data)
{
	uint16_t spidata;
	spidata = command<<15;
	spidata = spidata | data <<7;

	SSIDataPut(SSI2_BASE, spidata);
	//
	// Wait until SSI is done transferring all the data in the transmit FIFO
	//
	while(SSIBusy(SSI2_BASE))
	{
	}
	//
	// Hit the SSI latch, locking in the data
	//
	GPIOPinWrite(GPIO_PORTE_BASE, GPIO_PIN_5, GPIO_PIN_5);
	GPIOPinWrite(GPIO_PORTE_BASE, GPIO_PIN_5, 0);

}

Everything thusfar seems to work, next up is to get the original output ment for the 8x8 Olimex boosterpack working for the LCD. Easy implementation will be to create 8 bars on the LCD that show the incoming audio.

 

cheers

CorB

 

PS: Since I do not want to disturb the original posters topic Ive created a new topic specific for the LCD

Edited December 17, 2012 by CorB

[larsie 121]

Wow... this is so nice! Really cool!!!

[CorB 64]

Hi all,

 

Ive now also got the code running properly with the LCD attached. It will show 8 bars with a valuerange of 0-102.

I wanted to test the code using the SampleSineTest but that did not show anything ... maybe EuphonisticHack can tell how that routine (is commented out in the original version) is used.

 

cheers

Cor

[CorB 64]

Hi,

 

I started to use the code in my "bat detector" project and found something that looks a bit odd:

 

After calculating the FFT for a given set of samples the power of the FFT samples is calculated for a 2x as large set of samples. Normally the power is calculated for only half of the samples ... anybody with a guess why in this example of FFT its 2x the size of the sampleset ?

//
	// Calculate complex power of FFT results
	//
	arm_cmplx_mag_f32(g_fFFTResult, g_fFFTResult, NUM_SAMPLES * 2); 

regards

 

CorB

EDIT 25/12 : Ive read the documentation and the routine should read : arm_cmplx_mag_f32(g_fFFTResult, g_fFFTResult, NUM_SAMPLES ); 

NUM_SAMPLES stands for the number of samples for both the real and imaginary parts of the data. So the total amount of data is NUM_SAMPLES*2.

 

Secondly I found that the old LED_EQUALIZER code uses all of the FFT output to make a spectrum graph. The output of FFT is an array half the size of the FFT and contains data that is in general considered double(mirrored). So the real usable part of the output is for a 2048 large FFT only the first 512 values. 

Edited December 25, 2012 by CorB