Reply by Steve at fivetrees●August 7, 20062006-08-07
"Ulf" <gebrauchtteile@arcor.de> wrote in message
news:eb824s.nk.1@gebrauchtteile.arcor.de...
On Sun, 6 Aug 2006 15:38:23 +0100 Steve at fivetrees wrote:
>Conditional compilation is your friend. For example, somewhere in a header
>(e.g. builds.h) use:
>> Sure, I know how to use the preprocessor. <<
Oops. Of course you do. Apologies. </me adjusts reading glasses>
>// Comment out for production:
>#define Debug 1
>
>In the code:
>
>#ifdef Debug
> printf( "Something happened.\n" );
>#endif
>> 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. <<
Yes, point taken. I've experimented with macros to avoid the visual
distraction of the conditional compilation directives, but I do tend to
still use them. I think I've got used to them.
>> 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. <<
Again, agreed.
>> 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. <<
Yesbutnobut... On platforms that permit it, I do like to have a kind of log
output during development. Right now I'm working on something that requires
a lot of TCP socket juggling, and it's useful to be able to watch the states
changing etc. My emphasis here is on development rather than purely
debugging. (In practice, I often have a verbosity setting too.) This slight
change of emphasis means that my log output is an integral part of the
product (albeit only for internal use), rather than something that gets
hacked in a panic. This mostly keeps me out of trouble ;).
The project I'm working on now does provide a debugger - I think I've used
it once, early on. I'm so used to being debugger-less it's not really an
issue.
Steve
http://www.fivetrees.com
Reply by Ulf●August 7, 20062006-08-07
On Sun, 6 Aug 2006 15:38:23 +0100 Steve at fivetrees wrote:
>Conditional compilation is your friend. For example, somewhere in a =
header=20
>(e.g. builds.h) use:
Sure, I know how to use the preprocessor.
>// Comment out for production:
>#define Debug 1
>
>In the code:
>
>#ifdef Debug
> printf( "Something happened.\n" );
>#endif
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.
>Steve
Ulf
Reply by ●August 7, 20062006-08-07
On Monday, in article
<44d6d8b4$0$21271$5a62ac22@per-qv1-newsreader-01.iinet.net.au>
markm@vl.com.au "Mark McDougall" wrote:
>Grant Edwards wrote:
>
>> 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.
>
>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?!?
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.
>Sorry - a little knowledge is a dangerous thing! ;)
>
>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.
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,
--
Mark McDougall, Engineer
Virtual Logic Pty Ltd, <http://www.vl.com.au>
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266
Reply by Grant Edwards●August 7, 20062006-08-07
On 2006-08-07, Mark McDougall <markm@vl.com.au> wrote:
>> 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/
>
> 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...
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).
--
Grant Edwards grante Yow! WHOA!! Ken and
at Barbie are having TOO
visi.com MUCH FUN!! It must be the
NEGATIVE IONS!!
Reply by Mark McDougall●August 6, 20062006-08-06
Grant Edwards wrote:
> 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/
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,
--
Mark McDougall, Engineer
Virtual Logic Pty Ltd, <http://www.vl.com.au>
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266
Reply by ●August 6, 20062006-08-06
On Sunday, in article
<ibtBg.8994$N64.2098@newsfe1-gui.ntli.net>
peter_harrison@ntlworld.com "Peter Harrison" wrote:
>Paul Carpenter wrote:
>>
>> The H8 does have 32 bit registers.
>>
>> The main problems come from the simple fact that quite a few I/O regsiters
>> can be accessed as 16 bit as well as 8 bit or just 8 bit or just 16 bit.
>> Now compound this with the problem that Renesas love to use int in their
>> I/O headers and GCC at least for H8 series has the ability to 'promote'
>> all ints to 32 bit (but not short) and the combination as I originally
>> stated is not portable within the same processor for different applications.
>> If int is 32 bit your bit fields are done as 32 bit, your unions with int
>> are 32 bit so the I/O header file is next to useless.
>>
>> I nearly always write my own to avoid some of the problems that can be
>> caused by Renesas I/O header files whose EULA for their use (when downloaded)
>> has clauses about not modifying them!
>>
>> The Renesas I/O headers are NOT portable for use on GCC and probably other
>> compilers for the SAME processor!
>>
>
>So the Renesas headers are not really safe with GCC? I suppose they were
Not safe with at LEAST GCC.
>written with the Hitachi compiler in mind (or was that a disguised GCC
Whatever that is these days as that appears to change regularly.
>port as some seem to be). It would be interesting to find some
>demonstration cases where incorrect compiler output were generated.
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.
>I don't suppose there is any other publicly available source of I/O
>headers for these devices?
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.
>Come to that, is there any kind of general convention for these things
>that I could read about?
>
> The H8 does have 32 bit registers.
>
> The main problems come from the simple fact that quite a few I/O regsiters
> can be accessed as 16 bit as well as 8 bit or just 8 bit or just 16 bit.
> Now compound this with the problem that Renesas love to use int in their
> I/O headers and GCC at least for H8 series has the ability to 'promote'
> all ints to 32 bit (but not short) and the combination as I originally
> stated is not portable within the same processor for different applications.
> If int is 32 bit your bit fields are done as 32 bit, your unions with int
> are 32 bit so the I/O header file is next to useless.
>
> I nearly always write my own to avoid some of the problems that can be
> caused by Renesas I/O header files whose EULA for their use (when downloaded)
> has clauses about not modifying them!
>
> The Renesas I/O headers are NOT portable for use on GCC and probably other
> compilers for the SAME processor!
>
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
Reply by ●August 6, 20062006-08-06
On Sunday, in article
<oImBg.8164$N64.4743@newsfe1-gui.ntli.net>
peter_harrison@ntlworld.com "Peter Harrison" wrote:
>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;
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.
>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);
Any code without comments is always a problem no matter what the I/O register
names are as I have seen all sorts of silly names for the other variables
that make it just as confusing. using your example
AD.ADCSR.BIT.SCAN = control.fred.wilma;
AD.ADCSR.BIT.CH = control.rubble.dino;
I have seen some nightmares like that and worse, search for Jack Ganssle's
papers on his site about readability and long names.
Readability is about the whole thing not just the I/O headers. giving
someone I/O Header files does not cure it it is only a small part of the
solution.
>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?
The H8 does have 32 bit registers.
The main problems come from the simple fact that quite a few I/O regsiters
can be accessed as 16 bit as well as 8 bit or just 8 bit or just 16 bit.
Now compound this with the problem that Renesas love to use int in their
I/O headers and GCC at least for H8 series has the ability to 'promote'
all ints to 32 bit (but not short) and the combination as I originally
stated is not portable within the same processor for different applications.
If int is 32 bit your bit fields are done as 32 bit, your unions with int
are 32 bit so the I/O header file is next to useless.
I nearly always write my own to avoid some of the problems that can be
caused by Renesas I/O header files whose EULA for their use (when downloaded)
has clauses about not modifying them!
>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.
The use of structures can depend on how good the compiler is at getting
down to bit manipulation instructions. Not all compilers will translate
AD.ASCR.BIT.SCAN = 0
to Bit clear the scan bit in ADCSR register
Then it depends on the instruction set if the register can be
directly bit manipulated anyway.
When limited on code space or execution time (e.g. in ISR) several bit
manipulations are not always made into a single operation your example
ADCSR = (ACDSR & 0xFE) | channel;
May well translate into machine code of
Read ADCSR to R0
And R0, 0xFE
Or R0, channel
mov R0, ADCSR
Where as the several bit manipulations depending on architecture and compiler
could well end up as a lot more instructions, on PIC you nearly always have
to get the data into W register anyway to manipulate it and store back.
Some compilers cannot work backwards from several bit manipulations from
bit field structures, to what it is, as a byte/word operation.
Directly doing bit manipulations on some I/O registers is not recommended
due to the way they operate anyway.
Unless you can be sure that the I/O header is portable across applications
on the same processor or family under the same compiler, using bit fields
is always dangerous. Using bit fields on RAM operations is a different
matter entirely.
The Renesas I/O headers are NOT portable for use on GCC and probably other
compilers for the SAME processor!
--
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
Reply by Steve at fivetrees●August 6, 20062006-08-06
"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