 |
 |
| View previous topic :: View next topic |
| Author |
Message |
Linuxbuilders
Joined: 20 Mar 2010
Posts: 193
Location: Auckland NZ
|
| program speed |
 Posted: Fri Sep 17, 2010 7:36 am |
 |
|
Hi,
I have a small question.
I have noticed that execution of simple if( a==b) {} is faster than if this is not true. It the function does not return true I can see significant delay in program processing. Anyone know anything about such thing?
| Code: |
if (server_mode == 1) {
if (bus_mode == 1) {
fprintf(eth,"\n>CPU: Server mode can't operate when Bus mode is ON!");
server_mode = 0;
} //*
else {
if (general_tasks >= general_task_delay) {
tasks();
ping();
} //*
} //*
} //*
|
This creates such delay if true that I can see it...very strange...
It affects ram operation too (overrides data).
I initiate vars in globals like this:
| Code: | long int general_task_delay = 2000;
long int general_tasks = 0;
short bus_mode = 0;
short server_mode = 0; |
I wonder if it is "short" responsible for my troubles...
Thank you
_________________
Help "d" others and then you shell receive some help from "d" others. |
|
 |
Ttelmah
Joined: 11 Mar 2010
Posts: 19365
|
|
| Posted: Fri Sep 17, 2010 10:17 am |
|
|
You talk about a function returning true, but there is no function shown in your code doing this.
If the test 'a==b', is true, then there is going to be a significant delay. Not from the test, but from the code called. If 'bus_mode' is true as well, you are going to take a huge time printing a message - if the serial is running at 9600bps, then something over 50mSec, going the other way, if the next test on 'general_tasks' is true, you have all the time involved in 'tasks', and 'ping'.
The total time for a bit mode test on a short variable, is normally just a couple of machine cycles. About the quickest test possible (slightly longer if a bank switch is needed).
You have something else wrong, probably in one of the subroutines involved, or the code you are using to test the performance.
As a comment, remember the 'non zero', is inherently true, so you could write:
if (server_mode)
Also easier to understand if you use the boolean defines, so:
server_mode=FALSE;
These won't save anything though, the compiler does this for you.
Best Wishes |
|
|
Linuxbuilders
Joined: 20 Mar 2010
Posts: 193
Location: Auckland NZ
|
|
| Posted: Fri Sep 17, 2010 6:47 pm |
|
|
thank you
_________________
Help "d" others and then you shell receive some help from "d" others. |
|
|
Linuxbuilders
Joined: 20 Mar 2010
Posts: 193
Location: Auckland NZ
|
|
| Posted: Sat Sep 18, 2010 12:48 am |
|
|
I have found a problem, PCH 4.107 is initiating PLL wrong on the chip.
I am using 10Mhz external crystal and want it to clock mpu with 40MHz.
according to datasheet:
HSPLL High-Speed Crystal/Resonator mode,
PLL can be enabled or disabled in
software, crystal/resonator connected
between RA6 and RA7.
However fuses for this chip does not have such option.
| Code: |
//////// Fuses: HS,EC,DEBUG,NODEBUG,XINST,NOXINST,STVREN,NOSTVREN,WDT,NOWDT
//////// Fuses: PROTECT,NOPROTECT,WDT1,WDT2,WDT4,WDT8,WDT16,WDT32,WDT64
//////// Fuses: WDT128,WDT256,WDT512,WDT1024,WDT2048,WDT4096,WDT8192
//////// Fuses: WDT16384,WDT32768,FCMEN,NOFCMEN,IESO,NOIESO,IOL1WAY
//////// Fuses: NOIOL1WAY,INTRC,WPCFG,NOWPCFG,WPBEG,WPEND,WPDIS,NOWPDIS
//////// Fuses: LPT1OSC,NOLPT1OSC,T1DIG,NOT1DIG,MSSPMSK5,MSSPMSK7,INTRC_PLL
//////// Fuses: INTRC_PLL_IO,INTRC,DSWDT2,DSWDT8,DSWDT32,DSWDT128,DSWDT512
//////// Fuses: DSWDT2048,DSWDT8192,DSWDT32768,DSWDT131072,DSWDT524288
//////// Fuses: DSWDT2097152,DSWDT8388608,DSWDT33554432,DSWDT134217728
//////// Fuses: DSWDT536870912,DSWDT2147483648,DSWDT,NODSWDT,DSBOR,NODSBOR
//////// Fuses: RTCOSC_INT,RTCOSC_T1,DSWDTOSC_INT,DSWDTOSC_T1,WPFP,NOWPFP
|
What I had in my code was H4_SW and this was compiled by 4.107. After upgrade to 4.110 compiler didn't agree with this option. When I have done everything as per 18F45j11.h then whole thing went to heaven and is very happy since.
Any idea how to get HSPLL working on this chip?
This is my setup:
| Code: |
#FUSES WDT //No Watch Dog Timer
#FUSES WDT2048 //Watch Dog Timer uses 1:128 Postscale
#FUSES HS
#FUSES NODEBUG //No Debug mode for ICD
#FUSES NOXINST //Extended set extension and Indexed Addressing mode disabled (Legacy mode)
#FUSES STVREN //Stack full/underflow will cause reset
#FUSES NOPROTECT //Code not protected from reading
#FUSES FCMEN //Fail-safe clock monitor enabled
#FUSES NOIESO //Internal External Switch Over mode disabled
#FUSES IOL1WAY //Allows only one reconfiguration of peripheral pins
#FUSES NOWPCFG
#FUSES WPEND
#FUSES WPDIS
#FUSES NOLPT1OSC //Timer1 configured for higher power operation
#FUSES NOT1DIG
#FUSES MSSPMSK7
#FUSES DSWDT2048
#FUSES NODSWDT
#FUSES NODSBOR
#FUSES RTCOSC_INT
#FUSES DSWDTOSC_INT
#FUSES WPFP
#use delay(clock=10M,RESTART_WDT)
|
thnx
_________________
Help "d" others and then you shell receive some help from "d" others. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19365
|
|
| Posted: Sat Sep 18, 2010 2:00 am |
|
|
clock=10M, is never going to be 'right' for a 40MHz system....
clock=40M,crystal=10M
Best Wishes |
|
|
Linuxbuilders
Joined: 20 Mar 2010
Posts: 193
Location: Auckland NZ
|
|
| Posted: Sat Sep 18, 2010 2:04 am |
|
|
this gives an error - NO PLL
_________________
Help "d" others and then you shell receive some help from "d" others. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19365
|
|
| Posted: Sat Sep 18, 2010 2:33 am |
|
|
So what chip is this?.
You talk about having done everything 'as per 18F45j11.h', but don't tell us what chip you actually have.
Best Wishes |
|
|
Linuxbuilders
Joined: 20 Mar 2010
Posts: 193
Location: Auckland NZ
|
|
| Posted: Sat Sep 18, 2010 2:39 am |
|
|
that is the chip thnx, if I tell it to be 40mhz then I get rubbish from serial port, if I do it as you suggest (what is correct) then I get an error. so it must be set for 10Mhz and somehow I need to tell it to be PLL but the only way I can see it is by setup_oscillator(OSC_NORMAL, OSC_PLL_ON); which I do not think is intended for this purpose. I think CCS has missed this bit (H4) in .h file.
my setup is here:
| Quote: |
#FUSES WDT
#FUSES WDT2048
#FUSES HS
#FUSES NODEBUG //No Debug mode for ICD
#FUSES NOXINST //Extended set extension and Indexed Addressing mode disabled (Legacy mode)
#FUSES STVREN //Stack full/underflow will cause reset
#FUSES NOPROTECT //Code not protected from reading
#FUSES FCMEN //Fail-safe clock monitor enabled
#FUSES NOIESO //Internal External Switch Over mode disabled
#FUSES IOL1WAY //Allows only one reconfiguration of peripheral pins
#FUSES NOWPCFG
#FUSES WPEND
#FUSES WPDIS
#FUSES NOLPT1OSC //Timer1 configured for higher power operation
#FUSES NOT1DIG
#FUSES MSSPMSK7
#FUSES DSWDT2048
#FUSES NODSWDT
#FUSES NODSBOR
#FUSES RTCOSC_INT
#FUSES DSWDTOSC_INT
#FUSES WPFP
#use delay(clock=10M,RESTART_WDT)
|
_________________
Help "d" others and then you shell receive some help from "d" others. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19365
|
|
| Posted: Sat Sep 18, 2010 2:55 am |
|
|
4.107, for the 18F45J11, lists E4_SW as a legitimate fuse. Though I don't normally use the Wizard, selecting 40MHz, with PLL, gives the following fuses:
| Code: |
#FUSES HS //High speed Osc (> 4mhz for PCM/PCH) (>10mhz for PCD)
#FUSES E4_SW
|
Which compiles happily, with the clock line posted, and seems to be operating at 40Mhz in MPLAB.
Best Wishes |
|
|
Linuxbuilders
Joined: 20 Mar 2010
Posts: 193
Location: Auckland NZ
|
|
| Posted: Sat Sep 18, 2010 3:07 am |
|
|
hmm...that is what I get from 4.110
| Quote: |
//////// Standard Header file for the PIC18F45J11 device ////////////////
#device PIC18F45J11
#nolist
//////// Program memory: 16380x16 Data RAM: 3840 Stack: 31
//////// I/O: 34 Analog Pins: 13
//////// C Scratch area: 00 ID Location: 0000
//////// Fuses: HS,EC,DEBUG,NODEBUG,XINST,NOXINST,STVREN,NOSTVREN,WDT,NOWDT
//////// Fuses: PROTECT,NOPROTECT,WDT1,WDT2,WDT4,WDT8,WDT16,WDT32,WDT64
//////// Fuses: WDT128,WDT256,WDT512,WDT1024,WDT2048,WDT4096,WDT8192
//////// Fuses: WDT16384,WDT32768,FCMEN,NOFCMEN,IESO,NOIESO,IOL1WAY
//////// Fuses: NOIOL1WAY,INTRC,WPCFG,NOWPCFG,WPBEG,WPEND,WPDIS,NOWPDIS
//////// Fuses: LPT1OSC,NOLPT1OSC,T1DIG,NOT1DIG,MSSPMSK5,MSSPMSK7,INTRC_PLL
//////// Fuses: INTRC_PLL_IO,INTRC,DSWDT2,DSWDT8,DSWDT32,DSWDT128,DSWDT512
//////// Fuses: DSWDT2048,DSWDT8192,DSWDT32768,DSWDT131072,DSWDT524288
//////// Fuses: DSWDT2097152,DSWDT8388608,DSWDT33554432,DSWDT134217728
//////// Fuses: DSWDT536870912,DSWDT2147483648,DSWDT,NODSWDT,DSBOR,NODSBOR
//////// Fuses: RTCOSC_INT,RTCOSC_T1,DSWDTOSC_INT,DSWDTOSC_T1,WPFP,NOWPFP
////////
////////////////////////////////////////////////////////////////// I/O
// Discrete I/O Functions: SET_TRIS_x(), OUTPUT_x(), INPUT_x(),
// PORT_x_PULLUPS(), INPUT(),
// OUTPUT_LOW(), OUTPUT_HIGH(),
// OUTPUT_FLOAT(), OUTPUT_BIT()
// Constants used to identify pins in the above are:
|
it does not recognize H4,E4, and _SW... Where is "fuses" setup nested? I think it will be simple mistake and may be easily corrected by adding proper bits into config file...
When I go to chipedit then I see no data for HSPLL, There is only HS mask 0007 and value 0004 CW 2.
thnx
_________________
Help "d" others and then you shell receive some help from "d" others. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19365
|
|
| Posted: Sat Sep 18, 2010 8:10 am |
|
|
It is worth saying, that the fuse 'listing' at the top of the header file, means _nothing_. It is not used by the compiler, and does not always relate to the real fuses available. It was there as an 'aide memoire' with the early compilers, but now is so often wrong that using it is pointless...
If you have the ICD, then the 'valid fuses' pull down, does give a list that normally seems to agree with the real fuses.
Now, it appears that 4.107, had 'lost' the actual 'enable PLL in the fuses' fuse setting, and this is back in the later compilers as HSPLL.
4.110, had a lot of bugs (look at the posts here).
Best Wishes |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
