Author Topic: i.MX RT 600  (Read 1102 times)

0 Members and 1 Guest are viewing this topic.


Offline mark03

  • Frequent Contributor
  • **
  • Posts: 377
  • Country: us
Re: i.MX RT 600
« Reply #1 on: October 17, 2018, 04:17:13 am »
Looks interesting!  Can someone who's used the Tensilica DSP comment on how open it is?  Are there free tools?  Is there an optimized FFT for it that you can access without signing away your firstborn?
 

Online technix

  • Super Contributor
  • ***
  • Posts: 2782
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: i.MX RT 600
« Reply #2 on: October 17, 2018, 04:36:45 am »
I wonder if they will revise their i.MX 8 to replace the M4F's with M33F's...
 

Online Berni

  • Super Contributor
  • ***
  • Posts: 1501
  • Country: si
Re: i.MX RT 600
« Reply #3 on: October 17, 2018, 04:38:12 am »
Interesting chip there.

The DSP part of it is not that hugely impressive, it is pretty beefy as far as audio DSPs go but in the end it can only do 4 per cycle 32x32 integer MAC or 8 per cycle 16x16 integer MAC. Running that at 600MHz makes for some pretty speedy math compared to any ARM Cortex M7 out there. Yet a lot of bigger ARM chips have NEON instructions and this gives them 4 per cycle 32x32 float or integer MACs or even 16 per cycle 8x8 integer MACs(Not useful for audio but for graphics certanly). Additionally these bigger ARMs tend to run at around 1 GHz and often have more than 1 core.

So i guess this chip better be resonably cheap or low power to make it worth it. And yes hopefully you can get your hands on the C compiler for it, but seeing the compiler is made by Cadecence i have a feeling its not going to run you cheap for a license.
 

Offline blueskull

  • Supporter
  • ****
  • Posts: 10197
  • Country: cn
  • Power Electronics Guy
Re: i.MX RT 600
« Reply #4 on: October 17, 2018, 04:47:09 am »
600MHz, octa-MAC, 2 circular buffers, HS USB 2.0 -- BlackFin+ killer. Consider the M33 free.
At that hardware feature set, I don't see how ADSP-BF70x competes.
Especially considering the BF70x needs a $1000 compiler.
SIGSEGV is inevitable if you try to talk more than you know. If I say gibberish, keep in mind that my license plate is SIGSEGV.
 

Offline ataradov

  • Super Contributor
  • ***
  • Posts: 4839
  • Country: us
    • Personal site
Re: i.MX RT 600
« Reply #5 on: October 17, 2018, 04:49:11 am »
Especially considering the BF70x needs a $1000 compiler.
Does Tensilica DSP have a free compiler? I too wonder how open it actually is.
Alex
 

Online technix

  • Super Contributor
  • ***
  • Posts: 2782
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: i.MX RT 600
« Reply #6 on: October 17, 2018, 04:58:51 am »
Especially considering the BF70x needs a $1000 compiler.
Does Tensilica DSP have a free compiler? I too wonder how open it actually is.
It appeared to me that those DSP cores uses the same compiler as the Xtensa cores, as found in ESP8266... So hijack that?
 

Offline blueskull

  • Supporter
  • ****
  • Posts: 10197
  • Country: cn
  • Power Electronics Guy
Re: i.MX RT 600
« Reply #7 on: October 17, 2018, 05:00:16 am »
Does Tensilica DSP have a free compiler? I too wonder how open it actually is.

Don't know. But if a company like NXP rolls a chip, it will get the compiler sorted out for the customer.
ADI is notoriously bad on tools support because they mainly target high end customers.
NXP and ST are more focused on volume products with thinner margin.

Or maybe NXP will just add VLIW/SIMD support to the existing GCC-xtensa, which will be very appreciated.
At least ESP32 users will appreciate that -- ESP32 doesn't have free compilers that will utilize SIMD without using intrinsics or assembly.
SIGSEGV is inevitable if you try to talk more than you know. If I say gibberish, keep in mind that my license plate is SIGSEGV.
 

Offline mark03

  • Frequent Contributor
  • **
  • Posts: 377
  • Country: us
Re: i.MX RT 600
« Reply #8 on: October 17, 2018, 05:02:24 am »
Not just the compiler, but a freely-available library of basic DSP functions.  For all its warts, CMSIS-DSP at least exists and is free, so the barriers to entry for M4F/M7 DSP are low.  If the same is not true for the Tensilica DSP, it won't be of much interest to smaller players.
 

Offline djacobow

  • Frequent Contributor
  • **
  • Posts: 804
  • Country: us
  • takin' it apart since the 70's
Re: i.MX RT 600
« Reply #9 on: October 17, 2018, 05:21:09 am »

[ Disclosure: I worked for Tensilica 2000-2005 before it was aquired by Cadence. By far, the best company I ever worked for. ]

The way Tensilica Xtensa Processor Generator works is that licensees use a GUI to select among a bunch of "canned" processor features: multipliers, MMU, cache size/type/none, special instructions for this or that. Additionally, using a special language called "TIE", fully custom instructions can be created that use custom IO, custom register files, etc. When the user clicks "go" the processor RTL is created on the fly, along with a verification suite, scripts for synthesis and layout, etc, along with a full suite of GCC-based software tools that understand all the customizations including the new instructions.

Regarding the compiler, at a minimum, instrinsics are created so that you can instantiate variables matching the register file entries and call the instructions directly on them without dropping to assembler. But when the register and instruction types created result in vector operations on "normal" types (float, int32, uint32, etc), the compiler is generally smart enough to use them on its own, unrolling loops and such.

It's really an incredible platform, and was far ahead of its time. It was basically everything RISC-V claims to be regarding extensibility, except better and more automatic, but, of course, not free or open.

Anyway, the Xtensa HiFi engine 4 is essentially a fully canned audio DSP where all these choices have been made in advance by Tensilica, but conceptually works the same as any Xtensa processor. Tensilica definitely provided NXP with a compiler and all the regular tools.

Is there an optimized FFT? I am absolutely sure there is and it is part of the basic support for the DSP.

Will NXP be providing these tools to users for free? Don't know. Will they provide the FFT library to users? Don't know.

Someone asked whether the ESP32 tools could be used to build binaries for this machine. The answer is a definite maybe, if the ESP32 is a strict subset of instructions to whatever is in this processor. Probably things like the linker map would have to be adjusted, and of course, the compiler would not use the DSP instructions, but you could create intrinsics for them. But a better path by far would be to use the compiler that was generated for the DSP.

-- dave j
 
The following users thanked this post: Berni, mark03, blueskull, MT

Online Berni

  • Super Contributor
  • ***
  • Posts: 1501
  • Country: si
Re: i.MX RT 600
« Reply #10 on: October 17, 2018, 04:26:37 pm »
That sounds pretty jazzy. I never even seen a FPGA softcore generator that is this automated.

Oh and how is the software support for the i.MX RT family in general?
Everyone quite likes the STM32 chips here and the new Attolic true studio IDE works well and the CubeMX tool for generating a project and initialization code is a great idea. Yet in the end these so called HAL drivers that ST provides are at times simply garbage. Quite a few times i ended up using the driver to initialize the peripheral and then ignoring the HAL driver away and using direct register access to run it afterwards. That is because the driver simply was not capable of doing what i needed (Such as having UART continuously receive or generate a I2C restart rather than sending a stop followed by a start) or sometimes i had to fix a bug in the driver myself (Like the ethernet driver had a broken transmit function). On top of it all the source code is a convoluted mess of #defines and #includes where you have to dig down 4 function calls and 6 macro expressions deep before you find the actual hardware register its writing to (Even for simple things like I2C or ADC).

Are the drivers provided by NXP for the RT family better than this?
 

Online ali_asadzadeh

  • Frequent Contributor
  • **
  • Posts: 547
  • Country: ir
    • ASiD Designer
Re: i.MX RT 600
« Reply #11 on: October 17, 2018, 08:04:34 pm »
RT is the way to go for Future Cortex M designs, if they could make something better than STMCUBE for them, it would be like heaven ^-^ ^-^ ^-^ ^-^
You can order parts from www.ASiDesigner.com
we are a wire-based company
 

Offline ogden

  • Super Contributor
  • ***
  • Posts: 1193
  • Country: lv
Re: i.MX RT 600
« Reply #12 on: October 17, 2018, 08:40:00 pm »
Everyone quite likes the STM32 chips here and the new Attolic true studio IDE works well and the CubeMX tool for generating a project and initialization code is a great idea. Yet in the end these so called HAL drivers that ST provides are at times simply garbage.

Yes they are and it's ok. CubeMX and ST HAL libraries are good for beginners/students to quickly get "hello world" and ST code examples running. Professionals shall not rely on "free for all" libraries that does not even have proper support.
 

Offline mac.6

  • Regular Contributor
  • *
  • Posts: 130
  • Country: fr
Re: i.MX RT 600
« Reply #13 on: October 17, 2018, 10:05:52 pm »


Are the drivers provided by NXP for the RT family better than this?

Some differences, IDE is MCUXpresso (Eclipse based IDE) which support most debug probes (jlink, opensda, pemicro etc...).
You have config tool for pinmux and clock, much like CubeMX, which spit out C code compatible with SDK. You can even do peripheral code but I haven't used it.

Software is into SDK, with drivers, middleware (rtos, tcpip stack, usb stack) and a lot of examples. One SDK per part.

All SDK share the same structure, the same drivers API (where possible), so moving through parts is easy, given the parts support the same SDK family (not always the case, especially with old and deprecated parts).
 

Online ali_asadzadeh

  • Frequent Contributor
  • **
  • Posts: 547
  • Country: ir
    • ASiD Designer
Re: i.MX RT 600
« Reply #14 on: October 18, 2018, 02:24:21 am »
How does RT600 compares to XMOS parts? any Ideas?
You can order parts from www.ASiDesigner.com
we are a wire-based company
 

Online Berni

  • Super Contributor
  • ***
  • Posts: 1501
  • Country: si
Re: i.MX RT 600
« Reply #15 on: October 18, 2018, 04:32:04 pm »
The problem with XMOS is that its hard to find suitable applications for it. They market them as being 32 core microcontrollers but its actually a 4 core microcontroller with 8 threads on each core (And you need to use at least 4 threads per core to get the full MIPS speed on that core). Additionally each core lives in its own memory space with its 256KB of RAM (This used to be only 64K). That sounds like a decent amount of on chip memory right? Well... there is no flash so this RAM has to hold all of your program code too, and there are no external memory interfaces so expanding this memory is not possible. The impressive MIPS number and single cycle execution does give it significantly more processing grunt than ARM MCUs, but there is no hardware floating point and because you have no peripherals you often have to dedicate cores for bitbanging (using serdes on pins) of things like UART, SPI, I2S etc so a few 100s of MIPS will be lost to IO tasks.

So in the end the XMOS chip is in an awkward position standing on the border where the lands of MCUs, DSPs and FPGAs intersect. Its a fast MCU with limited memory size, its a DSP with no float and a not hugely impressive MMACs spec, its a FPGA that can run weird exotic interfaces but only at speeds under about 50MHz and limited complexity. XMOS has a lot of cool things that nobody else does, but ends up being limiting in annoying ways.

So for most applications in think the RT600 makes more sense.
 
The following users thanked this post: ali_asadzadeh, ogden

Online ali_asadzadeh

  • Frequent Contributor
  • **
  • Posts: 547
  • Country: ir
    • ASiD Designer
Re: i.MX RT 600
« Reply #16 on: October 18, 2018, 08:57:50 pm »
Thanks :)

I think the main  i.MX RT 600 draw back is the lack of Ethernet Controller, and maybe the LCD controller and External Memory controller.
You can order parts from www.ASiDesigner.com
we are a wire-based company
 

Offline blueskull

  • Supporter
  • ****
  • Posts: 10197
  • Country: cn
  • Power Electronics Guy
Re: i.MX RT 600
« Reply #17 on: October 19, 2018, 02:35:38 am »
Thanks :)

I think the main  i.MX RT 600 draw back is the lack of Ethernet Controller, and maybe the LCD controller and External Memory controller.

Ethernet and LCD are high level features -- you won't be able to get them to work without an OS or a huge amount of effort.

FreeRTOS is fine, but a bit notch up to Linux won't hurt, especially considering Linux can be boot in less than 2 seconds on iMX6ULL @ 528MHz (heavily stripped U-boot and Kernel with custom init scripts), which is not bad for a GUI application.

If you really need instant live on power up with Ethernet, you better go with an industrial MCU, instead of an MPU.

EMIF is a huge pain. You only use it when you have to use it. If so, why not go with a Cortex-A which is very cheap (iMX6ULL) and has faster core speed and NEON-based SIMD?
SIGSEGV is inevitable if you try to talk more than you know. If I say gibberish, keep in mind that my license plate is SIGSEGV.
 

Online technix

  • Super Contributor
  • ***
  • Posts: 2782
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: i.MX RT 600
« Reply #18 on: October 19, 2018, 03:42:26 am »
Thanks :)

I think the main  i.MX RT 600 draw back is the lack of Ethernet Controller, and maybe the LCD controller and External Memory controller.

Ethernet and LCD are high level features -- you won't be able to get them to work without an OS or a huge amount of effort.

FreeRTOS is fine, but a bit notch up to Linux won't hurt, especially considering Linux can be boot in less than 2 seconds on iMX6ULL @ 528MHz (heavily stripped U-boot and Kernel with custom init scripts), which is not bad for a GUI application.

If you really need instant live on power up with Ethernet, you better go with an industrial MCU, instead of an MPU.

EMIF is a huge pain. You only use it when you have to use it. If so, why not go with a Cortex-A which is very cheap (iMX6ULL) and has faster core speed and NEON-based SIMD?
I was a bit confused at people shoehorning LCD and Ethernet into a MCU, be it i.MX RT or STM32F7. I always thought at that price point it is cheaper and easier to develop with V3s + 64MB SPI NOR/256MB SPI NAND/16GB eMMC or something. V3s is even cheaper than iMX6ULL, and comes with built-in 64MB DDR2. Or if 64MB wasn't enough (which you really shouldn't have used those Cortex-M7 by this point) a slight step up to A13 which can go up to 512MB DDR3 while still cheaper.
 

Offline blueskull

  • Supporter
  • ****
  • Posts: 10197
  • Country: cn
  • Power Electronics Guy
Re: i.MX RT 600
« Reply #19 on: October 19, 2018, 05:17:21 am »
I always thought at that price point it is cheaper and easier to develop with V3s + 64MB SPI NOR/256MB SPI NAND/16GB eMMC or something.

I seriously considered V3s before, but I have no idea when will that cease to produce. If I make a low volume, high added value design, I'd like to keep it in production for as long as possible.

I would rather use a $25 Ovtavo module than a V3s for that reason.
SIGSEGV is inevitable if you try to talk more than you know. If I say gibberish, keep in mind that my license plate is SIGSEGV.
 

Online Berni

  • Super Contributor
  • ***
  • Posts: 1501
  • Country: si
Re: i.MX RT 600
« Reply #20 on: October 19, 2018, 05:18:02 am »
We use STM32 MCUs with LCD and external memory a lot at work so i don't see why that would be a Linux thing.

External memory is pretty easy to use on a MCU. Just set up the memory controller for the kind of RAM chip you have and suddenly the RAM is part of your memory map. The LCD controller is also very useful because a lot of displays that are QVGA(320x240) resolution and up have a RGB interface, you just set up the LCD controller and give it a pointer to your framebuffer in RAM and wouala its showing it on the display without any CPU intervention. We have a STM32F7 running a 640x480 display just fine (it does have hardware bitblt DMA too), sure you don't have the horsepower to do fancy smooth animated menus at such a resolutions (Especially since the rest of your app also needs some CPU time and RAM bandwith), but it can still draw a nice looking UI at a decent speed once things are optimized enough. All of it running in C without a real Linux like OS while sipping so little power it can run for an entire day continuously(Including the LCD) from a smartphone battery.

I also dealt with some Ethernet on a STM32H7. Once you get lwip running on it you got most things taken care of. Also due to the pretty optimized "zero copy" nature of lwip combined with a DMA shoveling traffic trough the ethernet controller you can saturate a full duplex 100 Mbit ethernet link with ease(It doesn't support gigabit PHYs). Okay you sure as heck won't be running a PHP webserver on this, but you can certainly fetch webpages, send emails, stream audio or just generally send large amounts of data to something on a network.

Linux is not always the right tool for the job. It certainly is great for any kind of complex device, but a god damn multimeter really does not need Windows CE and a 1 minute boot time!
 

Online technix

  • Super Contributor
  • ***
  • Posts: 2782
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: i.MX RT 600
« Reply #21 on: October 19, 2018, 04:43:16 pm »
I always thought at that price point it is cheaper and easier to develop with V3s + 64MB SPI NOR/256MB SPI NAND/16GB eMMC or something.

I seriously considered V3s before, but I have no idea when will that cease to produce. If I make a low volume, high added value design, I'd like to keep it in production for as long as possible.

I would rather use a $25 Ovtavo module than a V3s for that reason.
That was my point investigating Linux on PIC32MZ DA, as it is also a TQFP chip with built-in DDR DRAM. For me the Octavo parts seem like unobtanium and expensive, and the equivalent would be V3s, PIC32MZ2064DAG176 and ATSAMA5D27C-D1G-CU.
 

Online ali_asadzadeh

  • Frequent Contributor
  • **
  • Posts: 547
  • Country: ir
    • ASiD Designer
Re: i.MX RT 600
« Reply #22 on: October 21, 2018, 02:09:56 am »
Ethernet is an industrial Port! we use it every where, since 50+MHz MCU's we have it! I have done very nice and cool things with LPC1768@100Mhz including some Impress JS and JSON, Also Smaller size LCD's can be very beneficial,So why not! they are every where and At least in our company most of us hate Linux to play with. ^-^ ^-^ ^-^
You can order parts from www.ASiDesigner.com
we are a wire-based company
 

Online ali_asadzadeh

  • Frequent Contributor
  • **
  • Posts: 547
  • Country: ir
    • ASiD Designer
Re: i.MX RT 600
« Reply #23 on: October 23, 2018, 08:02:26 am »
Is there any Price info available?
You can order parts from www.ASiDesigner.com
we are a wire-based company
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf