Hot!TMR1 as volatile variable or not

Page: < 12 Showing page 2 of 2
Author
RISC
Super Member
  • Total Posts : 4744
  • Reward points : 0
  • Status: offline
Re: TMR1 as volatile variable or not 2017/10/13 05:00:09 (permalink)
+3 (3)
Hi,
You should not assume the order in which the compiler will access the high and low parts when you manipulate 16bit values on an 8 bits uC. This is not specified by C language standard and therefore implementation specific. This may even be changed if you use the optimizer...
I personally always do this as separate instructions to make sure the order I need will be granted.
Regards
 
#21
DarioG
farewell.
  • Total Posts : 53177
  • Reward points : 0
  • Joined: 2006/02/25 08:58:22
  • Location: porcodioland
  • Status: offline
Re: TMR1 as volatile variable or not 2017/10/13 05:04:11 (permalink)
0
Maybe that's why there was also a function version Smile
(I think it can be grabbed from old plib as well; anyway, writing own's code and learning ... is even better!)

forget about me, subhumans. adieu

#22
qhb
Superb Member
  • Total Posts : 6258
  • Reward points : 0
  • Joined: 2016/06/05 14:55:32
  • Location: One step ahead...
  • Status: offline
Re: TMR1 as volatile variable or not 2017/10/13 05:06:47 (permalink)
+2 (2)
RISC
You should not assume the order in which the compiler will access the high and low parts when you manipulate 16bit values on an 8 bits uC. This is not specified by C language standard and therefore implementation specific. This may even be changed if you use the optimizer...

However, if you use the macro supplied with the compiler, you'd assume they know what they are doing...
 
#23
naeem1234
Super Member
  • Total Posts : 229
  • Reward points : 0
  • Joined: 2015/02/19 06:39:28
  • Location: 0
  • Status: offline
Re: TMR1 as volatile variable or not 2017/10/13 05:20:14 (permalink)
0
DarioG
 
... anyway, writing own's code and learning ... is even better!


 
In that case do you think this will work, specially the order in which high and low bytes are declared?
 

union{
struct{
unsigned char t1hi;
unsigned char t1lo;
}s_timer1;
unsigned int timer1;
}u_timer1;

#24
1and0
Access is Denied
  • Total Posts : 7332
  • Reward points : 0
  • Joined: 2007/05/06 12:03:20
  • Location: Harry's Gray Matter
  • Status: offline
Re: TMR1 as volatile variable or not 2017/10/13 06:03:13 (permalink)
+3 (3)
naeem1234
In that case do you think this will work, specially the order in which high and low bytes are declared?
union{
struct{
unsigned char t1hi;
unsigned char t1lo;
}s_timer1;
unsigned int timer1;
}u_timer1;


It is not about how the bytes are declared.  It is the order in which the low and high bytes of the timer are accessed.  Read the PIC datasheet.
#25
naeem1234
Super Member
  • Total Posts : 229
  • Reward points : 0
  • Joined: 2015/02/19 06:39:28
  • Location: 0
  • Status: offline
Re: TMR1 as volatile variable or not 2017/10/16 09:51:57 (permalink)
0
If i do read or write on 16-bit timer1 after stopping the timer will that be the best way to stay safe of any wrong read or write operation on 8-bit mcu?
#26
jtemples
Super Member
  • Total Posts : 10432
  • Reward points : 0
  • Joined: 2004/02/13 12:31:19
  • Location: Southern California
  • Status: offline
Re: TMR1 as volatile variable or not 2017/10/16 11:05:09 (permalink)
+2 (2)
If i do read or write on 16-bit timer1 after stopping the timer will that be the best way to stay safe of any wrong read or write operation on 8-bit mcu?

 
The whole point of the timer's read/write latches is so you don't have to stop the timer or do other special code when accessing the timer.
#27
naeem1234
Super Member
  • Total Posts : 229
  • Reward points : 0
  • Joined: 2015/02/19 06:39:28
  • Location: 0
  • Status: offline
Re: TMR1 as volatile variable or not 2017/10/16 11:20:24 (permalink)
0
jtemples
If i do read or write on 16-bit timer1 after stopping the timer will that be the best way to stay safe of any wrong read or write operation on 8-bit mcu?

 
The whole point of the timer's read/write latches is so you don't have to stop the timer or do other special code when accessing the timer.




Alternatively if i disable global interrupts before reading or writing the 16-bit timer1 will that be safe enough without doing any special code for accessing the timer?
#28
jtemples
Super Member
  • Total Posts : 10432
  • Reward points : 0
  • Joined: 2004/02/13 12:31:19
  • Location: Southern California
  • Status: offline
Re: TMR1 as volatile variable or not 2017/10/16 11:34:22 (permalink)
+2 (2)
Alternatively if i disable global interrupts before reading or writing the 16-bit timer1 will that be safe enough without doing any special code for accessing the timer?

 
Disabling interrupts is doing special code.  And no, it doesn't help, because the timer is still running and you have to worry about rollover issues.
#29
qhb
Superb Member
  • Total Posts : 6258
  • Reward points : 0
  • Joined: 2016/06/05 14:55:32
  • Location: One step ahead...
  • Status: offline
Re: TMR1 as volatile variable or not 2017/10/16 12:29:59 (permalink)
+4 (4)
naeem1234
If i do read or write on 16-bit timer1 after stopping the timer will that be the best way to stay safe of any wrong read or write operation on 8-bit mcu?


Why are you still asking questions when the best solution was identified three days ago?
Just use the macros supplied in pic18.h. That is what they are for.
They are supplied with the compiler, so they are guaranteed to work.
 
 
#30
Ian.M
Super Member
  • Total Posts : 13087
  • Reward points : 0
  • Joined: 2009/07/23 07:02:40
  • Location: UK
  • Status: online
Re: TMR1 as volatile variable or not 2017/10/16 13:31:29 (permalink)
+3 (3)
.... and it is guaranteed that they will be maintained so they continue to work if a future version switches the byte operation order.   Copying those macros in your own code may silently fail with some future compiler update, so don't do that!   The function version will continue to work because the accesses to the volatile registers are separated by sequence points and the C standard doesn't permit them to be reordered.  Its impossible to write a reliable macro version that wont need modifying on compiler version updates and doesn't use a pre-declared temp variable without insider knowledge,  because there are very few operators that are sequence points inside a C expression, and the only one that is usable, the comma operator, doesn't pass any value across the comma.

--
NEW USERS: Posting images, links and code - workaround for restrictions.
I also support http://picforum.ric323.com because this forum is sometimes too broken to use!
#31
naeem1234
Super Member
  • Total Posts : 229
  • Reward points : 0
  • Joined: 2015/02/19 06:39:28
  • Location: 0
  • Status: offline
Re: TMR1 as volatile variable or not 2017/10/16 20:49:41 (permalink)
-1 (1)
qhb
 
Why are you still asking questions when the best solution was identified three days ago?
Just use the macros supplied in pic18.h. That is what they are for.
They are supplied with the compiler, so they are guaranteed to work.
 

 
Would you kindly tell about the RD16 flag for the above macros, should it be set or cleared?
#32
qhb
Superb Member
  • Total Posts : 6258
  • Reward points : 0
  • Joined: 2016/06/05 14:55:32
  • Location: One step ahead...
  • Status: offline
Re: TMR1 as volatile variable or not 2017/10/16 20:59:53 (permalink)
+2 (2)
RD16 should be set.
I already emphasised that back in post#15.
 
#33
1and0
Access is Denied
  • Total Posts : 7332
  • Reward points : 0
  • Joined: 2007/05/06 12:03:20
  • Location: Harry's Gray Matter
  • Status: offline
Re: TMR1 as volatile variable or not 2017/10/17 04:17:40 (permalink)
+2 (2)
qhb
pic18.h contains these lines:

#define WRITETIMER0(x) ((void)(TMR0H=((x)>>8),TMR0L=((x)&0xFF)))
#define WRITETIMER1(x) ((void)(TMR1H=((x)>>8),TMR1L=((x)&0xFF)))
#define WRITETIMER3(x) ((void)(TMR3H=((x)>>8),TMR3L=((x)&0xFF)))


What is the (void) for and is it necessary here?
 
<edit> After a quick search online, the (void) is so the macro does not return a value, which would be that of the last operand of the comma operation; in this case, it's ((x)&0xFF).
post edited by 1and0 - 2017/10/17 04:54:23
#34
Page: < 12 Showing page 2 of 2
Jump to:
© 2018 APG vNext Commercial Version 4.5