Hitachi H8?
Kähkönen Jukka
The H8 series of Hitachi is an interesting processor series. Where
would the summary from the processors of this series be found from? on
the home page of Hitachi http://www.halsp.hitachi.com in other words
is information about everybody. So from everybody. In the H8 series
about 200 different type processors are. Therefore I search them for
the summary because, correct choosing is the same matter as the
looking for of the needle from the haystack.
Or. Does somebody operate a processor of the H8 processor family of
this Hitachi? Tell me what H8 processor you have in use?
Hitachin H8-sarja on mielenkiintoinen prosessorisarja. Mistä löytyisi
yhteenveto tämän sarjan prosessoreista? http://www.halsp.hitachi.com
eli Hitachin kotisivulla on tiedot kaikista. Siis kaikista.
H8-sarjassa on eri tyyppisiä prosessoreja n. 200. Siksi etsin niistä
yhteenvetoa, sillä oikean valitseminen on sama asia, kuin neulan
etsiminen heinäsuovasta.
Tai. Käyttääkö joku jotakin tämän Hitachin H8-prosessoriperheen
prosessoria?
Jukka Kähkönen
http://www.sci.fi/~rikos
Remove _remove.nospam from address
"Eniten ääntä löytyy niiltä, joilla ei ole hajuakaan asiasta"
Paul E. Bennett
In article <3487e266...@news.eunet.fi>
ri...@sci.remove.nospam.fi "Kähkönen Jukka" writes:
> The H8 series of Hitachi is an interesting processor series. Where
> would the summary from the processors of this series be found from? on
> the home page of Hitachi http://www.halsp.hitachi.com in other words
> is information about everybody. So from everybody. In the H8 series
> about 200 different type processors are. Therefore I search them for
> the summary because, correct choosing is the same matter as the
> looking for of the needle from the haystack.
>
> Or. Does somebody operate a processor of the H8 processor family of
> this Hitachi? Tell me what H8 processor you have in use?
[original language message deleted]
If you are looking for H8 series processors already made up and with
useable software on board then Triangle Digital Services produce the
TDS2020 which has an H8/330 on board running Forth. The board is
configured to provide plenty of useful I/O including PWM, LCD, Keyboard
and Comms. Well worth looking at.
The different processors in the range just give you performance and I/O
differences. The more powerful ones are the H8/500 series. I think the
H8/300 series have proved themselves adequate for the majority of
applications though.
Triangle Digital Services (TDS) are on +44 (0)181-539-0285.
--
Paul E. Bennett ................... <p...@transcontech.co.uk>
Transport Control Technology Ltd. <http://www.tcontec.demon.co.uk/>
+44 (0)117-9499861 <enq...@transcontech.co.uk>
Going Forth Safely
Stuart Clubb
>The different processors in the range just give you performance and I/O
>differences. The more powerful ones are the H8/500 series. I think the
>H8/300 series have proved themselves adequate for the majority of
>applications though.
Yikes !
DO NOT DESIGN IN H8/500.
It's more expensive and less powerful than H8/300H. Things are moving
on with the H8S and of course SuperH.
Stuart
--
For Email remove "die.spammer." from the address
Kai Ruottu
>The H8 series of Hitachi is an interesting processor series. Where
>would the summary from the processors of this series be found from? on
>the home page of Hitachi http://www.halsp.hitachi.com in other words
>is information about everybody. So from everybody. In the H8 series
>about 200 different type processors are. Therefore I search them for
>the summary because, correct choosing is the same matter as the
>looking for of the needle from the haystack.
>
Perhaps the "H8300S.PDF" (H8/300 Summary) would be the document you
are searching...
BTW. Ask for the free CDROM from Hitachi Europe (fill the coupon at
the Hitachi site, www.hitachi-eu.com, or fax to:
+49 89 9 29 30 00 / +49 89 9 29 30 01
and ask for it... It has all the PDF-files for H8, SH and other
Hitachi components. Much more nice having it, than gather the docs
from the net.
If you would like to try a H8/300, H8/300H and H8S targeted GCC
compiler for Win32 (NT/95), Linux or SCO hosts (and a little newer
than the DOS/go32 or Sun hosted compilers from Hitachi, the DOS-
hosted compilers are on the CDROM), please contact me...
>Or. Does somebody operate a processor of the H8 processor family of
>this Hitachi? Tell me what H8 processor you have in use?
I haven't used, just made the compiler for a fun and to check it will
work. The included H8-simulator seems to run OK under Linux, but not
yet under Win32... but the older Cygnus-made DOS/go32-hosted simulator
seem to work OK...
>Hitachin H8-sarja on mielenkiintoinen prosessorisarja. Mistä löytyisi
>yhteenveto tämän sarjan prosessoreista?
Samat vastaukset meän kielellä, savoksi ja stadiksi, genki desu...
Gomen nasai, Jukka-san, nihon go ga hanase-masen...
>"Eniten ääntä löytyy niiltä, joilla ei ole hajuakaan asiasta"
"Lääkäri on pätevä silloin kun huomaa ettei tiedä lääketieteestä
yhtään mitään", Sinuhe Egyptiläinen
Ken Lee
>The H8 series of Hitachi is an interesting processor series. Where
>would the summary from the processors of this series be found from? on
>the home page of Hitachi http://www.halsp.hitachi.com in other words
>is information about everybody. So from everybody. In the H8 series
>about 200 different type processors are. Therefore I search them for
>the summary because, correct choosing is the same matter as the
>looking for of the needle from the haystack.
Probably the best way is to get in contact with your local Hitachi
distributor. He can give you the lowdown as well as the various CDROMs
which has all the info.
>Or. Does somebody operate a processor of the H8 processor family of
>this Hitachi? Tell me what H8 processor you have in use?
I've used the H8/3002, H8/3003 and H8/3048F and also the SH-1 7032.
In the H8/300H series they are all pretty similar it's just a question
of how much I/O you want, flash ROM and DAC channels and costs. The
H8/3002 is about AUD$14 in small (50 off) quantities. The 3048F is
about $48 (expensive option) if you want an integrated Flash ROM.
For the H8/300H the GNU tools which come with the evaluation boards
are all that you would ever need. It comes with the remote debugger
GDB so you can download your program and step through it. The SH-1
tools are pretty much the same.
To give you an idea of performance the H8/3048F (and H8/3002 for that
matter) running at 16MHz is slightly faster (on the average) compared
to a 68332 at 16.67MHz. The H8S/2000 family absolutely kills the 68332
and it's code compatible with the H8/300H. Price? Well the H8S/2350 is
US$8.90 in lots of 1000 - I don't have a small quantity price.
It's probably cheaper where you are as the local distributors are
probably screwing us blind :)
As to which processor to use? Well it depends on your requirements.
The H8/300H series use the same CPU core and the same sets of I/O and
peripherals. In fact peripherals such as the ADC are located at the
same absolute address for the different configurations.
Iain Tebbutt
>
>The different processors in the range just give you performance and I/O
>differences. The more powerful ones are the H8/500 series. I think the
>H8/300 series have proved themselves adequate for the majority of
>applications though.
Don't use the H8/500 use the H8/300H or SH instead. If you're looking
for an easy way to start using the SH then we supply a single board
computer based on the SH1 (7032 processor).
(reply address is modified to reduce spam please reply to the email
address below).
Iain
--
Iain Tebbutt
Claritech Ltd
Tel: +44 (0)1530 412488
Fax: +44 (0)1530 412488
email: i...@claritech.demon.co.uk
www: http://www.claritech.demon.co.uk
Olav Woelfelschneider
Peter <z...@ds.com> wrote in comp.arch.embedded:
P> The H8/500 is dead.
Too bad my boss decided to use the H8/534, even though I told him that many
people in this group recommend against it.
Both of two distributors he spoke with said the H8/500 is well alive and
won't be discontinued in foreseable future. Hmmm...
But who am I, a lowly programmer, that I understand the high art of
business...
However, the H8's are a nice architecture, especially if you already know 68k.
--
Olav "Mac" Wölfelschneider wo...@rbg.informatik.th-darmstadt.de
PGP fingerprint = 06 5F 66 B3 2A AD 7D 2D B7 19 67 3C 95 A7 9D AF
But let your communication be Yea, yea; nay, nay: -- Matthew 5:37
for whatsoever is more than these cometh of evil. on computers
Ken Lee
On Thu, 11 Dec 1997 06:26:16 +0100,
wo...@rbg.informatik.th-darmstadt.de (Olav Woelfelschneider) wrote:
>Peter <z...@ds.com> wrote in comp.arch.embedded:
>P> The H8/500 is dead.
>
>Too bad my boss decided to use the H8/534, even though I told him that many
>people in this group recommend against it.
>
>Both of two distributors he spoke with said the H8/500 is well alive and
>won't be discontinued in foreseable future. Hmmm...
>
>But who am I, a lowly programmer, that I understand the high art of
>business...
>
>However, the H8's are a nice architecture, especially if you already know 68k.
The H8/500 will be around for a while I guess, but it now seems
totally irrelevent especially with the release of the H8S/2000 series.
I think the clock speed is only 10MHz for a H8/534 so that's typically
a 200ns instruction cycle. That's OK but your boss should have
listened to the "lowly programmer".
Ken.
Vaughan McPherson
Olav Woelfelschneider wrote:
>
> Peter <z...@ds.com> wrote in comp.arch.embedded:
> P> The H8/500 is dead.
>
> Too bad my boss decided to use the H8/534, even though I told him that many
> people in this group recommend against it.
>
> Both of two distributors he spoke with said the H8/500 is well alive and
> won't be discontinued in foreseable future. Hmmm...
>
> But who am I, a lowly programmer, that I understand the high art of
> business...
>
> However, the H8's are a nice architecture, especially if you already know 68k.
>
> Olav "Mac" Wölfelschneider wo...@rbg.informatik.th-darmstadt.de
> PGP fingerprint = 06 5F 66 B3 2A AD 7D 2D B7 19 67 3C 95 A7 9D AF
> But let your communication be Yea, yea; nay, nay: -- Matthew 5:37
> for whatsoever is more than these cometh of evil. on computers
Development tool cost may make a compelling arguement in favour of the
300H series given that the only C compiler vendor (that I'm aware of)
for
the 500 family is IAR, which costs a lot more than GNU tools for the
300H family (ie nothing). ICE's for the 500 series are less common
and more expensive as well.
Stuart Clubb
On Thu, 11 Dec 1997 06:26:16 +0100,
wo...@rbg.informatik.th-darmstadt.de (Olav Woelfelschneider) wrote:
>Too bad my boss decided to use the H8/534, even though I told him that many
>people in this group recommend against it.
Of all you could have picked, the 534 probably is the safest choice,
but why not a 3042 or 3048? Much nicer, and the toolset will make your
life way easier.
>Both of two distributors he spoke with said the H8/500 is well alive and
>won't be discontinued in foreseable future. Hmmm...
Probably a true statement, but talk to any Hitachi FAE about designing
in H8/500 and the response will be "duh, why do you want to do that?"
Ask your disti about compiler support, Hitachi WorkBench, MakeApp,
HDI/CIDE etc. then you may have enough ammunition. Plus check the cost
of silicon too. It's not to late to save the day!
>But who am I, a lowly programmer, that I understand the high art of
>business...
>
>However, the H8's are a nice architecture, especially if you already know 68k.
Agreed. But the 300H is way nicer. (no paging for a start!)
Ken Lee
On Sat, 13 Dec 1997 23:05:45 GMT, z...@ds.com (Peter) wrote:
>Out of interest, how do the GNU H8 tools compare with the IAR tools?
>
>Peter.
>
>Return address is invalid to help stop junk mail.
>E-mail replies to z...@digiXYZserve.com but
>remove the XYZ.
Well when I started looking for development tools for the H8/300H, I
looked at IAR, the Hitachi compiler (the Japanese version) and GNU. In
terms of code generation they were very similar - maybe the IAR was a
little better. I finally chose the GNU tools mainly because of the
extensive assembler preprocessor, GASP and the remote debugger GDB.
I mainly do my development on Windows NT but sometimes the cross tools
are needed on Unix - GNU offered this option.
Why did I need GASP? Well part of my RTOS that I use is written in
assembler and it made the RTOS so much easier to port if the macros
gave extensive argument passing. IAR does have a macro assembler (in
all of the assemblers did) but it didn't seem to allow me to
concatenate macro arguments. So this meant that for an initialisation
of 10 tasks, instead of taking 5 lines of macro declarations, it would
have taken me something like 60 lines of hand-crafted code. You're all
probably thinking "why didn't I write this in C" - well the next
incarnation of this RTOS will be written in C (a larger part of it at
least).
The other reason I chose GNU was that I'm more familiar with Unix
tools. For this reason many of you out there in the other camp would
probably find the GNU Toolset difficult to use.
The 2 final reasons why I chose GNU was the remote debugger GDB and
the cost of the tools. I think GDB is the greatest thing since sliced
bread. In the H8/3048F EVB there is also a Windows version of GDB
called WingGDB. I mainly use the DOS GDB though (old habits die hard).
Cost? Well the H8/3048F EVB which comes with and evaluation board and
all of the GNU toolset was AUD$450 and the SH-1 (7032) EVB (basically
the same as the H8/3048F EVB but configured for the SH-1) is available
for AUD$149. Why is the SH-1 EVB cheaper - I guess Hitachi must be
doing a promotional push. If you are really strapped for cash then you
can get the GNU tools from the 'Net and compile them yourself. I can
do it for Unix, but I'm not sure how to create a DOS system.
But I guess I'm drifting here. My 2nd choice was the IAR tools. I
can't remember whether it included a remote debugger. I'm aware of
another company in Sydney using the IAR tools for H8/300H
devlelopment. They chose the IAR tools mainly because they couldn't
come to terms with the GNU Toolset.
My suggestion is to give the GNU tools a go. Your friendly Hitachi
distributor will have a CDROM that he can lend you with the GNU tools
on it - the GNU Toolset is covered by the FSF lcencing which means
that the tools are free to be distribute. The Cygnus Development Kit
(CDK) is the GNU distribution that comes with the H8/300H and SH-1
EVB's and the libraries are free to use in embedded products.
Sorry for this long article but I always wonder why developers pay
good money when cheap or free quality tools are available on the 'Net.
Ken.
Jason Aspinall
I wouldn't go so far as to say the H8/500 series is dead. It's simply not
in the firing line for new development such like the 300 series.
We use about 14k 534's per annum, we also use handfuls here and there for
automated test jigs etc, etc. They are so bloody useful! Dead easy to
program, fast, loads of bits integrated into them..... Mmm Mmm, lovely!
On saying all of this, we are developing a 3048 into a unit to replace the
534. This is simply to put flash on the board for in-the-field firmware
upgrades. Pricing side of things; now that more people are using the 3048
we can finally get a decent price for a microcontroller with 128k of flash
for around 10GBP. The 534 with only 32k rom space is around 14.5GBP for 15k
annual quantities.
--
Jason Aspinall
CAD Development Engineer
Lion Laboratories plc
thec...@lion-breath.com
http://www.lion-breath.com
Peter wrote in message <34915c47....@news.netcomuk.co.uk>...
>The H8/500 is dead.
Ken Lee
On Mon, 15 Dec 1997 19:22:01 GMT, z...@ds.com (Peter) wrote:
>Ken,
>Thanks for the reply. Here in the UK, Hitachi were pushing the very
>expensive IAR tools exclusively, until a year or two ago, then they
>started giving out the GNU compiler on a CD, and just now I noticed
>they are back to pushing IAR.
I think part of the strategy in promoting a micro is ensuring that you
get quality tools at a reasonable cost. I've no doubt that the IAR
compiler is a good product but paying a couple of thousand (is that
the right order of magnitude?) a seat is a bit expensive for me.
In Australia, Hitachi are pretty aggressive with their push and sell
the SH-1 EVB with all the GNU tools for AUD$149. The H8 EVB is still
expensive at AUD$450. Hitachi however were late in introducing an
integrated CAN in their micros and I think they've missed the boat
there. This is an area that Siemens absolutely dominates.
>I heard their distributors were unhappy about losing the nice margins
>they used to make on IAR tools, so this is possibly why they are back
>to IAR.
I think one of the problems with the GNU toolset is that the supplied
documentation is not sufficient for the non-Unix types. I have an Unix
background so I had no problems. This is maybe why they reverted back
to IAR as well as the mercenary aspects. In Australia, there is a
large Unix-based per capita.
>One of the problems with the H8 family is that while the volumes
>shipped are (by all "reliable" accounts) reasonably high, I suspect
>the number of different customers is not that high. Nowhere near as
>high as e.g. 8051, Z80, and the 80x86 variants. This means that a H8
>compiler won't ever be as thoroughly tested as e.g. a Z80 or 80x86
>compiler. I personally rapidly found, in pretty limited testing, a
>number of bugs in a commercial H8 compiler, I know of various bugs in
>one version of an IAR H8 compiler which I once used, and if the GNU
>compiler was widely used that would give me more confidence than
>anything else.
Yes, I agree - the H8 GNU tools owes its heritage from a common GNU
development tree which is used probably more than any commercial
available product. Also I'm waiting for someone to come up with a GNU
Windows CE suite for the SH-3. There's already a GNU suite for the
PalmPilot which is pretty good.
>The code generation of most compilers today is fairly close,
>especially for the H8 which doesn't require half the code generation
>tricks which a Z80 compiler needs to employ.
Are there still people using the Z80? I know there's the Z180 and I
did in my younger years do quite a lot of development using the
Z-World tools, but I didn't think anyone these days was doing any
serious (new) developments with these micros. I take it back the
GameBoy is of course based on a Z80 derivative. Also I think some PLC
blocks are based on Z80. I guess there's still quite a large hobbyists
market based on this micro.
Where have all the Z80's gone?
Olav Woelfelschneider
Jason Aspinall <thec...@lion-breath.com> wrote in comp.arch.embedded:
JA> On saying all of this, we are developing a 3048 into a unit to replace the
JA> 534.
Not having digged deep into 3048 internas, but knowing about the 534, I would
like to ask you about a few words on the migration path.
Since the architectures of both cpus are similar, I guess it is not that hard.
OTOH, the 3048 surely has another bunch of on-chip peripherals than the
534, which could be an obstacle.
Curious,
Juhani Rantanen
On Thu, 18 Dec 1997 15:49:32 GMT, Peter <z...@ds.com> wrote:
>The Z80, and it more modern derivaties, continues to sell steadily at
>around 50 million per year, according to Zilog. It has sold over a
>billion units to date. I don't know if this includes ASIC versions.
TI-85 uses Z80, and there are quite a few people that like assembly
programming in their TI-85.
--
Juhani Rantanen
Tyvikatu 17 C 13 33340 Tampere http://www.sgic.fi/~misty/
Kehotan samaa sukupuolta olevia keskinäiseen haureuteen
<http://www.iki.fi/liw/haureus.html>
Kjell Esko
Ken Lee wrote:
> I think part of the strategy in promoting a micro is ensuring that you
>
> get quality tools at a reasonable cost. I've no doubt that the IAR
> compiler is a good product but paying a couple of thousand (is that
> the right order of magnitude?) a seat is a bit expensive for me.
The price of an IAR C compiler for the H8 family is 17.000 SEK or around
$2.200.
> I think one of the problems with the GNU toolset is that the supplied
> documentation is not sufficient for the non-Unix types. I have an Unix
>
> background so I had no problems.
IAR also provides UNIX versions of the H8 compiler including
professional documentation.
> >One of the problems with the H8 family is that while the volumes
> >shipped are (by all "reliable" accounts) reasonably high, I suspect
> >the number of different customers is not that high. Nowhere near as
> >high as e.g. 8051, Z80, and the 80x86 variants. This means that a H8
> >compiler won't ever be as thoroughly tested as e.g. a Z80 or 80x86
> >compiler. I personally rapidly found, in pretty limited testing, a
> >number of bugs in a commercial H8 compiler, I know of various bugs in
>
> >one version of an IAR H8 compiler which I once used, and if the GNU
> >compiler was widely used that would give me more confidence than
> >anything else.
> Yes, I agree - the H8 GNU tools owes its heritage from a common GNU
> development tree which is used probably more than any commercial
> available product.
That is actually the case with the IAR C compilers as well. The
compilers are built up using a modular approach with large generic parts
and small target specific parts (mostly in the code generator & assembly
level optimisations). This means that more than 3/4 of the code are
re-used in all products thereby ensuring that all IAR compilers are well
used by many customers regardless if they are supporting
microcontrollers that has many design-ins or not. This is of course one
of the reasons for the high level of stability reached in all IAR
compilers.
> Are there still people using the Z80? I know there's the Z180 and I
> did in my younger years do quite a lot of development using the
> Z-World tools, but I didn't think anyone these days was doing any
> serious (new) developments with these micros.
Yes, there are. IAR has a C compiler for the Z80/180 as well. There are
still many actually using the 8051 so why not the Z80?
Best regards
Kjell Esko
Product Marketing Manager
Hitachi related products
IAR Systems AB
Ken Lee
On Fri, 19 Dec 1997 16:18:03 +0100, Kjell Esko <kjell...@iar.se>
wrote:
>Ken Lee wrote:
>> Are there still people using the Z80? I know there's the Z180 and I
>> did in my younger years do quite a lot of development using the
>> Z-World tools, but I didn't think anyone these days was doing any
>> serious (new) developments with these micros.
>
>Yes, there are. IAR has a C compiler for the Z80/180 as well. There are
>still many actually using the 8051 so why not the Z80?
The 8051 is slighlty different in that it has a lot of different
on-board peripheral configurations to choose from such as ADC, DAC,
serial ports, I2C and even USB. Is this true for the Z80/Z180? If this
is true then I concede to your arguments.
Regards,
Ken.
Christopher Madden
Hi,
Another issue regarding GNU versus IAR is that GNU tools cannot produce
UBROF - IAR tools can.
The emulator that we have (Hitachi PCE3003 ICE) supports UBROF as do many
others.
UBROF: Universal Binary Relocatable Object Format: IAR proprietary.
"UBROF files are application program files that have been compiled such that
the debug, C source and symbolic information is available, in addition to
the application object code."
The distributor that we use supplies IAR and GNU tools and emulators for the
H8 so I have asked them about this. They have already said that they will
not provide support if GNU tools are used. I am awaiting a response on
whether it is possible to get an UBROF equivalent with the GNU tools for use
with the Hitachi PCE3003 ICE.
Cheers,
Chris
>
>>Thanks for the reply. Here in the UK, Hitachi were pushing the very
>>expensive IAR tools exclusively, until a year or two ago, then they
>>started giving out the GNU compiler on a CD, and just now I noticed
>>they are back to pushing IAR.
>
.........SNIP.........SNIP.........SNIP.........SNIP.........SNIP.
>
>>I heard their distributors were unhappy about losing the nice margins
>>they used to make on IAR tools, so this is possibly why they are back
>>to IAR.
>I think one of the problems with the GNU toolset is that the supplied
>documentation is not sufficient for the non-Unix types. I have an Unix
Kjell Esko
Ken Lee wrote:
> Ken Lee wrote:
> The 8051 is slighlty different in that it has a lot of different
> on-board peripheral configurations to choose from such as ADC, DAC,
> serial ports, I2C and even USB. Is this true for the Z80/Z180? If this
>
> is true then I concede to your arguments.
You are correct Ken. My point however is that if you have a lot of code
already written for an old micro, you tend to try and stay with that
micro as long as possible, really tweeking things to the extreme. That
goes for the Z80 as well as for the 8051. There exists a lot of new
micros that are much easier to use and in many (most) cases suits the
application much better than the 8051, but engineers still prefer to use
it.
This is what we at IAR base our business idea upon. By providing
development tools for many different architectures but still maintaining
the same user interface and programming style, we enable our customers
to use the best possible microcontroller in each project instead of
limiting himself to the one micro he has the code written for
originally. By doing this we limit the lines of code that have to be
rewritten (that are target specific or written in asm). One of our
customers that had an application of over 600 KB in size, ported their
source code from one architecture to a completely new one in less than
one week!
It should not be the development tools that limits what options the
developer has in a project.
Best regards,
Kjell Esko
IAR Systems AB
Kjell Esko
Peter wrote:
> Good to see a post from a real hardware/software vendor!
Thank you!
> Also, this generic approach unfortunately cuts both ways. One can get
> sub-optimal code generation. I once (in 1991) spent a lot of time
> optimising a program originally written in IAR Z80 C (target was the
> Z180) into assembler. We had to make runtime savings of several times,
>
> and were unable to further optimise the algorithm.
>
> I do not know if IAR compilers have much improved in recent years, but
>
> I know of one other compiler whose output I could not optimise to
> anywhere near the same degree. But I found "quiet" bugs in that
> compiler too.
Since the beginning of the 90's the IAR tools has gone through several
major revisions. These revisions has had the goal of improving the
optimizations in our compilers as well as making them more generic and
thus more stable. As you say, many of the bugs tend to occur in the
target specific parts and the way for IAR to attack that problem has
been to develop programming models for how the target specific code
should be written as well as to continuoulsy update our test system.
That way, we have been able to both increase the level of optimization
and the reliability of our products significantly.
> The bottom line is that there is no free lunch. The only way to get a
> debugged tool is by carefully writing it, thoroughly testing it, and
> having plenty of people actually using it.
I agree. IAR have over 20.000 users world-wide on top of the programming
and test system described above. We are serious in providing efficient,
stable and easy-to-use development tools.
Robert
Maybe a little late to join this discussion of the H8, but because of
vacation and other work, I just saw the discussion today.
I have been using the H8 for already some years, the h8/330, 338, 325 and
now a new project with the 3048F. I have always used this line with no
problems and want to keep using it a little longer.
I have always used the IAR compiler. I think its a good compiler, a little
expensive and a little to many bugs in it. But on the other hand the
support was always good. If I had a bugreport, I always got a newer
version. But now they have changed the compiler a little bit in a way
which is not compatible any more with the older version.
So that is why a wanted to take a look at the GNU compiler which is on the
CDROM. It looks fine and is for free. But has no documentation, the
supplied documentation is only general documentation and, for me, hard to
use (UNIX format?).
The biggest problem is that the library is not complete, or I made some
mistakes. When I use a program with e.g. sprinf, the linker complains that
this is not in the library.
Is this true, or do I just make some mistake? I can't find anything of a
library I must include. Maybe someone can help me.
Greetings
Robert Pot
Ken Lee
On Mon, 05 Jan 1998 09:58:21 +0100, Robert <obser...@pi.net> wrote:
[text deleted]
>So that is why a wanted to take a look at the GNU compiler which is on the
>CDROM. It looks fine and is for free. But has no documentation, the
>supplied documentation is only general documentation and, for me, hard to
>use (UNIX format?).
If you get the Hitachi HiView CDROM, the GNU manuals are in PDF form.
Actually I could be wrong here as I got 3 CDROMs with the SH7032 EVB
board. The GNU manuals were in PDF form but I can't recall if it was
on the HiView distribution.
Incidentally the HiView CDROMs have SH-1 and H8/300 & H8/300H
versions.
>The biggest problem is that the library is not complete, or I made some
>mistakes. When I use a program with e.g. sprinf, the linker complains that
>this is not in the library.
>
>Is this true, or do I just make some mistake? I can't find anything of a
>library I must include. Maybe someone can help me.
Sprintf is certainly with the Hitachi-CDK distribution of the GNU
toolset. Could it be that you haven't included the library for
linking? I've been using the H8/3003 and H8/3048F EVB's and sprintf is
included with these.
My suggestion would be to get a copy of HiView CDROMs from your
Hitachi distributor - it's free (or it was for me anyway - it pays to
send them a Christmas card).
Regards,
Ken.
Ralf Corsepius
Robert wrote:
> The biggest problem is that the library is not complete, or I made some
> mistakes. When I use a program with e.g. sprinf, the linker complains that
> this is not in the library.
>
> Is this true, or do I just make some mistake? I can't find anything of a
> library I must include. Maybe someone can help me.
>
newlib might be what you are looking for (ftp://ftp.cygnus.com/pub/newlib)You
might consider also to have a look at the crossgcc-FAQ:
ftp://ftp.cygnus.com/pub/embedded/crossgcc/FAQ-0.8.1
Ralf.
Ibrahim Kolbas
"sprintf" is present in its full glory in "libc.a". Consider using the more
efficient (and working) version I've posted in this newsgroup for Peter.
Ibrahim
Robert
Thanks for your response. It looks like there are more kind of CDROM available.
The one I have is one which comes with the evaluation boards and one with the
databook on it, but it looks like I have to get another one.
Regards,
Robert
Ken Lee wrote:
> On Mon, 05 Jan 1998 09:58:21 +0100, Robert <obser...@pi.net> wrote:
>
>
> If you get the Hitachi HiView CDROM, the GNU manuals are in PDF form.
> Actually I could be wrong here as I got 3 CDROMs with the SH7032 EVB
> board. The GNU manuals were in PDF form but I can't recall if it was
> on the HiView distribution.
>
> Incidentally the HiView CDROMs have SH-1 and H8/300 & H8/300H
> versions.
>
Ken Lee
On Tue, 13 Jan 1998 08:56:16 +0100, Robert <obser...@pi.net> wrote:
>Thanks for your response. It looks like there are more kind of CDROM available.
>
>The one I have is one which comes with the evaluation boards and one with the
>databook on it, but it looks like I have to get another one.
>
>Regards,
>Robert
The HiView distribution or the "Hitachi Visual Integrated Engineering
Workplace" (the label on the CDROM) is meant to be distributed with
the EVB's, both H8/300H and SH-X. It may be that you've could got some
old stock of the EVB (which has only the Cygnus distribution) so
you'll have to ask for the CDROM separate;ly
Ken.