Sometimes, programming is the art of exploring large numbers of dead ends quickly. Backup plans upon backup plans and flexibility are key.
So, what needs to be done, but I'm not qualified to do, or interested in, is make an abandonware product (based on an ARM board and almost an certainly exploitable C app that tries to parse XML and does a terrible job) talk to a Flash app. The ARM board talks to the network and other hardware.
But trying to reverse engineer this mess and work with Flash for something Flash shouldn't be used for didn't appeal. So I decided to use Perl to try to replace it. And use a rather nifty graphic accelerated ARM board running Linux to do it.
So I wrote code in Perl and Coro, and wrote XS bindings for the vendor's C++ libs. Getting C++ to link to Perl is a bit involved and non-obvious. I found a tutorial and I think I linked to it in a previous entry. Or maybe that was me on Twitter.
But the libs didn't work as documented, and I couldn't figure out or get them to tell me how they work. Oh yeah. That was after I struggled for ages trying to get some version of Unix pivot_root'd on there that would link to the libraries, which were compiled softfloat rather than hardfloat. The ARM board has no floating point acceleration, but the kernel traps and emulates it, which is slower than software, but for Linuxes on ARM, hardfloat is the standard. I tried building a custom gcc on another ARM board that had a kernel that would swap. But that didn't help. I misunderstood the problem. I tried building a Linux from parts of Debian and the Linux on the board, but it turns out that the various libs on the board were hardfloat, not softfloat, so the graphics libs wouldn't link to them. Turns out the cross compiler, for Windows, was making static binaries that didn't even try to use the libraries on the board. I even broke down and installed Windows and failed to get the cross compiler working, so I was a bit in the dark on all of this.
And all of that was after Debian debootstrap would *not* boot strap itself. I had to hack the code all up and cherry pick bits of Debian from this other ARM board I have to get it to install. Then I screwed up the install and had to do it again.
So I move the code to x86 and SDL.. And Perl starts coredumping. Perfect. Just perfect. Not Perl's fault. SDL and Coro were fighting... Coro hates threads, SDL loves them.
SDL pretty closely mirrors the blitter hardware on the board so it's a good match for prototyping for the board, assuming the vendor helps us out again. We're kind of in a stalemate. They want us to buy the board, and we want to see it work first before we buy it. Should have bought the one long ago and looked at buying more and written this one off if it didn't work. But that's always how it goes.
There they have some other hardware that looks really awesome -- 3D accelerated core on the ARM chip -- called OpenVS. If this board doesn't go, maybe I can do that.
So, once I got SDL not sucking in pthreads, I of course had to get Coro::Cont working again. Marc dropped support for it. But that's another post.
-scott
