RoadTest: Renesas RX65N MCU EV Kit
Author: Andrew J
Creation date:
Evaluation Type: Development Boards & Tools
Did you receive all parts the manufacturer stated would be included in the package?: True
What other parts do you consider comparable to this product?: Other MCU development boards with LEDs; Arduino
What were the biggest problems encountered?: User Fit Parts: The board is designed to be extended with tested parts that a User can fit. Two of these are obsolete, and one of those is an extremely unusual pin configuration - if they'd used a more common one it might have been possible to source alternatives. Of the remaining parts, two I could only source from the US (using reputable suppliers.) Renesas has no response to this and have made no attempt to issue an advisory note or other information to help customers. The board itself is only 2 years old as far as I can tell and I'm surprised the parts have become obsolete so quickly. I expected better. Related to User Fit parts, removal of the LCD so that the parts can be added to the board was a lot more difficult than it ought to have been. Through-hole parts will potentially short out to the bottom of the LCD so care must be taken there as well. I couldn't get two of the Firmware Integration Technology (FIT) modules to work. These are used to integrate to features on the board without having to write realms of code yourself. It's likely they were not configuring themselves properly based on experience of a bug in the Serial Communications Interface FIT module (covered below.)
Detailed Review:
The Envision board is positioned as a kit to allow the easy evaluation of the RX65N MCU, which in turn is positioned as a choice for HMI (Human Machine Interface) designs. Their examples are car displays, white goods (e.g. washing machine panels) and so on. To enable this evaluation, the board comes with a 480x272 pixel TFT-LCD with an integrated touch controller and 2d drawing engine and a built-in debugger (e2lite.) Provision is also made for customers to use Segger emWin GUI software as well - a set of development tools/API to allow for easy UI development.
The specs for the board can be read on-line but to summarise:
Given its positioning, my road test is to take this board and develop an HMI utilising key elements of the board, MCU and development tools Renesas offer. The board comes with Arduino headers, arranged as for a UNO, plus a large LCD, so it’s easy to see that it might be picked up by hobbyists for inclusion in their own projects and not just by industry in the development of prototypes.
Specifically, it would allow me to make an assessment of the ease of developing such an interface against more popular products such as Arduino. The board and MCU are not positioned or marketed as an alternative to Arduino so my intention is not to actually draw conclusions on that basis - it would be unfair - but to take a view on the ease of prototyping with the board.
I documented the progress of this development across a number of individual blog entries, which are linked and summarised below - essentially, it’s a road trip to the final result. I tried to summarise my findings at the start of each post as I know a lot of readers will be less interested in this and more interested in a technical coverage. Jan Crump’s road test complements this one in such a way and is well worth reading; indeed some of his testing took a slightly different approach to reach the same result. There was a great exchange of messages between us and I’d like to thank him for his input on a number of occasions.
Pin 1 is identified: can you tell me which one it is? Quiz not open to other road testers!
The board is well packaged and comes with a USB cable which I know is a little thing in-and-of itself but I never seem to have one to hand with the right connector when I need it. The construction quality looks to be excellent and I couldn’t see any bad soldering and there are no bodge connections. I had a number of expectations in terms of being provided enough information to get going and prove that the board wasn’t DOA without having to track down that information. The provided quick start guide, pre-loaded demo apps and large, bright LCD met those expectations and overall, I was left with a positive impression of the package right from the start.
I’m looking here at getting to grips with the Envision kit and a background to the RX65N MCU. It should be easy to update the firmware of the board and find information related to both its operation and capability.
I’m impressed with the approach to Firmware updating and the resources provided to support people new to the platform or MCU development in general is very useful. Specifically, the dual-bank flash memory allows a new firmware to be uploaded to the not-in-use bank and the board swapped over; if it fails, it can be rolled-back to the known, good version. This is a great way of avoiding ‘bricking’ the board - it does require the firmware to be developed to support the dual-bank feature.
Here, I take a look at the development tools, helpers and utilities to develop for the MCU.
It makes great sense to use an existing open-source tool to base your IDE on as it is widely supported and has a range of plugins. It took a little while to get a sample program up-and-running and it does require delving into the configuration to get them working giving the specifics of my install. However, the information provided has been sufficient to work through issues and get a program running under the debugger. The overall environment for developing and debugging I found to be excellent and I was able to find my way around easily enough (I’m not an experienced C developer or Eclipse user)
At this point in the road test, it became worthwhile to create some short notes about very specific items that were worth drawing attention to.
As I go through the features of the development toolset, I remain impressed with the support Renesas has provided to help. The Smart Configurator is really the backbone of development for the RX MCU family and it does a lot of heavy-lifting. Essentially, it’s a configuration wizard that gives access to software modules called Firmware Integration Technology (FIT) modules and the Ports, Pins and built-in timers that the MCU has. Some of the FIT modules are self-configuring others have additional wizards to configure: I have found them all intuitive to use. Selecting the modules and configuring as necessary, also sets up the right ports and pins for use, or at least makes a reasonable choice - in some cases, depending on the application, the port/pin choice has to be changed. They are extremely useful and I can’t imagine why anyone would choose not to use them (of course, there are die-hards creating samples that become a lot harder to use because they haven’t used the Smart Configurator.) With my first usage of it I developed an interrupt driven application with only around 10 lines of handwritten code.
As time went on, like the documentation, I became a lot more tuned-in to how this worked and what was expected.
Here, I have an issue and I’m vacillating in what to say: on the one-hand its a small part of the product but on the other, the Envision board is still being sold and marketed (Farnell in the UK still have it flagged as a ‘new’ product although it’s not that new now) with the ability to extend its functionality with Ethernet, SD Card, various headers and Joystick. Two of the parts are obsolete and two are US ship only (from reliable vendors.) What I find most annoying is that the board was only released in September 2017 (based on document dates) and is still in production with no notification that the user fit parts can’t be. I have to ask whether or not these parts were flagged as ‘not for new designs’ or ‘obsolete’ at the time - I have no empirical experience on the amount of notice that manufacturers give on obsolescence to know if I’m being unfair on Renesas. However, I do take umbrage that Renesas haven’t looked at suitable alternatives as an advisory note as I wasn’t the only person looking for these - there’s nothing reflected back in the board’s user guide which still lists the old parts. I had intended to use the SD card as part of the road test and was advised to look harder and further afield.
The SD card is an unusual 13+2 pin configuration rather than one that is more common and I couldn’t find any suitable alternative. If an SD card was definitely required for your prototype, this is not the product for you; I expect that if you were really interested in a joystick that could be sourced.
I am using emWin to develop my app and this is just a brief post on downloading and getting it running. It mostly went to plan but was frustrating as there is no information for getting this working with the MCU. I’ve come to expect that the Toolchain won’t be right as versions change and I wouldn’t expect samples to be kept unto date in that respect, but it proved tricky to get a base application working that would just do the standard ‘hello world’. I gave up in the end and adapted a sample created by someone else that I found on a forum post. I did, ultimately, find out what was wrong with my version of the base application (memory allocation was incorrect) but I do feel it was harder than it ought to be. Apparently the sample that comes as part of the download specifically for the Envision board is not a good place to be starting from when creating your own emWin applications - this is according to a Renesas forum moderator - but there is nothing else!
I should note here, that once I got past this initial experience I was really impressed with how easy it was to get GUIs created and working using emWin: it’s a great addition to the board and it has features that seem geared towards low-ram MCUs.
(at this stage of the process I was wondering what on Earth the board designer was thinking about!)
This was a lot more difficult than it ought to have been really, given that the removal is a requirement for most (but not all) of the User Fit parts. I don’t understand why Renesas didn’t at least factory fit the headers at least as they aren’t expensive and likely to be used as a lot of the pins are broken out to these parts. I managed to break one of the connectors (not terminally fortunately) and the 3M pads used to stick the LCD to the PCB were difficult to reach - it would help to attach the screen with a clip of some sort rather than inaccessible 3M pads. Anyway, I managed to remove it, solder some headers on, and replace it. I chose not to stick it back down with the 3M pads but to just use some Kapton tape, that way if I need to remove it again, I can just ‘hinge’ it out of the way.
This was easy to set up based on a found demo (different board and MCU but easy enough to adapt). I’m very impressed with the accuracy - my quick demo had a reading between 0mV and 5mV to a DMM attached to the circuit which is actually in-line with the meter’s accuracy specification. The RX65N has a 12-bit ADC capability and the resolution can be reduced to increase conversion speed. The actual ADC functionality seems to be feature rich as well, although I didn’t test it all during the road test, and they’ve really gone to town on this. For example: 21 ADC pins across two units; single, continuous and grouped scanning for different priorities and configurations; software and sync-/asynchronous triggering; external Op Amp integration in the conversion path; 0.48uS conversion speed at 12-bit; sample and hold. Compared to the results I am getting out of an Arduino, it’s significantly better and I don’t think it’s just down to the 10-bit / 12-bit reading resolution difference.
Here, I set up the basic GUI using the tools provided as part of the emWin product set. This post was just a quick overview of using emWin and GUIBuilder to develop a working UI.
emWin isn’t part of the Envision board per-se, but I found it an extremely useful addition to the development tools Renesas offer with it.
In this post, I bring all the above together to display readings pulled in through the ADC units and I2C connections. To keep things ‘complex’ for testing I used triggering and callbacks to drive the ADC readings but I need to be clear: using the ADC units on the RX65 is, in no way at all, complex - I found it no more difficult to get up and running than I did with the Wire library on Arduino. Ditto, the I2C connection which was totally straightforward. This is because the Smart Configurator, as I noted above, does all the heavy lifting and getting the configuration set up is really intuitive using it.
I chose to use triggers to drive the ADC on purpose in order to explore this as part of the road test: it isn’t ideal, because a lot more work has to be done to deal with things like interrupts interrupting callback processing, especially when multiple timers are involved, one of which must be kept going because it is timing. This needs careful working out, part of the process of developing for MCUs and the typical solutions they find themselves used for. Interrupt and Timer configuration is helped immensely by the Smart Configurator and the code it generates.
I am using the USB connection to send data to a host PC as I imagine that’s an obvious use case. I’m also doing so under command of the Host which can turn on/turn off data transmission.
There is a difficulty in this: the board can use the USB UART/Serial connection for either that purpose OR for debugging but not both simultaneously. Jan mentioned this in his review and had a workaround not available to me unfortunately. Still, it wouldn’t be the first time I’ve had that problem and the MCU has a screen attached for outputting. Really, Renesas should address this and provide a different port for serial interfacing: it was extremely tedious to swap between the two board configurations as it was a frequent necessity given the inability to use traditional debugging tools.
There is a bug in the Serial Communications Interface FIT module which has been reported on the forum - no response as yet. I actually couldn’t get the USB/Peripheral communications FIT modules working at all despite it not being particularly complex to set up. I have no idea why; I also struggled initially getting Jan’s app that he created as one of his tests to work, again no idea why.
Ultimately, the interfacing is working and I can now send commands to the board to start/stop data transmission, and send the readings on the screen as a dataset to the Host PC terminal application. I’m still extremely impressed with the way the Smart Configurator works despite the issues noted in the post.
Notwithstanding the user fit parts issue, this board does achieve its aims of providing a quick and easy means of evaluating the RX65N MCU and creating prototypes around it. For anyone new to MCU development or looking at this as an alternative to, say, an Arduino, then it is a good launchpad for getting a working HMI solution as long as you have some reasonable experience in development and development problem solving: you won’t find as much hand-holding and pre-written libraries as you will for something like an Arduino. At a price of just under £50 inc vat, it feels like a bit of a bargain given the MCU, LCD, debugger and emWin.
I have to particularly call out the excellent Smart Configurator, FIT modules and Quick and Effective (QE) solutions as well as all the samples and application notes as they really make a big difference to getting to grips with the MCU. In developing the application I have used 13 of them, so a wide range, some of which are wholly self-configuring.
Whilst the documentation is very functional, I found that I got used to it quite quickly and was able to work out the best way of extracting information out of it: there is a stack of it, and it’s all comprehensive - indeed the Hardware Guide for the RX65N is over 2700 pages long.
There are very, very few samples for the Envision board (two I think provided by Renesas but some other individual has create 12 using straight code, i.e. not Smart Configurator) but there are lots for the RX family in general using other boards. These samples can be readily adapted to the Envision board and RX65N and whilst it caused a bit of head-scratching at first, I was able to work out the best way of using them.
The board itself has no mounting points so to encase it will require a bit of effort: 3D printing a mount, or creating some frame to hold it. There’s no room to use rails to mount the PCB either as ports/headers are right on (each) edge.
I’ve attached the final application code to post 7 to review if you are interested: user code/generated code should be fairly obvious and I’m happy to answer any questions about it.
Finally, I’d like to thank Element 14 and Randall for picking me for the review: it’s been really interesting to undertake.
Top Comments
Hi Andrew,
Actually in this case there's no need to look for any dots : ) Renesas PCB designers did a nice thing, and marked off every tenth pin (I try to do that on high-density chips too). So, pin 1 can…
That’s what those marks are, I did wonder! You are right - of course under normal circumstances those marks wouldn’t be there, you would go on the small dimple on the IC rather than the large ones. Or…
Pin1 is top left, would be my guess. Nice review that complements the one by Jan Cumps (as you said).