LPC2478-STK, SD Card and displaying images

[Kevin]

I'm using only the simulator at this time, but the target is the LPC2478-STK.

1. I've enabled SDCARD_SUPPORT and re-named the HTTP default file BMenu.htm (I think that's the spelling), ftp'd the HTTP files to the SD-Card and the Web page is being served from the SD-CARD (with a few glitches like the refresh generating a 404 error).

2. Do you have a recommendation fro displaying .bmp files from the SD card?  I was trying to use place the file in the same sdram location as when the image is posted from the web page, but I can't find the routine that does it or the location of the buffer.  I thought I might try adding a uart menu command to load bmp's from the sd card.

3. When I want to run this on hardware, can I just use the SEL0, SCLK0, MISO0 and MOSI0 lines that appear to be unused on the LPC2478-STK?

Thanks
Kevin

[mark]

Hi Kevin

1) The file BMenu.htm is a bit special since it links files in the uFileSystem which use the large-granularity method (see http://www.utasker.com/docs/STR91XF/FileSystemSTR91X.PDF for an explanation of what this means). When it refreshes it links to itself but using a different name according to the large-granularity rules as required by the LPC FLASH.

This will not work correctly on the SD card since this used FAT32 and so will not find the link. It is best to use other HTML files in this case.

2) To display new BMP content it must be extracted from the BMP file and converted to the color format as used by the TFT. The routine that does this from the HTTP post input is in GLCD.c and is called
extern int fnDisplayBitmap(unsigned char *ptrData, unsigned short usLength)
This routine can be used for other inputs too since it just needs a BMP input as a stream of data (actually as blocks of data making it up as is the case of receiving TCP frames). If the file is read from the SD card in blocks and each passed through fnDisplayBitmap() it should work.

3) The SD card interface is SPI based (it doesn't support the SD controller in the LPC23/LPC24 at the moment). This means that it needs to be connected to a free SPI bus. This is configured in app_hw_lpc23xx.h and has been tested on the LPC2478-STK by connecting the free SPI lines.

Regards

Mark

P.S. I just added an LPC2478-STK executable on the web site. This is pre-built simulation which can be run just by executing the *.exe file and then the web server and TFT tested as you do with the simulation project: http://www.utasker.com/SW_Demos.html#SW_EX

[mark]

Hi Kevin

I have further information about serving the demo web pages from the SD card. This is valid when working with the simulator or working on the target.

In addition to the fact that the web pages designed for the uFileSystem may not be fully compatible for running from the web page - only true when working with large-granularity system or when the start page is not set correctly as the start page from the SD card - there is another detail which needs to be corrected.

For example, when refreshing a web page by clicking on a refresh button this causes a GET to be sent to the web server with the following (example) information:
http://192.168.0.3/9I_O.htm?r=Refresh

This is performing a GET of the file 9I_O.htm and sending additional parameters which are interpreted, in this case simply as a refresh but in other cases sending new parameters. A problem that I found was that the SD card case was making a mistake in trying to find a file on the card called "9I_O.htm?r=Refresh". This of course fails since there is no such file and a file with such an extension is obviously not possible.

The fault is in the routine extern CHAR *fnWebStrcpy(CHAR *cStrOut, CHAR *cStrIn) in webutils.c which is parsing the file name after the parameters have been handled. It is performing various conversions needed when sending file names to the web server but not recognising the '?' as a terminator. Since a '?' is not allowed in a file name I believe that this should always be interpreted as a terminator and so a change will cause no problems.

The change is (in extern CHAR *fnWebStrcpy(CHAR *cStrOut, CHAR *cStrIn))
        else if (*cStrIn <= '&') {
to
        else if ((*cStrIn <= '&') || (*cStrIn == '?')) {

This then allows parameter passing to operate correctly without causing the web server to not find the file on the SD card that is to be displayed.

Regards

Mark

[Kevin]

Mark-

In app_hw_lpc23xx.h: The SD card SPI pin assignments are as follows:
  
   #define SPI_CS1_0                  PORT0_BIT14
    PINSEL0 |= (PINSEL0_P0_8_MISO1 | PINSEL0_P0_9_MOSI1 | PINSEL0_P0_7_SCK1); \

    PORT0_BIT14 is pin 69 which is the VBUS line connected to the usb_dev connector (I verified continuity)

    PINSEL0_P0_8_MISO1 is pin 160 and connected to LCD16 on the TFT and EXT-8 (I verified continuity)
    PINSEL0_P0_9_MOSI1 is pin 158 and connected to LCD17 on the TFT and EXT-9 (did not check continuity)
    PINSEL0_P0_7_SCK1 is pin 162 and is connected to LCD9 on the TFT and EXT-7 (did not check continuity)

    I don't think you are actually using these connections on teh LPC2478-STK since they would interfere with teh USB and TFT.

    Have you tried using SPI or SPI0?  This pins connect to the UEXT connector and are otherwise not used on the board.

    Unfortunately,  it looks like SCK0 is on PINSEL0 but MOSI, MISO and SSEL are on PINSEL1.
    SCK0: PINSEL0_P0_15_SCK0 pin 128
    SSEL0: PORT0_BIT16  pin 130
    MISO0: PINSEL1_P0_17_MISO0 pin 126
    MOSI0: PINSEL1_P0_18_MOSI0 pin 124

    What signals are you using in the development version?

   -Kevin




  

[Kevin]

I got the SD card working with SPI0.
-Kevin

[Kevin]

Mark-
  I'm having some FTP problems with the real target and an SD CARD
  Working on the LPC2478-STK target.
  I've got an SD CARD hanging off of SPI0 (as indicated above).

  I can put small files, but when I try to put the 320x240 images only 64240 bytes transfer and then the target closes the ftp connection.  This happens no matter which image I use.

  The attached session shows that a 4096 byte file works fine (I can also create directories from ftp)

  When I try to transfer the f430.bmp (It's just renamed from F430_320x240_24.bmp) the session is closed and only 64240 bytes are transferred.

  After loading images from the PC directly to the sd card, I have been viewing files on the TFT from the SD card with no issues.

  I have not checked the SD card signals with a scope yet.

Code: [Select]

ftp> dir
200 OK.
150 Data.
drwxr-xr-x 1 502 502 0 Jan 03 2010 dir1
drwxr-xr-x 1 502 502 0 Jul 10 2010 images
226 OK.
ftp: 84 bytes received in 0.14Seconds 0.60Kbytes/sec.
ftp> binary
200 OK.
ftp> put B4096.txt
200 OK.
150 Data.
226 OK.
ftp: 4096 bytes sent in 0.00Seconds 4096000.00Kbytes/sec.
ftp> put B8890.txt
200 OK.
150 Data.
226 OK.
ftp: 8890 bytes sent in 0.00Seconds 8890000.00Kbytes/sec.
ftp> put f430.bmp
200 OK.
150 Data.
> Netout :Connection reset by peer
Connection closed by remote host.
ftp>


Code: [Select]

ftp> dir
200 OK.
150 Data.
drwxr-xr-x 1 502 502 0 Jan 03 2010 dir1
-rw-r--r-- 1 502 502 4096 Jan 03 2010 B4096.txt
-rw-r--r-- 1 502 502 8890 Jan 03 2010 B8890.txt
drwxr-xr-x 1 502 502 0 Jul 10 2010 images
-rw-r--r-- 1 502 502 64240 Jan 03 2010 f430.bmp
226 OK.
ftp: 231 bytes received in 0.22Seconds 1.05Kbytes/sec.
ftp>


[mark]

Hi Kevin

It may be that I tested the SD card interface on the LPC2478 board without other things operating, therefore collisions with other peripherals would not have been considered. The code that I have in the development project hasn't changed since then. The LPC23XX and LPC24XX have SD card controllers and the next step would in fact be to use these rather than the SPI mode.

Concerning the FTP problem with larger files, it may be better to send a WireShark recording since then the timing is also visible.

In the meantime I have made a picture frame application that is running on the STM32, AVR32 and Luminary TFT boards. I didn't experience any FTP problems with these. I would like to also do the same for LPC17XX board with NOKIA LCD whereby I would also like to optimise the BMP routine so that it accepts larger images (than the display) and just crops the picture. This doesn't work at the moment, as you may have found, and results in an error and the need to restart the board to accept further images.

Regards

Mark

[mark]

Hi Kevin

I have been making some progress on the LPC24XX project and have a first working project with TFT, Ethernet stuff, SD Card (using SD/MMC controller) and USB (mass storage - i.e. the images can also be copied from a PC with the card looking like an additional hard drive). This is performing either a slide show or running an emulated monochrome demo (new is also the ability to scale the image to save RAM - eg. rather than running a 320 x 240 image, requiring 9k back-up RAM, it can display single pixels as groups of pixels and so work in an emulated 160 x 120 mode - only 1/4 the RAM required).

There is a quick, provisional video here: http://www.youtube.com/watch?v=5dD2cZ8FEqo (just showing the slide show with a few details about SD/MMC DMA speed limits) - see also technical discussion: http://tech.groups.yahoo.com/group/lpc2000/message/50514

Regards

Mark

[Kevin]

Mark-

Just a thought.  Could the over runs be caused by writing images from the sd card to the same memory read from the tft controller?

Have you tried writing the image to one buffer, while the image being displayed is being read from another buffer, then switching buffers?

-Kevin

[mark]

Hi Kevin

The problem is to to with the SD Controller FIFO operation. When running at 18MHz the SW must feed these FIFOs with new data at a fast rate (64 bytes within just a few us). If there is an interrupt that takes place the interrupt latency is already enough to miss and get a FIFO under-run or overrun. In fact the LPC SD controller should never be operated in SW mode since the risk of an error is just too high (unless you run it at a slow rate, which makes no sense...).
Even with DAM feeding the FIFOs the DMA controller doesn't always keep up with the 18MHz rate (when TFT controller is also using DMA the two DAM controllers stall each other, increasing the risk). I never has a problem at 9MHz, just at 19MHz, so it seems as though this respects the HW's worst-case.

Note that the over-/under-runs have nothing to do with task trying to do different things with the card at the same time. It can happen when a single read or single write takes place.

I was interested to see that the STM32 SDIO controller is almost identical to the LPC's (registers are almost a copy of it). However it contains HW flow control (there is a bit which enables this). With HW flow control active the controller will automatically recognise when an under/overrun is about to take place and will stall the SD controller's clock so that it effectively waits until the situation has been cleared and then continues. This is exactly what is missing in the LPC's SD controller since there is no reason why the controller should generate 1024 clocks at 18 MHz and expect the SW to keep up with this (this is the block read/write operation). If for some reason there is a slight delay the whole block gets corrupted - the HW flow control will simply leave out a couple of clocks - forgiving a slight SW (or better DMA) delay - and hardly causing throughput to be reduced. In the LPC's case the clock needs to be halved  to avoid the risk.

The USB MSD throughput is however improved using the SD controller:

Write speed was about 270kBytes/s and read speed was about 510kBytes/s (measured by writing and reading a file of a few hundred MBytes size - USB path included). In SPI mode I was getting about 200kByte/s writes and 250kByte/s reads, if I remember correctly. Certainly there is an interesting improvement when reading and TFT image update is noticeable faster.

Regards

Mark

[Kevin]

It seems like every LPC has an SD controller.  You'd think they would have fixed the issue before the LPC23/24xx where introduced.

-Kevin