iMXRT1060 etc...

[stroh90]

Is it me or does NXP / Freescale documentation suck for the iMX family.

I'm trying to figure out how the internal bus interconnects are made.

On the STM32 family this is clear to see in the documentation and you can see where bus masters connect to slave memory. You can have an intensive DMA session hitting memory A and certain bus interconnects to (for example) memory B are completely free.

I can't find anything like that in the rt1060 "documentation" (*). I guess it's not possible anyway because as far as I can see the OCRAM is a single block of memory with 1 port Or did I perhaps miss something in the 3500 pages. In a heavily loaded DMA intensive scenario I think the (slower CPU) ST parts could potentially work much better.

If ST had ah F7 or H7 part with 2 x HS USB I wouldn't go anywhere near the iMX parts.

Has anyone messed around with the rt10xx parts enough to know this level of detail?

(*) Note to NXP : A verilog -> pdf dump with Chinglish sprinkled on top is not documentation. ST's documentation is great compared to this junk.

[errorprone]

I agree, the documentation could be much better but I have found some description of the bus matrix in these two documents.

https://www.nxp.com/docs/en/application-note/AN12042.pdf
https://www.nxp.com/docs/en/application-note/AN12077.pdf

As for a dma heavy application, I used the imxrt1020 at 396mhz and could definitely see the bus contention or flexram contention. I and had a timer kick off a dma transfer for a spi dac every 2 us and a spi adc dma transfer linked to it ( it would interrupt after 250 samples all from ocram).  This was on top of freertos and everything was running from itcm.  During the interrupt I toggled a gpio and measured the jitter.  Instead of toggling every 500us, sometimes it would take as long as 520us.

Afterwards I also found out that the bus frequency is limited to 1/4 the core frequency.  Haven't had a chance to try out the stm32h7 or f7 but datasheet says they have a bus frequency of 1/2 or 1x the core frequency respectively and separate memories which seems like it out would help.

Sent from my LG-H810 using Tapatalk

[stroh90]

Thanks for the links!

I'll take a look.

If you want to 'drive in a straight line' as fast as possible, than I guess this family works pretty good.

But as soon as you go round a corner, I have a feeling that the wheels will start to fall off...

This thing is feeling very much like a bargain basement Vybrid rather than a high end micro controller. It's  a shame that the NXP team didn't develop this thing. I'm sure they would have targeted it as a high end LPC.

I like the ST parts. But I do get the feeling that ST don't really know what they're doing  The F7/H7 in particular feels like they just threw a bunch of random stuff on top of the other random stuff. At least the H7 (finally) got a better DMA controller (so now it has 3 *different* DMA controller designs in the same device  ) I just need 2 x HS USB ...

[ehughes]

Instead of toggling every 500us, sometimes it would take as long as 520us.

Also, be careful with using GPIO for performance analysis on this chip.   The GPIO in particular are tied through couple layers of synchronization, etc and it is hard to get a toggle rate better than about 13MHz.     The 1st version of silicon did not have the bitset and bitclear registers on the GPIO implemented.....

It is a good device when you need to do some number crunching but some of the IO bottlenecks are frustrating.

[errorprone]

I like the ST parts. But I do get the feeling that ST don't really know what they're doing  The F7/H7 in particular feels like they just threw a bunch of random stuff on top of the other random stuff. At least the H7 (finally) got a better DMA controller (so now it has 3 *different* DMA controller designs in the same device  ) I just need 2 x HS USB ...

I know what you mean, especially with the release of the F7/H7 value line with reduced flash. One good this I can say about the i.MX RT parts is that the IDE makes the external flash transparent to the user.  You can program, erase, and debug from the IDE directly with the same work flow as any other microcontroller.

Instead of toggling every 500us, sometimes it would take as long as 520us.

Also, be careful with using GPIO for performance analysis on this chip.   The GPIO in particular are tied through couple layers of synchronization, etc and it is hard to get a toggle rate better than about 13MHz.     The 1st version of silicon did not have the bitset and bitclear registers on the GPIO implemented.....

It is a good device when you need to do some number crunching but some of the IO bottlenecks are frustrating.

I totally agree with you about the layers of synchronization.  With the benchmark numbers I was trying to emphasize that these layers are also shared resources and a DMA in the background can alter the time it takes from an instruction executing to the pin toggling.  Yes those IO bottlenecks are quite troublesome for low jitter applications especially since this part is marketed for real time systems.