I noticed that there are some *.bmp and *.jpg image conversion programs around (some with source code) for the Nokia display 130 by 130. Some of them will spit out an array of C source syntax pixel color data for use in a *.h file. Has anyone worked with any of these?

http://norm-online.net/NOKIA_6100_BMP_Converter.php

http://www.olimex.com/dev/soft/BmpToArray.zip

Or other ones out there that are a good choice?

I assume you could just run through the array with pixel color calls. Some other drivers seem to have a load BMP function. Has anyone done bitmaps with the current cookbook Nokia LCD driver?

http://mbed.org/users/sakai/programs/RawLoader/lmf6ho has a program to load a RAW format file on the NOKIA LCD and it adds a blit function to the Cookbook Nokia LCD code.

One of the convertors has a 12-bit output option, so it looks like it might work with the code.

Students have a BMP and JPG converter running on mbed for the Nokia LCD

http://mbed.org/users/XkLi/notebook/digital-photo-frame/

That looks really good.

Also checked out the video on the notebook page.

I'm trying to do something similar but without the sd card. Is it possible to read images from the mbed directly do you know? Thanks

I see you have an LPC1768, which has LocalFileSystem. You can attempt simply replacing the SD definition with LocalFileSystem (http://mbed.org/handbook/LocalFileSystem). Now that has some limitations that SD card doesn't have, so it might not work, but worth a try. If you also give it "sd" as name it should accept the same directories.

I can get a small demo to work but as soon as I include any digital or analog in declarations the program ceases to work. The commented out lines seem to be the offending parts but I have no idea why. Any guesses?

I should mention that this is ultimately going to be used for a N5110 lcd screen game of life project.

#include "mbed.h"
#include <iostream>
#include <string.h>
#include "N5110.h"
#include <ctime>
#include <EasyBMP.h>

LocalFileSystem local("local"); //file system
Serial pc(USBTX,USBRX); // for debugging

//BusOut unused(p16, p17, p18, p19); //set unused analog to high
AnalogIn pot(p20); //speed
AnalogIn randa(p15); //to seed rand()
//DigitalIn select(p23); //selection button
//DigitalIn start(p22); //go button

int newframe[84][48]; //set array
int X = 84; //set size
int Y = 48;
//int maxX = X-1; //set max element
//int maxY = Y-1;
int total = 0; //neighbour count
int delay = 0; //deley between frames
int choice = 0; //selection counter
int buttondown = 0; // selection button down?


void genBMP();

int main(){
    genBMP();
}

void genBMP() {
    
    BMP AnImage;
    AnImage.ReadFromFile("/local/TESTIM~1.BMP");

    for (int i = 0; i <= 5; i++) { //loop through pixels
        for (int j = 0; j <= 5; j++) {
            pc.printf("new %d,%d = %d\n\r",i,j,AnImage(i,j)->Red); //for debugging
        }
    }
}

So this works, but when you uncomment 11-15 it doesn't work anymore? Thats kinda weird, they should be doing little. Try to figure out which line exactly is the issue. There was also someone who had an issue with p15 causing crashes, although that was as digitalout.

Uncommenting any of 11-15, 20 or 21 seems to cause the mbed to get stuck finding the file. The mbed ejects itself as it should do when reading a file but noting happens after that. What confuses me is that when the file couldn't be found an error message printed to the terminal window (eg wrong file name) but this simply freezes.

EDIT: On further inspection the analog pins have no problem. - lines 13 and 14

Is anything connected to those pins?

The digital pins are connect to a couple of push to close buttons. p16, p17, p18 and p19 aren't connected to anything.

Try removing everything not required (such as half those libraries at the top which are included). Then check if you can see where it stops (does it for example come somewhere in the main function?). Also see if you have the latest mbed version. If you do, try an older version (click on the lib, revisions, go a few back).

With the code changed this:

#include "mbed.h"
#include "N5110.h"
#include <EasyBMP.h>

LocalFileSystem local("local"); //file system
Serial pc(USBTX,USBRX); // for debugging

//BusOut unused(p16, p17, p18, p19); //set unused analog to high
AnalogIn pot(p20); //speed
AnalogIn randa(p15); //to seed rand()
//DigitalIn select(p23); //selection button
DigitalIn start(p22); //go button

int newframe[84][48]; //set array
int X = 84; //set size
int Y = 48;
//int maxX = X-1; //set max element
//int maxY = Y-1;
int total = 0; //neighbour count
int delay = 0; //deley between frames
int choice = 0; //selection counter
int buttondown = 0; // selection button down?

int main(){
    BMP AnImage;
    pc.printf("break 1"); //for debugging
    AnImage.ReadFromFile("/local/TESTIM~1.BMP");
    pc.printf("break 2"); //for debugging

    for (int i = 0; i <= 5; i++) { //loop through pixels
        for (int j = 0; j <= 5; j++) {
            pc.printf("new %d,%d = %d\n\r",i,j,AnImage(i,j)->Red); //for debugging
        }
    }
}

The terminal window shows break1 but not break 2. Where do I find the lib?

Can you publish your program (right mouse button on it, publish). Then post te link here? Since you aren't using anything special here yet I should be able to run it on my own LPC1768.

http://mbed.org/users/el13tjoc/code/BMPtests/ should be the link. Thanks for the help BTW.

Okay had a look at it, was quite hard to find exactly what is going wrong, especially since it didn't happen as it should happen. When it cannot allocate memory it should return a NULL pointer, it isn't doing that for some reason. But I am 95% certain the issue is simply lack of memory. Why it behaves exactly as it behaves, I don't know. But it is allocating 4 bytes per pixel, and during that allocation it just stops. Yes or no digitalOut is probably driving it just over the edge of memory. Your newframe variable is optimised away since nothing is done with it. But when I did something pointless with it, so the compiler couldn't optimise it away anymore, suddenly it got alot less far.

I assume you have an 84*48 bitmap. It is allocating 4 byte per pixel = 16128 bytes just for that. Thats half the total memory available. But dynamically allocated memory also has overhead. And maybe also allocating more memory for other stuff. So not exactly a solution, but the cause is a lack of memory.

Ahh okay, well that helps a lot. I think I will try and condense the BMP library in a similar way to the other project. Thanks for the help.

Whether related or not, just a few hours ago I came across a memory allocation issue. Some code I was trying to use had the construct:

windowBuf = new unsigned char [windowSize];

And as it turned out, windowSize exceeded available memory. Some c++ compilers return NULL, like would happen in c with:

p = (unsigned char *)malloc(windowSize);

But, as best I can tell, the online compiler uses the more standardized c++ behavior to throw an exception. Unfortunately, I don't know how to catch the error. See Is it possible to enable exception handling. [Erik just spotted my post there and replied too.]

I've decided it would be easier to write my own code to read from the file but I'm having some trouble. I can't work out where the pixels I want are hiding. My image is this: http://i.imgur.com/ewBUBqX.png which if you can't see is white with the first and third pixel on the first line set to 0x636363 (100).

#include "mbed.h"

unsigned int *buffer;
LocalFileSystem local("local"); //file system
Serial pc(USBTX,USBRX); // for debugging

void readfile() {
    FILE *f = fopen("/local/TESTIM~1.BMP", "rb");
    buffer = new unsigned int[4*4];
    fseek(f, 54, 1);
    fread(buffer, 4*4*3, 3, f);
    fclose(f);
}

int getpixel(int x, int y) {
    //assuming your x/y starts from top left, like I usually do
    return buffer[x+y];
    //return buffer[2];
}

int main(){
    readfile();
    for (int i = 0; i <= 12; i = i + 4) {
        for (int j = 1; j <= 4; j++) {
            pc.printf("val(%d) = %d\n\r",i+j,getpixel(i,j)); //for debugging
        }
    }
}

Hi Toby. png files are hard to decode. i can do small ones, but the decompression takes a lot of ram and then it fails. bmp are much easier. follow the link on my name, and then look at my RA8875 driver. it has a bmp parser in the graphics.cpp file.

Ahh sorry for the confusion. The image has been converted by the website. The image should indeed be a .BMP file. Ideally I want to keep the code as simple as possible as I'm not the most confident C++ programmer.

If you haven't done so yet, read the bmp file specification. You can find it online in many places. Here's one attempt at parsing a bmp file and presenting it onscreen.

GraphicsDisplay.cpp does a lot more than bitmaps, but if you look for "_RenderBitmap" on about line 450. Down about line 526 it prepares to send the data to the screen. This would certainly require adaptation for a different display, but perhaps something to go on if you haven't finished your own solution yet.

I've got it working to a degree. Presently I can get a 32x32 bmp to display but memory runs out greater than that. I need a system by which I can get individual bytes from the image or I need to read the image in parts and send it to the display periodically.

Hi Toby, I'm not familiar with the Nokia display, so it may have some special requirements. The code I referenced above reads a bitmap from a file. In a reasonably memory efficient manner, first it reads just the header chunks. Then it knows how much memory is required to host the color palette. When it gets to the actual image data, it will have allocated only enough memory to read one scanline of data at a time from the file and sends that to the display.

I can publish [using the LPC1768] a 24-bit image of 480x272 (down-samples to 16-bit color for the display I'm using). One of my test images is nearly 400Kbytes in file size. I don't know your technique, but it blows up quickly if try to cache the whole image in ram at some color depth.

Now, having thought about this once more while writing this - when I allocate the color palette, I host it in "native" format from the bmp file - which is wasting memory. I could down-sample it to 16-bit color when I pick it up from the file system. That would free a bit more memory, and make it a bit faster to boot!

The slowest part is a trade-off. Since BMP files are more or less stored upside down, I could either read the file from start to end (and write the display from bottom to top), or read the file from end to start (and write the display from top to bottom). I'm not sure which would be faster - but the latter was the path I chose.

http://mbed.org/users/el13tjoc/code/FinalBMP3/ - got it working how I want. This is a really simple example so if anyone else has trouble with this in future this might be a good learning program.