Jump to content
Automate

Frequency analyzer built from the new Stellaris Launchpad

Recommended Posts

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.

Share this post


Link to post
Share on other sites

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. 

Share this post


Link to post
Share on other sites

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
 
 
 
 
 

Share this post


Link to post
Share on other sites

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 by CorB

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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 by CorB

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×