Renesas HEW

Yes. We've been using various versions of it for some years now in the automotive industry. I've seen better products, but I've also seen worse.

We have a friendly Renesas dealer who often does the 1000km (600mile) trip down from Sydney to give support. OTOH, we do buy chips in automotive quantities.

Geoff

--
Geoff Field
Professional Geek,
Amateur Stage-Levelling Gauge

I've been using it since about '97 or so. It's been fine. Nowadays I use it as a front-end to the KPIT GNU tools:

I confess I've not used the debugging side much; I mostly verify, rather than debug. I don't remember any crashes or major bugs. Works fine for me.

Steve

I used it for a few days. I found it slow, clunky, and difficult (pretty par for all MS-Windows-based point-and-click IDEs). I tossed it and went back to my normal Linux/gcc development environment.

--
Grant Edwards                   grante             Yow!  Yes, but will I
                                  at               see the EASTER BUNNY in
                               visi.com            skintight leather at an
                                                   IRON MAIDEN concert?

I used it on the software development project for one of our product lines. The version that I used was mostly the pre Renesas tool set, when it was Hitachi Europe. I didn't think that the tool set was too bad and the debugging capabilities were decent, using the E6000 emulator. However, at a price tag of over $10K USD, I think it was EXTREMELY over priced. My most recent project, by way of comparison, uses TI with Code Composer and the Spectrum Digital JTAG emulator, which seems to me to be a much more power development system for less than 1/5th of the price. Granted, the processor itself may be more powerfull in that it supports the JTAG emulator, compared to the Renesas H8S that we used, but the price of the processors is nearly identical in the quantity that we are buying (non automotive). With respect to the technical support I felt that their support was less than adequate and they were overly concerned with getting maximum amount of money for providing a limited amount of support.

In summary, given a choice I would NOT use their system again.

Well now it is a free download, or comes with debuggers like E8 (USB) which replace their older E-10 range. I am going to try it on one of the few H8s that support the E8 (H8/Tiny), the only reason is on this project I will see if it helps speed up development.

The E8 I got was about 100 GBP (150 'ish' USD).

The E6000 and similar and saw the price tag and went how many months that would have to save in time was not practical, compared to base code generated on an EVB using HDI for a lot less. After that the interactions with hardware became complex, where by logic analyser noteing sequences of high speed data comms to a couple of pins from the device wa what was needed.

I will see what it is like for simulation and debugging, but if major problems return to my own project and make files to control what is going on.

--
Paul Carpenter          | paul@pcserviceselectronics.co.uk
    PC Services
              GNU H8 & mailing list info
             For those web sites you hate

In my case, tech support was provided by the UK distributor (Arrow), rather than by Renesas, and specifically by one tech sales rep - who was excellent. No complaints there at all.

Re price: ISTR that the high price was/is for the compiler, rather than HEW (which is a GUI IDE). As I said elsewhere, I'm now using HEW with the GNU tools, and HEW itself was a free download.

Steve

I sadly must agree with you. We tried it out, when we were ready for a new high volumedesign because the chips (R8C) was really cheap at high volumes, but both the emulator and simulator was so buggy and slow and chunky to use, that we dropped it after a while. Not only was the software buggy and prone to crashing all the time, but also higly unstable. Emulator stopped running for no apparant reason, connection was lost and so on.

The support from the ditributor was excellent, but they also didn't understand what went on and after quite a lot of exchanges of different emulators and demoboards we dropped the product.

However, if better tools where around (they might be, I have not checked) I would stille recommend the chips. They are quite cool and very cheap.

Just my $0.02.

Henrik

I recently finished porting gcc and binutils to the r8c/m16c/m32c families, and gdb support was recently added too (with a simulator).

My notes are here:

You'll want the cvs "head" versions of gcc (well, svn trunk), binutils, newlib, and gdb to get everything. I'm open to feedback about the quality of the produced code, too.

The simulator supports the RGB leds on the r8c eval board too ;-) It also supports one of the hardware serial ports, but I forget which chip I modelled. It lets me run the same binary images on the board and the simulator, and still have a working "printf". You can easily tweak the sim sources to match your hardware.

The tools can be used to produce SREC files that HEW and KD30 can download to the boards.

I looked at the M16C a couple years back, and when I was wondering about the possibility of a GCC port, I was told that that GCC doesn't know how to deal with data pointers and code pointers that are different sizes, so an M16C port would be limited to a single 16-bit address space.

I see from your page that GCC supports 1M of code space on the M16C, yet has 16 bit pointers. How are pointers to functions handled?

--
Grant Edwards                   grante             Yow!  I'm CONTROLLED by
                                  at               the CIA!! EVERYONE is
                               visi.com            controlled by the CIA!!

Thunks. For each function needing a 16 bit pointer, a jump opcode is placed in the 16 bit address space which jumps to the function, and the address of that opcode is used.

You're wulcome.

Thanks.

I'll add the Mitsubishi parts to the "preferred" list now that there are gnu tools for them. :)

--
Grant Edwards                   grante             Yow!  Is it FUN to be
                                  at               a MIDGET?
                               visi.com

FYI: Mitsubishi sold that line to Renesas, so they're now Renesas parts.

Sort of. The microprocessor divisions of Hitachi and Mitsubishi merged and formed Renesas. However, I still refer to the M16C et al as Mitsubishi processors and H8 et al as Hitachi processors. AFAICT, they've put the "Renesas" name on everything, but the old Hitachi and Mitsubishi organizations are still pretty much separate.

--
Grant Edwards

I don't think I've ever seen a corporate merger go as smoothly as hoped, but in this case, there's at least one reason to start thinking of them as "Renesas" - that's what you have to search for at digikey to find their chips ;-)

Where are the differences between your port an KPIT's one ?

--
42Bastian
Do not email to bastian42@yahoo.com, it's a spam-only account :-)
Use @monlynx.de instead !

Where can I find the calling convention used ? (W/o digging the gcc sources :-)

--
42Bastian
Do not email to bastian42@yahoo.com, it's a spam-only account :-)
Use @monlynx.de instead !

I'm the m32c gcc and binutils maintainer, which means I'm putting in most of the work to the FSF's sources. I don't know if KPIT changes anything, but in general, they're just taking the FSF's gcc sources, building them, and packaging them up. They've submitted a couple of patches to gcc that I've rejected as incorrect, which indicates that they might have different sources than the official ones. You'd have to check their release notes to know for sure.

Other than that, new stuff tends to show up in the FSF sources first, followed by the KPIT release as soon as they get around to rebuilding it.

Also, since KPIT takes a snapshot and (I assume) tests it, you're less likely to be bitten by "current development" breaking something. Although, if you do get bitten, I *really* want to know about it ;-)

Here is gcc/config/m32c/m32c.abi from the gcc sources. The only major difference is that gcc has 16 bytes of "memory" registers, mem0..mem15, which it uses as additional real registers. GCC doesn't like chips with small numbers of registers, I've found I get better code sometimes if it has some spare (albeit costly) registers to use. You can disable those with command line options if you don't need them, but you'll have to rebuild libgcc.a if you do. Reducing the dependency on these spare registers is a to-do item.

Target Definitions for R8C/M16C/M32C Copyright (C) 2005 Free Software Foundation, Inc. Contributed by Red Hat.

This file is part of GCC.

GCC is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2, or (at your option) any later version.

GCC is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with GCC; see the file COPYING. If not, write to the Free Software Foundation, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.

These are just some random notes I used during development of this port. Please don't consider these to be "official" specifications, just additional information to help make the code easier to understand.

Frame =====

+-------------------- | incoming args +-------------------- | return Address osp -> +-------------------- | saved fp fp -> +-------------------- | local data +-------------------- | saved regs +-------------------- | outgoing args (opt) sp -> +--------------------

Argument Passing ================

r8c, m16c

---------

First arg may be passed in r1l or r1 if it (1) fits (QImode or HImode), (2) is named, and (3) is an integer or pointer type (no structs, floats, etc). Otherwise, it's passed on the stack.

Second arg may be passed in r2, same restrictions (but not QImode), even if the first arg is passed on the stack.

Third and further args are passed on the stack. No padding is used, stack "alignment" is 8 bits.

m32cm, m32c

----------- First arg may be passed in r0l or r0, same restrictions as above.

Second and further args are passed on the stack. Padding is used after QImode parameters (i.e. lower-addressed byte is the value, higher-addressed byte is the padding), stack "alignment" is 16 bits.

Return Value ============

r8c, m16c

---------

QImode in r0l HImode in r0 near pointer in r0 (desired) SImode in r2r0 far pointer in r2r0 (actual) Anything bigger than 16 bits is returned in memory, at mem0 (mem0 through mem15 are provided by libgcc.a)

Aggregate values (regardless of size) are returned by pushing a pointer to a temporary area on the stack after the args are pushed. The function fills in this area with the value. Note that this pointer on the stack does not affect how register arguments, if any, are configured.

m32cm, m32c

----------- Same.

Registers Preserved Across Calls ================================

r8c, m16c

--------- sb, fb, sp (i.e. nearly all registers are call clobbered)

m32cm, m32c

----------- r1, r2, r3, a0, a1, sb, fb, sp (except when used for return values)

Interrupt Handlers ==================

The stack frame is slightly different for interrupt handlers, because (1) we don't have a usable parent frame, and (2) we have to use special instructions to return and thus must save/restore everything differently.

+-------------------- | program state osp -> +-------------------- | return address +-------------------- | saved r0..fp (pushm) fp -> +-------------------- | local data +-------------------- | saved regs mem0..mem15 +-------------------- | outgoing args (opt) sp -> +--------------------

Thanks.

--
42Bastian
Do not email to bastian42@yahoo.com, it's a spam-only account :-)
Use @monlynx.de instead !