I am look for a C library that will allow me
to convert a bmp file to a simple bin file.
Any suggestions on where to look for this?
I presume that you want to produce a raw binary file that you can blit to a TFT display. Either in software or by DMA.
This is the fastest way to display a picture. Especially if it does not use a File System.
I can read several .BMP formats from a FAT microSD and let the MCU do the conversion in software. This uses a fair amount of processor power. It does mean you can display different types of BMP file.
The UTFT library has a PC utility for converting a 24-bit BMP to 16-bit RAW file on the SD disk. From memory, it puts the bytes in the wrong order for DMA.
There are universal PC programs that can do many formats.
Thanks for the reply.
The project I am working on requires that a file from an SD card be
converted into a RAW single color (Black) bitmap. The conversion has to
be done on a ATmega1280 based controller card. The output is loaded
into pair of industrial print heads.
The card has 32k of external ram. I only need to convert a single file at
a time and I have lots of time to make the conversion ( minutes ).
Unfortunately, I have little or no knowledge of BMP files. I am hoping
that there is a lib somewhere I can buy or use.
So you want a 1-bit depth BMP file or a RAW binary file ? With bits msb first ? Left to Right? Vertical ?
KS0108 bitmaps are in horizontal strips. A T6963C bitmap is one pixel deep on horizontal scan lines.
The beauty of .BMP files is that they follow a recognised (if messy) format.
Binary files are completely arbitrary.
Please post a typical BMP and describe the output that you want. And its dimensions.
Mind you, the BMP describes its own size.
There are certainly PC programs that would do anything. It should be pretty simple to do with the AVR.
I think I've posted my own C implementation of Flloyd-Steinberg here before now - search it out.
Cliff / David,
Thank you for the assistance.
I will be dealing with only one version of the BM file. The image will
only ever be 1 bit in depth. I should be able to write some code to
convert a file into the format I need.
If it's already a b/w BMP then surely it's almost exactly what you want without processing? The only thing required is to remove the (fixed size) BMP header at the start.
After reading the file spec and wading through
the different file formats, its pretty straight forward.
Now I just need to figure out how to send it over a
comm port on a windows 8 machine. I haven't done
this before and it seems a little overwhelming.
Any suggestions or should I start a new thread?
Thanks again Cliff. As usual, you have been a big help.
There was a recent thread discussing the merits of various techniques for transferring a block of data from a PC to an AVR. The bottom line is that you could start by simply sending all the bytes in the file. Most PC terminal programs have a "send contents of ..." that would simply read a file and send all it contains. However the issue then is one of "stopping condition". Either you need to know upfront how many bytes are coming and the AVR just reads N bytes then stops. Or you need some kind of "end marker". A common choice would be the ASCII "EOF" (End of File) character but that's fine when you send text because text would not normally contain 0x1B which is the numeric value of "EOF" but binary data like BMP might hold ANY value from 0x00 to 0xFF so you can't really use any byte value as an end marker.
So the next idea after that is to use a binary transfer protocol like X, Y or Zmodem or Kermit file transfers. Almost all PC terminal programs know how to to X/Y/Z/Kermit so then it would just be a case of implementing one of those in your AVR.
X is not so great as it's still tricky to determine exactly where the file ends as things are sent in 128 byte packets so the transfer tends to be a multiple of N * 128 bytes.
So you may want to look at using a protocol that includes an exact byte length in the information transferred.
Alternatively you could think up a whole new protocol of your own devising. Perhaps you always send "len=NNNNN,data=" at the very start where NNNNN is the number of bytes following "data=". But the problem with thinking up a new protocol like this is that your standard PC teminal program won't have a mechanism to do it so you'd need to write special PC sending software too.
I guess what I'm saying is "consider Ymodem".
Of course the question that then arises is where is the BMP data actually going and why it needs to be sent at run time in the first place? If you are just trying to get BMPs from PC to AVR wouldn't it be easier to add an SD/MMC interface to the AVR and read pictures from that at run time?
I have a customer that uses an existing software package to
generate files for printing labels. The software package has
built in drivers for various types of industrial printers.
There is no spec available for the existing driver because
they are proprietary. Fortunately the package will generate
a bmp file.
I did propose moving the bmp file by sd/mmc but my customer
is asking that this be as seamless as possible.
I do have a very small amount of exposure to C++ boulder but
would be glad to have someone to write a small windows utility to
export the file or portions of it.
I did just this a few years back. I was playing around with .BMP files because a had a nice mono LCD I was working with. I downloaded a company logo off the internet and converted and resized it a monochrome .BMP file using http://www.irfanview.com/. I then wrote a simple C program on a PC that converted the .bmp file to a standard human readable C file in the format used by some font creation tool that I was using to generate new fonts for the drivers. I added the HEX encoded .bmp C files to the project. I also added a screen print function on the machine that would store a .bmp file to a SD card which came in fantastically handy for the manual writers.
I posted a screen shot from it in the past.
I do not see the problem. I presume that the "existing software package" generates BMP files on a PC.
Just browse the directory in Windoze with File Explorer. You will see Tiles that display a miniature version of the BMP. And a description of its dimensions at the bottom of the pane.
You need a specific Viewer or conversion program. On my PC if you click on a BMP, the "Windows Photo Viewer" will render it. And know its bit-depth. However it is not clever enough to save in a different format.
As I said earlier, post a typical generated "BMP". And say what binary format you want to end up with.
You can make a BMP render in many ways. If your printer requires a non-standard way, it is easier to manipulate the BMP than worry about the printer. i.e. you just give it what it expects.
Even if you reverse the order of the data in the BMP, it will still display correctly on a proper PC (if you describe your order in the BMP header). Then your ignorant printer simply gets the binary data after you have "seeked" past the header.
The trouble is I am dealing with both ends. The printer is a stand alone device
of our own that to date has not been connected to a PC. It has RS485 hardware
built in but the comm port has not been used in any significant way. At the other end,
the PC is running someone else's app.
The existing PC software will generate a bmp file with 1 bit depth and of the
correct resolution for our printer.
I don't think I will have much difficulty outputting the file from the controller
once I have the file or the data to be printed on the controller.
I am looking for the most seamless way to get a bmp or the dot location data
from a Windoz 8 PC to a our printer. I am try to avoid getting involved in developing
comm program to run on the PC.
Well, if your input file is a kosher BMP format, all that you need to do is create the necessary data for your printer.
Only you know what your printer wants. If you were to reveal this, you would get a sensible answer within minutes.
I could "guess" that it wants to scan horizontally, but what do I know?
If it is mechanical, it might want to zigzag like the old dot matrix printers.
It might want to print in stripes like a dot matrix.
It might ...
Quite honestly, I would select an industry standard format and then make your firmware "understand" it.
OTOH, your company politics may want to produce something proprietary so that the customer is locked into using your product.
Hey andrew99, You posted this as your problem:
"I am look for a C library that will allow me to convert a bmp file to a simple bin file. Any suggestions on where to look for this? "
THEN after people tried to help you MANY times you changed your problem to this: "I am looking for the most seamless way to get a bmp or the dot location data from a Windoz 8 PC to a our printer. I am try to avoid getting involved in developing comm program to run on the PC.
What? You can't even state your problem in the most basic terms or concepts. You insist on spelling "Windows" as "Windoz" like a 13 year old would.
I must stop my unhelpful input to this thread but I won't because you...
I am sorry I ever wasted my time responding to your original post.
I am guilty of typing "Windoze" as a deliberate mis-spelling.
And then I get irritated by "texting" abbreviations.
We all have our faults !!!
Sorry, I was unable to respond to your post. Seems I have too many balls in
Having said that.
I've been posting here very once in a while for a few years. First time I have ever
been flamed. In at least one post above I asked if I should start a new thread and the
term "Windoz" is used by many in describing "Windows".
If you think anything I have posted in this thread is inappropriate then flag it. If
you simply don't like the content, then I would suggest you do what anyone over
the age 13 would do. Don't read it.
I've taken a look at the file. It appears to be a standard bmp file.
While our printer is equipped with a serial port, the code to support
it has not been written yet. I will probably just send down printable
characters with "escape" characters for control.
The printer uses industrial grade piezo type print engines. I have attached
a picture of the typical output. This particular engine prints in a 0.72" swath
and we stitch several together for taller prints.
Unfortunately, this type of head is not very common and the companies that
use it are very careful about distributing their documentation to competitors.
Thank you for the input.
If the printer is a standalone device with a serial port that is not used, then how does one transfer bytes into the printer? centronics 8 bit parallel cable? usb? ethernet? The pc has a bmp file on the disk. I like the idea of writing it to a usb drive. How do you really print the label again? We have those datamax vinyl label printers. The other programmer dude that's a c# and java genius here just wrote a program to draw the barcodes all in graphics mode. Send me a pm and I'll fwd it to him. I betcha he can send you a program in a day. You can dicker about renumeration.
Imagecraft compiler user
The printer is a stand alone unit with a built in keypad, display, BB ram
and RTC. I added an SD slot some time ago but to date I have only run
some simple file routines to test it.
They are typically sold to companies that need to mark on packaging but
we do have customers that mark on things like car parts and cd cases.
I agree with you on ease of using an SD card. The problem is that the customer
already has an existing software package with over 1000 label files. He required
that the updating of label content be as simple as possible. The printer is also in
a remote location adding to the difficulty of using the SD card.
At this point I have worked out 90% of the bmp handling. I just have to work
out the details of the serial interface. It has taken a few hours to get a handle
on Visual C# but I think I have it covered.
Thanks again for the offer. If I find myself in a jam, I will take you up on it.
Microsoft Bitmap is actually a pretty simple format and would be easy to work with, compared to something like JPEG.
If you needed to convert color depth (as in from 24-bit to a 16-bit format), you would need to develop an algorithm for doing this. The simplest method would be to just truncate the least significant bits from the red, green, and blue byte values and pack them into 16-bits and this would probably be just fine.
© 2020 Microchip Technology Inc.