| View previous topic :: View next topic |
| Author |
Message |
Ttelmah
Joined: 11 Mar 2010
Posts: 19215
|
|
 Posted: Wed Apr 15, 2020 10:31 am |
 |
|
CCS does have an ERRNO define. I think we need to ask them to
update the core maths so that there is an options that when an
overflow occurs, this is set to reflect this. It really would be a more
competent implementation. |
|
 |
kmp84
Joined: 02 Feb 2010
Posts: 345
|
|
| Posted: Wed Apr 15, 2020 12:06 pm |
|
|
I have mailed them few times for bugs problems but they doesn't answer.
Also I have many trouble with their ICD (especially ICD-U80), after update to v.5.092 and ICD firmware upgrade it stopped completely, but this is another topic!
P.S What is "ERRNO define"?
Thank you for attention! |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19215
|
|
| Posted: Wed Apr 15, 2020 1:19 pm |
|
|
They normally respond quite quickly. They have gone silent recently, Covid
has obviously prevented them getting into their normal offices.
I'm afraid we will have to wait till the situation with this 'eases' before
such an update will be available.
The more advance maths library for things like EXP, SIN, COS etc.,
has a variable called ERRNO, which if created, then takes a value to
tell you what maths error has occurred.
If you #include "errno.h" before you load the maths library, this is
enabled. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19215
|
|
| Posted: Thu Apr 16, 2020 3:35 am |
|
|
Thinking about it, other than accessing the overflow flag, the only way
to reliably 'pre test', is to use this:
| Code: |
#DEFINE U32_MAX 4294967295
void main()
{
unsigned int32 Vol, Prc, Sum;
unsigned int carry;
Vol = 1234567;
Prc = 12345;
sprintf(output, "\n\rTarget 16F1459 Start.\n\r");
while(TRUE)
{
for (Prc=3000;Prc<15000;Prc+=100)
{
if (vol>(U32_MAX/Prc))
{
carry=TRUE;
Sum=0;
}
else
{
Sum = Vol*Prc;
carry=FALSE;
}
sprintf(output, "\r\nSum=%lu, Carry:%u\r\n", Sum, carry);
delay_cycles(1);
}
}
}
|
Problem is (of course) that it requires a division, but this will correctly
trap the carry before it happens. |
|
|
kmp84
Joined: 02 Feb 2010
Posts: 345
|
|
| Posted: Thu Apr 16, 2020 6:08 am |
|
|
Thanks for the second option.
How long take 32bit mul, div for example mcu running at 16Mhz, 32Mhz? Are these times different for PIC16 and PIC18? |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19215
|
|
| Posted: Thu Apr 16, 2020 6:19 am |
|
|
If you open the manual in the compiler screen, then 'Contents',
'Common questions and answers', there is a tab 'how much time do math
operations take'. The table there has to be scaled to suit your processor
speed, and the real values will shift a little as bank switching is needed,
but these are very close.
Generally the PIC18 is faster. Particularly on multiplication, where there
is a hardware 16bit multiply instruction. This about triples the speed for
multiplications. It's perhaps 10% faster at the same clock rate for most
things. |
|
|
kmp84
Joined: 02 Feb 2010
Posts: 345
|
|
| Posted: Thu Apr 16, 2020 6:53 am |
|
|
About my project:
This is 'simple' volume counter project reading 2ch. rotary encoder, do few 32bit unsigned math calc. and show calculations on i2c lcd display. Because there is a possibility of overflowing 32bit math calc. I'm thinking which pic family to use:
some 'stable' PIC16,18 or move to some one low pin count PIC24,dsPic30,33?
Thanks, |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19215
|
|
| Posted: Thu Apr 16, 2020 7:40 am |
|
|
If you use a PIC24/30/33, you have int64.
The _mul instruction directly allows you to multiply two int32 values
and have an int64 result. You can then just test this for being greater
than the int32 max value.
The maths is also a lot faster on these chips.
I've done a lot with chips like the PIC24FJ64GB004. Just 28pins, built in
32MHz oscillator, 64K of ROM, and 8K RAM.
2*I2C, 2*SPI, 2*UART. The I2C1, has pins that can go to two locations.
Both UART's and the SPI use PPS. Quite an easy little 'basic' PIC24.
You lose two pins for the internal voltage regulator, and it's control. You
need to have good smoothing on the regulator pin with the right sort
of capacitor mounted close.
3.3v device. |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9098
Location: Greensville,Ontario
|
|
| Posted: Thu Apr 16, 2020 7:49 am |
|
|
| Using Mr. T's PIC24 sounds like a great solution especially for the extensive 'math' routines. There will be a learning curve but could be a 'Swiss Army Knife' PIC. If you can concentrate using ONE PIC, then life gets easier...as you'll have known,working libraries based on a stable PIC. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19215
|
|
| Posted: Thu Apr 16, 2020 7:57 am |
|
|
Actually I'd have to check, but the PIC24, has a hardware maths
overflow interrupt. Not sure if the int32*int32 will trigger it, but it may. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19215
|
|
| Posted: Thu Apr 16, 2020 8:15 am |
|
|
No, the maths interrupt doesn't trigger.
However:
| Code: |
//variables declared as:
unsigned int32 Prc, Vol;
unsigned int64 Sum;
unsigned int carry;
carry=FALSE;
Sum = _mul(Vol,Prc);
if (Sum>U32_MAX)
{
carry=True;
Sum=U32_MAX;
}
|
Has the multiply taking 2.625uSec at 32MHz. Against 28.5uSec for a PIC18
at the same clock..... |
|
|
kmp84
Joined: 02 Feb 2010
Posts: 345
|
|
| Posted: Thu Apr 16, 2020 11:55 am |
|
|
If I use PIC24(dsPic) it will be not necessary using int48 or int64. I'll just compare if have some limits in lcd digits:). But if CCS recover "STATUS" bits will be very useful in such situations.
Thank You All for suggestions and help!
Best Wishes! |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19215
|
|
| Posted: Thu Apr 16, 2020 12:37 pm |
|
|
Study what I show.
The two source variables are int32. The compiler offers the special function
_mul, which multiplies two variables of a given type, and returns the result
in the next larger type. So it multiplies the two int32's, but generates an
int64 result. Now I'm testing if the result is bigger than the int32 supports,
and if it does load the maximum int32 value and set the 'carry' bit.
Loading the value may well not be needed. The carry flag is probably all you
need. The _mul function is using int32 arithmetic, but saving the overflow.
Just what is needed.  |
|
|
kmp84
Joined: 02 Feb 2010
Posts: 345
|
|
| Posted: Thu Apr 16, 2020 2:06 pm |
|
|
.. Yes nice function.
But the _mul function is not applicable for PIC16, PIC18 with two int32 arguments. Also in CCS help file they don't tell what type of argument can be passed (sign, unsiged)  For int8 and int16 works correct. How much more optimized it is for speed and size in comparison to normal multiplication? |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19215
|
|
| Posted: Fri Apr 17, 2020 1:16 am |
|
|
The core function is the same.
The maths on the PIC16/18, is all based on a application note that was
published by MicroChip quite early on in the days of the PIC. They designed
all the basic int8, int16 etc., multiplications and divisions to be as fast
as possible given the architecture of the chip. This is in fact 'why' the
CCS fp maths format differs from the IEEE format, allowing a saving of
about four instructions.
On the PIC24/30/33, the presence of larger hardware multiplication
and division allows the IEEE format to be used without loss, so on these
chips this is the format used.
The big 'point' about _mul, is that if you started a normal multiply
with int64 values you would have to do an int64 multiplication, which
takes about 60% longer than int32. _mul instead performs the int32
multiplication, but just keeps any overflow bits. Result same speed as
an int32 multiplication, but gives you the extra output bits allowing you
to 'know' if an overflow has occurred.
Since there isn't an int64 'type' in the PIC16/18, you can't do it this
way on these. |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
