Easy way to include binary data file in executable?
Rayman
Posts: 14,670
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?
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
-Phil
Perhaps I can add all this to my build.bat file and make it relatively seamless...
Hmm...Perhaps SimpleIDE should include such a utility?
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.
This should produce a linkable object file with the following global symbols defined: These can be referenced in your code to identify the start and end of the binary "blob" and its size in bytes.
But, might be the way I go...
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 code space (in case of XMMC)
- huge code space (in case of SDXMMC)
- a new challenge (Spin is just too easy to use )
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
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
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
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
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
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.
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.
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...