Which development environment for H8?

Hi there,

for a possible rewrite of software running on custom hardware built
around a Hitachi/Renesas H8/3002 I'm thinking about changing the
development tools.
Right now the "IDE" is made of IAR Compiler/Assembler/Linker and a bunch
of home-brewed tools for building the program-image and uploading it to
the target.
The most annoying about this kind of toolchain is that it's missing any
kind of debugger or simulator, which makes debugging rather hard work.

But now it seems likely that a rewrite of the software will be made,
what makes me think of striking a new path and maybe get rid of the
limited debugging capabilities.

I did take a quick look at the Hitachi/Renesas HEW, but as I don't have
a license for it yet, I cannot do much more than catch a glimpse on the
GUI and read the manual. It seems as it has everything I need (even if I
crashed it just by editing, reproducible). I'm just not sure about its
debugger used on anything other than an eval-board (no chance of using
an eval-board).

The other possibility may be GCC which should be able to build output
for th H8-Series and GDB which can hopefully be ported in a few hours to
get the stub working on the H8.=20

As I'm not very familiar with both alternatives I hope someone here can
help me with some pro's and con's for them or maybe point me another
alternative. I'm interested in the debugging capabilities, especially
those of GDB, as I've never used it before and I'm not sure what will be
possible with it.


TIA,
Ulf

On 2006-08-04, Ulf <gebrauchtteile@arcor.de> wrote:

> The other possibility may be GCC which should be able to build
> output for th H8-Series

It can.  I've been using GCC for H8 for a few years now, and
I'm quite happy with it.  I recommend grabbing either pre-built
binaries or source tarballs from the KPit-Cummins web site:

http://www.kpitgnutools.com/

They do quite a bit of maintenance on the H8 target stuff and
always have well-tested snapshots.

FWIW, I usually grab sources and build them myself.

> and GDB which can hopefully be ported in a few hours to get
> the stub working on the H8. 

There are a couple H8 GDB stubs floating around.  I've got one
somewhere that's a tweaked version of one that Bill Gatliff
<http://www.billgatliff.com/> wrote.  If you want a copy, let
me know.

> As I'm not very familiar with both alternatives I hope someone
> here can help me with some pro's and con's for them or maybe
> point me another alternative. I'm interested in the debugging
> capabilities, especially those of GDB, as I've never used it
> before and I'm not sure what will be possible with it.

I used GDB a bit when debugging the intial HW, and it worked
fine. But, I don't use it much for software debugging (I find
that looking at the source code and thinking gets the job done
faster -- especially when combined with a few "printfs" or
toggling some port lines that you can watch with a 'scope).

-- 
Grant Edwards                   grante             Yow!  Yow! I like my new
                                  at               DENTIST...
                               visi.com            

On Friday, in article
     <649.273.537.121.a92@gebrauchtteile.arcor.de>
     gebrauchtteile@arcor.de "Ulf" wrote:

>Hi there,
>
>for a possible rewrite of software running on custom hardware built
>around a Hitachi/Renesas H8/3002 I'm thinking about changing the
>development tools.
>Right now the "IDE" is made of IAR Compiler/Assembler/Linker and a bunch
>of home-brewed tools for building the program-image and uploading it to
>the target.
>The most annoying about this kind of toolchain is that it's missing any
>kind of debugger or simulator, which makes debugging rather hard work.
>
>But now it seems likely that a rewrite of the software will be made,
>what makes me think of striking a new path and maybe get rid of the
>limited debugging capabilities.
>
>I did take a quick look at the Hitachi/Renesas HEW, but as I don't have
>a license for it yet, I cannot do much more than catch a glimpse on the
>GUI and read the manual. It seems as it has everything I need (even if I
>crashed it just by editing, reproducible). I'm just not sure about its
>debugger used on anything other than an eval-board (no chance of using
>an eval-board).

My personal opinion of HEW is it is only useful for simulating the parts
of the code that do NOTHING with peripherals or external memory. The
interface I found clucky and all the files it generates are proprietary
ENCODED. So if you want to support this in 5 or more years time it will
be a pain. Its default directories are the program installation directory.

Using it with some of the eval boards is fine for evaluation and little
to no use for developing real applications, with some of their processors
going to JTAG like debugger interfaces, they had a chance to do something
good with HEW, but in my opinion failed. Possibly deliberately to extract
more money out of people.

>The other possibility may be GCC which should be able to build output
>for th H8-Series and GDB which can hopefully be ported in a few hours to
>get the stub working on the H8.

There are ports for H8 GDB already in existance as well as various other
tools.

See   my sig for a site that links to all sorts of other sites relating
to GCC GDB and flavours of H8.

>As I'm not very familiar with both alternatives I hope someone here can
>help me with some pro's and con's for them or maybe point me another
>alternative. I'm interested in the debugging capabilities, especially
>those of GDB, as I've never used it before and I'm not sure what will be
>possible with it.

Quite a bit in simulator but perhiperal limitations as HEW. with stubs
it can talk to a target even versions using one of the serial ports.

Then again I have managed quite a lot without GDB for several years,
once I have startup and a basic kernel with serial and other I/O support
running.

Just delivered two systems using GCC for ASIC testing in the last few
weeks.

-- 
Paul Carpenter          | paul@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/>    PC Services
<http://www.gnuh8.org.uk/>              GNU H8 & mailing list info
<http://www.badweb.org.uk/>             For those web sites you hate

"Grant Edwards" <grante@visi.com> wrote in message 
news:12d7j41os2akof8@corp.supernews.com...
> On 2006-08-04, Ulf <gebrauchtteile@arcor.de> wrote:
>
>> The other possibility may be GCC which should be able to build
>> output for th H8-Series
>
> It can.  I've been using GCC for H8 for a few years now, and
> I'm quite happy with it.  I recommend grabbing either pre-built
> binaries or source tarballs from the KPit-Cummins web site:
>
> http://www.kpitgnutools.com/
>
> They do quite a bit of maintenance on the H8 target stuff and
> always have well-tested snapshots.

I second this. I've been developing for the H8 for a long time - started out 
with the Hitachi toolchains (various versions), and now use the KPIT GCC 
tools. This includes a version of the HEW IDE, by the way.

> I used GDB a bit when debugging the intial HW, and it worked
> fine. But, I don't use it much for software debugging (I find
> that looking at the source code and thinking gets the job done
> faster -- especially when combined with a few "printfs" or
> toggling some port lines that you can watch with a 'scope).

Yep, again same here.

Steve
http://www.fivetrees.com 

"Paul Carpenter" <paul$@pcserviceselectronics.co.uk> wrote in message 
news:20060804.2316.319070snz@pcserviceselectronics.co.uk...
> On Friday, in article
>     <649.273.537.121.a92@gebrauchtteile.arcor.de>
>     gebrauchtteile@arcor.de "Ulf" wrote:
>
>>Hi there,
>>
>>for a possible rewrite of software running on custom hardware built
>>around a Hitachi/Renesas H8/3002 I'm thinking about changing the
>>development tools.
>>Right now the "IDE" is made of IAR Compiler/Assembler/Linker and a bunch
>>of home-brewed tools for building the program-image and uploading it to
>>the target.
>>The most annoying about this kind of toolchain is that it's missing any
>>kind of debugger or simulator, which makes debugging rather hard work.
>>
>>But now it seems likely that a rewrite of the software will be made,
>>what makes me think of striking a new path and maybe get rid of the
>>limited debugging capabilities.
>>
>>I did take a quick look at the Hitachi/Renesas HEW, but as I don't have
>>a license for it yet, I cannot do much more than catch a glimpse on the
>>GUI and read the manual. It seems as it has everything I need (even if I
>>crashed it just by editing, reproducible). I'm just not sure about its
>>debugger used on anything other than an eval-board (no chance of using
>>an eval-board).
>
> My personal opinion of HEW is it is only useful for simulating the parts
> of the code that do NOTHING with peripherals or external memory. The
> interface I found clucky and all the files it generates are proprietary
> ENCODED. So if you want to support this in 5 or more years time it will
> be a pain. Its default directories are the program installation directory.

You seem to be confusing HEW with the simulator. HEW is an IDE, into which 
one can optionally plug a simulator, amongst other things.

I'd agree re simulators in general, though.

Steve
http://www.fivetrees.com 

On Saturday, in article <67udnaWOV5QtMEnZRVnytQ@pipex.net>
     steve@NOSPAMTAfivetrees.com "Steve at fivetrees" wrote:
>"Paul Carpenter" <paul$@pcserviceselectronics.co.uk> wrote in message
>news:20060804.2316.319070snz@pcserviceselectronics.co.uk...
>> On Friday, in article
>>     <649.273.537.121.a92@gebrauchtteile.arcor.de>
>>     gebrauchtteile@arcor.de "Ulf" wrote:
>>
>>>Hi there,
>>>
>>>for a possible rewrite of software running on custom hardware built
>>>around a Hitachi/Renesas H8/3002 I'm thinking about changing the
>>>development tools.
>>>Right now the "IDE" is made of IAR Compiler/Assembler/Linker and a bunch
>>>of home-brewed tools for building the program-image and uploading it to
>>>the target.
......
>> My personal opinion of HEW is it is only useful for simulating the parts
>> of the code that do NOTHING with peripherals or external memory. The
>> interface I found clucky and all the files it generates are proprietary
>> ENCODED. So if you want to support this in 5 or more years time it will
>> be a pain. Its default directories are the program installation directory.
>
>You seem to be confusing HEW with the simulator. HEW is an IDE, into which 
>one can optionally plug a simulator, amongst other things.

I was confusing need to sleep and need to post (after 4hours sleep in two
days).. Should have been more specific the versions of HEW that I have used
was with E8 and even with the debugging interface was hopeless. The simulator
was not much better.

My personal view of the IDE side is that is a bit like XP 'improvements' with
everything being lots of clicks away and more than they should be to be saved
in proprietary file formats that will be difficult to maintain. Similar to
things on XP appears to have a default 'would you like to search the internet'
on finds or open with, that has to be passed through first before doing what
you want.

I actually think HEW makes setting up for a project harder than learning
linker scripts et al.

If all you want is something that allows you to edit all the files, but save
the project files where you want by default, call a compiler and redirect
error output, then there are more general purpose solutions like MED editor
(www.med-editor.com).

HEW tries to be too many things and in my opinion, is a master of none.
Don't get me started on their standard i/o header files that most registers
have to be defined as structures and unions, with ints not shorts.

It suffers from default directory issues as in the 'PIC vs AVR' thread.
Along with FDT and other Renesas tools.

>I'd agree re simulators in general, though.

Simulators are only really good for hosted applications, debuggers
should work with target not just EVB and not require flash rewrites
for single stepping (H8/Tiny).

Then again about all I use the _current_ debuggers or simulators for
is getting startup code/basic kernel functioning to toggle I/O or
printf stage.

-- 
Paul Carpenter          | paul@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/>    PC Services
<http://www.gnuh8.org.uk/>              GNU H8 & mailing list info
<http://www.badweb.org.uk/>             For those web sites you hate

Am Fri, 04 Aug 2006 22:38:57 -0000 schrieb Grant Edwards:

>> The other possibility may be GCC which should be able to build
>> output for th H8-Series
>
>It can.  I've been using GCC for H8 for a few years now, and
>I'm quite happy with it.  I recommend grabbing either pre-built
>binaries or source tarballs from the KPit-Cummins web site:
>
>http://www.kpitgnutools.com/

Thanks, that looks nice.

>I used GDB a bit when debugging the intial HW, and it worked
>fine. But, I don't use it much for software debugging (I find
>that looking at the source code and thinking gets the job done
>faster -- especially when combined with a few "printfs" or
>toggling some port lines that you can watch with a 'scope).

That's what I do now, but some errors do not appear where I coded them
;-) And then it would be nice to have more information than just what I
thought I need. An overview of the current system-state at a given point
or time would often be enough but can hardly be made with some printfs.
And on the other hand it's not very maintainable to put too many output
in the source, even if shortened as much as possible.


Ulf

Am Sat, 05 Aug 2006 00:16:23 +0100 (BST) schrieb Paul Carpenter:

>My personal opinion of HEW is it is only useful for simulating the parts
>of the code that do NOTHING with peripherals or external memory.

That's a problem with all simulators. But what is described in the
HEW-Manual seems to be quite useable even with the I/O-simulation.
When it comes to handle timing-constraints with peripherials no
simulator will do the job right.

>The interface I found clucky and all the files it generates are =
proprietary
>ENCODED. So if you want to support this in 5 or more years time it will
>be a pain.

Ok, big con.

>There are ports for H8 GDB already in existance as well as various other
>tools.
>
>See   my sig for a site that links to all sorts of other sites relating
>to GCC GDB and flavours of H8.

Sounds good, thanks for the links.


>Then again I have managed quite a lot without GDB for several years,
>once I have startup and a basic kernel with serial and other I/O support
>running.

The basics should be no problem, they can be used from the current
software. And in the end, all serial channels will be in use, so the
last bit of debugging will be made "oldschool", but in between it may be
nice to have more than just some output. Much too often it takes me
several tries to trace errors if they are were I'd never expected one.
Taking a quick look with a debugger will then be much easier and faster
than inserting new output-code.


Ulf

Paul Carpenter wrote:

> Don't get me started on their standard i/o header files that most registers
> have to be defined as structures and unions, with ints not shorts.
> 

Sorry but I must... :)

I find the I/O header files difficult to follow and see what belongs 
with what. On the other hand, I do find that the code that you end up 
writing is very readable with its built-in reminder of what register the 
flag or whatever belongs to. Certainly this:

AD.ADCSR.BIT.SCAN = 0;
AD.ADCSR.BIT.CH = channel;

seems a little easier to read than this (which seems to be in the style 
preferred by the AVR port of GCC):

ADCSR =  (ACDSR & 0xFE) | channel;
ADCSR &= ~(1 << SCAN);

I can see how that would be a problem if a given flag or field was to be 
found in a different register for a different processor but that may be 
as bad in either style.

I have also seen many warnings about the use of bitfields to map to 
hardware devices in this way. One of the reasons being portability 
issues. While this seems to make sense, the I/O definitions are pretty 
intrinsically non-portable anyway so why is it so important?

So, if we accept that you do not like the way the I/O header files are 
made up, what might be a better way to do it? I am not having a go - I 
just want to know the best way to do this. Ideally, as portably as 
possible as I have some code that I would like, one day, to be able to 
put into AVRs, H8s, PICs and whatever else. The hardware abstraction is 
a bit of a bugger.

Pete Harrison

"Ulf" <gebrauchtteile@arcor.de> wrote in message 
news:eb4kj4.tk.1@gebrauchtteile.arcor.de...
Am Fri, 04 Aug 2006 22:38:57 -0000 schrieb Grant Edwards:

>> >I used GDB a bit when debugging the intial HW, and it worked
>fine. But, I don't use it much for software debugging (I find
>that looking at the source code and thinking gets the job done
>faster -- especially when combined with a few "printfs" or
>toggling some port lines that you can watch with a 'scope). <<

>> That's what I do now, but some errors do not appear where I coded them
;-) And then it would be nice to have more information than just what I
thought I need. An overview of the current system-state at a given point
or time would often be enough but can hardly be made with some printfs.
And on the other hand it's not very maintainable to put too many output
in the source, even if shortened as much as possible. <<

Conditional compilation is your friend. For example, somewhere in a header 
(e.g. builds.h) use:

// Comment out for production:
#define Debug 1

In the code:

#ifdef Debug
    printf( "Something happened.\n" );
#endif

Or replace printf with your own serial string handler.

Steve
http://www.fivetrees.com