I voted no.

The processor peripherals are interesting but it uses a proprietary core supported by expensive Renesas development tools.

The competition (based on ARM M cores) is widely supported by free, paid for (cheap or expensive) and open source tools. The same tools and debug interfaces can be employed on chips from many different sources.

So it comes to  - is the price keen enough and the analogue front end good enough to put up with these disadvanatages - which could only ever be the case for mass production or very special low volume projects.

The on chip ADC is nothing special (ADCs with much better performance are readily available and easy enough to interface) and the chips are not that cheap (in small quantities).

So I conclude that the Roadtest is only interesting for its entertainment value or if the tester can make use of it in a one off special project.

MK

I voted no.

The processor peripherals are interesting but it uses a proprietary core supported by expensive Renesas development tools.

The competition (based on ARM M cores) is widely supported by free, paid for (cheap or expensive) and open source tools. The same tools and debug interfaces can be employed on chips from many different sources.

So it comes to  - is the price keen enough and the analogue front end good enough to put up with these disadvanatages - which could only ever be the case for mass production or very special low volume projects.

The on chip ADC is nothing special (ADCs with much better performance are readily available and easy enough to interface) and the chips are not that cheap (in small quantities).

So I conclude that the Roadtest is only interesting for its entertainment value or if the tester can make use of it in a one off special project.

MK

I partialy agree with properietary core notice but disagree with adc note. Proprietary core can have benefits like better DSP/FPU instrctions in comparison with standard ARM Cores which could be very benefical and beat the disadvatages in aplications targeting analog base dapplications which this MUC targets. I did not study details of RXv2 instruction set and cannot objectively compare but I do not conider it bad by default.

Also Renesas provide port of GCC for their RX family. jancumps know more information about it and If I remember correctly he mentioned some restrictions like that some example projects are hard to compile with free GCC and crypto accelerator is impossible to use, but generaly it should be possible to develop for this MCU for free at least in a limited way.

I totaly disagree with ADC notice. Very few MCU has so advanced analog circuit integrated in MCU. I agree that many MUCs have ADCs with comparably high resolution but this has many other features like PGAs and constant current sources for using with resistive sensors which this MCU targets. See analog block on block diagram in product brief:

When I took in account all its analog features then it is quite a unique ADC peripheral and I do not know many other MCUs integrating all these. The only other MCU which has similar peripherial and I know about it is new MAX32675. Can you show any other MCU haivng this advanced ADC?

I was mainly suggesting that it would usually be better to use an ARM M type micro with an external converter unless the planned production volume was very high.

And if you are planning serious volume production a RoadTest of a £255 board isn't a very exciting prospect.

If you actually have a use for the special features of the part and the board - great.

We were asked if we would apply for the RoadTest, and I assumed that reasons would be helpful.

MK

misaz said:

Also Renesas provide port of GCC for their RX family. jancumps know more information about it and If I remember correctly he mentioned some restrictions like that some example projects are hard to compile with free GCC and crypto accelerator is impossible to use, but generaly it should be possible to develop for this MCU for free at least in a limited way.

That was for the RX65 member of the RX proprietary core:

• Generic examples were easy to switch to GCC
• Examples where you had to modify linker scripts (to reserve big areas of memory for display buffers) were somewhat harder, because the Renesas toolchain has a very different memory map / linker way of working. But doable. see  Renesas RX65 Envision Kit - part 12: RAM Use with GCC ToolChain and Renesas RX65 Envision Kit - part 10: Reserve LCD Frame Buffer in Expansion RAM with GCC.
• Examples that used FAT and encryption were not portable at the time, because only provided as Renesas toolchain precompiled blobs. See  Renesas RX65 Envision Kit - part 3: Port an example from Renesas toolchain to GCC .
  This has now somewhat changed: Renesas customers that use the GCC toolchain can now request the crypto source code: www.renesas.com/.../crypto-library. 
  
  

  Obtaining the product
  We will provide the product to customers who will be adopting or plan to adopt a Renesas microcontroller. Please contact your local Renesas Electronics sales office or distributor.