Which development environment for H8?

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:

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.

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

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).

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.

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.

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.

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.

Yep, again same here.

Steve

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

......

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

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.

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.

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

Thanks, that looks nice.

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:

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.

proprietary

Ok, big con.

Sounds good, thanks for the links.

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

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

;-) 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.

Which is fine until you get even longer multiple lines

if( AD.ADCSR.BIT.SCAN == 1 && AD.ADCSR.BIT.DONE == 1 && scan_control.end == AD.ADCSR.BIT.CH......

After several nesting in....

as compared to

if( (ADCSR & 0xC7) == (scan_count + 0xC0) )

Long names do not always make all lines of code more readable.

So the Renesas headers are not really safe with GCC? I suppose they were written with the Hitachi compiler in mind (or was that a disguised GCC port as some seem to be). It would be interesting to find some demonstration cases where incorrect compiler output were generated.

I don't suppose there is any other publicly available source of I/O headers for these devices?

Come to that, is there any kind of general convention for these things that I could read about?

Pete Harrison

Not safe with at LEAST GCC.

Whatever that is these days as that appears to change regularly.

int is a dangerous type to use in ANY C so is not portable, see even the original K & R on the subject. Especially when you have 32bit registers in the device. To make things portable they should use the proper descriptors.

All the ones *I* have seen for other compilers/IDE are based upon Renesas header files. All the rest are part of examples from other people, one day I may gather my various header files into freely available ones.

First follow the general conventions of not relying on what one compiler does for portable code.

Are you sure that it's compatible with the H8/3002? IIRC, the 3002 was a bit of a black-sheep in that it didn't support backwards compatibility with the H8/300...

I came across this when I was looking at the possibility of using the H8/3002 core in MAME for a H8/330 project...

Regards,

According to the Renesas web site the 3002 has an H8/300H cpu core. I don't know why that would make it a black sheep, since there are ton's of other parts with H8/300H cpu cores.

I'm sure the 300H is one of the architectures supported by GCC: I'm currently using gcc for a part with an H8/300H cpu (the H8/3062).

From MAME...

"Note: The H8/3000 series is normally back-compatible to the 8-bit H8/300, but the 3002 does not include "emulation mode" - it always runs in full 16/32-bit ("advanced") mode. So this core is not suitable for general H8/300 emulation."

But I'm guessing from your comments that the above-mentioned "advanced" mode is equivalent H8/300H!?! So I guess not a problem after all?!?

Sorry - a little knowledge is a dangerous thing! ;)

Regards,

On H8/300H (and HS) the advanced mode is the H8/300H core used in its full capacity. The "emulation" mode refered to Renesas on H8/300H cores as "Normal" mode is when the unit only has 64K address range instead of 16M, which on some devices limits the Flash and RAM available, in some modes disabling them.

GCC supports the H8/300, H8/300H, H8/300S, and H8/300Tiny it is possible also to support the H8/300SX and H8/300SLP, by carefully using the H8/300H and H8/300S support and remembering what instructions not to use in assembly routines.

Having used the support for H8/300H, H8/300S and H8300Tiny cores myself.

There is of course the SH support as well.

header=20

Sure, I know how to use the preprocessor.

That's what I mean by "not very maintainable". The more of this kind of debug-output you put in your code, the less readable it gets. This is code that doesn't belong to the software-logic, it just visually tears your code apart.

And then this kind of debug-output has countless disadvantages. There are only two reasons to use it, it's easy to use and it can be used on virtually every system. That's why you find it in at least 99% of C/C++ sourcecode, although you can shoot yourself in the foot with it real easy without even noticing.

Don't get me wrong, I'm using it all the time often because I don't have an alternative, but if there is an alternative I can rely on, like a well tested debugger, it will be no question what to use.

Ulf

debug-output you put in your code, the less readable it gets. This is code that doesn't belong to the software-logic, it just visually tears your code apart. > And then this kind of debug-output has countless disadvantages. There are only two reasons to use it, it's easy to use and it can be used on virtually every system. That's why you find it in at least 99% of C/C++ sourcecode, although you can shoot yourself in the foot with it real easy without even noticing. > Don't get me wrong, I'm using it all the time often because I don't have an alternative, but if there is an alternative I can rely on, like a well tested debugger, it will be no question what to use.