• gus (unregistered)

    Not so bad, especially since there used to be some programs for converting bitmaps to some quasi-standard file format, was it XPM? The format was C syntax, so you could just include the C files in your program and have data at hand.

    Some of us even equipped homebrew web browsers, very early on, to handle this incoming graphic format. Urp.

  • NeoMojo (unregistered) in reply to Someone You Know
    Someone You Know:
    Alex:
    ...as there were no makefiles and over warnings and errors.

    I think you may have forgotten to pull a number out of your ass here.

    I'm gonna say 12.

  • Patrick (unregistered) in reply to Someone You Know
    Someone You Know:
    Alex:
    ...as there were no makefiles and over warnings and errors.

    I think you may have forgotten to pull a number out of your ass here.

    It's OVER 9000!!!!

  • 3rd Ferguson (unregistered)

    Did anyone mention this all makes sense for an embedded system? Just asking.

  • morry (unregistered)

    Not a WTF. It's for ease of change. If you want to modify the bitmap, all you have to do is change a few source lines and recompile.

  • jimbobmcgee (unregistered) in reply to 3rd Ferguson

    Only everyone....

  • gsl (unregistered)

    This is why many otherwise-talented C and C++ coders have not passed interviews at our company. You really need a different mindset when you're dealing with a system with 32k of Flash, 4k of RAM, and a 1MHz clock speed (which drops to 32kHz when you need to conserve power).

    Some projects I've worked on, for example, had to keep function calls to a minimum because the overhead (both speed and stack space) was too expensive.

    So I can see why this would be a WTF for the uninitiated, but in an embedded system, sometimes a good old hardcoded char array is the best way to go.

  • (cs) 
    file=foo.bmp; identifier=my_bmp_data; \
        hexdump -ve '/1 "0x%02x" "\n"' "${file}" | xargs | \
        sed -re 's/ /, /g' -e "s/^(.+)\$/const char ${identifier}[] = {\1};/"

    Output should be something like:

    const char my_bmp_data[] = {0x42, 0x4d, 0x36, 0x0c, 0x00, ...snip... 0xed, 0x4d, 0x47, 0xf1};
    I've never personally done it, but I came up with that command line for someone else trying to get a similarly binary format into source code.

    It's a little more compact with a const char *:

    file=foo.bmp; identifier=my_bmp_data; \
        hexdump -ve '/1 "0x%02x" "\n"' "${file}" | xargs | \
        sed -re 's/0x/\\x/g' -e 's/ //g' \
                -e "s/^(.*)\$/const char * const ${identifier} = \"\1\";/"

    Output is something like:

    const char * const my_bmp_data = "\x42\x4d\x36\x0c\x00...snip...\xed\x4d\x47\xf1";
  • (cs)
    Zylon:
    morry:
    Not a WTF. It's for ease of change. If you want to modify the bitmap, all you have to do is change a few source lines and recompile.
    I honestly can't tell if you're trolling or just that dumb.
    What? All you have to do is regenerate the array, copy then paste! Easy as 1, 2, 3.
  • gsl (unregistered) in reply to DaveK

    That's assuming you're using GCC. I've used GCC for embedded ARM and AVR projects, but if you're dealing with a PIC, or an MSP430, or a Cypress PSoC, you're most likely using proprietary toolchains.

    I agree that linking a binary image (provided it's a dead-simple uncompressed one) is the best way to go, though, if you have the option.

  • sirlewk (unregistered) in reply to 3rd Ferguson

    No definetly not. You are the first, thank you for your insight. It is a good thing you didn't bother to read the comments, that would have just slowed you down in posting this helpful perspective.

  • onlyyou (unregistered)

    I think this is a real WTF. The proper way to do it is obviously to base64-encode the bitmap and store it in a CDATA section in an XML string in the source file.

  • (cs)

    If either storage or memory for libraries is a problem (like it usually is in embedded systems) then this is the normal thing to do. Also handy for displaying things like "error unable to load bitmaps" on a system that can not output text easily.

  • (cs) in reply to gsl
    gsl:
    This is why many otherwise-talented C and C++ coders have not passed interviews at our company. You really need a different mindset when you're dealing with a system with 32k of Flash, 4k of RAM, and a 1MHz clock speed (which drops to 32kHz when you need to conserve power).

    Some projects I've worked on, for example, had to keep function calls to a minimum because the overhead (both speed and stack space) was too expensive.

    So I can see why this would be a WTF for the uninitiated, but in an embedded system, sometimes a good old hardcoded char array is the best way to go.

    Fun, isn't it. I've spent the last several months writing support utilities in Delphi, and I can't wait to get back to the embedded stuff ! (Yes, I am being serious).
  • Robb (unregistered)

    hah!

    FOX toolkit does that! Or something like that...

  • Not a WTF (unregistered)

    You see this all the time in embedded systems because some boards don't have real operating systems with file support. So creating a fake file system for files like bitmaps and the like using giant arrays is pretty much your only choice.

    The example given here is of code used across a large variety of boards, so it was written to work with the lowest common denominator.

    Not a WTF.

  • (cs) in reply to 3rd Ferguson
    3rd Ferguson:
    Did anyone mention this all makes sense for an embedded system? Just asking.

    It's EVE Online

  • Crash Magnet (unregistered)

    The only WTF I see is that the orignal developer didn't cook the image enough when he encoded the data.

    I see some structures for headers (color, size, offsets, etc) and palettes. The orignal developer should have optimizes the image for his display and dumped the meta data.

  • (cs) in reply to dgvid
    So the lesson here is that when your background is in PC programming, embedded code makes you go "WTF?"

    That can be just the tip of the iceberg, though. Those embedded folks work in a strange, strange world.

    Actually, Windows has been doing a variant of this since the beginning. To change the splash screen that Windows 3.1 and earlier displayed, just make an RLE encoded 16-color BMP and make your own WIN.COM by running:

    COPY /B WIN.CNF + VGALOGO.LGO + MYPIC.RLE WIN.COM
  • Someone too lazy to login and at work (unregistered) in reply to 3rd Ferguson
    3rd Ferguson:
    Did anyone mention this all makes sense for an embedded system? Just asking.

    Yes. Everyone.

  • Top Tension (unregistered)

    Johnny D. should probably stick to living in the cozy world of file systems, string builders and resource files if he thinks this is a WTF.

    Most normal thing in the embedded world and I have written my share of binary file to C-code converters. Probably there was one in the lost makefile once.

    TopTension

  • Zapp Brannigan (unregistered) in reply to 3rd Ferguson

    Too bad I can't mod you up for being insightful.

  • Wodin (unregistered) in reply to Code monkey
    Code monkey:
    What, none of you ever programmed with PEEKs and POKEs and endless lists of DATA statements that could be machine code, image data, sounds, or whatever? Fo' shame!

    Captcha: erat. Quod Erat Demonstrandum.

    Of course! With crappy printouts in magazines where you often could not tell the difference between a B and an 8 :(

    Made for painstaking typing followed by a swift and colourful crash on a ZX Spectrum.

  • gatechman (unregistered)

    I'm still calling this WTF as the original developer could have linked a binary file instead leaving it as a C file. This is by far the better solution as changing the bitmap would only require replacing the file instead of re-writing a C file. In addition you can specify in your linker script where you want the bitmap to be loaded in memory. Finally, manually editing file headers? Well I guess if your in windoze and your dealing with Mr. Gates idea of a bitmap..

  • Mike (unregistered)

    I had the source for a bunch of the "VGA demos" that we used to trade on floppies back in the early 90s. Many of them were written just like this.

    CAPTCHA: inhibeo - is TDWTF trying to tell me something?

  • SR (unregistered) in reply to gatechman
    gatechman:
    I'm still calling this WTF as the original developer could have linked a binary file instead leaving it as a C file. This is by far the better solution as changing the bitmap would only require replacing the file instead of re-writing a C file. In addition you can specify in your linker script where you want the bitmap to be loaded in memory. Finally, manually editing file headers? Well I guess if your in windoze and your dealing with Mr. Gates idea of a bitmap..

    Was there some part of "no filesystem" that you didn't understand?

  • Anonymously Yours (unregistered)

    I didn't know I had anything left in me to die.

  • A. Mous (unregistered) in reply to SR

    Yeah, this code is fine.

    Admittedly, the developer machine ideally would have linked in the bitmap at link time(prior to upload), but that probably wasn't available at the time or the developer didn't know about it.

    Not a big deal. The Web 2.0 guys are getting their panties twisted tho', kinda funny to see...

  • Max (unregistered)

    We used to use that pattern when writing demos and intros back in the day. The only real reason was to end up with a single executable with no external filesystem dependencies. There's really no reason for such nonsense in the "real world", though. :)

  • Anonymous Cowardly Lion (unregistered)

    JWZ's X-Screensaver does this (uses XDM) for its display as this is more secure than having separate image files. If this is a WTF, it's not in the technique itself but in the application of it.

  • SP (unregistered)

    [image]

    for the curious... 26x24

  • (cs)

    Everyone keeps saying "EMBEDDED DEVICE WITH NO FILESYSTEM AND NEXT TO NO RESOURCES!!!!!!1111one!!", but I have to wonder how relevant that notion actually is anymore. Heck, even my cellphone has 256 MB of RAM, and a filesystem to manage a few gigs' worth of storage on a tiny storage chip that an infant could close their hand around. And at CES they just demoed a Droid-powered microwave! Are these fabled "embedded devices" actually still being created anymore? If so, what are they used for?

  • (cs)

    The fact that so many of you think this is a WTF is exactly why we hire people with embedded experience for embedded jobs. Normal desktop/app programmers have no idea what to do on machines with limited resources or which have no OS at all, so they can't architect anything properly. For instance, you don't do floating point math in interrupt routines (don't laugh, I've seen it attempted). You often don't have a filesystem to just load your data from. And your primitive linker may not support embedding arbitrary binary blobs in your target and/or giving your code the offset to them.

    This is a perfectly valid, time tested way to do it within all these constraints - assuming you have some tool to output the code for you from the resource blob. If you're creating and maintaining it by hand then you may have a wtf on your hands.

  • The Sussman (unregistered)

    Mason Wheeler No, not at all. Especially not in a washing machine with an LCD display (and a small splash screen), a car, a microwave, a calculator, a remote control, a power meter, an electric door lock, a card reader, a security camera, an automatic door, medical equipment, robots, signal processing devices, regular or cordless phones, heat pumps and A/C devices, hard drive controllers, rice cookers, electric ranges, ticket machines, wickets, planes, scrolling displays, interphones, or anything you'd use really.

    The c-bitmap This isn't a WTF.

  • (cs) in reply to Mason Wheeler
    Mason Wheeler:
    Everyone keeps saying "EMBEDDED DEVICE WITH NO FILESYSTEM AND NEXT TO NO RESOURCES!!!!!!1111one!!", but I have to wonder how relevant that notion actually is anymore. Heck, even my cellphone has 256 MB of RAM, and a filesystem to manage a few gigs' worth of storage on a tiny storage chip that an infant could close their hand around. And at CES they just demoed a Droid-powered microwave! Are these fabled "embedded devices" actually still being created anymore? If so, what are they used for?

    as relevent as wasteing millions of dollars per year on additional memory and almost millions on software maintance.

    1. use smaller memory chips
    2. save 1 dollar per unit * 2 million units
    3. ????
    4. PROFIT
  • Balau (unregistered)

    If the application needs speed, the system has plenty of memory, maybe the embedded display works by pointing to a memory area where a bitmap is, then this solution works well.

    I really don't see the WTF here. Or maybe I'm overlooking something...

    Can you provide an example of a strictly better alternative?

    captcha: haero

  • Techpaul (unregistered) in reply to Mason Wheeler
    Mason Wheeler:
    Everyone keeps saying "EMBEDDED DEVICE WITH NO FILESYSTEM AND NEXT TO NO RESOURCES!!!!!!1111one!!", but I have to wonder how relevant that notion actually is anymore. Heck, even my cellphone has 256 MB of RAM, and a filesystem to manage a few gigs' worth of storage on a tiny storage chip that an infant could close their hand around. And at CES they just demoed a Droid-powered microwave! Are these fabled "embedded devices" actually still being created anymore? If so, what are they used for?

    Ah the SMALL volume items, the larm systems, coffee machines, microwaves, distributed processing units in modern cars, let alone anything with a small graphic LCD or even SWITCHES that LCD displays that can change the caption on the switch.

    The VAST bulk of microprocessors/controllers shipped by VOLUME are 4 and 8 bit processors, with next to no memory (ROM and RAM).

    Captcha dolor - A devalued currency

  • me_again (unregistered)

    Ouch my head hurts now after reading all the comments and understand < 0 portions of it; I sure am glad you guys are around to keep my washing machine with an LCD display (and a small splash screen), a car, a microwave, a calculator, a remote control, a power meter, an electric door lock, a card reader, a security camera, an automatic door, medical equipment, robots, signal processing devices, regular or cordless phones, heat pumps and A/C devices, hard drive controllers, rice cookers, electric ranges, ticket machines, wickets, planes, scrolling displays, interphones ... etc working.

  • COward (unregistered)

    It saves writing loader code and you have all your bitmaps linked into your program, instead of having to have a bunch of external files.

    The GIMP can even generate this code.

    Not really a WTF.

  • Techpaul (unregistered) in reply to Patrick
    Patrick:
    Someone You Know: Alex:

    ...as there were no makefiles and over warnings and errors.

    I think you may have forgotten to pull a number out of your ass here.

    It's OVER 9000!!!!

    Hey I have seen desktop jockeys get that many errors because they forgot obvious compiler switches, like -

    Do NOT include Standard C runtime Do not include Standard Math libraries for float Do not include stdio/printf/sprintf calls Do not limit the max integer to 16 or 8

    Then over half is because the memory map ha overflowed.

    Still designing embedded systems (since the early 1980's), from T-11, 6809, 8085 through H8 and beyond.

    Captcha augue - more precise than vague

  • Techpaul (unregistered) in reply to oldtaku
    oldtaku:
    The fact that so many of you think this is a WTF is exactly why we hire people with embedded experience for embedded jobs. Normal desktop/app programmers have no idea what to do on machines with limited resources or which have no OS at all, so they can't architect anything properly. For instance, you don't do floating point math in interrupt routines (don't laugh, I've seen it attempted). You often don't have a filesystem to just load your data from. And your primitive linker may not support embedding arbitrary binary blobs in your target and/or giving your code the offset to them.

    This is a perfectly valid, time tested way to do it within all these constraints - assuming you have some tool to output the code for you from the resource blob. If you're creating and maintaining it by hand then you may have a wtf on your hands.

    I wonder how many "Gizz'us a job" requests you get??

    :-^

    Captcha duis - rap speak for 'doing his [girlfriend/hoe]'

  • mmarrero (unregistered)

    Reminds me of Basic listings of ancient magazines like Compute! and Family Computing.

    Borland Turbo Pascal and C had BINOBJ.exe, converted binary files to objects to be linked directly to the executable.

    That C listing is just "portable", but, I don't have a clue why the infamous .bmp format. Header is large, lots of unsupported variants (rle, os/2), and, pics are stored upside-down!

  • web3o4u (unregistered)

    Look at the forefront of web technology: Data URLs for images all over the place. The c-bitmap is even better, because it is semantic.

  • Scott (unregistered) in reply to SP

    So this is for a levitating tractor controller?

  • (cs) in reply to jspenguin

    I sign my name under this one.

    I've used XPM files for a long time. They are the easiest way to embed a simple image on an executable.

    WTF is this WTF anyway ?

    The real WTF would be (I know, this is used somewhere, just don't remember where):

    <?xml version="1.0" encoding="UTF-8"?>
<image width="2" height="2">
 <row>
  <pixel red="128" green="128" blue="128"/>
  <pixel red="128" green="128" blue="128"/>
 </row>
 <row>
  <pixel red="128" green="128" blue="128"/>
  <pixel red="128" green="128" blue="128"/>
 </row>
</image>
  • Anon (unregistered) in reply to SP
    SP:
    [image]

    for the curious... 26x24

    Okay, but what is it? A tractor sitting on top of a tree moving to the left?

  • David Souther (unregistered)

    Embedding images into C code isn't WTF, it's actually fairly common. In fact, there's an entire file format designed to do specifically that, called XPM (X PixMap). GIMP imports and exports natively, and Qt at least "just does it." Doing bitmaps for icons this way sounds like a perfectly reasonable version of this pattern.

    http://en.wikipedia.org/wiki/X_PixMap

  • @Deprecated (unregistered) in reply to Mason Wheeler
    Mason Wheeler:
    ... on a tiny storage chip that an infant could close their hand around.

    WTF? That's a choking hazard!

    PS,. that icon is like the greatest icon for "Launch photon torpedoes and energize tractor beam" that I have ever seen!

  • squidbot (unregistered)

    Absolutely NOT a WTF as has been stated over and over. This may be the first I've seen that I would like to be removed from the site. Prior commentators have already listed the reasons this is perfectly valid.

    If there is a WTF, perhaps it's on the head of "Johnny D". If I were to guess, he's a young programmer with very little experience outside of Java or the likes.

  • gsl (unregistered) in reply to oldtaku
    oldtaku:
    The fact that so many of you think this is a WTF is exactly why we hire people with embedded experience for embedded jobs. Normal desktop/app programmers have no idea what to do on machines with limited resources or which have no OS at all, so they can't architect anything properly. For instance, you don't do floating point math in interrupt routines (don't laugh, I've seen it attempted). You often don't have a filesystem to just load your data from. And your primitive linker may not support embedding arbitrary binary blobs in your target and/or giving your code the offset to them.

    This is a perfectly valid, time tested way to do it within all these constraints - assuming you have some tool to output the code for you from the resource blob. If you're creating and maintaining it by hand then you may have a wtf on your hands.

    Hear hear. Most of the projects I've worked on have had no OS at all, and I've hit Flash and/or RAM constraints dozens of times. Dynamic allocation? Sorry, there's no heap. Most of the processors have no floating point unit whatsoever, and you definitely don't have the space or time to emulate it, so you do your calculations using fixed-point tricks instead. Lookup tables are extremely common (for the same reason). And the best part: paying thousands of dollars for the tools, and having them be buggy and crash-prone anyway because there's really no competition out there.

    Here's one example where the C-bitmap works extremely well... one project I've worked on has a 240x64 black-and-white LCD, and the memory map of the LCD has each byte equal a 1x8 column of pixels, with the MSB at the bottom. So you basically encode bitmaps as series of 8-pixel-tall strips of confetti. That sort of memory mapping makes conversion from any sort of other bitmap on the fly slow and wasteful.

    It's really a totally different world when you're working under such limiting circumstances -- much more like application programming was during the days of the Apple //e and Commodore 64 than any sort of PC programming today.

Leave a comment on “The c-bitmap”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article