How easy is it to develop with Renesas RX micros? - Page 1
Forum section: electronics / general

author: splin
author_rank: Frequent Contributor
timestamp: May 22, 2020, 03:48:58 pm
content: In another thread PCB.Wiz drew my attention to the RX23E 32 bit micros with 24bit ADCs that look interesting. I was under the impression that Renesas were only interested in large OEMs, especially the automotive sector rather than the hobby/SME arena and thus development tools were expensive and support limited or non-existent.But perhaps I've got this wrong as I see they do a low cost (£23) target board with debugger and emulation support:https://www.mouser.co.uk/ProductDetail/Renesas-Electronics/RTK5RX2310C00000BR?qs=%2Fha2pyFaduj9MlX0bOXgQ%2FBzc98Ddjs%2FXZ04L64K5Qs=There is an Eclipse based IDE, e2studio which supports the GNU compiler which is promising and there are support forums.They also have a range of stand-alone debuggers ranging from an £53 E2 emuator to the £897 E20 emulator with instruction trace.But just because they are available doesn't mean they are any good. Flakey/unreliable emulators in particular are not uncommon. So has anyone developed with RX micros and used e2studio? What was the experience like compared to say using STM's tools and development boards?

author: rsjsouza
author_rank: Super Contributor
timestamp: May 22, 2020, 04:27:10 pm
content: I don't know about today, but 2~3 years ago I tried to work with one of their boards but was not considered important enough to get any kind of support. At that time I then moved to greener pastures.

author: andersm
author_rank: Super Contributor
timestamp: May 22, 2020, 05:24:08 pm
content: I don't remember running into too many issues. Segger also support the RX line, some of the Renesas boards have on-board J-Link interfaces (I haven't used that combination personally). Renesas unfortunately seem to treat their debug interfaces as some kind of state secrets, do don't expect to see them supported in OpenOCD any time soon.E2 Studio is Eclipse with some plugins. If you don't like Eclipse you won't like E2 Studio either. The GCC distro isn't by Renesas, instead they contract third parties to provide them. They recently updated the base compiler from GCC 4.8 to 8.3. If you're the type to whine about ST's middleware, you're going to whine about Renesas' middleware too.

author: filssavi
author_rank: Frequent Contributor
timestamp: May 22, 2020, 05:32:24 pm
content: I used them few years ago for a uni assignment...AFAICT they were alright, not amazing, not terribleThe peripherals are the same as either 8 or 16 bit older chips, so good if you have a lot of renesas code, not great otherwiseOverall I would give them a 7.5 out of 10

author: free_electron
author_rank: Super Contributor
timestamp: May 22, 2020, 05:37:11 pm
content: analog devices also has microcontrollers with high bit count adc.

author: rsjsouza
author_rank: Super Contributor
timestamp: May 22, 2020, 07:41:12 pm
content: Quote from: free_electron on May 22, 2020, 05:37:11 pmThat reminded me... It may not be your cup of tea, but MSP430 (16-bit) has 24-bit ΔΣ ADCs as well.

author: splin
author_rank: Frequent Contributor
timestamp: May 22, 2020, 10:32:09 pm
content: Thanks, for all the helpful responses; it seems like it may be worth trying it out.Quote from: free_electron on May 22, 2020, 05:37:11 pmThanks. I had a quick look at theADC7061ADuC7061- $4.3 @ 1K from cheapest distributer compared to$1.57 for the R5F523T5ADFL#30 Wrong part - the R5F523E5ADFL#30 is the cheapest part with the 24b ADCs costing $7.33. It has much less memory (32K Flash, 4K RAM v 128K/16K) and the ADCs are noisier (20.2 bits @ 50Hz output data rate v 22.4).A major fail in the datasheet is that the integral linearity isn't properly specified - it only provides a typical +/-15ppm figure and only for a PGA gain of 4. WTF? Does Analog expect all it's customers to have to characterise the devices themselves over time/temperature/batchs etc. to determine the worst case numbers and the typical values given there's a very good chance that you won't be using a PGA gain of 4. This is especially bad as INL at these levels is very hard to measure especially if you don't have the design details of the ADC.INL might not be too important in many applications but they do call this part a 'Precision Analog Microcontroller'.Quote from: rsjsouza on May 22, 2020, 07:41:12 pmThe SD24 ADCs are much noisier than the Renesas specs - 15.1 bits ENOB at 4k SPS compared to 19.4 and have INL max of 30ppm compared to 15ppm. They are at lot cheaper at $0.78 though.The Ti documentation is very annoying - nowhere (that I could find) in either the MSP430i202x datasheet, or the Family User's Guide could I find out what the actual ADC data rate is - the datasheet doesn't specify the sampling rate used for the performance characteristic - only the oversampling ratio. I had to read a metering application note to find that an OSR of 256 with a 1.048576MHz clock gives 4096 SPS.

author: rsjsouza
author_rank: Super Contributor
timestamp: May 23, 2020, 01:40:38 pm
content: Quote from: splin on May 22, 2020, 10:32:09 pmUnless I missed something, the part number you mentioned has only 12bit ADChttps://www.renesas.com/us/en/products/microcontrollers-microprocessors/rx/rx200/rx23t/device/R5F523T5ADFL.htmlCan you somehow associate two channels to get added precision? (I have never seen that nor dove into the documentation to learn more)Quote from: splin on May 22, 2020, 10:32:09 pmCan the Renesas get 19.4 at 4kSPS? That is quite impressive; I'll have to take a look.Quote from: splin on May 22, 2020, 10:32:09 pmYou can find the information in the technical manual by reading the entire operation mode, etc. but you are correct - the speed specification is nowhere to be found.

author: RABeng224
author_rank: Contributor
timestamp: May 23, 2020, 03:29:05 pm
content: We use Renesas almost exclusively. They’ve really stepped up their game in the last couple years. Their homegrown CC-RX compiler is very good and is free with memory restrictions. Also the new emulators (E2 lite) are much more affordable than what was previously offered. Our biggest grip was their chip configuration and driver code tools. Their chips are very flexible which makes them complex to setup (setting up a “simple” DMA transaction is anything but simple). However, they have finally combined the Smart Configurator (pin/ peripheral setup) tool and the FIT modules (driver/library code). Now it is trivial to setup a project and get running, even a FreeRTOS version.This is all specific to the RX line. I cannot comment on the RA or Synergy lines. We also use the RL78 line a lot, but only the CC-RL compiler is good. The Appliet tool (pin/peripheral generator) is nice but the resultant code that is generates is horrid and is only good for a “get running quick” demo.They are the defacto standard micros used in motor control and automotive applications. They are extremely robust chips and have longevity. However, because they offer an insane amount of memory and pin configurations (can be hundreds of SKUs for just a single RXn line) lead times & availability can be all over the place ( no joke was quoted 28 week lead time once).

author: 0xdeadbeef
author_rank: Super Contributor
timestamp: May 23, 2020, 03:54:49 pm
content: Personally, I wouldn't touch Renesas micros with a ten foot pole. I have to work with the R850 family at work and we stumble over design flaws, lack of documentation and weird company philosophy all the time. Like there are no errata sheets since Japanese engineers obviously rather commit seppuku than to document errata. You can't even read out the CPU identifier unless you sign an NDA to get access to the debug manual.There are unbelievable flaws in the register protections mechanism which makes them somewhat pointless, weird/unusable FIFO implementations, lack of DMA requests for certain peripherals. Even the default interrupt system makes it impossible to use an OS so you need to use some kind of SW mode which makes performance counters useless etc. The Lauterbach Aurora debugging shows weird behavior like even writing a single byte seems to stop the CPU for a short time.It feels like this is their first attempt to create an embedded microcontroller. Then again, I worked with a Hitachi SH7055 (which was some kind of predecessor) about 21 years ago and it was ahead of its time in several ways. Something must have gone terribly wrong since then.

author: SiliconWizard
author_rank: Super Contributor
timestamp: May 23, 2020, 04:43:15 pm
content: Hitachi CPUs were pretty good.I've never worked with any Renesas product. Sad if it has gone downhill.

author: nctnico
author_rank: Super Contributor
timestamp: May 23, 2020, 04:49:37 pm
content: Quote from: SiliconWizard on May 23, 2020, 04:43:15 pmYes, but even back then you'd had to jump through hoops to get access to basic stuff like firmware protection mechanisms. And that also included getting very expensive programming hardware.

author: Ero-Shan
author_rank: Frequent Contributor
timestamp: May 23, 2020, 06:16:27 pm
content: At work, we use Renesas RX210 and RX231 MCUs. Coming from 68HC11 and M16C, they were a huge step up. (Our products have a very small power budget, so the clock frequencies are far from what the chip allows. But they are really performant.)The critique about their secrecy is well deserved. And the documentation is - Japanese in english. Very stilted, lots of words instead of a few lines of example code. Quite often, I don't understand their prosa and just experiment a bit until I grok it.AFAIK, the RX line is a descendant of the Hitachi processors.The IAR compiler produces pretty good code. GCC code is OK starting with version 9 (older ones inflate the code with gratuitous and fanciful NOPs). One thing to watch out: gcc allocates bitfields from MSB to LSB, the Renesas headers assume LSB to MSB. Took me quite a while until I found that out!And theydopublish errata.They're probably not the best choice for hobbyists, but I really like them.

author: andersm
author_rank: Super Contributor
timestamp: May 23, 2020, 06:19:25 pm
content: Quote from: 0xdeadbeef on May 23, 2020, 03:54:49 pmI think we've discussed this some time before, but there's really no connection between the V850 (NEC) and SuperH (Hitachi). The RX series shares some peripherals with the H8S/H8SX series, also from Hitachi, so I assume there's more of a lineage there.

author: splin
author_rank: Frequent Contributor
timestamp: May 23, 2020, 06:37:04 pm
content: Quote from: rsjsouza on May 23, 2020, 01:40:38 pmYour right - I was actually looking at the R5F523E5ADFL#30 datasheet:https://www.renesas.com/eu/en/doc/products/mpumcu/doc/rx_family/001/r01ds0330ej0100-rx23e-a.pdfUnfortunately the cheapest RX23E-A part is $7.33 which makes it rather less interesting. The 24b ADC specs are pretty good however:Quote12b ADC + 12bADC = 12 1/2b ADCQuoteActually it probably do even better than that - all the noise specs are with a 2.5V reference, probably because it has an internal 2.5V reference which is the most likey use case, but it can use a 5V external reference so add one extra bit to all the values in the above table!The specs are impressive but the datasheet doesn't specify the filter settling time. It has a SINC3 filter so the fully settled data rate is likely 1/3 the data rate shown in the above table, which is important for multiplexed applications. Unfortunately, at $7.33 it's much less interesting than when I thought it was < $2.The dual ADC ADS1292 for example is $4.09 and has very similar noise performance. Coupled with a <$2 STM32 or similar gets the same or better performance without all the hassle of learning a new processor with its unique quirks and foibles, instruction set, development tools etc.

author: 0xdeadbeef
author_rank: Super Contributor
timestamp: May 23, 2020, 06:48:09 pm
content: Quote from: Ero-Shan on May 23, 2020, 06:16:27 pmTrue, forgot about that: they should hire English native speakers to proof-read almost all of their documentation. Indeed, grammar and style are partly horrible.Quote from: Ero-Shan on May 23, 2020, 06:16:27 pmThis reminds me that the headers for the peripherals were all done the wrong way. Instead of using macros for the actual peripheral definitions, they used initialized variables and trusted that the compiler would remove these due to optimization. Which it didn't always. This caused a lot of issues (due to our mapping not expecting variables etc.) and debugging efforts until they finally agreed to fix the headers.Besides, they seem to refuse to take over responsibility for their headers to be used in production. Which is somewhat ridiculous.Quote from: Ero-Shan on May 23, 2020, 06:16:27 pmNot for the RH850 CPUs we're using. They are only publishing errata for IP from other folks (like Bosch). Their own flaws are hidden in "specification updates" and Power Point presentations, but not in industry grade errata sheets.

author: SiliconWizard
author_rank: Super Contributor
timestamp: May 23, 2020, 06:51:33 pm
content: Quote from: nctnico on May 23, 2020, 04:49:37 pmYes, overall that was pretty expensive.

author: JPortici
author_rank: Super Contributor
timestamp: May 24, 2020, 04:37:26 am
content: Quote from: Ero-Shan on May 23, 2020, 06:16:27 pmjesus christ.why they never fixed that? all the gcc versions i use, for MCU or windows assume LSB to MSB bitfields.How are you nor going insane using bitfields?

author: Ero-Shan
author_rank: Frequent Contributor
timestamp: May 25, 2020, 07:11:08 am
content: Quote from: JPortici on May 24, 2020, 04:37:26 amSorry, my fault - its just the other way round!So, the blame goes to Renesas (and me). IAR offers a #pragma to set the bitfield allocation direction. Alas, gcc doesn't provide an __attribute__().@0xdeadbeef:Doesn't Intel call their errata also 'specification updates'? Phony, but as long as they do document them under any name, I'm okay.

author: rf-fil
author_rank: Regular Contributor
timestamp: May 25, 2020, 11:46:21 am
content: I am literally right now writing some firmware on one of the smaller RX family chips. I've spent about a year or so using this MCU. The documentation is unintelligible in many places. I could not get their I2C peripheral working and went back to bit banging. Bit banging: few hundred lines of code and 100% bullet proof. There is no good DMA for some of the peripherals where you'd want it. The way to implement the in-app firmware upgrade / bootloader is horrible. The unique chip ID is not accessible unless you load your code to RAM, and run from there to read it back. Their own support code / framework / drivers are as bad as every other MCU manufacturer. They all seem to employ year 1 summer interns to write their code. It is not production quality code. Eventually, it's sort of OK and my code works ok, but it's really not worth the effort. I've previously spent a few years, professionally, with another MCU family, which wasn't nearly as bad. None of the micros are perfect once you get to know them well enough, but I'd suggest to stay away from Renesas RX. They have an obscure neat feature which was why my predecessors at my current place of employment chose it, but that was years ago. There's no particular advantage or reason to use these nowadays. Basically, they get out-performed on every metric. For hobbyists or learning, I'd suggest to pick something popular. Their lead times have been pretty bad as well, if you are looking to productize./rant (disgruntled firmware guy, LOL)

author: 0xdeadbeef
author_rank: Super Contributor
timestamp: May 25, 2020, 01:35:51 pm
content: Quote from: Ero-Shan on May 25, 2020, 07:11:08 amThis might be true for their desktop CPUs but theydohave errata sheet for their more embedded offerings. Anyway, Intel isn't really a big player in the embedded microcontroller market.From what I can tell, errata sheets which list and describe all errata of a certain revision of a specific microcontroller derivate are an industry standard since you need to be able to check which errata could affect you in a production lot. At least for Freescale (when they still existed), NXP, Microchip (including formel Atmel) and Infineon microcontrollers, you can download errata sheets from the according websites.

author: JPortici
author_rank: Super Contributor
timestamp: May 25, 2020, 02:45:31 pm
content: Quote from: Ero-Shan on May 25, 2020, 07:11:08 amstill, though.*AFAIK gcc also has a pragma for bitfield order but it could be "version defined". for example, Microchip's XC16 and XC32, which are GCC, do NOT have this option, but the manual states under the "implementation defined behaviour" section which is the order of bits in bitfields(Interestingly , though in XC16 they are "from least significant to most significant" whereas in XC32 they are "from left to right" which i think means the opposite)*Moment of self flagellation: I Am currently working on a device which has an 8-way dipswitch to define user settings.The dipswitch has "switch 1" on the left, the way it's read "switch 1" is the LSB so i had to reverse the reading (yuk) in order to have a logical correspondence between the positions and the settings word.It would be fine-ish if it wasn't that ONE of the options is multi-bit so those bits in have to be reversed again.I think i dun goofed badly on this and deserve to be lashed.. as did those guys at renesas apparently

author: SiliconWizard
author_rank: Super Contributor
timestamp: May 25, 2020, 02:49:02 pm
content: The C standard states:Quote

author: andersm
author_rank: Super Contributor
timestamp: May 25, 2020, 04:36:17 pm
content: The order would be specified by the platform ABI. The Renesas headers we're using have duplicate definitions of all registers, for big and little endian. Not that it matters, because no-one should ever use bit fields for hardware registers.

author: 0xdeadbeef
author_rank: Super Contributor
timestamp: May 25, 2020, 05:17:56 pm
content: Quote from: andersm on May 25, 2020, 04:36:17 pmSo true. Unfortunately, nobody seems to care anymore.

author: ajb
author_rank: Super Contributor
timestamp: May 25, 2020, 08:56:30 pm
content: Quote from: andersm on May 25, 2020, 04:36:17 pmReally? That's ridiculous. One of the first rules of pragmatic programming is "Don't Repeat Yourself", and the worst possible way to violate that rule is repeating yourself in a slightly but critically different way.Quote from: 0xdeadbeef on May 25, 2020, 05:17:56 pmYes, it's one of those things that's sort of nice syntactically for single bits, but really not worth the trouble and potential issues. Also annoying when they'r'e declared in such a way that you have to tack ".reg" onto the end of every single register access if you're not using the bitfields.

author: andersm
author_rank: Super Contributor
timestamp: May 26, 2020, 04:44:40 am
content: Quote from: ajb on May 25, 2020, 08:56:30 pmFrom the CPU's POV, the layout of the registers changes depending on endianness, so there's no much choice. To be clear, each bitfield definition contains an "#ifdef __RX_ENDIAN__BIG__ #else #endif" pattern, they don't duplicate the outer "struct" part.

author: ajb
author_rank: Super Contributor
timestamp: May 26, 2020, 06:32:59 pm
content: Quote from: andersm on May 26, 2020, 04:44:40 amOOOOoooh, the CPU can be switched, got it. From the context I was under the impression that it was to support toolchains with different (or switchable) conventions for bitfields.Switchable endianness seems like a rather expensive feature for limited benefit--maybe a couple of hardware instructions for swapping bytes would have been better and more flexible?

author: andersm
author_rank: Super Contributor
timestamp: May 26, 2020, 09:02:24 pm
content: Quote from: ajb on May 26, 2020, 06:32:59 pmI suspect it's a backwards compatibility feature, the H8 series and older SuperH were big-endian. It's a bit quirky in that code is always little-endian, but data endianness is configurable via an option bit.

author: 0xdeadbeef
author_rank: Super Contributor
timestamp: May 26, 2020, 10:55:36 pm
content: I wouldn't trust switchable endianess. The earlier Motorola/Freescale/NXP eSys controllers with PowerPC core had this features but it was so bug ridden that it was finally removed.On a somewhat related note, Motorola also counted the bits the other way round, so the least significant bit in a 32bit register was 31. Even worse, some cores also existed as 64bit versions with some peripherals and buses being also 64bit wide, but only the "lower" 32bit were implemented on a 32bit core. So some 32bit registers were counted from 63 (LSB) to 32 (MSB). Now ifthatisn't confusing.

author: andersm
author_rank: Super Contributor
timestamp: May 27, 2020, 04:55:06 am
content: Quote from: 0xdeadbeef on May 26, 2020, 10:55:36 pmPowerPC implemented little-endian by XORing the LSBs of the address, which doesn't work as expected with unaligned data. That's not an issue with the RX implementation.