• Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

PIC 18F family - CORDIC division algorithm: dividend (up to 48 bits) / divisor (up to 32 bits)

atferrari

Well-Known Member
I recently became aware of the so called CORDIC division algorithm thanks to a post of an AAC's member which brought me to this site.

Instead of limiting myself to 16 bits I decided to greedily work out a routine able to cope with up to 48 bits (dividend) and 32 bits (divisor). The algorithm gives de facto the remainder whether you need it or not.

Two hours ago I completed the first tests with valid results. Had to struggle with lot of clerical errors and a printed flow diagram was invaluable.

Code is not optimized in any way albeit seems to be correctly debugged but I do not plan to show it yet.

The calculations for the initial alignment of both MS bits plus the subsequent shiftings make for a lot of code, lot of RAM registers and a lot of T cycles.

My request: before deciding whether to stop here or to continue improving my code, I would like to hear comments if it sounds reasonable simply maybe because this CORDIC variety is not the way to go for huge numbers.

Gracias.

F2 79 D8 94 65 31 / BC = 01 4A 2E 16 93 9A | 19
 

gophert

Well-Known Member
Most Helpful Member
What is the maximum resolution (bits) possible on an 8-bit PIC with c in MPLab? I assume you are doing this with 8-bit chips, correct?
 

atferrari

Well-Known Member
18 F family - 8 bits, gophert.

Sorry, I am not C conversant.
 

atferrari

Well-Known Member
Have to shift 6 bytes every time for divisor and 6 for the base index.

Keep in mind Ian Rogers that I wrote it for 48/32.

To avoid the pseudo substractions for deciding if dividend is equal or higher than divisor I use compares (18F family has them) bit still takes time.

With code running apparently OK but not yet improved, the stop watch gave me some 1070 Tcy.

Lot still to be done if I want this reasonable to use.
 

gophert

Well-Known Member
Most Helpful Member
I think it is interesting to explore in assembly code but most programmers that need such resolution are using 32-bit micros and extremely efficient divide algorithms to execute divide within c. The 32-bit chips also have more core commands that allow divide to be executed with fewer clock cycles.

the XC32 compiler in C for PIC32 can handle 64bits in long double variable type with the first 53 bits being a signed integer and the last 11 bits are a signed integer as an exponent (+/-1023) which gives an enormous range at great resolution.

I also have trouble thinking of why one would need so many bits of resolution when doing division with an 8-bit chip. If doing a running average, or a voltage average or what ever, picking a convenient denominator of n^2 allows for simple bit shifting to do the division. But it is an interesting exercise to know how many clock cycles are needed in an 8-bit chip when justifying a more expensive and more complicated chip.
 

atferrari

Well-Known Member
I think it is interesting to explore in assembly code but most programmers that need such resolution are using 32-bit micros and extremely efficient divide algorithms to execute divide within c. The 32-bit chips also have more core commands that allow divide to be executed with fewer clock cycles.

the XC32 compiler in C for PIC32 can handle 64bits in long double variable type with the first 53 bits being a signed integer and the last 11 bits are a signed integer as an exponent (+/-1023) which gives an enormous range at great resolution.

I also have trouble thinking of why one would need so many bits of resolution when doing division with an 8-bit chip. If doing a running average, or a voltage average or what ever, picking a convenient denominator of n^2 allows for simple bit shifting to do the division. But it is an interesting exercise to know how many clock cycles are needed in an 8-bit chip when justifying a more expensive and more complicated chip.
Hola gophert

My routine, as is, to divide C3 00 C3 00 / C3 00 takes a humongous 1080 Tcy appr.

A lot can be reduced but not sure if I would do the effort albeit I feel satisfied with my code running almost in the first try.

Assembly - 18F2321 - MPLABX 5.40 - pic-as 2.20.

Could you elaborate on the part in bold, please?
 

rjenkinsgb

Well-Known Member
Most Helpful Member
the XC32 compiler in C for PIC32 can handle 64bits in long double variable type
The C compilers for all PIC types can handle up to 64 bit integer or float types. The data size is not related to the word size of the CPU, it just takes more instructions when it has to be done in smaller sections.
 

gophert

Well-Known Member
Most Helpful Member
Hola gophert

My routine, as is, to divide C3 00 C3 00 / C3 00 takes a humongous 1080 Tcy appr.

A lot can be reduced but not sure if I would do the effort albeit I feel satisfied with my code running almost in the first try.

Assembly - 18F2321 - MPLABX 5.40 - pic-as 2.20.

Could you elaborate on the part in bold, please?
For example, one could write code that calculates a running average 12 or 30 values but that means dividing create a significant amount of math and possible delay in making adjustment to stabilize a system. It is usually better to just take 16 or 32 values for your running average and shift right 4 or 5 bits (respectively) and the division is done.
 

gophert

Well-Known Member
Most Helpful Member
The C compilers for all PIC types can handle up to 64 bit integer or float types. The data size is not related to the word size of the CPU, it just takes more instructions when it has to be done in smaller sections.
Umm, nope.
In xc8, it says double double is same 32 bits as double - if 32 bit is selected. Default is 24bit

Screenshot_20201018-132334.png
 

rjenkinsgb

Well-Known Member
Most Helpful Member
OK, I use the CCS C compiler, as it's far more versatile in regard to device peripherals. That has the same limits for all device families.
I did not realise XC8 was restricted like that.
 

Latest threads

EE World Online Articles

Loading
Top