Forums

Which development environment for H8?

Started by Ulf August 4, 2006
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