On Thursday, in article
<BUHyG3A$3xoAFA7B@phaedsys.demon.co.uk> chris@phaedsys.org
"Chris Hills" wrote:
>In article <20040512.2235.299232snz@pcserv.demon.co.uk>, Paul Carpenter
><paul$@pcserv.demon.co.uk> writes
>>>
>>>int and short are both 16 bit on this compiler.
>>
>>They are on quite a few, but it is possible on some like GCC
>>to force ALL ints to 32bit, which may be his problem, or how
>>the link to the simulator is doing it.
>
>As I said on THIS compiler both are 16 bits. The compiler being
>discussed was the Keil compiler.
All compilers have options, I never said it was the problem, but
'may be his problem', which is slightly different.
>What has Gcc got to do with this? Just because Gcc is incorrect it is
>no reason to assume other compilers will be.
He claimed in an earlier post that he was getting 32bit values (probably
finger trouble or simulator operation issue), however there are always
possibilities of misconfiguring compilation.
It is not 'incorrect' for GCC in general to do this as on some processors
some registers can be accessed as 32 bit and 32 bit operations exist for them
as well. Hence for some applications it is a choice, whether it is a
good choice is not a matter I would want to debate. For this processor
I would never remotely suggest it should be used, but some people assume
more bits is always better.
--
Paul Carpenter | paul@pcserv.demon.co.uk
<http://www.pcserv.demon.co.uk/> Main Site
<http://www.gnuh8.org.uk/> GNU H8 & mailing list info.
<http://www.badweb.org.uk/> For those web sites you hate.
Reply by Hans-Bernhard Broeker●May 13, 20042004-05-13
Roman Mashak <mrv@tusur.ru> wrote:
> Thank you all for help! Problem was solved by compulsory setting
> the TR2 bit to '0' before making calculations of high & low bytes.
In other words: the problem was not that TL2 was being *set* to the
wrong value, as you claimed it was, but rather that by the time you
inspected it, the timer had already ticked up several counts from
there.
Lesson learned: if you want to observe what actually gets written into
a timer or other volatile storage, you have to set a break on the very
machine instruction that *sets* it, and check what the value being
written actually is.
--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
Reply by Chris Hills●May 13, 20042004-05-13
In article <20040512.2235.299232snz@pcserv.demon.co.uk>, Paul Carpenter
<paul$@pcserv.demon.co.uk> writes
>>
>>int and short are both 16 bit on this compiler.
>
>They are on quite a few, but it is possible on some like GCC
>to force ALL ints to 32bit, which may be his problem, or how
>the link to the simulator is doing it.
As I said on THIS compiler both are 16 bits. The compiler being
discussed was the Keil compiler.
What has Gcc got to do with this? Just because Gcc is incorrect it is
no reason to assume other compilers will be.
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\
/\/\/ chris@phaedsys.org www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Reply by Roman Mashak●May 12, 20042004-05-12
Hello, nospam!
You wrote on Wed, 12 May 2004 14:22:13 +0100:
??>> Reload_08H = (tByte)(Reload_16 / 256);
??>> Reload_08L = (tByte)(Reload_16 % 256);
??>>
??>> In this case I got the following:
??>>
??>> 'Inc' is calculated correctly, 'Reload_16' also....
??>> Reload_08H got 0x8A (OK), Reload_08L is 0xCF - why? If we make '%'
??>> operation (35535 % 256) - it should take division remainder, i.e. 80.
n> 35535 is 0x8ACF so the 0xCF is correct
??>> And now is the most intersting: TH2 and TL2. TH2 is assigned
??>> correctly, i.e. 0x8A, but TL2 is 0xD1 now, so it was increased with 2,
??>> why?
Thank you all for help! Problem was solved by compulsory setting the TR2
bit to '0' before making calculations of high & low bytes.
Sorry for making traffic about this simple problem :)
With best regards, Roman Mashak. E-mail: mrv@tusur.ru
Reply by Roman Mashak●May 12, 20042004-05-12
Hello, Hans-Bernhard!
You wrote on 12 May 2004 13:10:38 GMT:
??>> Yes, I tried, but nothing changed.... They all have the same width
??>> - 32 bits.
HBB> Most certainly not. On an 8051 compiler, both int and short will
HBB> almost invariably be 16-bit data types. You don't want to use 32 bit
HBB> types any more than you absolutely have to, on such a small CPU.
Yes, you absolutely right. My mistake, I misprinted....
??>> So, TH2 is correctly setup (0x8A), RCAP2H also, BUT TL2 is incorrectly
??>> setup (0xD1 instead of 0xCF), while RCAP2L is fine!
HBB> I'm still not convinced. Show actual assembly output from the listing
HBB> file please.
Here is a full assembler output of function I got after compilation:
0000 75C804 MOV T2CON,#04H
0003 E4 CLR A
0004 FC MOV R4,A
0005 FD MOV R5,A
0006 FE MOV R6,A
0007 7BE0 MOV R3,#0E0H
0009 7A2E MOV R2,#02EH
000B F9 MOV R1,A
000C F8 MOV R0,A
000D 120000 E LCALL ?C?LMUL
0010 E4 CLR A
0011 7B0C MOV R3,#0CH
0013 FA MOV R2,A
0014 F9 MOV R1,A
0015 F8 MOV R0,A
0016 120000 E LCALL ?C?ULDIV
0019 8F00 R MOV Inc+03H,R7
001B 8E00 R MOV Inc+02H,R6
001D 8D00 R MOV Inc+01H,R5
001F 8C00 R MOV Inc,R4
; SOURCE LINE # 82
0021 C3 CLR C
0022 74FF MOV A,#0FFH
0024 9F SUBB A,R7
0025 F500 R MOV Reload_16+01H,A
0027 74FF MOV A,#0FFH
0029 9E SUBB A,R6
002A F500 R MOV Reload_16,A
; SOURCE LINE # 87
002C F500 R MOV Reload_08H,A
; SOURCE LINE # 88
002E 850000 R MOV Reload_08L,Reload_16+01H
; SOURCE LINE # 89
0031 750000 R MOV Reload_16,#00H
; SOURCE LINE # 95
0034 8500CD R MOV TH2,Reload_08H
; SOURCE LINE # 96
0037 8500CB R MOV RCAP2H,Reload_08H
; SOURCE LINE # 97
003A 8500CC R MOV TL2,Reload_08L
; SOURCE LINE # 98
003D 8500CA R MOV RCAP2L,Reload_08L
; SOURCE LINE # 102
0040 D2AD SETB ET2
; SOURCE LINE # 105
0042 D2CA SETB TR2
; SOURCE LINE # 107
0044 D2AF SETB EA
; SOURCE LINE # 108
0046 22 RET
With best regards, Roman Mashak. E-mail: mrv@tusur.ru
Reply by Paul Carpenter●May 12, 20042004-05-12
On Wednesday, in article
<V8K3coAIkpoAFAbl@phaedsys.demon.co.uk> chris@phaedsys.org
"Chris Hills" wrote:
>In article <20040512.0217.299219snz@pcserv.demon.co.uk>, Paul Carpenter
><paul$@pcserv.demon.co.uk> writes
>>On Wednesday, in article <c7robl$1tmc$1@mpeks.tomsk.su>
>> mrv@tusur.ru "Roman Mashak" wrote:
>>>Hello, Not!
>>>You wrote on Tue, 11 May 2004 10:00:44 -0600:
>>>
>>> NRM> Try this change. It may not be the "correct" solution, but it seems
>>> NRM> to work:
>>>
>>> NRM> void Init_Timer2( const tByte tick)
>>> NRM> {
>>> NRM> static tLong Inc, Reload_long;
>>> NRM> static tWord Reload_16;
>>> NRM> tByte Reload_08H, Reload_08L;
>>>
>>> NRM> // Timer 2 is configured as a 16-bit timer,
>>> NRM> // which is automatically reloaded when it overflows
>>> NRM> T2CON = 0x04; // Load Timer 2 control register
>>>
>>> NRM> // Number of timer increments required (max 65536)
>>> NRM> Inc = ((tLong)TICK_MS * (OSC_FREQ/1000)) / (tLong)OSC_PER_INST;
>>>
>>> NRM> // 16-bit reload value
>>> NRM> Reload_long = (tLong) (65536UL - Inc);
>>> NRM> Reload_16 = (tWord) Reload_long;
>>>
>>> Thank you very much! It's really worked out.
>>> It seems compiler cannot make type casting correctly and assign 'tLong'
>>>value to 'tWord' variable ?
>>
>>Have you checked whether you have something set in the compiler to say
>>an 'int' is 32 bit?
>>
>>Try using tWord defined as an unsigned short?
>
>int and short are both 16 bit on this compiler.
They are on quite a few, but it is possible on some like GCC
to force ALL ints to 32bit, which may be his problem, or how
the link to the simulator is doing it.
--
Paul Carpenter | paul@pcserv.demon.co.uk
<http://www.pcserv.demon.co.uk/> Main Site
<http://www.gnuh8.org.uk/> GNU H8 & mailing list info.
<http://www.badweb.org.uk/> For those web sites you hate.
Reply by Chris Hills●May 12, 20042004-05-12
In article <20040512.0217.299219snz@pcserv.demon.co.uk>, Paul Carpenter
<paul$@pcserv.demon.co.uk> writes
>On Wednesday, in article <c7robl$1tmc$1@mpeks.tomsk.su>
> mrv@tusur.ru "Roman Mashak" wrote:
>>Hello, Not!
>>You wrote on Tue, 11 May 2004 10:00:44 -0600:
>>
>> NRM> Try this change. It may not be the "correct" solution, but it seems
>> NRM> to work:
>>
>> NRM> void Init_Timer2( const tByte tick)
>> NRM> {
>> NRM> static tLong Inc, Reload_long;
>> NRM> static tWord Reload_16;
>> NRM> tByte Reload_08H, Reload_08L;
>>
>> NRM> // Timer 2 is configured as a 16-bit timer,
>> NRM> // which is automatically reloaded when it overflows
>> NRM> T2CON = 0x04; // Load Timer 2 control register
>>
>> NRM> // Number of timer increments required (max 65536)
>> NRM> Inc = ((tLong)TICK_MS * (OSC_FREQ/1000)) / (tLong)OSC_PER_INST;
>>
>> NRM> // 16-bit reload value
>> NRM> Reload_long = (tLong) (65536UL - Inc);
>> NRM> Reload_16 = (tWord) Reload_long;
>>
>> Thank you very much! It's really worked out.
>> It seems compiler cannot make type casting correctly and assign 'tLong'
>>value to 'tWord' variable ?
>
>Have you checked whether you have something set in the compiler to say
>an 'int' is 32 bit?
>
>Try using tWord defined as an unsigned short?
int and short are both 16 bit on this compiler.
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\
/\/\/ chris@phaedsys.org www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Reply by nospam●May 12, 20042004-05-12
"Roman Mashak" <mrv@tusur.ru> wrote:
>
> Reload_08H = (tByte)(Reload_16 / 256);
> Reload_08L = (tByte)(Reload_16 % 256);
>
> In this case I got the following:
>
> 'Inc' is calculated correctly, 'Reload_16' also....
> Reload_08H got 0x8A (OK), Reload_08L is 0xCF - why? If we make '%'
>operation (35535 % 256) - it should take division remainder, i.e. 80.
35535 is 0x8ACF so the 0xCF is correct
> And now is the most intersting: TH2 and TL2. TH2 is assigned correctly,
>i.e. 0x8A, but TL2 is 0xD1 now, so it was increased with 2, why?
Without checking the timer documentation and modes I am not sure but make
sure the timer is stopped before you configure it and configured in the
right mode before you start it. It is the function of the timer in some
modes to increment TL2 so the value you load may be incremented by the
timer hardware before you inspect it.
Reply by Hans-Bernhard Broeker●May 12, 20042004-05-12
Roman Mashak <mrv@tusur.ru> wrote:
> PC> Try using tWord defined as an unsigned short?
> Yes, I tried, but nothing changed.... They all have the same width - 32
> bits.
Most certainly not. On an 8051 compiler, both int and short will
almost invariably be 16-bit data types. You don't want to use 32 bit
types any more than you absolutely have to, on such a small CPU.
> So, TH2 is correctly setup (0x8A), RCAP2H also, BUT TL2 is incorrectly setup
> (0xD1 instead of 0xCF), while RCAP2L is fine!
I'm still not convinced. Show actual assembly output from the listing
file please.
--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
Reply by Roman Mashak●May 12, 20042004-05-12
Hello, Paul!
You wrote on Wed, 12 May 2004 06:49:09 +0000 (UTC):
??>> 'Inc' is calculated correctly, 'Reload_16' also....
??>> Reload_08H got 0x8A (OK), Reload_08L is 0xCF - why? If we make '%'
??>> operation (35535 % 256) - it should take division remainder, i.e. 80.
PC> Why are you not just simply getting the low byte by anding with 0xFF ?
PC> It may just by that the modulus function is not correctly linked in.
PC> Use a simpler method as modulus '%' is nearly always some form of
PC> library function, which can need all sorts of extra code loaded.
As I said before, I'm studying this microcontroller, so I would like to
understand this code, and find the error!
By the way, this source code was provided in the book by Michael J. Pont
"Embedded C".
With best regards, Roman Mashak. E-mail: mrv@tusur.ru