Problem with pointers arithmetic

Beta Testing discussion on mikroPascal PRO for AVR.
Author
Message
octal
Posts: 534
Joined: 09 Feb 2005 14:15
Location: France
Contact:

Problem with pointers arithmetic

#1 Post by octal » 11 Dec 2008 00:12

Hello,
POINT1:
I'm trying to port my XGLCD Library (http://www.pocketmt.com/index.php?target=xglcdoverview) to mikroPascal for AVR, and I'm facing a strange problem with arithmetic operator involving pointers.

well I reduced all my code to the minimum that reproduce the problem (so the code is not that usefull, but compiling it generates the error).

Code: Select all

program prj1;

{ Declarations section }
{'
' Name    : xGLCD Library
'
' Author  : M. Ahmed Lazreg
'           octal@pocketmt.com
'
'           Copyright 2007 - Pocket MicroTechnics
'           http://www.pocketmt.com
'
' Version : 1.0.0
' Date    : 20/07/2007
'
' Software: Compiled Using mikroPascal v6.0.0.2
'
'
' Desc.   : xGLCD Library adds support of BIG Proportional font sizes to GLCD Lib.
'
'
}


const xGlcdSelFont : ^byte;

const xColorClear = 0;
      xColorSet   = 1;
      xColorInvert= 2;
      
var xGlcdX, xGlcdY  : byte;
    xGlcdSelFontHeight, xGlcdSelFontWidth,
    xGlcdSelFontOffset, xGlcdSelFontNbRows : byte;

    xGLCD_Transparency : boolean;


function xGlcd_Write_Char(ch, x, y, color : byte): byte;
const CurCharData : ^byte;
var i,j, CharWidth, CharData : byte;
   cOffset : longint;
begin
  cOffset := xGlcdSelFontWidth * xGlcdSelFontNbRows+1;
  cOffset := cOffset * (ch-xGlcdSelFontOffset);
  CurCharData := xGlcdSelFont+cOffset;
  CharWidth := CurCharData^;
  cOffset := cOffset + 1;
  for i := 0 to CharWidth-1 do
  begin
    for j := 0 to xGlcdSelFontNbRows-1 do
    begin
        CurCharData := xGlcdSelFont+(i*xGlcdSelFontNbRows)+j+cOffset;
        case color of
          0 : CharData := 0;
          1 : CharData := CurCharData^;
          2 : CharData :=  not (CurCharData^);
        end;
        //xGLCD_Write_Data(x+i,y+j*8,CharData);
    end;
  end;
  result := CharWidth;
end;

begin
  { Main program }
end.
on compiling this gives this error:
52 1012 Warning: Implicit typecast of integral value to pointer prj1.mpas
52 341 Operator "+" not applicable to these operands "xGlcdSelFont" prj1.mpas
52 341 Operator "+" not applicable to these operands "xGlcdSelFont" prj1.mpas
54 304 Syntax error: Expected ";" but ":=" found prj1.mpas

... other errors

The error operator "+" is not applicable is really strange :(

The error is visible at the line after the BEGIN after FOR J loop, in the line

Code: Select all

CurCharData := xGlcdSelFont+(i*xGlcdSelFontNbRows)+j+cOffset; 
it's about the first PLUS operator. If I change the PLUS to MINUS it compiles fine :(

I can send you all the project if you need it.

Notice: all XGLCD Lib code compiles fine under PIC mikroP compiler.
I used mikroPascal Pro for AVR Beta 1.2 (actual beta I downloded it from this forum link two hours ago).
I simply created a new project, selected Atmega16 as a target processor and kept all other things to default values. I saved the project and copied/Pasted this code as main source. This should reproduce the error.

Conditions: Athlon 64 Processor 2.4GHz, RAM 2GB, WinXP-Pro (32bit version) with all latest updates and SP.

POINT2:
Also note that in the Editor (in the IDE), in VAR declaration section, the declaration

Code: Select all

    xGLCD_Transparency : boolean;
shows "boolean" word underlined in red as if it were an error, altought it seems to compile ok.

POINT3:
In the editor, if you open any file, and simply click on an expanded region in order to fold it, and you click again to unfold (expand) a region of code, the region is marked as modified (yellow vertical line) despite the fact that you didnt changed anything nor typed any keyboard button.


Regards
octal
http://www.pocketmt.com

JohannesH
Posts: 68
Joined: 23 Apr 2007 07:51

#2 Post by JohannesH » 11 Dec 2008 07:32

Hi octal!

I see within your code:

const CurCharData : ^byte;

You have defined a constant without initialization and later you use it as a variable (assignment statement)? I am a little bit confused?

Regards
Johannes

octal
Posts: 534
Joined: 09 Feb 2005 14:15
Location: France
Contact:

#3 Post by octal » 11 Dec 2008 07:56

Hi JohannesH,
this is mikroPascal and not Turbo Pascal ;)

This way of writing constants means that CurCharData is a pointer to a rom constant. In my case it will be a pointer to the font array name, the font is stored in rom (code) space.

Anyway, the pb is not from it. The compiler acutally does not complain from the lValue, it seems to complain about using the add operator between expressions using pointers :(

Regards
octal
http://www.pocketmt.com

jpc
Posts: 1986
Joined: 22 Apr 2005 17:40
Location: France 87

#4 Post by jpc » 11 Dec 2008 09:39

i must confirm some problem with pointer-variables. It looks like expressions with pointer on both sides of the equation are not handled well.

Code: Select all

  this_channel^.tx_buff[this_channel^.head] := 'x';   : ok
  inc(this_channel^.tx_buff[this_channel^.head]);   : nothing seems to happen
  this_channel^.tx_buff[this_channel^.head] := this_channel^.tx_buff[this_channel^.head]+1;   : nothing seems to happen
  this_channel^.tx_buff[this_channel^.head] := 'z';  // ok again
as the debugger has some little issue with pointing at changed watch-variables i have not been capable of seeing eventual side-effects on wrong variables.

JohannesH
Posts: 68
Joined: 23 Apr 2007 07:51

#5 Post by JohannesH » 11 Dec 2008 19:23

@octal

Are you sure?
Please point me to the place within the documentation where I can read about this.

I found:

Constant is a data whose value cannot be changed during the runtime. Using a constant in a program consumes no RAM. Constants can be used in any expression, but cannot be assigned a new value.


regards
Johannes

yo2lio
Posts: 1878
Joined: 19 Sep 2006 12:57
Location: Romania, Arad City
Contact:

#6 Post by yo2lio » 11 Dec 2008 20:28

JohannesH wrote:Hi octal!

I see within your code:

const CurCharData : ^byte;

You have defined a constant without initialization and later you use it as a variable (assignment statement)? I am a little bit confused?

Regards
Johannes
Hello Johannes,

This declaration is a pointer in ROM (Flash).

Code: Select all

const rom_pointer : ^byte;

  rom_pointer := my_rom_address; // address is word type
  my_data := rom_pointer^;
or you can use ASM for this :

Code: Select all

  Z := my_rom_address; // address is word type 
  asm
    LPM R25,Z
  end;
  my_data := R25;
Best regards, Florin Andrei Medrea.

http://www.microelemente.ro/
http://www.microelemente.ro/produse-si-servicii/
http://www.microelemente.ro/custom-software/

mail : florin@microelemente.ro

JohannesH
Posts: 68
Joined: 23 Apr 2007 07:51

#7 Post by JohannesH » 11 Dec 2008 22:03

Hi Florin!

I understand what you say and I also understand the asm example.

That means if you declare

const myptr : ^byte;

you dont declare a constant, instead you declare a variable of type pointer to a byte in FlashRom. Correct?

If this is correct then we are far away from standard Pascal (which must not be bad in any case) but at least needs a indepth explanation within the documentation but I could not find it anywhere within Help (maybe my fault)?

regards
Johannes

yo2lio
Posts: 1878
Joined: 19 Sep 2006 12:57
Location: Romania, Arad City
Contact:

#8 Post by yo2lio » 11 Dec 2008 22:07

JohannesH wrote: const myptr : ^byte;

you dont declare a constant, instead you declare a variable of type pointer to a byte in FlashRom. Correct?
Yes !
Best regards, Florin Andrei Medrea.

http://www.microelemente.ro/
http://www.microelemente.ro/produse-si-servicii/
http://www.microelemente.ro/custom-software/

mail : florin@microelemente.ro

octal
Posts: 534
Joined: 09 Feb 2005 14:15
Location: France
Contact:

#9 Post by octal » 12 Dec 2008 10:49

JohannesH wrote: const myptr : ^byte;

you dont declare a constant, instead you declare a variable of type pointer to a byte in FlashRom. Correct?
...
regards
Johannes
This is what I said in my first answer (...means that CurCharData is a pointer to a rom constant...the font is stored in rom (code) space)
JohannesH wrote:Hi Florin!

If this is correct then we are far away from standard Pascal
Again this is what I said in my first answer (...this is mikroPascal and not Turbo Pascal...)

First thing to keep in mind is that in embedded world you cannot make a compiler that behavec like on PC where the operating systems handles a lot of things for you, and where a lot of hardware resources and complexity is hidden by the OS services.
Second thing, is that you cant compare pascal to C. C has been made to be close to hardware, so all kind of esoteric and specific notations for pointers types declaration where done/planned from first stage of its conception. So in C even the standard ANSI one, you'll find all these kind of notations.
In Pascal keep in mind that it was not first intended to be used for low level hardware handling. In Turbo pascal for example the only way to do low level working was to use the Port[] (or MEM[]) arrays and/or interrupt calling. Absolute keyword was also available and gave some solutions to direct hardware access to some extent.
Second thing to keep in mind, is that there is no real standard in Pascal world (ISO pascal or UCSD are really good only for making high level data management). Turbo pascal style was a good model but never become THE standard. and the bad thing for turbopascal (compared to C) is that it has enhanced mostly for PC world (for other old hardware v3 was ported but forgot about it). So in this case there where no real need to add strange constructs or data types for pascal.

Embedded world compilers are full of such strange deviations from standards. Deviations that makes and adds some confusion (and makes learning curve longer) for developers coming from PC world, but these deviations becomes a real swiss knife and killer tool when master them.


Regards
octal
http://www.pocketmt.com

JohannesH
Posts: 68
Joined: 23 Apr 2007 07:51

#10 Post by JohannesH » 12 Dec 2008 11:14

Hi octal!

Thank you very much for your comments and explanations!

Let me add some words to what you called "Deviations".
Its absolutely ok for me to have such deviations but at least I have to know that they exist. That means that the deviations have to documented very clearly. Maybe its my fault but I did not find anything within the documentation about pointer variables to flash declared as const.

There is another thing which looks a bit similiar to this.
Its const strings:

const myconststring = 'ABC';
or
const myconststring : string[4] = 'ABC';

This is a normal way to store string constants in flash and save ram space. But what can I do with this const strings?

Assume

var myvarstring : string[4];

I cannot assign the const to the variable:
myvarstring := myconststring; ==>> ERROR

Nor can I pass it to a procedure or function as a parameter of type string:
myproc(myconststring); ==>> ERROR

Do you have an additional information on this subject?

regards
Johannes

jpc
Posts: 1986
Joined: 22 Apr 2005 17:40
Location: France 87

#11 Post by jpc » 12 Dec 2008 11:20

sorry to interfere guys but this forum-section is supposed to concern beta-testing , not general discussion about specific compiler-features. I think this discussion belongs in regular forum , for developers it is best to use this section for bug-related discussions only i think.

octal
Posts: 534
Joined: 09 Feb 2005 14:15
Location: France
Contact:

#12 Post by octal » 12 Dec 2008 11:59

JohannesH wrote:Hi octal!

This is a normal way to store string constants in flash and save ram space. But what can I do with this const strings?

Assume

var myvarstring : string[4];

I cannot assign the const to the variable:
myvarstring := myconststring; ==>> ERROR

Nor can I pass it to a procedure or function as a parameter of type string:
myproc(myconststring); ==>> ERROR

Do you have an additional information on this subject?

regards
Johannes
Hello Johannes,

I dont know if it's just because mikroP is stilll in beta or if mikroE is going to add additional functions to its libs.
Most compilers that does not handle the on the fly type conversion of pointers (from "Cont (flash) Ptr" to "RAM Ptr" and vice-versa) provide functions like string functions (like strcpy, memMove, ...) that handles copying data from flash to ram (at least C18 from microchip does it this way).

I dont know the plans for mikroP and since pointer arithmetic seems a bit problematic, I didnt checked if we can write such routines ourselves.

maybe mikrE developers will answer that better than us.

Regards
octal
http://www.pocketmt.com

JohannesH
Posts: 68
Joined: 23 Apr 2007 07:51

#13 Post by JohannesH » 12 Dec 2008 12:02

Sorry if you dont like it.

But from my point of view: At least all what was discussed within this thread is missing from the documentaion of the new version.
So it is related to the beta and it is related to bugs (missing documentation).

regards
Johannes

jpc
Posts: 1986
Joined: 22 Apr 2005 17:40
Location: France 87

#14 Post by jpc » 12 Dec 2008 12:12

sorry to say so , this is not at all related to beta-testing , the pointer to constant allways had to be declared this way and finds its origin in de different memory-access for ROM and RAM on PIC.

octal
Posts: 534
Joined: 09 Feb 2005 14:15
Location: France
Contact:

#15 Post by octal » 12 Dec 2008 12:18

jpc wrote:for developers it is best to use this section for bug-related discussions only i think.
JPC, You have the right to think anyway you want, but no one (even from mikroE) said that this section is for BUG-RELATED discussions as you said.
and ALL what's said in this thread is related to Beta Version tests and to missing or mal functionning or Not documented stuff for mikroP for AVR.
I think that no harm has been done until now (unless you are un vrai mazo!)

Read again the title of this forum section "mikroPascal for AVR Beta Testing" so keep users post anything related to beta version, even new features proposals, bugs reports, strange behaviours, ... anything they want.

Related to the syntax: Keep also in mind that not all users have done embedded development with other languages, and in Turbo Pascal, there is no const pointer to flash or rom, and even me, personally, if I didnt learnt it from mikroE samples when I was working on XGLCD Lib for PIC using mikroPascal for PIC, I think I would never has suspected that such kind of declaration would exists at all. So asking for this stuff to be documented in mikroP doc is legitimate even if it seems obvious for you. All users have not YOUR experience JPC.

may I add that the only post in this thread that is not related to beta or microP is yours (and the answers related to YOUR posts). So please take off, c'est noel, vas y faire la fête!

Regards
octal
Last edited by octal on 12 Dec 2008 12:43, edited 1 time in total.
http://www.pocketmt.com

Post Reply

Return to “mikroPascal PRO for AVR Beta Testing”