TonyD wrote:Yeah, Luminary parts are a little slow (is 50MHz considered slow?)

No, 50MHz isn't really slow. But my vision is colored by all the wonderful 72MHz+ processors out there.
TonyD wrote:but they were one of the first Cortex-M3 licensees so their initial parts now look slow and lack many of the I/O interfaces of later Cortex-M3 licensees (ST,NXP, Cypress, Atmel) . That said, Luminary was recently bought by TI so you can expect TI will be pushing their parts strongly (lots of cheap offerings) and bringing out new devices.
Poking around some hobbyist forums I found the general opinion was that if you wanted some peripheral and a solid cpu, the luminary micro parts would probably have it, but they'd have it at a slower clock speed. I didn't realize the buyout had happened that recently! But then again I haven't really been paying attention until even more recently

...
TonyD wrote:OT - If you want to try a more exotic processor ...
Exotic was not the goal here! The goal is to have this be as friendly as the current Uzebox by trading off soldering complexity for easier debugging and software, and multicore is certainly not friendly! Though that is a really neat processor...
uze6666 wrote:Yeah I saw that video, very nice stuff. I'm wondering though, since all those newer ARMs have some sort of execution cache, how can you get deterministic state during video rendering (be cycle precise)??? Is there some way to flush the execution cache upon entering interrupts or something?
For most of the ones I've looked at you can actually flush the cache at any point, and a lot of the processors also allow for you to put blocks of code where it will run it without using the cache at all. In any case there must be a way to do it as there are a *ton* of audio/video processing ARMs on the market, and almost all of these seem to suggest that they can handle deterministic applications.
uze6666 wrote:As mentioned I've only worked with the ARM7TDMI, but choosing the right MCU is not easy and in the end it can be a question of personal taste and experience with the device. However since the never ARM9 or Cortex chip are faster I'd be tempted to used them, would it be just to not bring "to market" something already old.
I was more curious about other's personal experiences, as I have very little (I've mostly been a PIC person). While coming in with an ARM7TDMI would technically be coming to market with something old, I know that a lot of the ARM9 cpus are binary compatible with ARM7, so it wouldn't be too much of a leap to start with an ARM7 and move up later, transferring the code over slowly. Either way, I guess I was hoping to mooch off of someone else's personal preferences just because I haven't really formed an attachment to any particular ARM core yet as I've never really messed with them.
The main bear with the newer, bigger, better ARMs is the demand for multiple voltages, which as I previously mentioned makes routing on a two layer board a bit unrealistic. The really neat super ridiculous ARMs (like the OMAP) are all BGA, which makes them non-starters. Even PGA is pretty much a no-go as it would drive up the cost of the PCB far too much (it would need a 4-layer PCB and it would be really annoying to solder).
I found out that the Cortex-M3 Architecture is by design Harvard architecture which means that this is can't run code off of an SD card (at least not without it self-flashing, which would reduce the life of the CPU). So Cortex-M3 is now officially off the table as far as I'm concerned.
This was more a testing of the waters to see if there was some strong demand to design the "Super Uzebox" with a newer CPU, and whether anyone knew of excellent chips to use. The ARM7 definitely seems like it may not be the ideal choice, so I'm going through looking for ARM9 and Cortex-M series processors to see what I can find, but these appear to be generally less feature-rich than the similarly priced ARM7's out there. The ones listed above are definitely my top choices so far, but I haven't had a few hours to devote to searching yet.