software

is there any software that i can draw in, and then have it give me the pixel numbers or something similar, i am try to use a GLCD, and i need something to help me with taking picture i draw on the computer to code i can use. thank you much

If you on Windows, Paint can do that for you.

How do i get the pixel numbers once i draw something in paint?

what do you mean by pixel numbers? the color or position?

Or maybe this is what you are looking for?

I have somewhere if i can find it a program i write some years ago to convert a 128x64 mono image into a .c file to use with arduino, there are others on the net if i cant find mine.

just poisitions, because it's not a color display, a converter would be perfect, i'll look and see if i can find one

You can use gimp to save the image in .xbm format.
.xbm is a C data array.
It is very easy to then go through the data array and do setDot() API calls
to turn on the pixels based on the data in the Array.

But you will also want to make sure the array is in flash memory by using the PROGMEM extensions.
Then you will need to call pgm_read_byte() to read the data bytes from program memory.

Here is an example function that reads the data from program memory and plots it.

void glcd::DrawBitmapXBM_P(uint8_t width, uint8_t height, uint8_t *xbmbits, 
			uint8_t x, uint8_t y, uint8_t fg_color, uint8_t bg_color)
{
uint8_t xbmx, xbmy;
uint8_t xbmdata;

	/*
	 * Traverse through the XBM data byte by byte and plot pixel by pixel
	 */
	for(xbmy = 0; xbmy < height; xbmy++)
	{
		for(xbmx = 0; xbmx < width; xbmx++)
		{
			if(!(xbmx & 7))	// read the flash data only once per byte
				xbmdata = pgm_read_byte(xbmbits++);

			if(xbmdata & _BV((xbmx & 7)))
				this->SetDot(x+xbmx, y+xbmy, fg_color); // XBM 1 bits are fg color
			else
				this->SetDot(x+xbmx, y+xbmy, bg_color); // XBM 0 bits are bg color
		}
	}

}

--- bill

i found a piece of software called bmp2glcd.exe, and BMP-LCD.exe, but, seeing that you have "---bill", i am thinking you might be Bill Perry, so i will also look into trying it the way you described

Yep that is me.
Tell me what you really want/need to do and what OS and what type
of tools you are comfortable with.
There are a few options, for converting bitmap images to usable data structures
if you are using the glcd library.
There are commandline tools like bmp2glcd (I have a modified version for the glcd lib)
and then the glcd library includes a java based GUI conversion tool as well.

The code fragment I posted earlier is part of the XBM bitmap support code that
that will be in the glcd v3.1 release.
XBM format isn't as fast at rendering on the display as native glcd format
but it can be quite convenient.

--- bill

i am just looking to put a couple bit maps on a ST7565 (128 x 64, serial if it matters) anyway that makes sense,
i want to store the picture, but i don't want to waste space on the controller because i did something stupid, hehe

i am using windows 7, and can get comfortable with what ever type of tool, i have no problem learning, just want to make sure i am learning the right way
i have linx too if needed.

jeff

@bperrybap by setdot do you mean drawing pixel by pixel, because talking to these displays at low level 1 byte draws 8 pixels at once virtically which is 8x quicker than 1 pixel at a time

in plain english

bit = 0
for index = 1 to 8192 step 128
is bit set?
if yes var[bit] =1, bit+1
else var[bit] = 0, bit+1
until bit = 8
index +1

this gives you the first 8 virtical pixels in one byte.
I have'nt explained it very well but this is how my program worked with a 2 colour .RAW image file

P18F4550:
@bperrybap by setdot do you mean drawing pixel by pixel, because talking to these displays at low level 1 byte draws 8 pixels at once virtically which is 8x quicker than 1 pixel at a time

I'm very aware of the glcd page memory layout.
The glcd library goes through great pains to really limit the accesses to glcd memory
by doing page accesses whenever possible.
It gets very complicated depending on the format of the data and
the alignment of the image/glyph and the alignment of glcd memory which
is why the character rendering code is so large and complex.
(Some glcds us vertical pages, and some use horizontal pages)
The XBM drawing routine I posted is very simple, it renders 1 bit at a time which is why I said
it isn't as fast as when things are done in native glcd format.
But in some cases the rendering and the updates to the physical display are
not done at the same time. In that case the pixel updates don't hurt very much
and in some cases can actually be faster because you can have really small
and fast code to render, and then simple but fast code to take the rendered data and slam
it to the physical display. ug8glib kind of works this way.

bikeboy,
the glcd library does not support the ST7565, you should have a look at Oliver's ug8glib library:
http://code.google.com/p/u8glib/
http://arduino.cc/forum/index.php/topic,91395.0.html
It uses a very different model for talking to the glcd display than the glcd library
but it supports your display as well as XBM bitmap format.

--- bill