Now, to answer my own question (from that post): What to do with 144 cores? I guess I'm going to have to figure that one out...
I've got a big learning curve ahead of me, and although I'm not the type to post daily updates on "learning experiences", I'll probably post now and then how it is going. If I get an overwhelming burst of energy, then I may even fork my EVB001 adventures to a new blog dedicated to just that.
Anyway, what are my current plans?
- Learn enough arrayForth (ColorForth) to be dangerous.
- Work my way around the board (nodes and I/O).
- Begin world dominating project.
Regarding #1, I have followed ColorForth for years, but I never really used it. That being said, I am using Charley Shattuck's MyForth on my day job (shhh.. don't tell them) and that is different enough from ANS Forths that the arrayForth "culture-shock" is low.
Working around the board (#2) is critical as I have to figure out what my peripheral hook up options are. I figure that I would try and get the board talking to an accelerometer (or other sensor). This would be a good goal.
Now, world domination (#3) is a bit vague.
Now, here is what I am thinking.... My usual approach of building tiny/simple things that can be replicated (low volume production runs) won't work here. I simply can't afford to dedicate a $450 eval board to a single task. Then again, I hate the idea of just using it as a "prototyping" board for various ideas. I need a more singular goal.
So, I am viewing the eval board as a "platform". But, a platform for what?
When someone (for passion) designs and builds their own car, plane or boat, they are creating something unique. They are not making something with the end goal of mass production. They are building a "system" that satisfies their own needs. Now, if that "system" later results in replication due to demand, then that is great. But, it is all about building something unique -- something unlike the other guy's car, plane or boat.
You may see where I am getting... the usual place: Robotics.
But, here I use the word "Robot" in loose terms. I am thinking about building a platform to support the integration of sensors and actuators. I want to load up the EVB001 with as many sensors as possible and have it collect, correlate and react through the manipulation of actuators. However, I want to do this within the tightest time constraint possible: I want a tight coupling between sensors and actuators. I want a feedback mechanism. I want... my flocking Goslings (or at least one of them at this point).
Integrating lots of sensors with a single fast running ARM is certainly possible. But this would be interrupt hell (or polling hell or linux process/thread management hell). This is why I (and other sensible people) incorporate tiny 8051s, AVRs and MSP430s into dumb sensors -- to make them independently smarter. Unfortunately, when you have a bunch of microcontroller enhanced sensors (and actuators) you have a communication nightmare. And you need a separate master CPU to integrate all of the "smart" data and manipulate the actuators.
None of this is new. None of this is rocket science. However, the robot I design would be my bot. It would be unique.
More deep thoughts later... For now, I just need to figure out how to talk to my new toy ;-)