CCS math operation problems

[Ttelmah]

Could easily be a printf bug, I was watching the variable in a debugger.
Have just tried using sprintf, with 4.137, and %u, %lu (shouldn't be needed PCD treats an int as int16), and %d, all gave the same output of 25000.

Best Wishes

[castek]

I have changed but got same problem, result is still 511. How can I see the true value for res16?? I dont know if its a printf problem or a PCD math problem.

However I found a bad solution.

PCD gives a good result that way:

unsigned int16 ind1=5000;
unsigned int16 ind2=5000;

unsigned int16 res16;
unsigned int32 res32;

res32 = _mul(ind1,ind2)/100;
res32=res32/10;
res16=res32;


printf(LCD_PUTC, "\fA %Lu B %Lu \n res= %Lu", ind1, ind2, res16);

Dividing per 1000 does not work, but if I divide fist per 100 and then per 10 (which is the same as dividing per 1000), now it works.... Finally I think it´s a PCD problem

¿¿Did you tried it in PCD 4.134??

[Ttelmah]

Depends what debugging tools you have got.

Free one, is MPLAB, and run it in MPSIM.

Is anything else being done, while this code is working?. I find it too 'odd' that it gives perfectly normal results for me. Something overrunning an area of memory, and corrupting a variable, or something happening in an interrupt, are obvious suspicions.

Best Wishes

[castek]

Well.. I´m printing the result in an LCD in proteus... maybe there´s the problem. I´m using PCD 4.134 same as you. However I´m downloading the demo version of PCD 4.137 to check... I´m getting crazy, dont know why I cant divide a number higher than 1000 without errors. The extrange thing is that I can divide per 100 but not per 1000... !?!

[temtronic]

PIC rule #0 : READ PIC101 !!

PIC rule #1 : GET RID OF PROTEUS !!

PIC rule #2 : ALWAYS OBEY rule #1 !!

PIC rule #3 : PROTEUS is full of bugs,errors, faulty DRCs

[castek]

If cannot use proteus with CCS compiler, which simulator does CCS support or recommend? You should know mplab is not as good as proteus to test and simulate, cause you cannot do what proteus allow. You just can check your code, but cannot add external LCD, signals to analog pins, etc. The only solution is checking on physical pic, and not to simulate. Another is using XC16 c compiler and using proteus which is fully supported. What would you do?

[Ttelmah]

It is not a question of what CCS supports. CCS is not a supplier of simulators. The problem is that Proteus is rather too bug ridden. It is perhaps trying to be too smart, and forgetting just how different all the PICs are.

It uses the same library code for peripherals, even when the PIC concerned has a large number of errata for that peripheral.
It doesn't make any attempt to check frequencies. Allowing invalid oscillator combinations to be accepted as working.
It doesn't simulate the noise created by the PIC itself on the supply.
It has some very basic timing errors in some parts of the simulations.
Some of the components are just plain wrongly simulated.
It hides the PSU connections, which can often lead to people forgetting how important these are.

I had the full Proteus package for several years, and still use it as a PCB package, and as a simple to use simulator on analog circuitry. However on the PIC, I gave up. I have projects here that run fine on real PIC's, yet fail on Proteus, and others that will run on Proteus, yet lack quite major components that would prevent them from working on the real chip.
It rates as significantly _worse_ than CCS in terms of it's bugs, and that is saying a lot...
I'd say that something over 80% of threads where people are using Proteus, would behave _differently_ on the real chip. Probably not right, but differently. Which means that time spent chasing the 'Proteus' configuration, is largely time wasted.
Proteus gives _exactly the same bugs with XC16_. I have two projects which it claims would work, compiled with this, which also fail in the real board.

For small segments where I want to look in detail at what is happening to registers, I use MPLAB. For bigger stuff I use ICD or ICE systems. The _only_ way to really find out what is going to happen on a PIC, is to run it in the chip.

Don't blame CCS, for another companies c&*p product.

Best Wishes

[castek]

Thanks a lot for your help.

I thought that simulation was the future for electronic project, but I realize that there's not any good simulator that avoid physical testings on pic. I will use schematic of Proteus as it is, without simulations... I don't trust in that simulation now.

Now I want to ask you a question. Why CCS instead of XC16 ?

Rgds.

[Ttelmah]

Seriously, speed.
You can write a working project for a simple/medium application with CCS, in probably half the time it'd take in XC16.
The library support is vastly superior.
Don't upgrade the compiler just because a new version is available. Record the version you are using, and keep it with the project.
If you find a bug, just write your own fix and use it in the future until you are sure that the fault is fixed. Don't bother waiting for a fix from CCS if you are in a hurry.

Best Wishes

[Douglas Kennedy]

The issue this board has with Proteus is it very often is the premise of the questioner that CCS is the source of the error. Case in point no mention of Proteus until much later in the thread.
Look at the title of this query
CCS math operation problems.
What is next a result of 3+4=8 in Proteus and 2000 years of arithmetic is in question?
If you get an incorrect result and you used Proteus assume Proteus is mostly to blame. If you suspect CCS after trying for weeks using Proteus and Proteus boards then build a real circuit. If the real circuit doesn't work spend several days checking the wiring and reading the microchip documentation.. Then narrow the probable issue to a few lines of code and come to this board as a last resort.