Darrel,
How about a little tutorial on how to tell which assembler is in use, and how to switch to the mpasm?
Darrel,
How about a little tutorial on how to tell which assembler is in use, and how to switch to the mpasm?
OK, how bout this for detection ...If you put that in your program, and try to assemble it with PM.exe, It will automatically pop-up a window in MicroCode Studio like this ...Code:ASM ifdef PM_USED "Dude, you have to use MPASM with DT_INTS" endif ENDASM
<img src="http://www.picbasic.co.uk/forum/attachment.php?attachmentid=2450&stc=1&d=120694493 9" />
Then you can just click on "Compile Using MPASM", and it will set the MPASM option and compile it.
If it still fails to compile, you should try this ...
http://www.picbasic.co.uk/forum/show...5&postcount=11
I should add that to DT_INTS-14.
hth,
<br>
DT
Hi DT,
I wanted to post a "thank you" (also as an informative post).
For the first time ever, I used your 18F routine (with RX_INT) about a minute ago.
I saved 3100 bytes!!!
Really very interesting for me.
Thanks a lot for your amazing work.
"If the Earth were a single state, Istanbul would be its capital." Napoleon Bonaparte
Hi sayzer,
2 years and 3 months since you joined.
What took you so long?
WOW! Saved 3100 bytes. That's pretty impressive.
Can I ask what the difference was? or maybe where the savings came from?
<br>
DT
You mean that comparing to On-Interrupt of PBP you did a reduction of 3100?
Ioannis
Hi Ioannis,
Actually I tried different codes after this experiment and came up with these simple results.
1. In a relatively large code, DT's 18F int routine saves a lot of code space compared to On-Interrupt of PBP as you said.
Ex: I saved 3100 bytes for the same code (code size : approx. 18,000 bytes).
2. In a small code, DT's 18F routine becomes code hungry.
Ex: PBP On-Interrupt produces 318 bytes for a sample code I just tried, but
DT's 18F int routine produces 762 bytes. More then twice larger!
As the code gets longer, DT's int routine gets handier I suppose.
"If the Earth were a single state, Istanbul would be its capital." Napoleon Bonaparte
Since On Interrupts of PBP puts a check every assembly instructions is obvious why is that code explosion!
Sure Darrels routines are fixed in length, so either your code is short or long, these routines are known in length. And in my humbble opinion, comparing Darrels interrupts with PBP interrupts is like comparing apples and oranges. Two different things.
Ioannis
NO.. at least give more details... error message, code etc etc
Make sure you're using MPASM to compile
Steve
It's not a bug, it's a random feature.
There's no problem, only learning opportunities.
WoW!
those routines works like magic for a noobie like me
I've found out that most of my code must be done inside the interrupt part, otherwise if it's in the Main loop it can get trashed by the interrupt(like SEROUT to a serial LCD), but it got my
latest project running very quickly.
tnx Darrel
First of all thanx for the code my interups now gets handeled fast enoug so i dont loose any serial data, one problem for some reason my program do not return from the interupt.
Any ideas
i use a 16f913
Code:INCLUDE "MODEDEFS.BAS" INCLUDE "DT_INTS-14.bas" ; Base Interrupt System DEFINE OSC 20 ' Define crystal as 20Mhz '*Serial port Setup 9600 8N1* DEFINE HSER_BAUD 9600 ; 9600 Baud DEFINE HSER_RCSTA 90h ' Enable serial port & continuous receive DEFINE HSER_TXSTA 24h ' Enable transmit, BRGH = 1 DEFINE HSER_CLROERR 1 ; Clear overflow automatically '*ADC setup* DEFINE ADC_BITS 10 'SETS NUMBER OF BITS IN RESULTS 8,10,12 DEFINE ADC_CLOCK 3 'SETS CLOCK SOURCE (RC = 3) DEFINE ADC_SAMPLEUS 50 'SETS SAMPLING TIME IN MICROSECONDS 'This Part set PORTA 0-5 an analog inputs ADCON1 = %01110000 'FRC (clock derived from a dedicated internal oscillator = 500 kHz max) ANSEL = %00011111 'The ANSEL (91h) and CMCON0 (9Ch)registers must be initialized to configure an CMCON0 = %00000111 'analog channel as a digital input. Pins configured as analog inputs will read ‘0’. TRISA = %00011111 'set PORTA 0-5 as inputs ADCON0.7 = 1 'Right justify output of ADC datasheet P145 of 16F913 TRISC = %10000000 'Set PORTC for serial coms and pins as output TRISB = %00000000 'Sert PORTb as outputs and for use with the ICD2 V1 var WORD ID var byte[28] CELL1 VAR BYTE[11] I VAR BYTE PORTC = 0 ASM INT_LIST macro ; IntSource, Label, Type, ResetFlag? INT_Handler RX_INT, _IntLoop, ASM, yes endm INT_CREATE ; Creates the interrupt processor INT_ENABLE RX_INT ; enable external (RX) interrupts ENDASM Main: PORTC.5=1 PAUSE 200 PORTC.5=0 PAUSE 200 PORTC.5=1 PAUSE 200 PORTC.5=0 goto Main IntLoop: HSERIN [WAIT("^SMGL:"),SKIP 1 ,str ID\28] HSEROUT ["CELL NO:",_ ID[17],iD[18],ID[19],ID[20],ID[21],ID[22],_ ID[23],ID[24],ID[25],ID[26],ID[27],10,13] @ INT_RETURN END
As you're using HSERIN/HSEROUT, shouldn't RX_INT be PBP type instead?
Don't forget to add ReEnterPBP.bas in your INCLUDE list.
Last edited by mister_e; - 30th April 2008 at 18:56.
Steve
It's not a bug, it's a random feature.
There's no problem, only learning opportunities.
Hi,
I thought I could point this out. This forum is fortunate that there are less people like me. Late and lazy.
BTW Steve everytime I see the avatar banging head on the keyboard I feel concerned. Please stop banging your head. Its costly. I mean the keyboard that is...
Regards
Sougata
LMAO! well this avatar is really me... if you feel concern... i'm sorry
I see some other potential problem in the above anyways.
From one of his previous post he says that
^SMGL: 1,"REC UNREAD","+27829554322",,"08/04/20,17:12:09+08"
could be the incoming string... so obviously, using his HSERIN line, it may return to the INT routine and spining around and around. my 2nd suggestion add a little timeout like this...
this way + PBP type it should solve most, see all problems.Code:IntLoop: HSERIN 10, GETOUT,[WAIT("^SMGL:"),SKIP 1 ,str ID\28] HSEROUT ["CELL NO:",_ ID[17],iD[18],ID[19],ID[20],ID[21],ID[22],_ ID[23],ID[24],ID[25],ID[26],ID[27],10,13] GETOUT: @ INT_RETURN
HTH
Steve
It's not a bug, it's a random feature.
There's no problem, only learning opportunities.
Thanks mister-e the second suggestion with the time out did the trick, still not hundred present sure why it works like that but shore are glad it works
Thanks again
look post 296... if i was right, your PIC will wait 'till the next time it receive ^SMGL: when the timeout is not used.
Steve
It's not a bug, it's a random feature.
There's no problem, only learning opportunities.
I have been playing with the code shown below on a 16f737 as I was trying to get different prescaler values into the int routinues. As part of the testing I stripped the code right back to just be a simple interrupt with a value loaded into the pre-load registrer, but I seem to end up with an interrupt time of 204uS. According to the Timer Calc in Mister E's PicMulti Calc I should get an interrupt every 5.019mS. (see attached image for capture of the output waveform - I love my PICkit 2!)
This code is lifted straight from Darells example with the blinky led (1-2-3 version), and all I have done is add the pre-load. I have also removed the pre-load and still get the same time for the interrupt.
There has got to be something really simple I am missing...Code:DEFINE OSC 20 rs_led var portb.7 ' rs232 led led var portc.4 ' was Data_Out line ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' INCLUDE "DT_INTS-14.bas" ' Base Interrupt System INCLUDE "ReEnterPBP.bas" ' Include if using PBP interrupts ASM INT_LIST macro ; IntSource, Label, Type, ResetFlag? INT_Handler TMR0_INT, _doBAM, PBP, yes endm INT_CREATE ; Creates the interrupt processor ENDASM OPTION_REG = OPTION_REG & $80 | 1 'Set TMR0 Prescaler to 256, leave RBPU alone TMR0 = 158 ' preload with 158 to give 21uS interrupts (at 1:1) ' this should then give Interrupt every 5.019mS at 1:256 @ INT_ENABLE TMR0_INT ; enable Timer 1 interrupts '~~~~~~~~~~~~~~~~~~ goto main ' jump over ISR '---[TMR0 - interrupt handler]-------------------------------------------------- doBAM: toggle rs_led @ INT_RETURN '~~~~~~~~~~~~~~~~~~~~~~~~~~~ high rs_led main: ''''''''''''''''''''''' ' do some flashing led stuff ''''''''''''''''''''''' high led pause 500 low led pause 500 goto main
bill.
Last edited by bcd; - 1st May 2008 at 09:19. Reason: Clarification of a few things
Use OPTION_REG = %11010111
And load the timer on every interrupt.
<br>
DT
Thanks,
See told you it would be something really simple I missed..
(Hey Darrel - how do you get your code blocks so colourful and properly indented ?)Code:doBAM: toggle rs_led TMR0 = 158 ' reload the pre-load @ INT_RETURN
bill.
http://www.picbasic.co.uk/forum/showthread.php?t=6221
The page may take awhile to load.....
Hello;
I'm Ryan form the Philippines I must admit DTS-14 ints rules!!! i'd like to know how can i turn the interrupt on and off for USART continues recepton I'm using PIC16f877a toggling register PIE.5 doesn't seem to work
Thanks
PS.
Part of my project i'm paying my tuition continue college again OSY for sometime now hehe (",)
Check out this post, esp. post 5, http://www.picbasic.co.uk/forum/showthread.php?t=3251
If you do not believe in MAGIC, Consider how currency has value simply by printing it, and is then traded for real assets.
.
Gold is the money of kings, silver is the money of gentlemen, barter is the money of peasants - but debt is the money of slaves
.
There simply is no "Happy Spam" If you do it you will disappear from this forum.
you can use
@ INT_ENABLE RX_INT
and
@ INT_DISABLE RX_INT
Steve
It's not a bug, it's a random feature.
There's no problem, only learning opportunities.
ahhh thanks guys
fixed it toggling both
' CREN = 0
' SPEN = 0
I didn't bother with the interrupts just disabled the Port input thanks I appreciate it!!!
Hi Darrell, I tried to use your great rutines without any luck. I'm using a 18F248 sending CAN messages and I want to use a timer interrupt to send it.
Just to test the rutines I tried to compile the example you post for timer interrupt and DT_INTS-18.bas rutines. But I got some errors on the compilation. Attached you will find a screen shot of what i'm talking about. If anybody can tell me what I'm doing wrong, it will be a great help for me.
Thanks in advance for all yor help
Alfredo
Hi Alfredo,
Well apparently, not all CAN modules are the same.
There are 2 types, CAN and ECAN.
I didn't consider the plain CAN module when I wrote it.
I'll have to make a way for it to detect which module is available and only use the interrupts for it. Then I'll post an update.
But for now, you can just comment out the interrupt Sources that aren't available.
In the DT_INTS-18.bas file, comment out the following lines in the CAN Module section ...Thanks for the info!Code:asm ; -- CAN Module -- ifdef WAKIF ;----{ CAN bus Error }------------------------[PIR3, ERRIF]--- INT_Source CAN_ERR_INT, PIE3,ERRIE, IPR3,ERRIP ;----{ Invalid Received Message }-------------[PIR3, IRXIF]--- INT_Source CAN_IRX_INT, PIE3,IRXIE, IPR3,IRXIP ;----{ Receive Buffer 0 }------Mode 0--------[PIR3, RXB0IF]--- INT_Source CAN_RXB0_INT, PIE3,RXB0IE, IPR3,RXB0IP ;----{ FIFO Watermark }--------Mode 1, 2---[PIR3, FIFOWMIF]--- ; INT_Source CAN_FIFOWM_INT, PIE3,FIFOWMIE, IPR3,FIFOWMIP ;----{ Receive Buffer 1 }------Mode 0--------[PIR3, RXB1IF]--- INT_Source CAN_RXB1_INT, PIE3,RXB1IE, IPR3,RXB1IP ;----{ Any Receive Buffer }----Mode 1, 2-----[PIR3, RXBnIF]--- ; INT_Source CAN_RXBn_INT, PIE3,RXBnIE, IPR3,RXBnIP ;----{ Transmit Buffer 0 }-------------------[PIR3, TXB0IF]--- INT_Source CAN_TXB0_INT, PIE3,TXB0IE, IPR3,TXB0IP ;----{ Transmit Buffer 1 }-------------------[PIR3, TXB1IF]--- INT_Source CAN_TXB1_INT, PIE3,TXB1IE, IPR3,TXB1IP ;----{ Transmit Buffer 2 }-----Mode 0=-------[PIR3, TXB2IF]--- INT_Source CAN_TXB2_INT, PIE3,TXB2IE, IPR3,TXB2IP ;----{ Any Transmit Buffer }---Mode 1, 2-----[PIR3, TXBnIF]--- ; INT_Source CAN_TXBn_INT, PIE3,TXBnIE, IPR3,TXBnIP ;----{ CAN bus Activity Wake-up }-------------[PIR3, WAKIF]--- INT_Source CAN_WAKE_INT, PIE3,WAKIE, IPR3,WAKIP endif list endm list ENDASM
DT
WOOOOW!
Thank you very much for the info, now I can use your rutines!!! Your info fix my problem
Thanks again!!!
Alfredo
.Damn.. way to slow this time
my solution was..
From p18f8680.inc file...Code:asm RXBnIF=RXB1IF TXBnIF=TXB2IF FIFOWMIF=RXB0IF INT_LIST MACRO INT_Handler TMR1_INT, _ToggleLED1, PBP, yes endm INT_CREATE endasm
On another hand... seems odd...Code:;----- PIR3 Bits ----------------------------------------------------- RXB0IF EQU H'0000' RXB1IF EQU H'0001' TXB0IF EQU H'0002' TXB1IF EQU H'0003' TXB2IF EQU H'0004' ERRIF EQU H'0005' WAKIF EQU H'0006' IRXIF EQU H'0007' FIFOWMIF EQU H'0000' RXBnIF EQU H'0001' TXBnIF EQU H'0004'
Last edited by mister_e; - 30th May 2008 at 23:33.
Steve
It's not a bug, it's a random feature.
There's no problem, only learning opportunities.
Good one Steve. That would have worked too.
Since they're actually the same bit's, but with different Names depending on the mode, that might be an easy way for me to fix it. Maybe.
<br>
DT
But yeah... we know how Microchip work... hard to tell if it will always work... on all PIC
Worth a try!
Steve
It's not a bug, it's a random feature.
There's no problem, only learning opportunities.
Steve,
Do you know if the there is any difference in accuracy between using a xtal osc and the internal RC osc esp. in relation to timer interrupts?
Squib
Must be Steve's day off.
Hi Squib,
Well it depends on the internal oscillator type, and how you're using the interrupts.
The typical general purpose crystal will have a tolerance of +/- 50 PPM (Parts per million) Although there are other crystals with tighter tolerances, some down to less than 1 PPM. But they come at a higher cost.
If you're using one of the older 4mhz internal oscillators, depending on temperature and proper calibration numbers, they can vary up to +/-10% (100,000 PPM). A HUGE difference.
The newer 8mhz oscillators will vary a modest +/- 2.5% over the temperature range, but that's still 25,000 PPM.
If the interrupts are being used for "Long Term" timing like a clock, a difference of 1 PPM translates to an error of +/- 31.5 seconds per year. At 50 PPM it's 26.3 minutes/yr
But with the 8mhz INT_OSC, you're looking at a whopping 9.1 Days/Yr.. And with the old 4mhz osc you're off by +/-36.5 days. Yikes!
Of course these are "Worst case" numbers with maximum temperature extremes, actual results may vary.
hth,
DT
For reference, I recently tried to see what kind of baud I could get out of my pic serial port, using the internal 8MHz osc. I used an FTDI232R on the PC side, which accepts +/- 3% on the baud rate. The lower baud rates locked in fine, but at 125Kbaud, I had to slow the PIC baud rate down to 118k to 124k. (I did not try any fractions to get more precise failure speeds.) Apparently at the temperature of that particular pic at that particular time, the oscillator was running about 3% fast. That's 30,000 parts per million... way off, I would say.
Thanks DT for the info, those are some pretty scarey numbers you pulled up!
The reason I asked was I have a three minute timer using DT_14 interrupts and I also used Steves Pic timer calc but I'm consistantly getting the timer out by about -10 secs using the int_osc at 8MHz.
I'll try an ext_xtal and see if I get the same error, but comparing my error to the numbers you pulled up, mines probabaly due to a coding error. :-)
If I find a difference I'll let you know.
Cheers
10 seconds in 3 minutes ....
That's around a 5.5% error, and the OSC would be 7,555,556 Mhz.
http://spreadsheets.google.com/pub?k...uiCKE-EFrRLaZA
I think you're right about it not being the OSC
Are you using the Timer Template, or the Elapsed Timer?
DT
Apropos of nothing in particular . . .
I finally had a project where I needed a simple background "heartbeat" indicator while doing other things with a 16F627A, so I used Darrel's "overkill" blinky.
It works like a charm.
I'll tell everyone this:
It took a few tries, but solutions for each problem and error message I encountered were found on this site. I just had to Do A Search.
. . . well, except one instance--I was getting a message that the file path to the source code was too long (something like in excess of 62 characters). So I moved the file set to a different location with a shorter path. Duh!
I suppose the point I'm making, though, is that beyond RTFM and RTFDS, it doesn't hurt to DAFS.
The search tool Darrel posted works really well, sometimes with as little as a few words from the error message.
Kudos to Darrel Taylor!
Last edited by RussMartin; - 17th June 2008 at 09:46.
Russ
N0EVC, xWB6ONT, xWN6ONT
"Easy to use" is easy to say.
I'm having problems with my LCD (BPI-216) when using these intterupts.
When using the code for the clock interrupt and button interrupt the LCD display junk.
If using only one of the intterupts the junk is less, but still.
It is mostly happen if pressing then button very often.
Can someone advice?
Last edited by menta; - 22nd June 2008 at 21:37.
Bookmarks