Launchpad as a Data Acquisition module

[Mk_ 0]

Hi all,

 

I want to use the launchpad to build a DC motor position control system (for college).

I want to use one channel from the adc (to read a potentiometer) and one pwm (to control the speed of the motor).

 

As the "first step", i would like to only grab data from the adc with a fixed pwm, so to know the behavior of the motor.

 

Since the backchannel UART is limited to 9600 baud rate, i came up with 2 ideas of getting this data:

 

1 - Use the HW uart (from G2553 for eg.) and a FTDI (or any other Serial->USB).

2 - Use one or more SPI EEPROM chips to save this data, and send them "offline" to the PC, using the 9600 baud.

 

Does anyone know a better (or just simpler) way of getting this data out of the launchpad?

 

I already have a working code, were when you send a character 'c' from the pc, the adc makes one acquisition and send it back through the uart, but i cannot achieve much high rates.

 

Thanks in advance,

[SirZusa 34]

How much data do you need to store?

How much samples per minute (or second or hour)?

 

Maybe you want to have a look at the FRAM series (Experimenter Board) offering up to 16K inbuild non-volatile memory

[Mk_ 0]

Thanks SirZusa

 

My guess is that 1kSample/s for 10sec will be fine (10kSamples). (I will setup some parameters, run it and grab data for 10sec, then save this data, setup another parameters and so on..).

 

I'll take a look at the FRAM!

[SirZusa 34]

And of what type are these samples? Char? Int? Float?

 

Example if the samples have a size of 1 byte (= datatype char):

9600 baud (= Launchpad on-board UART) / (8 + 2 bit (= 1 byte + 2 control-bits)) / 1 byte = 960 bytes / second

 

So if your samples have a size of 1 byte each you can transmit 960 samples per second "in real-time"

[JWoodrell 285]

one thing to look at is a SD card. they have the ability to talk SPI into a SD card, that is on my project list to try myself after i get USB working. a SD card would give you as much data storage as you would ever want (a 2 GB card is just a few bucks).

 

here is a PDF talking about interfacing a MSP430 to a SD card over the SPI circuitry built in.

 

http://alumni.cs.ucr.edu/~amitra/sdcard ... _foust.pdf

 

hope this helps

[Mk_ 0]

SirZusa:

First i will try with 8bit samples to be easy to send/receive without much effort, but if it shows up to be losing precision, i will then change to more bits.

 

JWoodrell:

Since i dont need this really big memory, i will not try the SD card by now. But it will definitly goes to my to do list!

It would be nice to have a sort of file system, to do things like open/read/write/close text files, instead of just write bytes to the memory itself.

 

 

I was looking at the FR57xx user guide (slau272a), and to do this "data storage" in the fram seemed to be as easy as declare a unsigned char[] big enough and write every sample there (and the linker would take care of its placement).. Is that right?

[SirZusa 34]

The FRAm can be declared as code or data and the linker does this in most cases for you have a look at the Sources for the FRAM-Exp.-Board (slac492a) - they are using a pointer and increase it with every loop where the StartAdress is somewhere after the code

 

/**********************************************************************
* @brief  Performs 512 byte FRAM Write
* @param  StartAddress: For FRAM Write
* @return none
*************************************************************************/
void FRAM_Write(unsigned int StartAddress) {
 unsigned long *FRAM_write_ptr; 
 unsigned long data = 0x12345678;
 unsigned int i=0;

 //Incase FRAM Write Address is corrupted, exit loop
 if ((StartAddress >= FRAM_TEST_START) && (StartAddress < FRAM_TEST_END))  {
 	// Setup FRAM pointer
 	FRAM_write_ptr = (unsigned long *) StartAddress;

 	// Write 128 * 4 = 512 bytes
 	for ( i= 0; i<128; i++) {
   	*FRAM_write_ptr++ = data;
     }
 }
}

[oPossum 1,083]

I was looking at the FR57xx user guide (slau272a), and to do this "data storage" in the fram seemed to be as easy as declare a unsigned char[] big enough and write every sample there (and the linker would take care of its placement).. Is that right?

 

With CCS 4 you would have to declare const char foo[] to put it in FRAM. Then use a non-const pointer to write to it - char *x = (char *)foo;

 

I think CCS 5 has some way to put a non-const array in FRAM using a pragma or something.

[Mk_ 0]

SirZusa:

Thanks for point this out. I already looked another code that i've found searching ti's wiki, and it does something similar (setting a pointer anywere and writing to it), and it includes the code for the MPU too!

 

oPossum:

For sure!

I've looked forward on it, and checked slau132f (v4.0 compiler's optimization guide). There in the Section 5.9.21 it talks about a pragma "set_data_section". I've tested it, and it does exactly what you said.

 

With this code:

// outside of main... like a "global" variable.
#pragma SET_DATA_SECTION (".mydata")
unsigned char teste[0x2800]; // 10k
#pragma SET_DATA_SECTION ()
...
// inside of main, only to avoid compiler's optimization
int count = 0;
 for(count = 0; count < 0x2800; count++)
 {
  teste[count] = rand();
 }

I get this linker output (map file)

.mydata    0    0000c5e2    00002800     UNINITIALIZED
                 0000c5e2    00002800     blink.obj (.mydata)

 

The funny thing about all of this is that i already had the FRAM board, and never thought about using it for this.. :!!!:

[oPossum 1,083]

Here is the documentation for FRAM variables with CCS 5

[Mk_ 0]

Nice! it shows how to define a "named" memory region, and then how to place a custom defined section there!