Jim

Ok, ignore my posts. I've not used CC3200 and just assumed it was not too dissimilar to the other TI MCU's but it seems the CC3200 MCU's don't have N2HET, EMIF or any real flavour of HET as it's really cut down for specific purposes... looks nice for some jobs though. Still, you could use parallel Flash just about I think depending what you're doing with what pins are available.

Additional: And of course you can use DMA & N2HET (or EMIF) to stream directly from Flash/SRAM -> Display (even better if your display is Parallel... but you may be running out of pins with low end CC3200's I suppose).

@Grobat I don't know if your CC3200 has EMIF (I think it's correct to say only the higher pin count MCU's have the External Memory Interface), if not then of course it will have N2HET(s). Together with Parallel Flash, cheaply available from Digikey etc al (EG this one. Hundreds variations available) ought to do the trick? Indeed, you could just use SRAM. I don't know how many of these images you have to have on hand but you'd be fitting in ~7 per meg. Run Length Encoding (RLE) ought to be quite good increasing that number. Digikey again have choices for Parallel SRAM (x8 TSOP packages probably a good place to start). Good luck!

Good old Saleae. Thanks for the follow up info. Ah, so a software SPI like on some of the vanilla Arduinos. I see, yes that wouldn't be very efficient at all. So really there are at least three categories: Software SPI Hardware SPI & Parallel (not counting I2C and variations of Parallel of course). I suppose it would be interesting if you could do a screenshot, under the most similar circumstances you can, from an MCU with hardware SPI. Just so those looking in the future and coming across this thread can see the info for themselves? (or this goes into the Wiki).

Worth adding that if my maths is right (give or take) then the 16bit parallel gives a very healthy 50fps... even assuming there are some other timings to be added in and that drops to 30-40fps then that's still very good for full screen video at a relatively high resolution.

Given my own question a few posts/days back I just thought I'd take a look at the ILI9486L controller mentioned to see how fast (in theory) 16bit was in the above Use Case vs SPI. So 854px * 470px * 16bit colour depth = 802,760 bytes However the datasheet says the ILI9486L is a 320x480 controller so not sure if things have changed in the last week or so? In anycase the clock timings are fairly typical so I suppose as an exercise the following isn't completely useless.... Parallel I see on page pp212 of the datasheet that the Parallel Clock Cycle (write) has a minimum of 50ns with 15ns high/low pulses also. (there are other timings, but they seem to over & underlap those so are superfluous I think?) So that gives: 8080 Parallel (16bit) = 6,422,080 bits in 16 bit bursts = 401,380 bursts (of 16 bits per burst aka parallel) * 50ns (1 * 15ns + 15ns setup but subject to a minimum write cycle of 50ns) = 20.069 ms SPI Of course there isn't a theoretical SPI clock speed, just limited by the MCU and display controller but ~16MHz (~63ns) on the controller side seems to be a theme in many. I see on pp214 of the datasheet that the SPI Clock Cycle (write) has a minimum of 66ns with 15ns high/low pulses & 15ns setup time. SPI = 6,422,080 bits in 16 bit bursts = 401,380 bursts (of 16 bits) * 255ns (16 * 15ns + 15ns setup) = 102,352 ms Conclusion Assuming I'm correct (and some of those 0ns minimum timings seem suspect to me. There may be "waits" between bursts that need factoring in?), then in this Use Case 16bit parallel is five times faster than SPI. That makes sense as I see from anecdotal forum posts that 16bit parallel is about 5 times faster. 8bit parallel would be 2-3 times faster. Gut feeling says that's about right to me. With a display controller that can accept faster SPI then the gap would narrow of course. (Whilst I do have a Logic Analyser I don't have that MCU nor display controller so can't double check understanding of datasheets personally). I'm sure Joel/Inmarket/others will point out the flaws in the working out (please do!)

I found the general info in this thread very useful indeed. I've mostly used larger RA8875 based TFT's, and for smaller displays various SSD/UC based displays. Almost always SPI (once, I2C). Decisions usually due to pin counts and on the smaller pin count MCU's that is a big factor. Yet when using MCU's where the pin count is measured in the hundreds (with decent amount of memory, storage and clock speeds etc) inertia & familiarity has kept me on the SPI/I2C wagon. The usual tricks of a fast SPI clock, "transactions" DMA etc are all useful techniques of course. However perhaps it's time to look at 8 (or even 16) pin parallel. I really spent any time thinking that the performance difference would be so great. You imply it is... and I believe you. I (and no doubt others) would greatly appreciate if more detailed info could be provided... benchmark numbers, a feature comparison of various controllers etc. Of course that is a massive ask so it would need to be greatly simplified and perhaps added to over time. Key things such as which primitives are hardware accelerated (with the minimum being rectangle perhaps).