1. This forum section is a read-only archive which contains old newsgroup posts. If you wish to post a query, please do so in one of our main forum sections (here). This way you will get a faster, better response from the members on Motherboard Point.

Renesas HEW

Discussion in 'Embedded' started by Zaf, May 9, 2006.

  1. Zaf

    Zaf Guest

    Has anybody used the HEW (High performance embedded workshop) from
    Renesas?
    I have been testing it for about two weeks (using M16 simulator) and
    very unhappy abaout it.
    It has more bugs then benefits. Crashes all over the place.Trying to
    write debugger scripts is horrendous, basically piece of shit. That's
    probably why Mitsubishi doesn't give any tech support.
    Overall if you are planning to use it, just run away from it. There are
    excellent development tools out there and don't waste your time.
    Zafer Elbi
    T-Tronics AS.
     
    Zaf, May 9, 2006
    #1
    1. Advertisements

  2. Zaf

    Geoff Field Guest

    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, May 9, 2006
    #2
    1. Advertisements

  3. 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:
    http://www.kpitgnutools.com

    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
    http://www.fivetrees.com
     
    Steve at fivetrees, May 9, 2006
    #3
  4. 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, May 9, 2006
    #4
  5. Zaf

    Noway2 Guest

    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.
     
    Noway2, May 9, 2006
    #5
  6. On 9 May, in article
    <>
    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, May 9, 2006
    #6
  7. 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
    http://www.fivetrees.com
     
    Steve at fivetrees, May 9, 2006
    #7
  8. 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
     
    Henrik [6650], May 9, 2006
    #8
  9. Zaf

    DJ Delorie Guest

    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: http://people.redhat.com/dj/m32c/

    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.
     
    DJ Delorie, May 9, 2006
    #9
  10. 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, May 9, 2006
    #10
  11. Zaf

    DJ Delorie Guest

    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.
     
    DJ Delorie, May 9, 2006
    #11
  12. You're wulcome.
    Thanks.

    I'll add the Mitsubishi parts to the "preferred" list now that
    there are gnu tools for them. :)
     
    Grant Edwards, May 10, 2006
    #12
  13. Zaf

    DJ Delorie Guest

    FYI: Mitsubishi sold that line to Renesas, so they're now Renesas
    parts.
     
    DJ Delorie, May 10, 2006
    #13
  14. 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, May 10, 2006
    #14
  15. Zaf

    DJ Delorie Guest

    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 ;-)
     
    DJ Delorie, May 10, 2006
    #15
  16. Where are the differences between your port an KPIT's one ?
     
    42Bastian Schick, May 10, 2006
    #16
  17. Where can I find the calling convention used ?
    (W/o digging the gcc sources :)
     
    42Bastian Schick, May 10, 2006
    #17
  18. Zaf

    DJ Delorie Guest

    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 ;-)
     
    DJ Delorie, May 10, 2006
    #18
  19. Zaf

    DJ Delorie Guest

    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 -> +--------------------
     
    DJ Delorie, May 10, 2006
    #19
  20. Thanks.
     
    42Bastian Schick, May 11, 2006
    #20
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.