We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
I am using Timer12 and Timer7 to drive the CAPCOM6 unit on the Phytec C164 nanoModule using Space Vector Modulation for induction motor drive control. This program also uses CAPCOM6 interrupts for regular modification of pulse widths for sinusoidal waveform outputs. My problem is, the program works fast (as desired for precise pulse control) when I do not specify any number on the external memory in the Target configuration panel. I do get four warnings during linking, but the program works fine. However, when I specify ROM and RAM address and sizes on the panel, the warnings disppear but my program becomes miserably slow. What have the interrupt procedures to do with ROM and RAM locations???
Hi, Maybe the math functions behave differently when you change the memory locations. I have some interger and long integer divisions that seem to behave differently when the ROM and RAM addresses are correctly specified. Could it be a stack problem. I am using a lot of idata variables, does this also effect the math handling??
Sounds strange, but my problem with "execution speeds" was related more to math equations than to memory locations. My program uses variables that control timings on some timers. All these variables are manipulated inside interrupt functions. For example I get wrong results in the following program: int den = 0xff; int result; long num = 500000; void dummy() interrupt 0x3d /* timer ISR */ { result = num / den; } whereas 'result = num / 0xff;' gives me right results! It's been baffling me for quite some time. Forcing the equation by 'long' does not work. There is another higher priority interrupt using (not modifying) variable 'result'.
Did you try to single-step through your code in the disassembler window of simulator? Ususally it solves all 'mysteries' of this kind. Regards, - Mike
There is another higher priority interrupt using (not modifying) variable 'result'. What happens if the higher priority interrupt occurs when this interrupt routine is modifying result? Jon
Hi Mike and Jon, I haven't tried the simulator, however, I would like to know if it would simulate a timer interrupt? Replying to Jon's question, it is quite probable that the high priority interrupt could occur at the wrong moment of low priority ISR execution. The higher priority ISR is run by a timer at 10000 Hz and the low priority ISR at 10 Hz. What happens here - I do not know. I do not have a logic analyzer. I used to get the right results when the correct ROM location were not specified! Strange!? However, the division problem is definitely faced when operated in side the ISR and not in ordinary routines (main() for example. Thanks
I haven't tried the simulator, however, I would like to know if it would simulate a timer interrupt? The simulator simulates nearly everything on the C167 devices. All timers and interrupt are certainly simulated. I suggest you start the debugger and take a look at the peripherals menu. There are dialogs for every on-chip peripheral. Jon