.Bmp to LCD ??

[Mikat]

Hi Jonny.

I am looking that code too, because th ssd1289 code I written by me, and I am trying to code it show that bmp pic fast as possible, so could you tell me the fastest way to convert that bmp color format to 2 bytes rgb, the format should be byte1 RRRRRGGG and byte2 GGGBBBBB, after that the data just throw to the data ports and let the lcd window and the automatic address counter do the job, and then color again, so the address it set once by the beginning at the creating the window macro..
And what is the pixel orientation in bmp format?


Mika

[JonnyW]

Hi Mikat.

From what I understand you want to convert a bitmap to 16bpp? If you load your image into Ms Paint or some other bitmap editor, there should be an option to save as a 16bpp format image. This image has a header but no palette data. The BPP format should be as you require for this (I may be wrong).

As far as loading this data in, this post should detail a way of pulling this data off an external card. If you have the memory to store this data in ROM then the flowcharts on this thread should be easily modifiable to load from ROM instead, and this will be much faster than loading off an SD card.

Typically the pixel orientation in BMP format is inverted in the Y (this is not certain but Ms Paint will save in this form), so when this is rendered to the screen the first byte read will be the bottom left pixel on the screen.

I hope I have understood your question correctly,

Jonny

[Mikat]

Yep, I think I understood..
My question was the code which was in that topic, I am trying to write as fast as possible code to show that bitmap...
But it seems that the bitmap is already in RRRRRGGGGGGBBBBB format in the sdcard (this isn't my project, I am just trying to help), so all I have to do is read the first byte of the sdcard for color hi ,and second byte for the color lo, that makes things easy....
So in the code, there is completely useless conversions the color first for red green and bluen, and then to 16bit, and then in the 2 x 8bit for every pixel.... So no wonder if the code is quite slow, I just need to change the custom component code, so setting the pixel color on't need those conversions...

And if I check it right, the image is converted that the firs pixel is upper left, and it goes horizontal row left to right, and then goes to second row etc....

Mika

[cobra1]

Mika. When updating the LCD it starts with the pixel in the lower left corner and scans horizontally moving up a line at a time. For some reason bitmaps are stored upside down

[Mikat]

Nice.
That is was talking, when I asked about the pixel orientation... I am good to be unclear...

[cobra1]

Hi,

With Mikat's help i we have come to the conclusion that the FAT macros are slowing the screen write down too much, fastest i can get is 8 seconds, i tried low resolution but it really does look awful.

I was thinking that maybe a EEPROM might be faster, although it still uses the SPI.

I would like to give it a try before i give up on the loading of pictures due to slow speeds, i have used the 25LC1024 and can read from it using addressing, so basically i can read a byte at a time

What would i have to do to get the picture out of the EEPROM?

The HEX file for the EEPROM would be created by microchips "graphics resource converter" it converts an image to 16 bit in hex format for use with external flash.

[JonnyW]

Hello. Shame about the resolution, but it happens. Assuming the file stored in EEPROM is the same format as that stored on the disk, this should just be a matter of changing the Read_Byte_From_Buffer() to load a byte from the EEPROM instead. None of the sector loading required for the FAT stuff is required.

However, remember that the size of the image is an issue. 320x240 x 2 bytes is 150k - is your EEPROM large enough for this? Also, a direct counter in a 16-bit value is not large enough to deal with this size - I don't know the EEPROM API but if it assumes a max 64k (the maximum for a 16 bit value) or 32k (the max for a signed 16 bit value) this may be a problem.

Assuming the EEPROM API and size can cope with the image size, the best bet is to replace the 'sector move' icons from the FAT to keep a count of the 512byte block you are reading from, and a 16bit count of 512 byte blocks is plenty for a 16 bit counter. If youre not sure what I mean I can post an example image tomorrow.

Another alternative is to run-length encode the image, or compress in some other way. If you post the bitmap file you are using as your screenshot I can tell you if it would compress well - basically long lines of a solid colour would work well. There may also be other ways of reducing the image size but again I would have to see the image.

Let me know,

Jonny

[cobra1]

Hi jonny,

Your on late, didnt expect a reply yet.
It appears my EEPROM isnt big enough, only 125kb so thats not good since i require 3 images to be loaded at various points in the program.

I just wanted to see if you could answer something for me, before trying anything else.

Using the FAT component i have the option to use hardware SPI, when running at normal speeds i.e 16Mhz it works fine, but when i enable PLL the FAT component wont work. It will only work in software mode, which is half the speed as using Hardware SPI.

Is there any particular reason this should happen?

From what i remember a while back i was using the SPI Legacy component, i belive that uses hardware SPI and i could use that in PLL. So i know the SPI can work at that speed but just the FAT component wont.

[Benj]

Hello,

With SD cards there are multiple standards which dictate how fast the card can run. Maybe for the card you are using when you enable the PLL the SPI bus is running too fast to allow the card to communicate properly. You could try using the custom code feature to reduce the SPI prescaler which will have the effect of reducing the SPI rate inline with the device clock speed.

In the Init Card Function try changing these lines,

sspcon = 0;
sspcon1 = 0;

to

sspcon = 1;
sspcon1 = 1;

[Mikat]

Hi.
The problem is that the spi bus stays at the 4MHz that way, so the chip runs faster, but the spi and sd card don't, so the speed boost is not big...
Chris, what kind hardware do you have? Just think that if you have the sd card on different pcb, the 16MHz is quite lot via wires...
I am not sure, but I remember that I have seen table that sd card should work at 20MHz spi... But on the other hand, when you read at Microchip forum, seem that the spi clocs are quite low...

Mika

[JonnyW]

Hello.

I have had a look at the flowchart in:
http://matrixmultimedia.com/mmforums/po ... =29&t=9198

First to note the Read_Byte_From_Buffer() call should be very quick - by this time the buffer has already been loaded via the SPI. It is the Move_To_next_File_Sector() that is slow. Second you probably don't need to additional Read_File_Sector() - I think this was in my original example, but having looked at the component C code I think Move_To_next_File_Sector() reads the buffer anyway.

Maybe try this:

• In Main(), the Read_File_Sector() can be removed from inside the condition and always called - it will always be done so a condition is not necessary
• In Load_Pixel() the Read_File_Sector() (and its decision) can be removed altogether - try it like this as I'm pretty sure the sector is loaded anyway. This should nearly double the speed if it works this way.

Also, are the images you are displaying 'photo-quality' - that is, do they really need 65,000 separate colours? If not, then a saving in size and speed can be made by using a palette, maybe 8bpp or even 4bpp (though I would recommend 8bpp to start with). You could probably save some awkward processing by hard-coding the palette into your program if this is what you wanted to do. With an idea of what the images look like I could perhaps tell you how best to reduce their size.

Jonny

[Mikat]

Hi.

In the display, best option is read the pixel color information directly 2 x 8 bit variables, which can be directly put in the sent data macro... So therefore those color conversions are useless...
Now the code does lot of extra work, it reads the color 2x8bit at the sd card, then converts it to red, green and blue variables, then it combines those 16bit and break again in 2x 8bit.. . But when I try to read the fat directly to color_hi and color_lo, the code didn't work for some reason..
But anyway removing that extra work don't boost the code no more that few tenth of second..

Mika

[JonnyW]

Hi Mikat. Ah well, worth a shot I suppose.

I wouldnt worry about the colour conversion too much - this was provided in the example programs because the gLCD component expects R, G, B passed in separately, so these needed splitting up. If there is negligible impact to code size I wouldnt spend much time taking these out - they will have not much effect on the speed, as this is being dragged down so much by the FAT access. However, if your API expects a 16-bit colour directly, you should be able to pass 'pixel' in as a 16-bit value without any problems, I'm not sure why this isnt working - would you like to post example code?

Cheers,

Jonny

[Mikat]

The API uses 2x8 bit, because the code is written at 8 bit device, so the port width is 8bit..
But like I said, the impact of the speed is little, but the color conversion it useless, that was the point, and it should be easy to get rid of it (the code what I tested was done quickly at midnight, so there is probably the reason why it don't work) .. But as long as the fat slows the code so much, it doesn't mean anything, even at the color conversions, the lcd code uses less than 1 second to update whole screen @12MHz clock, which means something like 0,2 s at 64MHz clock...

[cobra1]

Hi guys

Ok. Just thought I would update on progress. I have the SD card working in PLL but not at full speed. Thanlks Ben for the pointer.
Although its working its still painfully slow at loading my images. The screen currently loads 6 images measiring 90x90 pixels and it takes about 2 seconds

I am considering now using a dsPIC30F4011. Is this chip supported in flowcode for dsPIC. Also what changes would be required to the SSD1289 custom file. I think ben has a copy of it?

Cheers so far for all your help guys

[Benj]

Hello Cobra,

I am considering now using a dsPIC30F4011. Is this chip supported in flowcode for dsPIC.

Yes this device is supported.

Also what changes would be required to the SSD1289 custom file.

Changes should be minor. register access such as port registers should change from lowercase to uppercase. May also need a slight change to the typecast for the font arrays. Other then this the code should work well as is.

[cobra1]

Hi Ben,

I just downloaded your demo of dsPIC, it only has 1 PIC listed in the devices. Is this just because its a demo??

I was just going to see what differences there were to these port registers, is it just like changing "porta" to "PORTA" etc

Also from your last post, what do you mena by typecast???


Oh im also aware that the demo wont support the custom files and the other advanced components, i was just looking to see what the differences were when using this new PIC.

[Benj]

Hi Cobra,

Yes flowcode is limited to a single device in the demo version you can see the list of supported devices in the full version here.
http://www.matrixmultimedia.com/softwar ... _dsPIC.txt

is it just like changing "porta" to "PORTA" etc

That should be about it. Most of the standard C code that does not reference registers will work as is.

Typecasting is essentially casting a variable type on a section of data eg in your code it will be the font data.

In boostc a ROM array is created like this.

rom char* ASCII1 = {x,x,x,x,x,x,x}

In Microchip C30 the code changes to look like this.

const char ASCII1[] = {x,x,x,x,x,x,x}

Simple when you know how

[cobra1]

Cheers for that ben. Made it a lot clearer. Now is it worth waiting for flowcode 5 for dsPIC. If so when is it likely to be released?

[cobra1]

i was wondering, if i were to use a 16bit chip instead of an 8 bit one, will there be any required changes to the code above?

the part where you get to bytes to create a word, is a 16 bit chip just able to get a word in one go?

[JonnyW]

Morning, and a happy new year!

Basically no, there should be no changes to this code. The 8->16 bit upgrade to the chip will not effect any Flowcode APIs and something that works in the pic8 version should work pretty much the same in the pic16 version.

Cheers,

Jonny

[cobra1]

Jonny i was wondering if this code could be modified to work on the nokia 6610 lcd . the datasheet says its a 9 bit screen so im not sure what i need to do

[JonnyW]

Hello. I'm afraid I don't know this device. There should not be much in the implementation code that would need changing though - calls like 'set pixel' should work for pretty much anything. It is the component code that needs changing for this, and that will be very specific to your device.

Things that may need to change are the bits-per-pixel and the resolution. Calls like LCD_Set_Fore_Color() will need to change to reflect your R, G, B colouring. Also you have 'y = 240' and 'while x < 320' icons, these will need to change to the size of the screen.

Apart from that I cant think of anything that would cause much of an upset.

I do not know what a 9 bit screen is, whether this relates to the bus or to the number of bits-per-pixel. Though I have never heard of a 9-bit RGB, this would give 3 bits for each, which would make sense. Does this communicate via SPI, or via direct memory access?

Jonny

[cobra1]

Hi

Ok, so i ran the 16bit code on this LCD and it does render the display OK,

Only problem is that the colours are wrong, looking at the glcd component file it seems that the software converts the data its given into 16bit data, so im not sure that giving it 16bit data is the best thing to do.

In the GLCD component it says in the init that its being setup for 8bit pixels, i tried modifying the code for 8bit pixel but it didnt work.

In the current setup where it collects 16 bit data from the SD card the upload works great, if i can just sort the colour issue out then im good to go.

The current printed colours are like this,

Should be Green = printing Yellow
should be blue = printing turquise (greeny blue)
Blacks and whites print as they should

[JonnyW]

Hello. You need to establish the bits per red, green and blue. To do this, write a loop that fills the background in white and prints a number on the foreground. Use that number as the colour of the text:

Code: Select all

  Set_Background(white)
  Clear_Screen()
  col = 0
  bit = 0
  loop while true
    col = 1 << bit
    Set_Foreground(col)
    Print_Number(bit)
    bit = bit + 1
    delay_seconds(2)

The text will display red, then go black, then green, then black, then blue, then black. At each stage, the time when it is black is the number of bits per pixel of first red, then red+green, then red+green+blue.

If you post these results we can figure out the conversion to do. I hope this makes sense.

Jonny