Looking for thoughts for multiple SPI devices

[seulater]

Thanks for the ideas!
Dave, thanks for the thread link on the SD card issue.

I have to say, .netmf is looking better and better these days. This is not an issue to talk to all these things at the same time with .netmf.


If i want to clear the screen for example, there are quite a few writes involved. I can see it now that when its in this loop i will get a request to access the SD card or IRQ for the touch screen. I dont want to Lock the OS before and after this loop because i have another thread running that needs to service a codec chip every 10ms and grab 480 bytes from it and sent that data out the Ethernet.

Code: Select all

void LCD_CLS(WORD color)
{
	DWORD x;

	GotoXY(0,0);

	WriteLCDCommand(0x22);

	// Pull I/O Pin High For Data
	LCD_DATA();

	//Switch SPI to 16 bit mode;
	sim_qspi.qmr &=~ 0x3c00;


	for(x=0;x<76800;x++)
	{
	    QSPISend(color);
	}

}

I can see that

[greengene]

here's how i set an area to fill. just set the row/colum start/end regs.
// (x0,y0) is the lower left corner and (x1,y1) is the upper right
void lcd_area(unsigned int x0, unsigned int y0, unsigned int x1, unsigned int y1)
{
lcd_cmd(0x03, (x0>>0)); //set x0
lcd_cmd(0x02, (x0>>8)); //set x0
lcd_cmd(0x05, (x1>>0)); //set x1
lcd_cmd(0x04, (x1>>8)); //set x1
lcd_cmd(0x07, (y0>>0)); //set y0
lcd_cmd(0x06, (y0>>8)); //set y0
lcd_cmd(0x09, (y1>>0)); //set y1
lcd_cmd(0x08, (y1>>8)); //set y1

return;
}

then follow that with your WriteLCDCommand(0x22),
and disable.

so, break the display area into smaller areas;
then for each area:
take the spi bus, set the display area regs, give the write command,
write that portion of the data, release the spi bus
-----------
i'm also using a SPI Flash chip, not SD card, with the EFFS. i just had
to remember to protect/lock the bus for all of the writes/reads done
including those for the directory copies - doh!
i'm looking forward to seeing the changes to EFFS done in 2.5.3.

[seulater]

i see, but when it comes to writing text to the screen its get more complicated.

Code: Select all

	do																//
    {																//
																	//
        data =  font_start + (offset * (int)(*lcd_string - 32));    //
																	//
																	//
		for (i=0;i < yme;i++)										//
        {															//
			mask =0x80;
			GotoXY(x,(y + i));
			WriteLCDCommand(0x22);

			// Pull I/O Pin High For Data
			LCD_DATA();
		    //Switch SPI to 16 bit mode;
			sim_qspi.qmr &=~ 0x3c00;


			for(b=1;b <= xme;b++)									//
			{
				if (*data & mask)									// if pixel data then put dot
				{													//
					QSPISend(fcolor);
				}													//
				else												// else use background color
				{													//
					QSPISend(bcolor);
				}													//
																	//
				mask>>=1;											//

				if( mask == 0)
				{													// if 8 bits have been gone through
					data++;											// then load in a new 8 bits
					mask = 0x80;									//
				}													//
			}														//
		}															//
																	//
        x+=xme;														//
																	//
		lcd_string++;												// next character in string
																	//
	}while(*lcd_string !='\0');										// keep spitting chars out until end of string
}

[greengene]

i wouldn't think that a single line of text should need the bus for very long
even with the single pixel high rasterizing. if that is still too long, you could
break it up at each character. this presents natural points to break up, i.e.,
release bus and take back.

as an aside, you might want to dump your processed font characters for
the entire string into a temp buffer, and then write that as a bigger chunk.
lots of ways to skin the cat. with this discrete data, time-sharing the spi
bus should be quite doable.

controlling access for my processor is fun enough, but then adding in mux
control to allow an fpga to dance too is even way more fun! sometimes i
think the board designers stay up nights just trying to see how convoluted
then can make it