Jump to content
CorB

Launchpaddemo on GLCD (with scrolling graph)

Recommended Posts

Hi,

 

Find attached code to run the launchpadDemo on the GLCD boosterpack(Lars Roland), The code will show the temperature in tenths of a degree and after pressing Switch2 on the GLCD boosterpack a scrolling graph will show the changes in temperature.

 

The file called Example_F2802xLaunchPadDemo1.c can be used to replace the original launchpaddemo file. All other files should be copied into the directory where "Example_F2802xLaunchPadDemo" resides.

 

The graph on the GLCD is is based on graphs writing to a screenmemory that can be dumped to the LCD.

 

I will add a screenshot tomorrow (EDIT: screenshots added).

 

cheers

CorB

Example_F2802xLaunchPadDemo.zip

post-74-14264717210833_thumb.jpg

post-74-14264717210955_thumb.jpg

Edited by CorB

Share this post


Link to post
Share on other sites

Ive added some screenshots to the original post, but I am working on the code still.

 

In the initial code the graph scrolls not very fast, this limitation was due to the fact that updating the GLCD screen very fast makes the text flicker.

In a new revision (the screenshots are from this) the graphics can be updated for a part of the screen only. So you can setup the GLCD with for instance 2 lines (from a total of 9 in this particular GLCD) that will be used for static information and all other lines for graphics. Only the lines that are ment to display graphics will scroll and react to a write into the graphicsmemory (on the MCU).

Share this post


Link to post
Share on other sites

Here are a few additional screenshots, I wanted to see how fast the code can display changes in the incoming signal. Ive hooked the ADC to another channel (ADCINA2) and put a jumpercable on the channel. This resulted in the 1st image (DSC_0007), there is clearly an alternating signal which is most probably the ADC picking up 50hz (mains are at 50hz overhere).There are 15-16 cycles in the display which probably means we see a timespan of 0.32 seconds.

In the next image I removed the code that also writes the ADC signalvalue to the screen (text), its very clear that we now get a far higher resolution. Only 6 cycles of the 50hz signal seem to be visible so that would bring the displayed timespan to 6/50= 0.12 seconds.

And finally I removed the code that allows the signal to scroll over the screen (which needs fullscreen updates of all pixels) and now we even do not get 1 cycle on the screen, so the timespan of the screen is around 0.02 seconds

 

All in all this shows that using bitbang SPI a simple LCD can be updated very fast and even can display signals that are of a low frequency. For higher frequencies the data will have to be captured and displayed afterwards.

 

cheers

 

CorB

post-74-14264717211428_thumb.jpg

post-74-14264717211569_thumb.jpg

post-74-14264717211704_thumb.jpg

Share this post


Link to post
Share on other sites

CorB and Lars,

 

As promised I resolved the issue with the hardware SPI. Turns out the bitstream was still being shifted out when CS went high. I added a short delay before PinHigh(CS_PIN) and it started working. I'm going to clean up the code and perhaps add interrupts so that I don't have to use a delay. Look for an update and explanation of the issue and the fixes soon!

Share this post


Link to post
Share on other sites

Ok, first let me explain why ya'll were having trouble getting this running on the hardware SPI.

If you simply setup the code for hardware SPI and call:

PinLow(CS_PIN); // pull CS LOW
SPI_write(LCDSpi, spidata);
PinHigh(CS_PIN);

You'll end up seeing something like this on the bus:

post-197-13513549395_thumb.png

The third trace is of course CS and you'll notice it goes high during the bitstream...no good.

For testing purposes I simply added a short delay after SPI_write and before I pulled CS high and sure enough the display started working.

post-197-135135493955_thumb.png

I actually ended up cleaning up Lar's code quite a bit to make it more software friendly. All the functions are now in a c file and the prototypes are extern'ed in an associated header file. I also used an interrupt to tell me when to pull CS high. Check out glcd_hwSPI.c and .h

 

If you copy the folder in the zip file to C:\ti\controlSUITE\development_kits\C2000_LaunchPad\f2802x_examples the example should import and build without issue.

Example_F2802xLCD_SPI.zip

post-6-14264717212352_thumb.png

post-6-14264717212623_thumb.png

Share this post


Link to post
Share on other sites

Hello Trey,

 

I can confirm that it works. I will try to explore the advantages of using HW SPI vs SW SPI in the coming weeks.

 

regards

 

Cor

Share this post


Link to post
Share on other sites

Trey,

 

In the new code for SPIWRITE below you do not set CS high anymore at the end of the routine. Why ?? Normally we should set CS low to communicate to the LCD via SPI and at the end set CS High again to end communication.

 

**************************************************************

 

void SPIWrite(uint16_t command, uint16_t data)

{

uint16_t spidata;

 

 

spidata = command<<15;

spidata = spidata | data <<7;

 

while(SpiaRegs.SPISTS.bit.BUFFULL_FLAG || txWait){

}

txWait = 1;

 

PinLow(CS_PIN); // pull CS LOW

SPI_write(LCDSpi, spidata);

 

 

}

Share this post


Link to post
Share on other sites

Hi,

 

I can clearly see the HW_SPI is slightly faster, the tests I have done above (using ADC2 and a free wire working as an antenna picking up 50Hz) show that I need to delay at least 100 uSeconds at every readout to get the same output as the fastest graph in the SW_SPI setup.

 

Cor

Share this post


Link to post
Share on other sites

I'm pulling CS high in the ISR. That way I know the transmission is done and it's safe to pull up CS.

 

Yes this device does have a hardware CS line, but the boosterpack standard doesn't define CS pins and the pin the GLCD CS is routed to is an analog IO.

Share this post


Link to post
Share on other sites

OK. You are pointing to this routine I guess ?

 

 

interrupt void spiTxFifoIsr(void)

{

// uint16_t i;

// for(i=0;i<2;i++) {

// // Send data

// SPI_write(mySpi, sdata);

// }

//

// for(i=0;i<2;i++) {

// // Increment data for next cycle

// sdata++;

// }

PinHigh(CS_PIN);

 

// Clear Interrupt flag

SPI_clearTxFifoInt(LCDSpi);

 

// Issue PIE ACK

PIE_clearInt(LCDPie, PIE_GroupNumber_6);

 

return;

}

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

×