PBP projects for R/C models

Ken, Here is what I think.
I agree with going back to the basics. As I have been reading this thread since your project started, I for 1 am not real sure where you are with methods, hardware, program,...

I suggest you do this: List all the parameters needed. such as how long does the sonar need to accquire a distance? How many things does the PIC need to do? Then you will be able to determine if your chosen PIC is up to the job.

I think it prolly is, and I think PBP is also up to it. Worst case is to sprinkle some ASM in if needed.

The SONARs each get a 10micro sec trigger. This creates an ultrasound PING. I use PULSIN plus PAUSE 10 to input the response and wait for the ringing to stop. Total time for two SONARs = at least 20msec.

To make room for the PWM pulses I could shorten the length of the SONAR PAUSEs. Trying to fit 20msec interrupts clearly might be a problem.

I could trigger the SONARs less often (interrupt driven). I do not need to be measuring the distances so often. The PIC could, at that time, skip a PMW interrupt - or delay it a couple of milliseconds.

Other than that all the code does is fly through various IF THEN state machines depending on the most SONAR readings. That is very simple.

However-----\

If I could calculate closing rates accurately and if I had a finely tuned proportional control system then I might be able to implement a real PID system. Not sure. I do not know how to analyze this.

Ken

Quote:

---

Originally Posted by Kenjones1935

Thank you for the October reference.

I have not learned to SEARCH the forum.

---

??????
No search required for that, it is a part of this thread.

Anyways, have you looked over the PID routines given by Henrik Olsson?

Quote:

---

Originally Posted by Kenjones1935

The SONARs each get a 10micro sec trigger. This creates an ultrasound PING. I use PULSIN plus PAUSE 10 to input the response and wait for the ringing to stop. Total time for two SONARs = at least 20msec.

---

hate to be picky, but is it micro or milli seconds?
Can both sonars be active at the same time?

Quote:

---

If I could calculate closing rates accurately and if I had a finely tuned proportional control system then I might be able to implement a real PID system. Not sure. I do not know how to analyze this.
Ken

---

Maybe I am just lucky at times, but i have never been properly introduced to a real PID system. I don't consider myself being able to emulate a PID when I am flying R/C planes, yet I can fly them. The finely tuned proportional control system is not too hard, I am sure we can get you there.

Yes, I looked at Olsson's routines. I got distracted by the thought that my 16F887 is just not up to the task at hand.

I glanced through the MicroChip 18F PICs. My eye fell on the PIC18F46K20.
It comes in 40 pin PDIP format. That is good. It has lots more code memory space. It is on the list of devices that can be programmed by my PICKIT 2 and my Microcode Studio PICBASIC PRO combination. It must be bigger, faster, more capable than my 16F887. True? Which 18F should I choose. I have little to no sense of the differences.

Ken

Ken, What makes you think your current device is not up to the task? R/C systems are very slow IMHO relative to processors. Think on this, pulses for the car happen for 1-2msec each every 20 msec. so 2 pulses (drive & steering) will be max 4 msec. That leaves 16 msec for the uP to do whatever like measure distance and decide what to output next. At 4Mhz clock, thats 16000 ASM instructions! Not PBP instructions but still a whole lot!

So heres a couple of thoughts: Use pulseout for the signals to the car. No need for int or PWM. How about connecting 1 of the car signals from the receiver to your pic. Then just check to see if the pin went high, if so its time to send out commands. This way you can use the car receiver as a 20mSec clock.

I do not have any experience with the 18F46K20 but two things that I think would make it a good one for this project are:

Quote:

---

Internal Oscillator Block:
- 8 user selectable frequencies, from 31 kHz to
16 MHz
- Provides a complete range of clock speeds
from 31 kHz to 64 MHz when used with PLL

---

And

Quote:

---

Enhanced CCP module: In PWM mode, this
module provides 1, 2 or 4 modulated outputs for
controlling half-bridge and full-bridge drivers.

---

I also think the PIC16 or 18 is plenty fast for the application. But the servo's and speed controllers are pretty picky about their signals. They need to be at regular intervals in order for the servo's and speed controllers to work smoothly. Otherwise their operation can be erratic. While you could measure the receiver with pulsin, I would stick to interrupts for the servo and speed controller. The PIC18F4431 has hardware that allows for R/C pwm frequencies. But it could be done with pretty much any PIC using spwm. I would probably use a PIC18 rather than a PIC16 because it opens up a couple of possibilities, but both are powerful enough.

Hi Walter, quick question. I am under the impression most Rx send their pulses sequencially, so when channel 1 is done, 2 starts, 2 done 3 starts... I know they are not always in numeric order, but none the less they wait until the last is don befor sending the next. At least with a little older equipment.

If my assumption is correct, in a 4 channel Rx, channel 4 could start anywhere between 4mSec to 8mSec after the start of the 20mSec frame. (channel 1,2 and 3 could be all min or all max). If this is true, They can't be too picky cuz 4 mSec is pretty darn big!. I would think it would take little effort to hit the 20mSec loop within .1msec.

so I was thinking in the main loop, don't measure the pulse from the Rx, just see if it went high. Then within a couple of instructions the "send pulses" routine would start. When thats done, acquire the next distance reading (10 mSec) then back to the old main loop waiting for the next trigger from the Rx.

Of course if my assumption is not correct, this was a nice typing excerise for me :)

1. Although the SONAR only requires a 10microsec trigger pulse, at 1100 feet per second a five foot sound echo returns (order of magnitude) in a bit less that 10 millisec. I can not trigger both SONARs at the same time. I believe their echos would interfere. I certainly do not have to trigger these devices 50 times per second. Three or four times per second would be enough. This would give the velocity rate calculations more meaning. (Maybe I should make the SONAR activity interrupt dependent, not the PWM activity.)

2. The PIC needs to control the steering. It needs to keep the car traveling parallel to the side wall a given distance (desiredtrack) from that wall. It also needs to turn the car dramatically left when a (corner) wall appears inside a given distance (frontfree) in front. Both 'desiredtrack' and 'frontfree' are VAR WORDs - functions of the POT position (which also influences the speed of the car).

3. There is a totally separate algorithm controlling steering when the car is backing up due to a collision or a very near miss. Basicly steer right and back up a couple of feet then steer left and try to go forward.

4. If the steering were absolutely under control I feel the wheel speed could be pretty much left alone. Check the POT and make the PWM signal to the Electronic Speed Control proportional in seven stages.

5. My PIC really should have four pieces of data to work from.
A. Distance to the right wall.
B. Closing rate to the right wall.
C. Distance from an object in front.
D. Closing rate on the object in front.
If it had this information I think even I could code proportional feed back loops. Note two are rates. Each of these require two readings a known time apart, a subtraction process and some comparisons to fixed estimated values.

6. My model level car can be put under radio control merely by turning on the power to the ratio transmitter. It is selection which PWM signals (radio receiver sourced or PIC sourced) that is done by the DPDT coil driven relay switch. It is driving that relay switch coil that requires the SN7407 current driver.

7. I chose the HPWM to shape the steering and DC motor signals because by trial and error I found parameters that seemed to work at slower speeds. The signals continue no matter what the PIC code is doing. I do wonder whether I screw up a sequence each time I exercise a new HPWM command even if it is a repeat of the previous HPWM command. I do not understand the architecture details of HPWM command.

Ken

Originally I used a three channel R/C system. I kept the transmitter on all the time. Like you all suggested I could have used its outputs to trigger the PIC's PWM signals.

To take R/C control I tuned on channel 3. The receiver signaled the PIC that channel 3 was active. The PIC flipped the DPDT relay thereby steering the radio receiver's servo signals to the car.

This was not a good system because the model level car which is the basis of my work comes naturally with a 2 channel R/C. Adding the third channel was a big expense. Too much for our school systems.

Ken

From what I can tell the PIC18F45K20 is compatible with the PICKIT2 and MPLAB systems. I see that it comes in a 40 pin PDIP configuration.

Do you think I could unplug my 40 pin PIC16F887 and plug in a new PIC18F45K20 40 pin PDIP, do a bit of rewiring and be ready to go hardwarewize?

KEn

What does it give you that you don't have with the '887?

Scalerobotics wrote a while back:

Quote:

---

A 12F683 design (would require a fair amount of changes to work on your chip)
http://www.picbasic.co.uk/forum/show...4998#post84998

This one could not be modified for your chip, and would require a 18F2431, or 4431.
http://www.picbasic.co.uk/forum/show...1961#post91961 (cleaner code than above)

And the one rmteo pointed out, which would require an 18 series chip: http://www.picbasic.co.uk/forum/cont...e-Servo-Driver (Darrels, so you can't really go wrong)

---

I am not enough conversant with the various Microchip models to talk intelligently about what I need or don't need.

Ken

After comparing the power and the 6 pin PC connector selections of the 44 pin 16F887 in the PICKIT2 and the 44 pin 18F45K20 in its StarterKit I think I can unplug one and plug in the other. I'll bet that will be the same for the 40 pin PDIP versions also. Good for our team.

Ken

ken, I think you should stick with the '887. You already have lots of experience with it and really it can suit your needs just fine.

If you want to jump up to the 18F, you may find yourself feeling like WOW, how do I do this. From what I have found, the 18F's just left me feeling like I had just stepped into a new world with regards to setting up and configuring it just to get it to run. You are doing basic stuff, ie no USB or 4 way PWM with encoder feedback. So the 887 can do that just fine.

BTW, I don't remember how fast you are running the PIC. Whats your osc speed?

My oscillator is 4Mhz (I think). I have done nothing to change it. Whatever it does naturally is what it is.

My guess is that SONAR triggering four times per second is sufficient.

Question: How do I create an interrupt every 1/4 second?

Ken

Quote:

---

Originally Posted by cncmachineguy

Hi Walter, quick question. I am under the impression most Rx send their pulses sequencially, so when channel 1 is done, 2 starts, 2 done 3 starts... I know they are not always in numeric order, but none the less they wait until the last is don befor sending the next. At least with a little older equipment.

If my assumption is correct, in a 4 channel Rx, channel 4 could start anywhere between 4mSec to 8mSec after the start of the 20mSec frame. (channel 1,2 and 3 could be all min or all max). If this is true, They can't be too picky cuz 4 mSec is pretty darn big!. I would think it would take little effort to hit the 20mSec loop within .1msec.

so I was thinking in the main loop, don't measure the pulse from the Rx, just see if it went high. Then within a couple of instructions the "send pulses" routine would start. When thats done, acquire the next distance reading (10 mSec) then back to the old main loop waiting for the next trigger from the Rx.

Of course if my assumption is not correct, this was a nice typing excerise for me :)

---

Hello Bert,

I think all your assumptions are correct.

What I have seen is when pulses of 1 to 2 ms are not timed to occur about every 20 ms, the servos exhibit some eratic behavior. If some timing is attempted, and you get close-ish to the 20 ms the servo's are expecting, then yes, you will probably be just fine. But if you are going to go to the trouble of getting the timing close, why not use interrupts? It would allow the pic to be looking at different sensors, and not make it "dead" for up to 4 ms (1/5 of the time) while it sends out a pulse to two servo's.

This is very helpful.
http://www.picbasic.co.uk/forum/cont....-PICMultiCalc

Probably the easiest way to get started is with ON INTERRUPT. It is not the most accurate, it will only interrupt when nothing else is going on. Sound silly but..
An example would be a long PAUSE, the ON INTERRUPT will flag and run when the PAUSE is finished. ASM interrupts or DT's instant interrupts will work as true interrupts, but for your case ON INTERRUPT should be close enough.

This should be close. Run it on your board and see what happens.

Code:

---

'FL PIC16F887
'16F887 INT RUPT
'44 PIN DEMO BOARD
  @ __config _CONFIG1, _INTRC_OSC_NOCLKOUT & _WDT_ON & _MCLRE_OFF & _LVP_OFF & _CP_OFF
  INTCON.5 = 1
  OSCCON = %01110000 '8 Mhz
  DEFINE OSC 8
  OPTION_REG = %01000111  ' 1:256 PRESCALE
  ON INTERRUPT GOTO TLOOP
  CNT  VAR BYTE
  D    VAR BYTE
  D = 0
  DATA @10,10,20,30
  TCNT  VAR    BYTE
 
  START:
  FOR CNT = 0 TO 150
  PWM PORTD.7,D,10
  D = D + 2
  NEXT CNT
  GOTO START
 
  DISABLE
  TLOOP:
  TCNT = TCNT + 1
  INTCON.2=0
  IF TCNT = 8 THEN
  TOGGLE PORTD.4
  TCNT = 0
  ENDIF
  RESUME
  ENABLE

---

I agree walter, if going to the trouble, why not be correct.

Ken, heres something I was thinking,
Set up a 5msec interupt timer.
on each int, increment a counter
first count (@5msec) ping sonar 1
second count (@10msec) update servos
third count (@15msec) ping sonar 2
fourth count (@20msec) reset counter, write things (from looking at your code), adjust pulse times for next servo update.

so your int handler will do:
reload timer, inc counter, clear jump flags, retrun

main will do something like this:
if counter =1 and sonar1flag=0 then ping sonar 1
if counter =2 and update flag=0 then updateservos
if counter = 3 and sonar2flag=0 then ping sonar 2
if counter =4 and mathflag=0 then math stuff

in each subroutine first thing to do is set the flag, then do the routine.

cncmachineguy

Five millisec interrupts seems like a good plan. I will do a little more complicated counting and skipping. I think the SONARs should be less often if I am going to calculate velocity.

I wish I felt more at home with PBP. I'm tempted go to the freebe C, but that means starting all over again. It's been too many years.... Too lazy. sigh...

How do I get 5millisec interrupts from a FOSC/4 oscillator. I just do not understand section 6.0 of the '887 spec sheet.

Ken

Quote:

---

Originally Posted by Kenjones1935

cncmachineguy

Five millisec interrupts seems like a good plan. I will do a little more complicated counting and skipping. I think the SONARs should be less often if I am going to calculate velocity.

---

I'm not sure what needs to be more complicated, but I am prolly not seeing the whol picture. Velocity calc won't take long, I am sure it can still be done in the fourth block You have 5000 cycles to burn up before the next interupt.

Quote:

---

I wish I felt more at home with PBP. I'm tempted go to the freebe C, but that means starting all over again. It's been too many years.... Too lazy. sigh...

---

I don't have any experience with PBP yet (but I will start programming in the next week or so :) ), all my programming has been in ASM. But from what I can see, there may be a few times when PBP isn't the best choice, but I don't know when that is. All languages have pros and cons. PBP seems to me to be a very good compilier. If I were you, I would just stick with it. I don't think it is where the difficulties are.

Quote:

---

How do I get 5millisec interrupts from a FOSC/4 oscillator. I just do not understand section 6.0 of the '887 spec sheet.
Ken

---

For my part of being lazy, its not going to look at the datasheet for this processor. But the good news is I don't think I need to to answer this. I assume '887 has at least 1 16 bit timer you are not using. So go look at the timer section and figure out how to configure it as a counter. What I find to be the most important part about osc is this, it takes 4 clock cycles to execute an instruction (ASM). So that means if using 4Mhz clock, each instruction takes .000001 seconds, or 1/(osc/4). so for 5 msec, thats 5000 instructions. The timer/counter will increment 1 for every instruction. So heres the math:
16 bit counter = 65535
65535 - 5000 = 60535

so if you preload the timer with 60535, it will take 5000 counts to roll over. thats 5 msec. If timer overflow interupt is enabled, an int will be generated at 5 msec. Then in the handler, reload the timer with 60535 so another int will happen in 5 more msec. and so forth.

1 thing to keep in mind, 60535 assumes there is no lag between rollover and reload. In reality there is, it will take a few cycles to enter the interupt, then another few to reload and start the timer. so your number would adjust up by some small amount. for instance: if it takes 12 cycles to go from overflow to reload, the number you want to load would be 60535 + 12 = 60547. Make sense?

You can determine the exact number with some testing, before you reload the timer, grab the timer low byte and save it. then look at that number. it will be the number of cycles it took to get to the point where you grabbed it. Then replace the code to grab it with code to load it and the timing should be within 1 or 2 cycles.

I will let you chew on this for a while.
BTW, If you find there is not enough time between int for math and such, change the clock to 8Mhz, then you will be able to execute twice as many instructions between interupts.

There are plenty of machine cycles to do the math work and the control decisions. I think the 5 millisec interrupt timing should give me accurate timing for the PWM signals. I have no idea how much noise there is in the SONAR responses. I want to space them further apart in time so the trends are clear. Four triggers for each SONAR per second is my first guess.

Now to bed. Thanks.

Ken

Folks, I have been PBPing on a wing and a prayer (to quote an old WWII song). I need more
reference material. I compiled Mackrackit's code and got the following error. I do not know
where to go to chase it down.

Error 118 c:/~~~.asm 67: Overwriting previous address contents(2007)

Here's from the .asm file:

Quote:

---

66 ASM?
67 __config _CONFIG1, _INTRC_OSC_NOCLKOUT & _WDT_ON & _MCLRE_OFF & _LVP_OFF & _CP_OFF
68
69 ENDASM?

---

Remove this line

Code:

---

@ __config _CONFIG1, _INTRC_OSC_NOCLKOUT & _WDT_ON & _MCLRE_OFF & _LVP_OFF & _CP_OFF

---

The above sets the configs in code space. You must be setting them in the *.inc file. Either way is good.

To read more about it
http://www.picbasic.co.uk/forum/cont...o-your-Program

Quote:

---

Originally Posted by Kenjones1935

There are plenty of machine cycles to do the math work and the control decisions. I think the 5 millisec interrupt timing should give me accurate timing for the PWM signals. I have no idea how much noise there is in the SONAR responses. I want to space them further apart in time so the trends are clear. Four triggers for each SONAR per second is my first guess.

Now to bed. Thanks.

Ken

---

Ken, I have been thinking about this, and IMHO the cleanest way may be to use 2 counters, one for the math/pwm, and 1 for the sonars

The PWM development works. Clearly LED #7 grows in magnitude through eight counts of #4.

The PWM is controlling the frequency of that signal's pulse. I do not unerstand
how the prescaler and the 8Mhz clock create the slowly blinking LED4.

KEn

Quote:

---

Originally Posted by Kenjones1935

There are plenty of machine cycles to do the math work and the control decisions. I think the 5 millisec interrupt timing should give me accurate timing for the PWM signals. I have no idea how much noise there is in the SONAR responses. I want to space them further apart in time so the trends are clear. Four triggers for each SONAR per second is my first guess.

Now to bed. Thanks.

Ken

---

I think once you have the PWM stuff sorted in your head, I feel like you may need to address this not knowing part. If your car is going a mere 10 mph, that's approx 14 feet per sec. If you only check each direction (front and side) four times a sec, your car will have traveled 3.5 feet!!! Ok maybe you are not going 10, but how bout 2 mph? That will still be 7.5 inches. At that rate, you will be correcting for things long past.

I have been forgetting that this car is capable of mph. Not just 10, but over 20. I am pushing some boundaries. I know nothing theoretical about control math. My gut tells me that knowing rate (ie trend) is of great importance -- somehow.....

Ken

Great point Bert.

Ken, can you remind me again, what sonar sensor you are using? Parallax's sensor looks like it can do just about every 20ms. But not sure what it will do with echos that are further away. But I don't think you are using their sensor, so it probably has different specifications.

Walter

Ken, I really don't know much about control math either. I tend to think of things as instant. So at some point This whole thing may very well go over my head. FWIW, I am thinking about your sensors as if they were a gyro on an R/C copter. The gyros watch for any movement not commanded by the Rx. when this happens, they instantly modify the signal to the servo to correct and bring the controlled axis (usually the tail) back to where it was. The more movement the harder it tries to bring it back. Now if we think about this in terms of a little older equipment, this can only happen every 20 msec. but that is plenty fast enough to keep the tail looking rock steady.

With your car, I look at it like this: if you want to maintain a distance, say 12 inches from the right wall, every command to the steering will have some adjustment in it to keep it there. Sensor takes a distance-wall is 11.9" away, turn left a little. next loop, wall is still 11.9 turn more. next loop, wall is 12.02", turn back.

Same with the front wall, except for the amount to turn will need to be more because the wall is approaching. the side sensor will also need to know it should expect to move away from the wall and not fight the front sensor.

Here's the WEB page for my SONAR SF05.

http://www.robot-electronics.co.uk/htm/srf05tech.htm

It says:
-10microsec trigger pulse
-produces an 8 cycle burst of 40khz sound (total duration 5millisec)
-can be triggered every 50millisec (20 per second)
-the beam pattern is conical.

Details! Details! Ain't technology grande!
Ken

cncmachineguy,

I sort of tried to do what you say:

Quote:

---

goingforward:
HPWM 1,Straight,50
HPWM 2,Forward,50
'-------------------
keepgoingforward: '----Compare to right wall
IF rangeright > outertrack THEN
HPWM 1,QuarterRight,50
ENDIF

IF rangeright < desiredtrack AND oldrangeright < rangeright THEN
HPWM 1,Straight,50
ENDIF

IF rangeright > desiredtrack AND oldrangeright > rangeright THEN
HPWM 1,Straight,50
ENDIF

IF rangeright > desiredtrack AND oldrangeright < rangeright THEN
HPWM 1,QuarterRight,50
ENDIF

IF rangeright < desiredtrack AND oldrangeright >= rangeright THEN
HPWM 1,QuarterLeft,50
ENDIF

GOTO main

---

I have three degrees of turning in each direction. My "oldrangeright" WORD is the previous reading of that SONAR. What I had not done was make this state machine "math" actually proportional. My present thinking is that with finer control I would get smaller oscillations.

Ken

I have avoided translating to digital any of my measurements. I have used > and <, but no actual arithmetic. To go proportional per the PID, requires that I do arithmetic. HEX or digital, that is the question. I'd like to think in digital, may I?

I'm going to reveal my age. I wrote in machine language on the IBM 370 back in the last century. Well back in the last century. Since then it has been C, C++, shell, tcl. I am used to having a large library backup and writing in a modular fashion. Now it is PBP. I think I need to know more about ASM coding and the architecture of the PICs. What is the easiest (best) way to learn?

Ken

cncmachineguy, TIMER1 interrupt with a carefully chosen pre-set sounds good to me. I am not succeeding in figuring out how to do it. Page 32 in the 887 spec talks about PIE1. Page 70 talks about T1CON. I do not know where to look for an example.

Is there a collection of PBP and ASM code samples? If so, where?

Ken

Hey Ken,

I know a lot of people prefer on interrupt type. But my vote for easy interrupt is to use Darrels instant interrupts (and I think an equally large number of people like them as well). Here is a simple example of a blinky interrupt using his include files. The pages on this site have a lot of information about the different kinds of interrupts you can do. Your chip needs to use DT_INTS-14. And of course DT_INTS-18 is for PIC18 devices.

http://darreltaylor.com/DT_INTS-14/blinky.html

I don't think you want on interupt, just my opinion from reading the manual. I think you want to figure out DT int. Seems to be true int without Dealing with ASM.

I agree that DT's interrupts or ASM's are the way to go. I gave the ON INTERRUPT code above as an example to get started. Ken will still need to know how pre-scalers and such work no matter what.

Ken seems to want to know the nuts and bolts of things. In my opinion getting a simple code to work with ON INTERRUPTS is a crawl/walk thingy.

I am not real clear on how the motor driver works. I understand it as PWM greater than 127 turns one way and less than 127 turns the other way??

I just drove home trying to simulate Ken's car. Pulsed the same degrees left or right, more pulses left or right for turns but always the same, say 5 degrees off center, and after each pulse returned to center.

What about a two chip solution. The main chip will do nothing more than
center, pulse left, center, pulse right, center...

Second chip deals with the sonar. If a correction needs made a given pin is toggled.

The main chip is using an interrupt on change and completely interrupt driven. The main chip can deal with the pulse left, center, pulse right while the other chip is busy with the next calculation.

Just a half baked thought.

Right now I want an interrupt every 5 millisec. With a 1megahz clock and a 65356 counter, every 5 millisec is every 5000 ticks of that clock. cncmachineguy suggests that I generate an interrupt each time the clock gets down to 60356 by pre-setting the TIMER1 counter.

I understand that, but have not the faintest notion how to accomplish it. I have gone to Darrel Taylor's site. It is well written, but I do not see how it helps me.

Please help me get an interrupt every 5 millisec. Then I can try to figure out what code is needed to control the little car.

Ken

Quote:

---

Originally Posted by mackrackit

I just drove home trying to simulate Ken's car. Pulsed the same degrees left or right, more pulses left or right for turns but always the same, say 5 degrees off center, and after each pulse returned to center.

---

How'd that work out for you? :)

@Ken, Clearly there is some learning/teaching to be done here. What would you like to start with? DT_INTS or pre scaling and such?

For DT_INTS, I am gonna grab a copy and look/learn it myself. I will prolly jump on the learning side with you when you are ready to go through it. There are plenty here that will be able to answer any/all of our specific questions.

As for the pre scaler, I will go grab a copy of your datasheet. I agree with Dave, this is something you should understand even if you don't need it just yet.

BTW, PIE1 is Peripheral Interupt Enable 1. Without looking (yet) at the datasheet, I am guessing that is the enable for timer 1. In ASM, to use interupts, you must do 2 things. GIE must be set (Global Interupt Enable) this allows any interupt to do its thing. then you must set each interupt enable you want to use such as PIE1. Now with DT_INTS, I think that may be taken care of as part of the include, but I am not sure just yet.