HI Mikroelektronika team
R0............R20
are these varables used by the compiler for maths data etc, such that can save them as part of the context data in RTOS. I can not find information regarding them in mikroc Pro help .
R0,R1,R2...................R20 global variables
Re: R0,R1,R2...................R20 global variables
Hi,
I believe you have been answered on the following post :
http://forum.mikroe.com/viewtopic.php?f=89&t=68974
Regards,
Filip.
I believe you have been answered on the following post :
http://forum.mikroe.com/viewtopic.php?f=89&t=68974
Regards,
Filip.
Re: R0,R1,R2...................R20 global variables
Hi,
I'm using PIC16F1829. For some reason I had to move R0..R15 registers to different address space instead of 0x70..0x7F.
I choose 0x40..0x4F region. And all went fine.
Until yesterday, when I found that my function to convert string to int returns wrong results.
I found, that this behavior is caused of _Mul16x16 function from __LIb_Math.mcl.
When I looked in assembly, I saw that R0..R15 when used in that function has addresses in 0x70..0x7F address space instead of 0x40..0x4F.
And the addresses are directly as digits, not R0..R15.
In the rest part of the program R0..R15 are in 0x40..0x4F address space, compiler swiches the bank when nedded.
Any solution?
Best Regards,
Rado
I'm using PIC16F1829. For some reason I had to move R0..R15 registers to different address space instead of 0x70..0x7F.
I choose 0x40..0x4F region. And all went fine.
Until yesterday, when I found that my function to convert string to int returns wrong results.
I found, that this behavior is caused of _Mul16x16 function from __LIb_Math.mcl.
When I looked in assembly, I saw that R0..R15 when used in that function has addresses in 0x70..0x7F address space instead of 0x40..0x4F.
And the addresses are directly as digits, not R0..R15.
In the rest part of the program R0..R15 are in 0x40..0x4F address space, compiler swiches the bank when nedded.
Any solution?
Best Regards,
Rado
Re: R0,R1,R2...................R20 global variables
Hi Rado,
Good luck!
Bold move and probably works mostly, if not only, for libraries with sources. With precompiled libraries, like the system ones, linker assumes that some addresses may be left untouched. And optimizer may also use fixed addresses for Rx registers (it certainly does for PIC18s).
You could 'borrow' source of this library from the AI for PIC compiler that comes with NECTO Studio (C:\NectoStudio\NECTOStudio\compilers\PIC\mikroC\core\math\P16_Enh\__LIb_Math.c). The AI compiler is a slightly upgraded version of the PRO compiler and there should be no problem in using its libraries with mC PRO. Whatever the deficiencies of Necto, at least in its latest versions sources of the system libraries became available. Just change name of the old __LIb_Math.mcl (to keep it safe) and put the source in the same folder (compiler installation directory\Uses\P16_Enh). Naturally, you may do the same with other system libraries.Until yesterday, when I found that my function to convert string to int returns wrong results.
I found, that this behavior is caused of _Mul16x16 function from __LIb_Math.mcl.
Good luck!