Opinions on Renesas controllers ? - Page 1
Forum section: electronics / general

author: ptricks
author_rank: Frequent Contributor
timestamp: February 04, 2013, 10:49:46 am
content: I tried out some of the renesas chips a few years ago and really didn't enjoy having to use the software tools they provided.Today I was giving their site another look and saw cubesuite listed as a development tool. Cube suite was originally an NEC product and was fairly easy to use for development so I started considering the renesas chips again but want to know if anyone else is currently using their products ?The thing that has me interested is the RL78 line of chips because they have some interesting features I don't see a lot.1 - They operate over the 1.8V-6.5V range for each chip, no need to get a special low voltage version or provide different voltages on the board.2 - power consumption, .7ma in sleep mode and it can still do 9600 baud UART , the UART can do 4Mbps at full power.3 - SPI and I2C using the full voltage range, you can connect a 5.0V spi target to the chip if the chip is using 1.8v without worrying about level conversion.4 - only part needed for operation is a capacitor, all crystals are internal5 - consumes 4ma in full power mode at 3.3Vhttp://documentation.renesas.com/doc/products/mpumcu/rl78/RL78_Brochure_020512.pdfI'm mainly looking at power requirements, being able to operate with the uart and use maybe 1ma is interesting for battery supplied projects. 2000 hours operation off 2 AA size batteries would be really nice.

author: nctnico
author_rank: Super Contributor
timestamp: February 04, 2013, 11:43:46 am
content: I have used Renesas controllers in the past but nowadays I use ARM based controllers almost exclusively. Renesas has nice controllers, few erratas but they are expensive and may be hard to purchase in small quantities.ARM based controllers are way more mainstream these days and much cheaper. AFAIK some Cortex Mx controllers from NXP also have 5V tolerance and work at 1.8V (brown out detect at 1.65V). You have to be carefull with the 1.8V spec in general though. Atmel for example likes to tout a product works at 1.8V but at that voltage there is no margin so the devices actually need about 150mV more (1.95V) to work reliably.Edit: if you want ultra low power you should also look at TI's MSP430 series. These are specifically designed for ultra low power.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: February 04, 2013, 02:01:14 pm
content: Quote from: ptricks on February 04, 2013, 10:49:46 am6.5V is unusual, but many PICs will do 1.8-5vQuotePretty much any PIC can do that (with way lower sleep current) with a soft UART as it can wake on the startbit and has an internal osc that starts fast enough and is accurate enough to to UART.Some parts with PLLs may get close to 4mbits/sec.Anything with a sufficiently accurate internal RC oscillator that starts up fast enough can do a soft UART from sleep mode. 1% RC oscs are pretty common - I know most newer NXP ARMs have them - not looked recently at the AVR oscs.QuoteMay be useful in some cases but the small cost of level translation probably outweighed by other factorsQuoteSee (2) aboveQuoteI don't think that's anything fancy these daysGenerally you need to think very hard about how much you need unique features in any less-than-mainstream part.there are all sorts of issues - part availability (MOQs, leadtimes, similar parts that can be substituted), product lifetime, support from manufacturer and community,availability of development software & hardware, availability of produciton programming solutions etc.Also if there is a chance that someone else may need to maintain it, availability of people familiar with the family & (more importantly) tools.Bottom line is stick to what you know (and/or what lots of other people know) unless teher is soem feature that really makes a difference. Don't forget that cost benefits in parts cost are minimal compared to any additional development effort/learning curve until volumes get into the thousands.