Shop OBEX P1 Docs P2 Docs Learn Events
Easy way to include binary data file in executable? — Parallax Forums

Easy way to include binary data file in executable?

RaymanRayman Posts: 14,670
edited 2012-09-17 06:38 in Propeller 1
I'd like to be able to do the equivalent of the Spin "file" command...

Suppose I could use Spin2Cpp to create a dat section, but is there an easier way?

I've looked at this way:
http://balau82.wordpress.com/2012/02/19/linking-a-binary-blob-with-gcc/

But, that looks like a real pain.
Is there an easier way?

Comments

  • Heater.Heater. Posts: 21,230
    edited 2012-09-15 17:11
    Pain? It's a single command using objcopy. I would put a rule for that in my make file and that's it.
  • Dave HeinDave Hein Posts: 6,347
    edited 2012-09-15 18:10
    I usually write a small program to convert a binary file to a hex file that can be included in my target C program. There seem to be other approaches, but I would suggest using the technique that you are most comfortable with.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2012-09-15 18:32
    Rayman wrote:
    Easy way to include binary data file in executable? I'd like to be able to do the equivalent of the Spin "file" command...
    Um ... you could use Spin instead of C. :)

    -Phil
  • RaymanRayman Posts: 14,670
    edited 2012-09-16 09:33
    I guess that's my fallback plan... If I can't figure out how to make objcopy work, then I'll try making a spin file called resources.spin and use Spin2Cpp on it to get resources.cpp.
    Perhaps I can add all this to my build.bat file and make it relatively seamless...
  • Heater.Heater. Posts: 21,230
    edited 2012-09-16 09:55
    You could always spend half an hour creating a simple program in the language of your choice to read a file, binary or otherwise, and output it as a C byte array decalration. Like this one: http://www.codeproject.com/Tips/219107/Include-a-binary-file-in-your-source-code-as-a-byt
  • Dave HeinDave Hein Posts: 6,347
    edited 2012-09-16 10:33
    Heater. wrote: »
    You could always spend half an hour creating a simple program in the language of your choice to read a file, binary or otherwise, and output it as a C byte array decalration.
    A half an hour? It took me 5 minutes to write this program. Of course, I've written this program a few dozen times before. :)
    #include <stdio.h>
    
    int main(int argc, char **argv)
    {
        int i, n;
        unsigned char buffer[16];
    
        FILE *infile=fopen(argv[1], "r");
    
        while ((n = fread(buffer, 1, 16, infile)))
        {
            for (i = 0; i < n; i++) printf("0x%2.2x,", buffer[i]);
            printf("\n");
        }
        return 0;
    }
    
  • Heater.Heater. Posts: 21,230
    edited 2012-09-16 10:41
    Yep like that. The other 25 minutes are an allowance for adding error checking, command line optons "--help. --version, -b -w -l etc". Internationalization and so on. Oh, and a nice GUI interface for Windows users:)

    Hmm...Perhaps SimpleIDE should include such a utility?
  • jazzedjazzed Posts: 11,803
    edited 2012-09-16 11:07
    I used od and awk ... both are available in linux, osx, or msys (windoze mingw system tools).
    Awk-ward for some, but this explanation took longer to write than it took to get and add the data.

    # get the longs
    $ od -Ax -tx4 Graphics.dat | awk '{print "0x"$2", 0x"$3", 0x"$4", 0x"$5", "}'

    # get the number of lines
    $ od -Ax -tx4 Graphics.dat | awk '{print "0x"$2", 0x"$3", 0x"$4", 0x"$5", "}' | wc -l

    Awk prints 0x0, ... for an empty line, so that requires a slight count modification.
  • David BetzDavid Betz Posts: 14,516
    edited 2012-09-16 15:23
    What's wrong with using the same approach we use for PASM drivers:
    propeller-elf-objcopy -I binary -B propeller -O propeller-elf-gcc xxx.bin xxx.o
    
    This should produce a linkable object file with the following global symbols defined:
    __binary_xxx_dat_start
    __binary_xxx_dat_end
    __binary_xxx_dat_size
    
    These can be referenced in your code to identify the start and end of the binary "blob" and its size in bytes.
  • RaymanRayman Posts: 14,670
    edited 2012-09-16 19:12
    Looks fairly reasonable... Still a bit more trouble than the Spin $file directive.
    But, might be the way I go...
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2012-09-16 19:22
    Rayman,

    You're a skilled Spin and PASM programmer. So I have to ask: why revert to C at all? I'm curious because I've always considered C on the Prop to be an entry ramp for those conversant with C but alien to the Propeller. But as a long-time, highly adept Propeller developer, what does C give you on the Prop that Spin and PASM do not?

    Thanks,
    -Phil
  • AribaAriba Posts: 2,690
    edited 2012-09-16 19:54
    Rayman,

    You're a skilled Spin and PASM programmer. So I have to ask: why revert to C at all? I'm curious because I've always considered C on the Prop to be an entry ramp for those conversant with C but alien to the Propeller. But as a long-time, highly adept Propeller developer, what does C give you on the Prop that Spin and PASM do not?

    Thanks,
    -Phil
    - more speed (in case of LMM)
    - more code space (in case of XMMC)
    - huge code space (in case of SDXMMC)
    - a new challenge (Spin is just too easy to use :smile: )

    Andy
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2012-09-16 19:58
    Andy,

    Those are not features that are unattainable with Spin and PASM. For a skilled Spin/PASM programmer, how does C make the development experience more productive?

    -Phil
  • Dave HeinDave Hein Posts: 6,347
    edited 2012-09-16 20:08
    Phil, actually Spin can acheive the features that Andy stated. You can program in Spin, and then use spin2cpp plus PropGCC to achieve it. However, one of the main features that C provides is portability. Programs written in Spin can only be run on the Prop, whereas programs written in C can be ported to almost any other platform. C also provides many more tools for program development than Spin does. The C compiler can detect many more programming errors than can be done in Spin. This is probably the primary reason that C is a better language for beginners to learn than Spin.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2012-09-16 20:29
    Dave,

    I get the universality across many MCUs; I get the beginning programmer bit, albeit guardedly -- Spin seems much easier to grok than C; what I don't get, and what has not been explained to my satisfaction, is why a skilled Spin/PASM programmer such as Rayman or myself would ever want to consider C as an alternative to Spin and PASM for programming the Propeller. I cannot see what C brings to the table that Spin and PASM do not already provide. The example C programs I've seen on the forum are loaded with pragmata and build directives that are unnecessary for productive Spin programming and appear to this non-C programmer, at least, to be a hindrance to rapid application development.

    Enquiring minds want to knowTM: Where's the beef?

    Thanks,
    -Phil
  • Dave HeinDave Hein Posts: 6,347
    edited 2012-09-16 20:49
    Phil,

    I agree that the integration of Spin with PASM makes some things a lot easier. The current method for including PASM into PropGCC programs is a bit clumsy. This should improve over time. Also, the tendency to used standard C functions can make things like character-oriented console I/O more difficult than the methods used in Spin. On the other hand, floating point and formated I/O is clumsy in Spin. So it just depends on what you need from a language whether Spin or C is a better choice for you.

    Dave
  • ersmithersmith Posts: 6,054
    edited 2012-09-16 21:02
    Those are not features that are unattainable with Spin and PASM. For a skilled Spin/PASM programmer, how does C make the development experience more productive?

    Some more advantages of C on the Propeller:

    (1) C programs can be pretty close to PASM in performance, at a fraction of the development effort of PASM.
    (2) C allows you to use structures and data types that are not available in Spin, which makes many algorithms much easier to express.
    (3) There are an enormous number of libraries and snippets of C code available on the web, so you can avoid re-implementing the wheel in many cases.
    (4) For really big programs, C lets you use external memory easily.

    Eric
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2012-09-16 22:33
    Dave Hein wrote:
    On the other hand, floating point and formated I/O is clumsy in Spin.
    I can't disagree with that, and both of those issues are areas of active interest with me. I've been able to overcome the formatted I/O issue via preprocessing, and I believe that floating-point expressions could succumb to the same treatment, albeit with deeper parsing.
    ersmith wrote:
    (1) C programs can be pretty close to PASM in performance, at a fraction of the development effort of PASM.
    (2) C allows you to use structures and data types that are not available in Spin, which makes many algorithms much easier to express.
    (3) There are an enormous number of libraries and snippets of C code available on the web, so you can avoid re-implementing the wheel in many cases.
    (4) For really big programs, C lets you use external memory easily.

    1. I guess that depends on the relative PASM vs. C skills of the programmer.
    2. Granted. The fact that Spin sorts variables by size makes heterogeneous structures a bit of a pain to define.
    3. I'll give that a push. I know enough C to render a C algo in PASM without too much difficulty. But others may prefer the convenience.
    4. I'm not sure that "really big programs" are what the Propeller is all about or that it excels over other micros in that arena; but as a warm-up for the P2, I'll defer to the possibility that it's an advantage.

    -Phil
  • jazzedjazzed Posts: 11,803
    edited 2012-09-16 23:25
    ... why a skilled Spin/PASM programmer such as Rayman or myself would ever want to consider C as an alternative to Spin and PASM for programming the Propeller.

    There are millions of programmers out there that have some kind of an answer. Wouldn't it be nice if they all bought a Propeller or two? Hopefully some percentage of them can resell thousands in products. Learning Spin/PASM is a nice adventure, but it's not what everyone wants to do.

    Regarding big programs: My own experience from several projects was that some of them just could not be finished because of the Propeller limits. And every time I hit that problem, I cursed the Propeller and my decision to use it. I no longer curse it, because I no longer face the prospect of being stuck with a pile of junk due to no options. Now the options are many and several external memory solutions actually run faster than SPIN and are just as deterministic.
  • Heater.Heater. Posts: 21,230
    edited 2012-09-17 02:25
    Phil,
    I've been able to overcome the formatted I/O issue via preprocessing,

    Sounds like you are on the road to re-inventing C :)

    Seriously, patching up Spin to overcome many of it's limitations will soon bring you to something C like.

    I do agree with you that for a begineer to programming Spin (and the PropTool or BST) is a lot easier to kick off with. What with no header files, no project or make files required, no funky pragmas or macros, no ocean of command line options, no linker in sight and so on and so on. It's rather like the kids starting off with BASIC on their C64's back in the day. Just type and go.

    However some how the Arduino guys managed to get their begineer programmers using C++ from the get go. This is done by using an IDE that hides all that mess, by never calling the Arduino language C++ and by providing tutorials, libraries and example code that carefully omits all the complicated parts of C/C++ only using the simplest of constructs.

    We can only hope that SimpleIDE can do that for begineers to C/C++ on the Prop as well.
  • Dave HeinDave Hein Posts: 6,347
    edited 2012-09-17 06:09
    I think anybody that is serious about programming the Prop should learn the main languages that are supported on it. In the past this was just Spin and PASM. C has now become a valuable tool for the Prop now that Parallax has a supported compiler. There are situations where any of the three languages are the right choice for a project. And I'm sure there will be cases where all three languages can be applied to a project. So I would suggest learning C instead of debating the pros and cons of different languages. After all, we all had to learn how to program Spin and PASM. It wouldn't hurt to dabble in PropBASIC and Forth also. OK, programming in Forth is painful, but it's one of those things you should try at least once. :)
  • RaymanRayman Posts: 14,670
    edited 2012-09-17 06:38
    Rayman,

    You're a skilled Spin and PASM programmer. So I have to ask: why revert to C at all? I'm curious because I've always considered C on the Prop to be an entry ramp for those conversant with C but alien to the Propeller. But as a long-time, highly adept Propeller developer, what does C give you on the Prop that Spin and PASM do not?

    Thanks,
    -Phil

    I think Spin is very clever and a nice thing for beginner programmers. C++ is, however, my favorite language. PASM is different than Spin, however, and I wouldn't group them together. I'm sure I'll continue to program PASM. Actually, the Spin2Cpp tool gives me the best of both worlds... I can use whichever language I want and I think even mix and match...

    Further, Spin is a dead-end for Prop2 and beyond I think. When you have that much power, you are going to want to do fancy things that encorporate vast amounts of code. At least, I'm going to want things like png decoding, MP3 decoding, USB interfacing, etc. I think you'll find that these routines already exist and that they are in C or C++.
    So, you can spend a little time learning to use C++ with Propeller or a lot of time translating code to Spin... It's an easy choice for me.

    I was going to wait for Prop2 to start using GCC, but several factors are coming together and changing my mind:
    First, Spin2Cpp makes it rediculously easy to port all my existing Spin code.
    Second, CMM mode makes code nearly as compact as Spin and much faster.
    Third, I think I can work in my favorite editor: Visual Studio 2010
    Lastly, it looks like C++ is a viable mode under GCC without the size bloating I was worried about...
Sign In or Register to comment.