Timer Library?
AlbertF
I was thinking of creating a generic library for the 8 and 16 bit
timers. For almost every project with PICs I've used the timers wihin
the PICs. So I browsed through my JAL source files and looked for a
common timer pattern(s) I've used. Below a first shot how the
interface, which can be used to start the discussion. In addition it
would be nice to have a wiki page with the timer related registers
(Seb?).
const TIMERX_TICKS_PER_SECOND = 1200
-- reset timer, set value to 0
procedure timerX_reset() is
end procedure
-- enable timer X
procedure timerX_enable() is
end procedure
-- disable timer X
procedure timerX_disable() is
end procedure
-- get the current timer value
function timer1_get() return word is
end function
-- block until ticks value < timer value
procedure timer_wait_till_tick( word in ticks) is
end procedure
-- initialize timer
procedure timer1_init() is
end procedure
-- enable timer X
procedure timerX_enable_interrupt() is
end procedure
-- disable timer X
procedure timerX_disable_interrupt() is
end procedure
Sunish Issac
Sunish
Joep Suijs
Personaly, I use timer frequently to generate an interupt (flag) at a
specified rate. This takes that the desired frequency is converted to
prescaler and a register value. I do this by hand but automagic would
be great ;)
> procedure timer_wait_till_tick( word in ticks) is
be very usefull! Could you also provide a non-blocking
function(timer_check_if_tick() or alike?). And in the process, you
need the code to handle the wrap-around. Maybe you could make that
available through the api too.
Joep
2009/7/31 AlbertF <a.f...@chello.nl>:
Sebastien Lelong
Nice idea. User could also register a callable called when timer reaches 0 (or another value), or when an interrupt is raised. Having alias feature makes code clear.
procedure my_proc() is
-- bla
end procedure
alias my_proc is timerX_callable
In addition it
would be nice to have a wiki page with the timer related registers
(Seb?).
Do you me to parse datasheets ? Maybe this information can be taken from MPLAB files (or device files ?) more easily. Rob, is it possible to do this from one of those ? Let me know, if not, I'll try to get something from DS.
Cheers,
Seb
--
Sébastien Lelong
http://www.sirloon.net
http://sirbot.org
Joep Suijs
> Nice idea. User could also register a callable called when timer reaches 0
> (or another value), or when an interrupt is raised. Having alias feature
> makes code clear.
>
>
> procedure my_proc() is
> -- bla
> end procedure
>
> alias my_proc is timerX_callable
>
You love new features, don't you ;)
Why don't you just define your code with the name timerX_callable?
This does require to include the timer library after the procedure. We
do this for i2c slave also, but I do not realy like this. I'd prefer
includes and defines at the top of the program, before any procedure
definitions.
An other thing is what my_proc() exactly is. I think you assume it is
not the isr itself, but called from the isr. This would make the isr:
if (defined(timerX_callable) == true) then
procedure timerX_isr is
pragma interrupt
if (timerXif == true) then
timerX_callable()
timerXif = false
end if
end procedure
end if
But... this would take an other stack level and more code. Would this
be worth it? We also could tell how to create the isr...
Joep
a.faber
I think it can be done from the datasheets, to have a wiki page similar as
the SSPCON registers, so I can look for commonalityifferences of the
registers mappings throughout the various PICs
Albert
http://www.sirloon.net
http://sirbot.org
Sebastien Lelong
You love new features, don't you ;)
Do I ?...
Why don't you just define your code with the name timerX_callable?
[...]
But... this would take an other stack level and more code. Would this
be worth it? We also could tell how to create the isr...
But I could use my_proc() both in the ISR by registering it as an alias, and also call it from my main program. Stack level can be saved with "pragma inline". And I as a user wouldn't have to actually *think* which interrupt flags I need to check, not to mention I have to remember to clear this flag. As a ser, I just want my special procedure to be called at specific times, I don't want to know if it's done using interrupts or not. This is an implementation detail...
I know this may be a contrived example, but I can't find any other one :)
And I also know this kind of construction (alias + registering within an interrupt) just fits my mind, the way I like to build things...
Cheers,
Seb
Sebastien Lelong
Hi Seb,
I think it can be done from the datasheets, to have a wiki page similar as
the SSPCON registers, so I can look for commonalityifferences of the
registers mappings throughout the various PICs
OK, I'll see but would first want to check what Rob can do with that too with MPLAB files. Not that I want to put the work on him but parsing datasheets isn't an exact science, I've played the wizard as Rob once said, but now I seem to be cursed :)
Cheers,
Seb
Joep Suijs
> But I could use my_proc() both in the ISR by registering it as an alias, and
> also call it from my main program.
Interesting testcase. if my_proc() has local variables or calling
parameters, the compiler will create two instances when the code is
called from both isr and main. I wonder if it does when aliasses are
used (it probably does, but worth checking).
> Stack level can be saved with "pragma
> inline". And I as a user wouldn't have to actually *think* which interrupt
> flags I need to check, not to mention I have to remember to clear this flag.
> As a ser, I just want my special procedure to be called at specific times, I
> don't want to know if it's done using interrupts or not. This is an
> implementation detail...
We agree on this. What I want to make sure is that the user does not
need to think about 2 new things, just because we want to shield 2
things. And it should give relative efficient code (no more stack
levels, no more ram uses if possible).
> And I also know this kind of construction (alias + registering within an
> interrupt) just fits my mind, the way I like to build things...
Very little fits in my mind these days, so I like as little
translation levels as possible. I have about 75 jal apps laying around
(counting jallib as one ;), so prefer to create a procedure called
timerX_callable() each time. This way I know at first glance it is
related to the timerx lib, without looking up the alias...
Joep
Rob Hamerling
Hi Albert,
a.faber wrote:
> I think it can be done from the datasheets, to have a wiki page similar as
> the SSPCON registers, so I can look for commonalityifferences of the
> registers mappings throughout the various PICs
I think I can do that for you without extreme effort. The SSPCON wiki
and some others are generated from the MPLAB .dev by scripts. I can
easily select other regsiters, simply let me know which registers you
want to be shown in this future wiki.
Regards, Rob.
--
Rob Hamerling, Vianen, NL (http://www.robh.nl/)
a.faber
Think if we start with the following registers we have captured the majority
registers/bits containing the text "TMR"
registers/bits containing the text "TxCON" where x = 1..4
Already created a list with number of 8 and 16 bits timers, based on the
info on the microchip site (so does not contain the obsolete PICs)
Albert
Overview with number of 8/16 bit timers per device
Product Family 8 bit 16 bit
PIC10F200 1 0
PIC10F202 1 0
PIC10F204 1 0
PIC10F206 1 0
PIC10F220 1 0
PIC10F222 1 0
PIC12F508 1 0
PIC12F509 1 0
PIC12F510 1 0
PIC12F519 1 0
PIC12F609 1 1
PIC12F615 2 1
PIC12F629 1 1
PIC12F635 1 1
PIC12F675 1 1
PIC12F683 2 1
PIC16F1826 2 1
PIC16F1827 4 1
PIC16F1933 4 1
PIC16F1934 4 1
PIC16F1936 4 1
PIC16F1937 4 1
PIC16F1938 4 1
PIC16F1939 4 1
PIC16F1946 4 1
PIC16F1947 4 1
PIC16F505 1 0
PIC16F506 1 0
PIC16F526 1 0
PIC16F54 1 0
PIC16F57 1 0
PIC16F59 1 0
PIC16F610 1 1
PIC16F616 2 1
PIC16F627A 2 1
PIC16F628A 2 1
PIC16F630 1 1
PIC16F631 1 1
PIC16F636 1 1
PIC16F639 1 1
PIC16F648A 2 1
PIC16F676 1 1
PIC16F677 1 1
PIC16F684 2 1
PIC16F685 2 1
PIC16F687 1 1
PIC16F688 1 1
PIC16F689 1 1
PIC16F690 2 1
PIC16F716 2 1
PIC16F72 2 1
PIC16F722 2 1
PIC16F723 2 1
PIC16F724 2 1
PIC16F726 2 1
PIC16F727 2 1
PIC16F73 2 1
PIC16F737 2 1
PIC16F74 2 1
PIC16F747 2 1
PIC16F76 2 1
PIC16F767 2 1
PIC16F77 2 1
PIC16F777 2 1
PIC16F785 2 1
PIC16F818 2 1
PIC16F819 2 1
PIC16F84A 1 0
PIC16F87 2 1
PIC16F88 2 1
PIC16F882 2 1
PIC16F883 2 1
PIC16F884 2 1
PIC16F886 2 1
PIC16F887 2 1
PIC16F913 2 1
PIC16F914 2 1
PIC16F916 2 1
PIC16F917 2 1
PIC16F946 2 1
PIC16HV540 1 0
PIC18F1220 1 3
PIC18F1230 0 2
PIC18F1320 1 3
PIC18F1330 0 2
PIC18F13K22 1 3
PIC18F13K50 1 3
PIC18F14K22 1 3
PIC18F14K50 1 3
PIC18F2220 1 3
PIC18F2221 1 3
PIC18F2320 1 3
PIC18F2321 1 3
PIC18F2331 1 3
PIC18F23K20 1 3
PIC18F2410 1 3
PIC18F2420 1 3
PIC18F2423 1 3
PIC18F2431 1 3
PIC18F2450 1 2
PIC18F2455 1 3
PIC18F2458 1 3
PIC18F2480 1 3
PIC18F24J10 1 2
PIC18F24J11 2 3
PIC18F24J50 2 3
PIC18F24K20 1 3
PIC18F2510 1 3
PIC18F2515 1 3
PIC18F2520 1 3
PIC18F2523 1 3
PIC18F2525 1 3
PIC18F2550 1 3
PIC18F2553 1 3
PIC18F2580 1 3
PIC18F2585 1 3
PIC18F25J10 1 2
PIC18F25J11 2 3
PIC18F25J50 2 3
PIC18F25K20 1 3
PIC18F2610 1 3
PIC18F2620 1 3
PIC18F2680 1 3
PIC18F2682 1 3
PIC18F2685 1 3
PIC18F26J11 2 3
PIC18F26J50 2 3
PIC18F26K20 1 3
PIC18F4220 1 3
PIC18F4221 1 3
PIC18F4320 1 3
PIC18F4321 1 3
PIC18F4331 1 3
PIC18F43K20 1 3
PIC18F4410 1 3
PIC18F4420 1 3
PIC18F4423 1 3
PIC18F4431 1 3
PIC18F4450 1 2
PIC18F4455 1 3
PIC18F4458 1 3
PIC18F4480 1 3
PIC18F44J10 1 2
PIC18F44J11 2 3
PIC18F44J50 2 3
PIC18F44K20 1 3
PIC18F4510 1 3
PIC18F4515 1 3
PIC18F4520 1 3
PIC18F4523 1 3
PIC18F4525 1 3
PIC18F4550 1 3
PIC18F4553 1 3
PIC18F4580 1 3
PIC18F4585 1 3
PIC18F45J10 1 2
PIC18F45J11 2 3
PIC18F45J50 2 3
PIC18F45K20 1 3
PIC18F4610 1 3
PIC18F4620 1 3
PIC18F4680 1 3
PIC18F4682 1 3
PIC18F4685 1 3
PIC18F46J11 2 3
PIC18F46J50 2 3
PIC18F46K20 1 3
PIC18F6310 1 3
PIC18F6390 1 3
PIC18F6393 1 3
PIC18F63J11 1 3
PIC18F63J90 1 3
PIC18F6410 1 3
PIC18F6490 1 3
PIC18F6493 1 3
PIC18F64J11 1 3
PIC18F64J90 1 3
PIC18F6520 2 3
PIC18F6527 2 3
PIC18F65J10 2 3
PIC18F65J11 1 3
PIC18F65J15 2 3
PIC18F65J50 2 3
PIC18F65J90 1 3
PIC18F6622 2 3
PIC18F6627 2 3
PIC18F6628 2 3
PIC18F66J10 2 3
PIC18F66J11 2 3
PIC18F66J15 2 3
PIC18F66J16 2 3
PIC18F66J50 2 3
PIC18F66J55 2 3
PIC18F66J60 2 3
PIC18F66J65 2 3
PIC18F66J90 1 3
PIC18F66J93 1 3
PIC18F6722 2 3
PIC18F6723 2 3
PIC18F67J10 2 3
PIC18F67J11 2 3
PIC18F67J50 2 3
PIC18F67J60 2 3
PIC18F67J90 1 3
PIC18F67J93 3 1
PIC18F8310 1 3
PIC18F8390 1 3
PIC18F8393 1 3
PIC18F83J11 1 3
PIC18F83J90 1 3
PIC18F8410 2 3
PIC18F8490 1 3
PIC18F8493 1 3
PIC18F84J11 1 3
PIC18F84J90 1 3
PIC18F8520 2 3
PIC18F8527 2 3
PIC18F85J10 2 3
PIC18F85J11 1 3
PIC18F85J15 2 3
PIC18F85J50 2 3
PIC18F85J90 1 3
PIC18F8622 2 3
PIC18F8627 2 3
PIC18F8628 2 3
PIC18F86J10 2 3
PIC18F86J11 2 3
PIC18F86J15 2 3
PIC18F86J16 2 3
PIC18F86J50 2 3
PIC18F86J55 2 3
PIC18F86J60 2 3
PIC18F86J65 2 3
PIC18F86J90 1 3
PIC18F86J93 1 3
PIC18F8722 2 3
PIC18F8723 2 3
PIC18F87J10 2 3
PIC18F87J11 2 3
PIC18F87J50 2 3
PIC18F87J60 2 3
PIC18F87J90 1 3
PIC18F87J93 1 3
PIC18F96J60 2 3
PIC18F96J65 2 3
PIC18F97J60 2 3
----- Original Message -----
From: "Rob Hamerling" <robham...@gmail.com>
To: <jal...@googlegroups.com>
Sent: Saturday, August 01, 2009 8:38 PM
Subject: [jallib] Re: Timer Library?
>
>
Rob Hamerling
Hi Albert,
a.faber wrote:
> registers/bits containing the text "TMR"
> registers/bits containing the text "TxCON" where x = 1..4
I thought so and have already committed a new wiki. This may not be
exactly what you want/need. If so I'll see your comments!
BTW there are PIC with more than 4 timers (e.g. 18f87K90).
a.faber
It is already very useful, it cought already the first inconsitencies in the
device files.
When i sorted everything by * reg * I noticed that a few T0CON had different
values which did not look correct
When looking for example at the 18f2450,
18F2450 T0CON TMR0ON T08BIT T0CS T0SE T0PS3 T0PS2 T0PS1 T0PS0
This matches with the device file (so wiki is genration is consistent with
device files)
var volatile byte T0CON shared at 0xFD5
var volatile bit T0CON_TMR0ON shared at T0CON : 7
var volatile bit T0CON_T08BIT shared at T0CON : 6
var volatile bit T0CON_T0CS shared at T0CON : 5
var volatile bit T0CON_T0SE shared at T0CON : 4
var volatile bit*4 T0CON_T0PS shared at T0CON : 0
however, the datasheet and the INC file state
bit 7 TMR0ON: Timer0 On/Off Control bit
1 = Enables Timer0
0 = Stops Timer0
bit 6 T08BIT: Timer0 8-Bit/16-Bit Control bit
1 = Timer0 is configured as an 8-bit timer/counter
0 = Timer0 is configured as a 16-bit timer/counter
bit 5 T0CS: Timer0 Clock Source Select bit
1 = Transition on T0CKI pin
0 = Internal instruction cycle clock (CLKO)
bit 4 T0SE: Timer0 Source Edge Select bit
1 = Increment on high-to-low transition on T0CKI pin
0 = Increment on low-to-high transition on T0CKI pin
bit 3 PSA: Timer0 Prescaler Assignment bit
1 = TImer0 prescaler is not assigned. Timer0 clock input bypasses prescaler.
0 = Timer0 prescaler is assigned. Timer0 clock input comes from prescaler
output.
bit 2-0 T0PS2:T0PS0: Timer0 Prescaler Select bits
111 = 1:256 Prescale value
110 = 1:128 Prescale value
101 = 1:64 Prescale value
100 = 1:32 Prescale value
011 = 1:16 Prescale value
010 = 1:8 Prescale value
001 = 1:4 Prescale value
000 = 1:2 Prescale value
;----- T0CON Bits -----------------------------------------------------
T0PS0 EQU H'0000'
T0PS1 EQU H'0001'
T0PS2 EQU H'0002'
PSA EQU H'0003'
T0SE EQU H'0004'
T0CS EQU H'0005'
T08BIT EQU H'0006'
TMR0ON EQU H'0007'
So I don't know how PSA is replaced by T0PS3 in the device file, any ideas?
Noticed the following T0CON irregularities, have not checked if there all
wrong
18F2410
18F2420
18F2423
18F2450
18F2585
18F25J10
18F25J11
18F25J50
18F25K20
18F2610
18F2620
18F2680
18F2682
18F2685
18F26J11
18F26J50
18F26K20
18F4220
18F4221
18F4320
18F4321
18F4331
18F43K20
18F4410
18F442
18F4420
18F4423
18F4431
18F4439
18F4450
18F4455
18F4458
18F448
18F4480
18F44J10
18F44J11
18F44J50
18F44K20
18F4510
18F4515
18F452
18F4520
18F4523
18F4525
18F4539
18F4550
18F4553
18F458
18F4580
18F4585
18F45J10
18F45J11
18F45J50
18F45K20
18F4610
18F4620
18F4680
18F4682
18F4685
18F46J11
18F46J50
18F46K20
18F47J13
18F47J53
18F6310
18F6390
18F6393
18F63J11
18F63J90
18F6410
18F6490
18F6493
18F64J11
18F64J90
18F6520
18F6525
18F6527
18F6585
18F65J10
18F65J11
18F65J15
18F65J50
18F65J90
18F65K22
18F65K90
18F6620
18F6621
18F6622
18F6627
18F6628
18F6680
18F66J10
18F66J11
18F66J15
18F66J16
18F66J50
18F66J55
18F66J60
18F66J65
18F66J90
18F66J93
18F66K22
18F66K27
18F66K90
18F66K95
18F6720
18F6722
18F6723
18F67J10
18F67J11
18F67J50
18F67J60
18F67J90
18F67J93
18F67K22
18F67K90
18F8310
18F8390
18F8393
18F83J11
18F83J90
18F8410
18F8490
18F8493
18F84J11
18F84J90
18F8520
18F8525
18F8527
18F8585
18F85J10
18F85J11
18F85J15
18F85J50
18F85J90
18F85K22
18F85K90
18F8620
18F8621
18F8622
18F8627
18F8628
18F8680
18F86J10
18F86J11
18F86J15
18F86J16
18F86J50
18F86J55
18F86J60
18F86J65
18F86J90
18F86J93
18F86K22
18F86K27
18F86K90
18F86K95
18F8720
18F8722
18F8723
18F87J10
18F87J11
18F87J50
18F87J60
18F87J90
18F87J93
18F87K22
18F87K90
18F96J60
18F96J65
18F97J60
Al bert
----- Original Message -----
From: "Rob Hamerling" <robham...@gmail.com>
To: <jal...@googlegroups.com>
Sent: Saturday, August 01, 2009 10:13 PM
Subject: [jallib] Re: Timer Library?
>
>
a.faber
Also the NT1SYNC for the 16f722 family does not seem to be correct,
var volatile bit T1CON_T1SYNC at T1CON : 2
T1CON_T1SYNC should be T1CON_NT1SYNC ?
Looking in the inc file for 16f722 there is the NOT
NOT_T1SYNC EQU H'0002'
Looking for example to the 16f72.jal file seems to be correct
var volatile bit T1CON_NT1SYNC at T1CON : 2
Albert
a.faber
Another one, T2CON bit values are missing for 18f2439, 18f2539, 18f4439
Rob Hamerling
Hi Albert,
a.faber wrote:
> It is already very useful, it cought already the first inconsitencies in the
> device files.
In the first place (maybe Seb can help): When I browse the Jallib.Wiki
page I don't see FindTimers.wiki, but I see it in the Source.wiki list.
Why is that? Does a wiki have to be created first from the web interface
before it can be updated via SVN?
The normalization for timer fields in the device files is currently
limited to some INTCON bits: T0IE -> TMR0IE and T0IF -> TMR0IF.
If any other normalisation is needed, please do a suggestion (an 'Issue'
seems the right place).
> When i sorted everything by * reg * I noticed that a few T0CON had different
> values which did not look correct
> When looking for example at the 18f2450,
>
> 18F2450 T0CON TMR0ON T08BIT T0CS T0SE T0PS3 T0PS2 T0PS1 T0PS0
>
>
> This matches with the device file (so wiki is genration is consistent with
> device files)
Yes (not surprisingly), the scripts for this wiki and the device files
both take the MPLAB .dev files as input and don't change any name (yet).
> var volatile byte T0CON shared at 0xFD5
> var volatile bit T0CON_TMR0ON shared at T0CON : 7
> var volatile bit T0CON_T08BIT shared at T0CON : 6
> var volatile bit T0CON_T0CS shared at T0CON : 5
> var volatile bit T0CON_T0SE shared at T0CON : 4
> var volatile bit*4 T0CON_T0PS shared at T0CON : 0
>
>
> however, the datasheet and the INC file state
(matching fields removed)
> bit 3 PSA: Timer0 Prescaler Assignment bit
>
> 1 = TImer0 prescaler is not assigned. Timer0 clock input bypasses prescaler.
>
> 0 = Timer0 prescaler is assigned. Timer0 clock input comes from prescaler
> output.
>
> bit 2-0 T0PS2:T0PS0: Timer0 Prescaler Select bits
>
(some not interesting lines removed)
> So I don't know how PSA is replaced by T0PS3 in the device file, any ideas?
Yes, this is an error in the MPLAB .dev files, which specify a 4-bit
field 'T0PS' for the 18F2420 (and probably others). I'll fix this in the
device files (and FindTimers.wiki).
I have opened an issue #82 for this defect.
> Noticed the following T0CON irregularities, have not checked if there all
> wrong
Do you mean *only* this glued-together T0PSA and T0PS fields? Or are the
other irregularities?
> Al bert
Typo or joke?
Regards, Rob,
Rob Hamerling
Hi Albert,
a.faber wrote:
> Also the NT1SYNC for the 16f722 family does not seem to be correct,
>
> var volatile bit T1CON_T1SYNC at T1CON : 2
>
> T1CON_T1SYNC should be T1CON_NT1SYNC ?
>
> Looking in the inc file for 16f722 there is the NOT
> NOT_T1SYNC EQU H'0002'
>
> Looking for example to the 16f72.jal file seems to be correct
>
> var volatile bit T1CON_NT1SYNC at T1CON : 2
>
On one hand T1SYNC in the device file for the 16F722 matches its
datasheet, but NT1SYNC seems more common (abbreviation for
T1CON_NOT-T1SYNC?). So we better normalize to NTSYNC, even though it
doesn't match the datasheet for some PICs (consider it as an error in
the datasheet?).
Similarly for T3SYNC: NT3SYNC is much more common
(while T5SYNC does not occur at all, only NT5SYNC).
Rob Hamerling
Regards, Rob.
a.faber wrote:
> ... T2CON bit values are missing for 18f2439, 18f2539, 18f4439
Another error in MPLAB .dev files to be fixed! Will do.
Rob Hamerling
Hi Albert,
a.faber wrote:
> Another one, T2CON bit values are missing for 18f2439, 18f2539, 18f4439
Now I've read chapter 12 of the datasheet of these PICs I don't think
anymore that it is an error in MPLAB (so nothing to fix).
It may be even of help to a generic timer library if the bits of T2CON
are *not* declared to determine if Timer2 is available.
Regards, Rob
a.faber
But why is the T2CON reg still defined? Isn't better to remove the T2CON reg
definition afterall if there is not Timer2 present?
Rob Hamerling
Hi Albert,
a.faber wrote:
> But why is the T2CON reg still defined? Isn't better to remove the T2CON reg
> definition afterall if there is not Timer2 present?
Don't ask me! Ask Microchip (or read the datasheet).
I just 'copy' what is in the MPLAB .dev files (and make some
corrections) without asking why ;-)
Of course I could remove Timer2 registers from the device files of these
PICs, but is that the right thing to do? Timer2 is present, but
according to the datasheet not supposed to be touched, but also not
absolutely forbidden to be touched!
Regards, Rob.
a.faber
Hi Rob,
Some more Microchip logic ;)
About halve of T2CON-T2OUTPS3 is defined as T2OUTPS3, while the other halve
is defined as using TOUTPS3
(same for other OUTPS registers)
The majority of T4CON-T4OUTPS3 is defined as, while the following devices
are using TOUTPS3
18F6527 T4CON - TOUTPS3
18F6622 T4CON - TOUTPS3
18F6627 T4CON - TOUTPS3
18F6628 T4CON - TOUTPS3
18F6722 T4CON - TOUTPS3
18F6723 T4CON - TOUTPS3
18F8527 T4CON - TOUTPS3
18F8622 T4CON - TOUTPS3
18F8627 T4CON - TOUTPS3
18F8628 T4CON - TOUTPS3
18F8722 T4CON - TOUTPS3
18F8723 T4CON - TOUTPS3
Any thoughts on this?
Regards Albert
----- Original Message -----
From: "Rob Hamerling" <robham...@gmail.com>
To: <jal...@googlegroups.com>
Sent: Sunday, August 02, 2009 2:36 PM
Subject: [jallib] Re: Timer Library?
>
>
Rob Hamerling
Hi Albert
a.faber wrote:
> About halve of T2CON-T2OUTPS3 is defined as T2OUTPS3, while the other halve
> is defined as using TOUTPS3
> (same for other OUTPS registers)
>
>
> The majority of T4CON-T4OUTPS3 is defined as, while the following devices
> are using TOUTPS3
>
>
> 18F6527 T4CON - TOUTPS3
(etc)
The datasheet specifies T4OUTPS3..(etc). So it seems an error in MPLAB
.dev files. We could normalize in two ways:
* Leave out the timer number for all Timers
(no conflict because we use the TxCON prefix)
* Insert the number to be consistent over the whole range
(and obey the datasheet).
Personally I like the first option most, but "the datasheet is the boss"
so I think it will become inserting the timer number where it is missing.
BTW I've seen that some field names are truncated in
FindTimerControl.wiki (e.g. of 18f86K22 line of T10CON and T12CON). I'll
repair that.
a.faber
Agree with your proposal, it would be nice if you can send me, after the
changes, the "old" WIKI file by mail, since I've created an excel sheet with
some analysis function to spot the differences.
----- Original Message -----
From: "Rob Hamerling" <robham...@gmail.com>
To: <jal...@googlegroups.com>
Sent: Monday, August 03, 2009 9:40 PM
Subject: [jallib] Re: Timer Library?
>
>
Rob Hamerling
Hi ALbert,
a.faber wrote:
> Agree with your proposal,
>> * Insert the number to be consistent over the whole range
>> (and obey the datasheet).
Well, it is somewhat more complicated:
- Is the number-insert also needed for the midrange PICs?
(will apply to Timer2 only: conflict with the datasheet)
- Is the number insert also needed for Timer2 of the 18Fs?
(might conflict with the datasheets, but I didn't check all)
> it would be nice if you can send me, after the
> changes, the "old" WIKI file by mail, since I've created an excel sheet with
> some analysis function to spot the differences.
What is 'old'? Do you mean the one with the TMR registers?
Rob Hamerling
Hi Guys,
I need your opinion/vote about proposed changes in device files for the
timer library Albert is designing. There are a number of inconsistencies
in MPLAB for the naming of some bit fields in timer control registers.
You can read it back in the Jallib, but to summarize:
1. Rename 'T1SYNC' of T1CON to 'NT1SYNC' for the 16F72x.
Later we found also that a number 18Fs have T1SYNC, T3SYNC
which should better be NT1SYNC and NT3SYNC for consistency
even though the datasheet specifies T1SYNC (with an overscore
to indicated 'not').
2. For many (18F) PICs the T2OUTPS field of T2CON is declared as
T2OUTPS. For some PICS it is declared as TOUTPS, while the
datasheets specify T2OUTPS. Since the datasheet prevails I
proposed to correct this deviation:
rename TOUTPS to T2OUTPS for T2CON
more generally rename TOUTPS of TxCON to TxOUTPS
(for PICs with more timers).
But the midrange PICS have only one Timer with TOUTPS field
(Timer2) and the datasheets seem consistently calling it TOUTPS.
> (etc)
>
> The datasheet specifies T4OUTPS3..(etc). So it seems an error in
> MPLAB .dev files. We could normalize in two ways: * Leave out the
> timer number for all Timers (no conflict because we use the TxCON
> prefix) * Insert the number to be consistent over the whole range
> (and obey the datasheet). Personally I like the first option most,
> but "the datasheet is the boss" so I think it will become inserting
> the timer number where it is missing.
Rob Hamerling
{sorry sent prematurely)
Hi Guys,
I appreciate your opinion/vote about proposed changes in device files
for the timer library Albert is designing. There are a number of
inconsistencies in MPLAB for the naming of some bit fields in timer
control registers.
You can read it back in the Jallib, but to summarize:
1. Rename 'T1SYNC' of T1CON to 'NT1SYNC' for the 16F72x.
Later we found also that a number 18Fs have T1SYNC, T3SYNC
which should better be NT1SYNC and NT3SYNC for consistency
even when the datasheet specifies T1SYNC (with an overscore
to indicated 'not').
2. For many (18F) PICs the T2OUTPS field of T2CON is declared as
T2OUTPS. For some PICS it is declared as TOUTPS, while the
datasheets specify T2OUTPS. Since the datasheet prevails I
proposed to correct this deviation:
rename TOUTPS to T2OUTPS for T2CON
more generally rename TOUTPS of TxCON to TxOUTPS
(x any number, for PICs with more of such timers).
But the midrange PICS have only one Timer with TOUTPS field
(Timer2) and the datasheets seem consistently calling it TOUTPS.
So if we normalize to T2SYNC for consistence it is in conflict
with the datasheet.
Questions:
1. Do we vote for NT1SYNC (item 1 above)?
2. Do we vote for consistent TxOUTPS for the 18Fs?
3. Do we vote for T2OUTPS for the baseline PICs?
If you don't care Albert is free to find a solution for the timer
library and I'll make the necessary adjustments in the device files.
Rob Hamerling
Hi Albert,
Rob Hamerling wrote:
> 1. Do we vote for NT1SYNC (item 1 above)?
> 2. Do we vote for consistent TxOUTPS for the 18Fs?
> 3. Do we vote for T2OUTPS for the baseline PICs?
For the FindTimerControl wiki I have assumed the following answers:
1: yes, 2: yes, 3: no (T2CON_TOUTPS remains unchanged).
The dev2jal script is changed accordingly, but can easily be changed to
whatever the Jallib community decides.
I'll update TimerControl.wiki and send you personally a special edition
(with TMR registers).