Hi-Tech C compiler variables

[Zedy]

hi!
I want to check some variables in RAM, is there some way to output them in MPLAB?
I have tried to use printf function to output variables to MPLAB SIM UART1, but it didn't work.

[deef]

Variables that are specific to the compiler? Can you provide an example? Are you referring to the conditional "#PRAGMA" features?

If it's a microcontroller specific register, or variable in your software, I would suggest trying to simulate the code using MPLAB's Simulator and viewing the state of the variable between breakpoints in the WATCH window.

[Zedy]

Variables that are specific to the compiler? Can you provide an example? Are you referring to the conditional "#PRAGMA" features?
If it's a microcontroller specific register, or variable in your software.

I have something like this: (variable is located into microcontroller RAM memory)

Code: [Select]

#include <htc.h>

signed short U = 10;
signed short I = 11;
signed short P;

void
main (void){
P = U*I;

}And I want to see P, I have very limited knowledge in C, so I have read about "#PRAGMA" feature, but I don't know how I can use it.

I would suggest trying to simulate the code using MPLAB's Simulator and viewing the state of the variable between breakpoints in the WATCH window.

I would be very grateful, if you could make some dummy guide, how to make it work, last night I spend almost half a night, trying different solutions, but none of them worked.

[Mechatrommer]

at menu debugger->select tool->mplab sim
double click code line will toggle breakpoint (round red B)
run (F9). if outdated, choose yes to rebuild and F9 again.
at menu view, choose anything simulated you want to see... local, file registers etc.
F6 to stop simulation. amien.

[Zedy]

at menu debugger->select tool->mplab sim
double click code line will toggle breakpoint (round red B)
run (F9). if outdated, choose yes to rebuild and F9 again.
at menu view, choose anything simulated you want to see... local, file registers etc.
F6 to stop simulation. amien.

Thank you!, it works!

[tyblu]

Note that this is just a simulation. To check variables on your chip you need a debugger and JTAG (or 1Wire for some chips) connection. Alternatively you can output them as part of your program (a monitor program), but this doesn't help in some situations; you'll need an output media, of course -- even an LED does it.

[Mechatrommer]

Note that this is just a simulation. To check variables on your chip you need a debugger and JTAG (or 1Wire for some chips) connection. Alternatively you can output them as part of your program (a monitor program), but this doesn't help in some situations; you'll need an output media, of course -- even an LED does it.

last time someone (cant remember who) tought me pickit2 can be used as a debugger. but i still have no pic project yet to test it.

[scrat]

@Zedy: you didn't state wheter you are using or not a real target (micro) and which tool (MPLAB ICD2, PicKit,...) you are using for that.
In the case of using MPLAB ICD2 (but with PicKit II it should be possible too) you can easily set breakpoints, run code, and watch variables (on the target, not simulated). This gives a great insight into your program.
One trouble with this approach is that you can't use it in some applications, since it is needed to halt the target to update values. This is not possible, for example, in a power supply controller (something may eventually blow up).
A workaround that I'm considering to implement (it is not an original idea) is using a serial port to monitor variables: an application on the PC sends to the target the variable address (taken from the watch window) and the target gives back the value.

[Zedy]

@Zedy: you didn't state wheter you are using or not a real target (micro) and which tool (MPLAB ICD2, PicKit,...) you are using for that.

Right now I don't have real target device. Just wanted to see, how much memory I would need for my code. Also I have pickit 2, but If I am right, I should have some headers to use it as debugger, and of course I need real microcontroller

Is MPLAB SIM working correct? because there is happening something very strange, after this code:

Code: [Select]

signed short long Ck, Sk;
Ck=0;
Ck=(800)*(52);it shows Ck value (in Watch window) in decimal -23936 (0xFFA280), you can notice, that A280 actually is the right value, that should be.
What is wrong?

[scrat]

I don't have the HighTech compiler installed, by now, but if you post the workspace file (File->save workspace), someone could easily try it.

[Zedy]

I don't have the HighTech compiler installed, by now, but if you post the workspace file (File->save workspace), someone could easily try it.

I attach project archive, if someone, wants to look in it.
Also you can see it in the screen shot:

[scrat]

Could you try executing "Ck = (signed short long)(800) * (signed short long)(52);" ?

[Mechatrommer]

Is MPLAB SIM working correct? because there is happening something very strange, after this code:

Code: [Select]

signed short long Ck, Sk;
Ck=0;
Ck=(800)*(52);it shows Ck value (in Watch window) in decimal -23936 (0xFFA280), you can notice, that A280 actually is the right value, that should be.
What is wrong?

this is the beauty of higher level language . try:
Ck = 800;
Ck *= 52;
if its not working, find another way until it is. the compiler will generate temporary variables to do the multiplication probably too short to store the result.
try to check disassembly listing while its running to see whats the (800)*(52) is actually doing in asm.

[oPossum]

.

[marianoapp]

The multiplication result is to big for the variable type you declared, so it overflows

A short long is 16 bits wide, capable of representing any value between 0 and 65535, but you declared the variable as signed, so instead it goes from -32768 to 32768 (the msb is reserved for the sign)
The result of the multiplication (41600) is bigger than the biggest representable number (32768), so the remaining (41600 - 32768 = 8832) is added to the smallest representable number, that is -32768 + 8832 = -23936 (you could also reason this by thinking that the msb of the result is overwriting the sign bit)

as opossum showed, use and unsigned short long variable and you won't have any problem, unless you want to store a number bigger than 65535.

[oPossum]

short long is 24 bits signed. (signed is always default - really no need to be explicit)

16 bit signed int is assumed unless a cast is present - that is the cause of the overflow

sign extension from 16 bit to 24 bit results in the leading 0xFF

[TheDirty]

You should get in the habit of using the more cross platform variable definitions in stdint.h  It should help beginners, since the bitwidth is right in the definition name.

uint8_t
int8_t
uint16_t
int16_t
...

http://en.wikipedia.org/wiki/Stdint.h#Exact-width_integer_types

[oPossum]

It would be great if HiTech, Microchip, and Microsoft had inttypes.h and/or stdint.h, but they don't.

I often use my own version so I can use those explicit sizes.

[Zedy]

short long is 24 bits signed. (signed is always default - really no need to be explicit)

16 bit signed int is assumed unless a cast is present - that is the cause of the overflow

sign extension from 16 bit to 24 bit results in the leading 0xFF

oPossum thank you, you made it clear for me

[Mechatrommer]

You should get in the habit of using the more cross platform variable definitions in stdint.h  It should help beginners, since the bitwidth is right in the definition name.

you should get the habit of making your own (maybe crossed platform) library... say in MyLib.h = #define MyInt uint16_t... well, my 2cnts and only me. nice advice TheDirty.

[TheDirty]

It would be great if HiTech, Microchip, and Microsoft had inttypes.h and/or stdint.h, but they don't.

I often use my own version so I can use those explicit sizes.

Really?  I thought these would be C99.  Oh well, ya, you'd have to make your own definitions, then.

[oPossum]

It is C99.

Microsoft finally added them in VS2010.

I assume Microchip C30 has them because it is derived from GCC C.

The Microchip C18, HiTech C, and VS2008 and earlier do not have them.

Strangely Microchip C18 has the printf field specifiers for the sized types, so that's a good thing.

I use this for Microchip C18...

Code: [Select]

typedef          char         int8_t;
typedef unsigned char        uint8_t;
typedef          int         int16_t;
typedef unsigned int        uint16_t;
typedef          short long  int24_t; // Microchip specific
typedef unsigned short long uint24_t; // Microchip specific
typedef          long        int32_t;
typedef unsigned long       uint32_t;


[TheDirty]

Not certain how they can be C99 without stdint.h, which is mandated under C99.

[oPossum]

I should have said that stdint/inttypes are in C99. I didn't mean that the compilers are C99 compliant.

Sorry for the unclear statement.