Electrical – Divide 32-bit by 16-bit number on a dsPIC

compilermicrocontroller

I'm working with a dsPIC33EP64GS506, and here you can find its datasheet: link.

In the dsPIC datasheet (page 294) it says that it supports 4 divide instructions:

DIV.S    Wm,Wn    Signed 16/16-bit integer divide
DIV.SD   Wm,Wn    Signed 32/16-bit integer divide
DIV.U    Wm,Wn    Unsigned 16/16-bit integer divide
DIV.UD   Wm,Wn    Unsigned 32/16-bit integer divide

Now, when I try to divide two variables in C, a 32-bit by a 16-bit variable, compiler for some reason decides not to use these instructions, but the ___divsi3 function instead, which is a software implementation of the divide algorithm. I use Microchip's free xc16 compiler version. Take this simple C code for example:

volatile int32_t num = 65537;
volatile int16_t den = 16384;
volatile int16_t res = num/den;

compiles to the following assembly code:

MOV [W15-22], W0
MOV [W15-20], W1
MOV [W15-18], W2
ASR W2, #15, W3
RCALL ___divsi3
MOV W0, [W15-16]

How can I convince a compiler to use DIV.SD instruction to divide these two variables?

Best Answer

I managed to find a solution. Apparently, there is a dozen of __bultin functions used to force the compiler (xc16) to use specific assembly instructions or series of instructions. For example, to force the compiler to use specific DIV instructions, one can use one of the following __builtin functions:

signed int __builtin_divf(signed int num, signed int den);
signed int __builtin_divmodsd(signed long dividend, signed int divisor, signed int *remainder);
unsigned int __builtin_divmodud(unsigned long dividend, unsigned int divisor, unsigned int *remainder);
int __builtin_divsd(const long num, const int den);
unsigned int __builtin_divud(const unsigned long num, const unsigned int den);

However, one must be certain that the result (i.e., the quotient) fits to a 16-bit register, otherwise, results are unexpected. All these builtin_div functions execute within 18 clock cycles, while ___divsi3 function which compiler normally uses for 32/16-bit division takes up to 500 clock cycles.

To go back to my example from the beginning, the C code would look like this:

volatile int32_t num = 65537;
volatile int16_t den = 16384;
volatile int16_t res = __builtin_divsd(num, den);

The compiler produces the following assembly code:

MOV [W15-16], W0
MOV [W15-20], W1
MOV [W15-18], W2
REPEAT #0x11
DIV.SD W4, W2
MOV W0, [W15-14]

Case closed.

Related Solutions

Electronic – Editable PIC Serial Number in HEX File

Specifically to resolve the question of binding variables to specific addresses in flash memory on the PIC18 with the C18 compiler, please reference the section "Pragmas" in the hlpC18ug.chm in the doc directory where the compiler is installed.

To do this you need to define a new "section" in memory and bind it to a start address so

#pragma romdata serial_no_section=0x1700

This creates a new section called "serial_no_section" that starts at address 0x1700 in flash (program) memory (because we defined "romdata" in the #pragma).

Directly after the #pragma line, define your variable(s) so:

#pragma romdata serial_no_section=0x1700
const rom int mySerialNumber = 0x1234;
#pragma romdata

Now you have 0x12 at address 0x1700 and 0x34 at address 0x1701 in memory (because PIC18 uses the little-endian model). The "const rom" ensure that the compiler knows that this is a const variable type, and that the variable lies in "rom" memory and thus need to be accessed via table read instructions.

The final #pragma romdata statement ensures that any following variable declarations are linked to default memory sections as the linker sees fits rather than following on in the "serial_no_section" section.

Now all code can simply reference the variable "mySerialNumber", and you know exactly what address the serial number can be found at in memory.

Editing the HEX code can be a bit challenging as you need to calculate the checksum for each line you edit. I am working on a C++ class to decode and encode Intel HEX files which should make this easier, but it is not finished yet. Decoding files works, encoding again is not yet implemented. The project (if you are interested) is here https://github.com/codinghead/Intel-HEX-Class

Hope this helps

Electronic – EEPROM read/write errors on dsPIC

Two things come to my mind:

First, according to the data sheet, a erase-write-cycle takes at least 0.8ms, and up to 2.6ms. You say that you have an interrupt every 1ms, which may lead to a write operation. I have seen in the code that you disable interrupts for parts of the erase and for parts of the write function. But you still might get funny interleaving of the function calls. Maybe it helps when you disable interrupts for the whole sequence of erase and write?

Second - you might want to write while to power goes down, and the EEPROM write happens exactly in the moment when the supply voltage goes below the operating voltage. You can try to monitor the supply voltage, and refuse a write when it is below, lets say, 4.5V. This assumes that it stays long enough above 2.7V as the minimal operating voltage, and brown-out-detection is set to trigger only below that point.

Best Answer

Related Solutions

Electronic – Editable PIC Serial Number in HEX File

Electronic – EEPROM read/write errors on dsPIC

Related Topic