Re: [Sdcc-user] sdcc 2.6.3, PIC16 port, dereferenced value assignment problem.

[Rodrigo G. <tio...@gm...>]

Hi Raphael,

I compiled your code exactly as you said both in AMD64 and in an Intel
machine. I tried diff between both .hex files and they are identical. The
.lst files differed only in their time-stamps. The .cod files differed as
well, but I could not really tell what because those are binaries -- anyway,
with diff -a (to treat binary as text files) it seemed to do with the
time-stamp as well.

About gpsim, you were right, latest versions do support 18f1220 (I guess
they just didn't update the text file PROCESSORS...).
I reproduced your steps using gpsim just like you said (with both Intel and
AMD64 .cod files, just in case) and the result was identical.

Now I will go try the exact code I used in the device to see what gpsim
shows...

Cheers,
Guerra

On 1/17/07, Raphael Neider <rn...@we...> wrote:
>
> Hi Rodrigo,
>
> > You said you tested with gpsim and I attempted to try as well but
> > gpsim (as of 0.22.0) seems not to support the PIC 18F1220 processor.
> > Apparently the only 16bit PIC it supports is 18Cxx2 but even this
> > seems to be not fully supported yet (accordingly to gpsim/PROCESSORS
> > in their sources).
>
> I use gpsim 0.21.12-pre (it may be an svn version, no official release);
>         gpsim
>         processor list
>         quit
> reveals that the pic18f1220 is/was supported. [Update: Looked up and
> tried with the gpsim-0.22.0 release; also supports the pic18f1220, also
> yields the same good results on my IA32 box.]
>
> Then I feed my code (below again in full) using
>         sdcc -mpic16 -p18f1220 -Wl,-m deref.c
>         gpsim -i -s deref.cod
>
> (My actual sdcc invocation has more -I and -L paths specified, but these
> should not matter.)
>
> <code name='deref.c'>
> unsigned char glo;
>
> void main(void)
> {
>     unsigned char c = 0x34;
>     unsigned char *p;
>
>     p = &c;
>     *p = 0x12;
>
>     glo = 0;
>     if (*p == 0x12)
>         glo = 1;
>     if (*p == 0x34)
>         glo = 2;
>     if (c == 0x12)
>         glo |= 4;
>     if (c == 0x34)
>         glo |= 8;
> }
> </code>
>
> Then I use the step command (step [Enter], [Enter], [Enter], ...) to
> obtain verbose output from the simulator, ignoring all warnings until it
> spins at the `bra $-0x0' instruction after having left main(). Scrolling
> back reveals that glo has been assigned 1 first and then its second bit
> has been set, indicating that both writing c via *p and reading back
> from both c and *p work nicely.
>
> Another way to obtain this result is to use the dump command after the
> simulator spins in the endless loop and look at memory locations
> 0x80..0x81 (according to my .map file, c goes to 0x80 and glo goes to
> 0x81). I find 0x80 holding 0x12 and 0x81 storing the desired value of
> 0x05.
>
> > Now I wonder if the problem could be more specific to certain types of
> > 16bit MCUs.
>
> Feel free to send me your .asm/.cod/.hex/.map/.lst files as generated by
> SDCC from the code above (or your failing test code)---maybe SDCC emits
> wrong code on AMD64?!? (Send these file to my personal mail account
> rather than the list, though.)
>
> > Which PIC did you use in your simulation?
>
> pic18f1220 as described above.
>
> Hope that helps,
> Raphael
>
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Sdcc-user mailing list
> Sdc...@li...
> https://lists.sourceforge.net/lists/listinfo/sdcc-user
>



-- 
Rodrigo da Silva Guerra
PhD Student

Department of Adaptive Machine Systems
Graduate School of Engineering
Osaka University - Japan