Re: [Sdcc-user] pic code / New banksel bug found

[Scott Dattalo <scott@da...>]

On Sun, 30 Nov 2003, Steffen Koepf wrote:

> Scott, where are you? ;)

Here I am!

Steffan, my apologies to you and all other SDCC PIC users. Over the last
year and a half I've had little time for SDCC. As it stands, the PIC port 
is mostly done. But mostly done is hardly acceptable for a compiler.

Over the last two months I've started back into Open Source development. 
I've been working on gpsim (the GNUPIC simulator). I expect to be working 
on gpsim for at least a few more months. After that I may be able to 
revisit SDCC. Meanwhile, I'll gladly try to help answer specific questions 
about the PIC port.

Regards,
Scott

Re: [Sdcc-user] pic code / New banksel bug found

[Steffen Koepf <taxman-ml@op...>]

> Some still have this failure that's been around for a few months:
> compare3.asm:830:Error [113] Symbol not previously defined (r0x20).
> 
> For the moment, the only place for C programmers here is inside sdcc's pic
> port, working to fix and enhance it... That's where I'll be when I get 
> time.

Yes, it is very sad that the development of the pic port does not continue...
I am a C coder and know the PIC very good, but i have no knowledge in
building a compiler. I used the whole day to track down a problem why the 
compiler does not generate banksel's for registers which never have a
write access, only read access in the code. Now i found out that the 
address fields in the pCode's have the value "0" (which forces the banksel
generating code to fail) when there is no write access to the register in 
the whole code. This is because the function allocDirReg(operand *op) 
(that assigns the address) is only called for a reg if there is a write 
access to this reg. But i think i have not enough knowledge to fix this bug 
in a good way. Are there people on this list that can help with the pic port? 
Scott, where are you? ;)

cu,

Steffen

Re: [Sdcc-user] LCD and MCU8051, I am still in stuck. Help me, plz

[Erik Petrich <epetrich@iv...>]

On Sat, 29 Nov 2003, Jung-Hee Park wrote:

> First of all, I would like to express my thank for your warming help me.
> Unfortunately, I still could not solve my problem. I have not gotten my
> expected result: The line "Test" on the LCD.
> The delay(unsigned int) in my progam has been tested with calling delay(100)
> that generates 1,25ms delay time duration. Thus I think the delay time for
> LCD is enough.
> 
> Actually, I tried the same procedure in RIDE evaluation version, my circuit
> works fine, i.e. The main problem is in my SDCC result software
> 
> I also attach the *.asm for thorough checking. Please help me out this.

void InitMCU(void)
{
	EA=0;
	EX0=0;
	ET0=0;
	EX1=0;
	ET1=0;
	ES=0;
/*	SP=0x5F;	 <<<< Do not reload SP */
	PCON=0x00;
	TCON=0x00;
	SCON=0x00;
	TMOD=0x00;
	//
	return;
}

Do not change SP like this, otherwise the function's return address will
no longer be at the top of the stack and the program will crash at the
return statement.

If you do not want to use SDCC's automatic stack placement, you should
instead use the --stack-loc command line option.

   Erik

Re: [Sdcc-user] LCD and MCU8051, I am still in stuck. Help me, plz

[Gernot Fink <gernot.fink@ne...>]

You wrote:
> Unfortunately, I still could not solve my problem. I have not gotten my
> expected result: The line "Test" on the LCD.

Most of this displays show  immediately after connecting Vcc a gray bar i=
n one
line (all dots a little bit active) if Vcontrast at Grount.

See you this bar?

If your display use a 16 pin connector check that you use the correct 14.

--=20
MFG Gernot

Re: [Sdcc-user] LCD and MCU8051, I am still in stuck. Help me, plz

[Jean-Paul <tchainick@fr...>]

On Sat, 29 Nov 2003 17:03:43 +0900, Jung-Hee Park 
<jhee_park2002@...> wrote:

> First of all, I would like to express my thank for your warming help me.
> Unfortunately, I still could not solve my problem. I have not gotten my
> expected result: The line "Test" on the LCD.
>

Obviously, we are not seing something too big!

Can we be sure that lcdInit actually did its job?

I suppose your display is a 2 lines x 16 char type, since you write 0x38 
after reset.
When powered and not initialised, with the contrast pot correctly set, it 
shows only the upper line as 16 black blocks.
Once initialised, it shows both lines as 16 light grey blocks (spaces).

If you don't see that behavior, it could be that your E pulse is too 
short, since your init code looks OK. The minimum E cycle time is usually 
500 µs.

If your E pulse is too short, you'll have to add some nop commands in
void    lcdputCmd(unsigned char nCmd)
between lcdEnable=1 and lcdEnable=0.
   {
     _asm
      nop	/* or more nops, according to the speed of your processor */
     _endasm;
   }


-- 
NEVER jump into a LOOP!

[Sdcc-user] LCD and MCU8051, I am still in stuck. Help me, plz

[Jung-Hee Park <jhee_park2002@ho...>]

First of all, I would like to express my thank for your warming help me.
Unfortunately, I still could not solve my problem. I have not gotten my
expected result: The line "Test" on the LCD.
The delay(unsigned int) in my progam has been tested with calling delay(100)
that generates 1,25ms delay time duration. Thus I think the delay time for
LCD is enough.

Actually, I tried the same procedure in RIDE evaluation version, my circuit
works fine, i.e. The main problem is in my SDCC result software

I also attach the *.asm for thorough checking. Please help me out this.

Usefull information:
SDCC - v: mcs51/gbz80/z80/avr/ds390/pic14/TININative/xa51 2.3.5 <Apr 21
2003> <MINGW32
PC: Win 2003


The old issues have been fixed as follows

On Tue, 25 Nov 2003 Erik Petrich wrote:
> Since the inner for(j=0;j<1000;j++) loop apparently does >nothing, SDCC
>will not generate any code for it. What remains is:

Actually, I have changed inside the FOR loop this loop into:
for(j=0;j<1000;j++)
{
        _asm
                nop
        _endasm;
}
And I check the pulse output of this routine ~ 2ms


On Wed, 26 Nov 2003 Jean-Paul and Steve Polishinski  wrote:
>If you have no inverter-buffer between the port line and
lcdRW on the display itself, lcdRW has to be drawn low in order to write
on the LCD.

Thanks for remind me. I have checked it and set lcdRW to 0 everytime (as you
can glance at the attached sourcecode)


On Wed, 26 Nov 2003 Gernot Fink wrote:
>nLocal=2;
>lcdRS=0;
lcdData=0x38; // Function set + ...
lcdEnable=1;
lcdEnable=0;
delay(nLocal)

Thanks for helping. I also pay attention to the Enable signal for LCD as you
suggested as followed the datasheet

RE: [Sdcc-user] Bit field access bug ?

[Stephen Ede <stephen.ede@in...>]

Many thanks !

-----Original Message-----
From: sdcc-user-admin@...
[mailto:sdcc-user-admin@...]On Behalf Of Erik Petrich
Sent: 26 November 2003 18:47
To: sdcc-user@...
Subject: Re: [Sdcc-user] Bit field access bug ?



On Wed, 26 Nov 2003, Stephen Ede wrote:

> Any chance somebody could take a quick look at this before I report it
> as a bug.
>
> Basically, I think a bug has recently been introduced into SDCC that
> prevents access to bit fields declared in external memory space. I had a
> quick look at the bug list and didn't see any similar problems reported.
>
> Attached is a test file (test.c) that accesses a bit field declared within
> a structure hierarchy by the header file (test.h).

Yes, it's a bug in SDCC. I've disabled the offending code; tomorrow's
binary snapshots should reflect this correction.

> Also, can anyone tell me why the following lines are produced by the
> later version of the compiler...
>
> ?Aslink-Warning-Definition of public symbol '__sdcc_external_startup'
found
> more than once:
>    Library: 'c:/sdcc/lib/large/libsdcc.lib', Module: '_startup'
>    Library: 'c:/sdcc/bin\..\lib\small/libsdcc.lib', Module: '_startup'
>
> The large model version appears first in this list and I'm assuming that
> this is the one that is linked - the code works so I'm ignoring this for
> now.

The older linker ignored this condition without saying anything. The
problem is that your Makefile is invoking the linker through the compiler
but not specifying the memory model. The compiler defaults to
--model-small and so tells the linker to use lib/small/libsdcc.lib in
addition to your manually specified lib/large/libsdcc.lib. So use

CL_FLAGS = --model-large

in your Makefile instead.

   Erik




-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
Sdcc-user mailing list
Sdcc-user@...
https://lists.sourceforge.net/lists/listinfo/sdcc-user

[Sdcc-user] Pointers to functions

[Murray R.Van Luyn <vanluynm@se...>]

Can I use pointers to functions somehow with SDCC?

The following crashes the compiler in the Win32 binary package, but I don't
know why.

unsigned char xmodem_tx(unsigned char (*buffer_loader)(unsigned char *))
{
    unsigned char no_more = 0;
    xdata unsigned char packet_data_buffer[PACKET_DATA_BUFFER_LENGTH];

    do
    {
        no_more = (*buffer_loader)(packet_data_buffer);

etc.

Some of these compiler messages are a little too cryptic. I don't understand
"says Zelda the deleted dog"?

Regards,
Murray.
_____________________________________
Murray R.Van Luyn
E-mail: vanluynm@...
           vanluynm@...

Re: [Sdcc-user] pls help me to solve this unusual behaviour

[Royce & Sharal Pereira <bethell@et...>]

Hi Ravi,

Why dontcha read the 80c51 data sheets first?
You'll find that EA pin is to tied to Vcc for internal program.

No SDCC options are required for internal/external rom. SDCC doesnt care
where your program is. EA state decides that.

If no Xram is used you can use the --no-xinit-opt option in the command
line...again read the SDCC manual first!

Bye,
--Royce.

----- Original Message -----
From: "Ravi Kumar" <ravivsn@...>
To: <sdcc-user@...>
Sent: Thursday, November 27, 2003 9:42 AM
Subject: Re: [Sdcc-user] pls help me to solve this unusual behaviour


> Hi,
> There is no external programme memory. And also ALE is not connected.
> Any way out!!
> Thanks
> Ravi Kumar CH
> On Tue, 2003-11-25 at 20:16, Jean-Paul Brodier wrote:
> > On 25 Nov 2003 19:41:54 +0530, Ravi Kumar <ravivsn@...> wrote:
> >
> > > Hi All,
> > > This is my first posting to the list.
> > > MC:AT89C51
> > >         SDCC : mcs51/gbz80/z80/avr/ds390/pic14 2.3.0 (Sep 20 2001)
> > > (UNIX)
> > > To test 89c51 board, I wrote a test program to generate clock on each
> > > port. I have attached the related c file and hex file.
> > >
> > > My problem:  when  loaded onto 89c51 I dont see any response of LEDs
> > > connected to P2. Observing P2 in oscilloscope shows me square waves on
> > > each pin of P2 but of different freq.
> >
> > Looks like your processor is scanning external addresses on P2 (A8 to
> > A15), looking for an external programme memory.
> >
> > Would you mind checking the level of AE\ pin? It should be high if
you're
> > using the internal flash ROM.
> >
> > > The same program when I write hex code and download onto 89c51 LEDs
are
> > > blinking and showing same freq, with this obeservation I cannot
suspect
> > > hardware.
> > > I strongly feel I am missing some thing in startup code or compiler
> > > options.
> > >
> > > sdcc -mmcs51 --model-small -c test.c
> > > sdcc -mmcs51 --model-small test.rel
> > > packihx test.ihx > test.hex
> > >
> > > Please help me out,
> > > Thanks in advance,
> > > Ravi Kumar CH
> > >
> >
> >
> >
> > --
> > NEVER jump into a LOOP!
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: SF.net Giveback Program.
> > Does SourceForge.net help you be more productive?  Does it
> > help you create better code?  SHARE THE LOVE, and help us help
> > YOU!  Click Here: http://sourceforge.net/donate/
> > _______________________________________________
> > Sdcc-user mailing list
> > Sdcc-user@...
> > https://lists.sourceforge.net/lists/listinfo/sdcc-user
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Sdcc-user mailing list
> Sdcc-user@...
> https://lists.sourceforge.net/lists/listinfo/sdcc-user
>

Start-up code for 89c51 Re: [Sdcc-user] pls help me to solve this unusual behaviour

[Ravi Kumar <ravivsn@ro...>]

Hi all,
Could any pls tell me what options to set for 
Atmel AT89C51 using built in data memory and program memory with no
external memory.
And start-up code for the same.
Thanks in advance,
Regards,
Ravi Kumar CH
On Thu, 2003-11-27 at 09:42, Ravi Kumar wrote:
> Hi,
> There is no external programme memory. And also ALE is not connected.
> Any way out!!
> Thanks 
> Ravi Kumar CH
> On Tue, 2003-11-25 at 20:16, Jean-Paul Brodier wrote:
> > On 25 Nov 2003 19:41:54 +0530, Ravi Kumar <ravivsn@...> wrote:
> > 
> > > Hi All,
> > > This is my first posting to the list.
> > > 	MC:AT89C51
> > >         SDCC : mcs51/gbz80/z80/avr/ds390/pic14 2.3.0 (Sep 20 2001)
> > > (UNIX)
> > > To test 89c51 board, I wrote a test program to generate clock on each
> > > port. I have attached the related c file and hex file.
> > >
> > > My problem:  when  loaded onto 89c51 I dont see any response of LEDs
> > > connected to P2. Observing P2 in oscilloscope shows me square waves on
> > > each pin of P2 but of different freq.
> > 
> > Looks like your processor is scanning external addresses on P2 (A8 to 
> > A15), looking for an external programme memory.
> > 
> > Would you mind checking the level of AE\ pin? It should be high if you're 
> > using the internal flash ROM.
> > 
> > > The same program when I write hex code and download onto 89c51 LEDs are
> > > blinking and showing same freq, with this obeservation I cannot suspect
> > > hardware.
> > > I strongly feel I am missing some thing in startup code or compiler
> > > options.
> > >
> > > sdcc -mmcs51 --model-small -c test.c
> > > sdcc -mmcs51 --model-small test.rel
> > > packihx test.ihx > test.hex
> > >
> > > Please help me out,
> > > Thanks in advance,
> > > Ravi Kumar CH
> > >
> > 
> > 
> > 
> > -- 
> > NEVER jump into a LOOP!
> > 
> > 
> > -------------------------------------------------------
> > This SF.net email is sponsored by: SF.net Giveback Program.
> > Does SourceForge.net help you be more productive?  Does it
> > help you create better code?  SHARE THE LOVE, and help us help
> > YOU!  Click Here: http://sourceforge.net/donate/
> > _______________________________________________
> > Sdcc-user mailing list
> > Sdcc-user@...
> > https://lists.sourceforge.net/lists/listinfo/sdcc-user
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Sdcc-user mailing list
> Sdcc-user@...
> https://lists.sourceforge.net/lists/listinfo/sdcc-user

Re: [Sdcc-user] pls help me to solve this unusual behaviour

[Ravi Kumar <ravivsn@ro...>]

Hi,
There is no external programme memory. And also ALE is not connected.
Any way out!!
Thanks 
Ravi Kumar CH
On Tue, 2003-11-25 at 20:16, Jean-Paul Brodier wrote:
> On 25 Nov 2003 19:41:54 +0530, Ravi Kumar <ravivsn@...> wrote:
> 
> > Hi All,
> > This is my first posting to the list.
> > 	MC:AT89C51
> >         SDCC : mcs51/gbz80/z80/avr/ds390/pic14 2.3.0 (Sep 20 2001)
> > (UNIX)
> > To test 89c51 board, I wrote a test program to generate clock on each
> > port. I have attached the related c file and hex file.
> >
> > My problem:  when  loaded onto 89c51 I dont see any response of LEDs
> > connected to P2. Observing P2 in oscilloscope shows me square waves on
> > each pin of P2 but of different freq.
> 
> Looks like your processor is scanning external addresses on P2 (A8 to 
> A15), looking for an external programme memory.
> 
> Would you mind checking the level of AE\ pin? It should be high if you're 
> using the internal flash ROM.
> 
> > The same program when I write hex code and download onto 89c51 LEDs are
> > blinking and showing same freq, with this obeservation I cannot suspect
> > hardware.
> > I strongly feel I am missing some thing in startup code or compiler
> > options.
> >
> > sdcc -mmcs51 --model-small -c test.c
> > sdcc -mmcs51 --model-small test.rel
> > packihx test.ihx > test.hex
> >
> > Please help me out,
> > Thanks in advance,
> > Ravi Kumar CH
> >
> 
> 
> 
> -- 
> NEVER jump into a LOOP!
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Sdcc-user mailing list
> Sdcc-user@...
> https://lists.sourceforge.net/lists/listinfo/sdcc-user

Re: [Sdcc-user] Bit field access bug ?

[Erik Petrich <epetrich@iv...>]

On Wed, 26 Nov 2003, Stephen Ede wrote:

> Any chance somebody could take a quick look at this before I report it
> as a bug.
> 
> Basically, I think a bug has recently been introduced into SDCC that
> prevents access to bit fields declared in external memory space. I had a
> quick look at the bug list and didn't see any similar problems reported.
> 
> Attached is a test file (test.c) that accesses a bit field declared within
> a structure hierarchy by the header file (test.h).

Yes, it's a bug in SDCC. I've disabled the offending code; tomorrow's
binary snapshots should reflect this correction.

> Also, can anyone tell me why the following lines are produced by the
> later version of the compiler...
> 
> ?Aslink-Warning-Definition of public symbol '__sdcc_external_startup' found
> more than once:
>    Library: 'c:/sdcc/lib/large/libsdcc.lib', Module: '_startup'
>    Library: 'c:/sdcc/bin\..\lib\small/libsdcc.lib', Module: '_startup'
> 
> The large model version appears first in this list and I'm assuming that
> this is the one that is linked - the code works so I'm ignoring this for
> now.

The older linker ignored this condition without saying anything. The
problem is that your Makefile is invoking the linker through the compiler
but not specifying the memory model. The compiler defaults to
--model-small and so tells the linker to use lib/small/libsdcc.lib in
addition to your manually specified lib/large/libsdcc.lib. So use

CL_FLAGS = --model-large

in your Makefile instead.

   Erik

[Sdcc-user] Bit field access bug ?

[Stephen Ede <stephen.ede@in...>]

Hi All,

Any chance somebody could take a quick look at this before I report it
as a bug.

Basically, I think a bug has recently been introduced into SDCC that
prevents access to bit fields declared in external memory space. I had a
quick look at the bug list and didn't see any similar problems reported.

Attached is a test file (test.c) that accesses a bit field declared within
a structure hierarchy by the header file (test.h).

The package also contains makefiles for two build directories, one
for the older version that produces the correct code, the other for the
more recent version that produces incorrect code.

The two versions of SDCC tested are...

SDCC : mcs51 2.3.1-pj3 (Jan 20 2002) (MINGW)

and...

SDCC : mcs51/gbz80/z80/avr/ds390/pic14/pic16/TININative/xa51/ds400/hc08
2.3.5 (Oct 16 2003) (MINGW32

Here's the line of C that is of interest...

bank0.block0.reg0.bits.bit5 = 1;

In the old 2.3.1-pj3 version, the compiler produces...

mov	dptr,#_bank0
mov	a,#0x01
swap	a
rl	a
anl	a,#0xe0
mov	b,a
movx	a,@dptr
anl	a,#0xdf
orl	a,b
movx	@dptr,a

In the newer 2.3.5 version, it produces...

mov	dptr,#___00000007
mov	a,#0x01
movx	@dptr,a

The required bitwise read-mod-write instructions are not being invoked
with the newer version of the compiler.

I implemented a work around using a pointer, which works ok. However,
this is a bit expensive and quite inconvenient, especially given that the
pointer
needs to be initialised locally. Using a global pointer with initialised
data
doesn't seet to work, I get the following kind of linker error...

?ASlink-Warning-Undefined Global '___00000004' referenced by module 'test'

Also, can anyone tell me why the following lines are produced by the
later version of the compiler...

?Aslink-Warning-Definition of public symbol '__sdcc_external_startup' found
more than once:
   Library: 'c:/sdcc/lib/large/libsdcc.lib', Module: '_startup'
   Library: 'c:/sdcc/bin\..\lib\small/libsdcc.lib', Module: '_startup'

The large model version appears first in this list and I'm assuming that
this is the one that is linked - the code works so I'm ignoring this for
now.

Thanks in advance,
Steve

Re: [Sdcc-user] Plz help me out this working with LCD and MCU 8031 & Attachment File

[Jean-Paul <tchainick@fr...>]

Hello,

I had a look at your source after I read Steve Polishinski's answer.

He is right. If you have no inverter-buffer between the port line and 
lcdRW on the display itself, lcdRW has to be drawn low in order to write 
on the LCD.

Second: lcdEnable is a strobe signal. Have a look at the LCD's bus timing 
specs: you have to settle lcdRW, lcdRS and lcdData before giving a strobe 
pulse on lcdEnable.
These devices work much like Motorola micros 6800, 6809, HC11 etc.



On Tue, 25 Nov 2003 13:56:15 +0900, Jung-Hee Park 
<jhee_park2002@...> wrote:
>  Hi,
> Sorry for last email that I forgot to attach file.
> 1 - Could you guys kindly help me out this issue. Plz see the code 
> attached
> for details.
>  The problem is that I could not see the result that I wanna: "TEST" on 
> LCD.
>  First, just care the basic working just to work with LCD than perfer
> solutions such as checking busy status, etc.
>  2 - I guess that maybe the issue lies at the delay time. But I could not
>  check yet. Does any have any suggestions?
>
>  More information:
>  - MCU: 8031
>  - LCD ACM1253 (~Hitachi 4400)
>  - Crystal 11.9MHz
>  - SDCC v2.3.0 under Window2k
>
>  I am looking forward to hearing your help.
>  Thanks so much for helps,
>
>  sincerely yours
>
>  This is J.H Park wrote from South of Korea

-- 
NEVER jump into a LOOP!

Re: [Sdcc-user] Plz help me out this working with LCD and MCU 8031

[Steve Polishinski <wb9ysd@ma...>]

J. Park,

Where you are doing anything with lcdRW?  Or did I miss something in your=
=20
lcd_test_jhp.c file?  (It's possible since I'm new to the 8051, though I'=
ve=20
dealt with my share of LCDs with several other micros.)=20

I'd add this line.

=09lcdRW =3D 0;

Dependent on the exact specs of your LCD module (assuming you never want =
to=20
read from it), you may be able to leave lcdRW at 0 all the time (or wire =
it=20
to ground & not the CPU).  Otherwise, you'll need more than just the simp=
le=20
line above.


Thanks, Steve

Re: [Sdcc-user] Plz help me out this working with LCD and MCU 8031 & Attachment File

[Gernot Fink <gernot.fink@ne...>]

On Tue, 25 Nov 2003, you wrote:

Try this:

	nLocal=2;
	lcdRS=0;
	lcdData=0x38;	// Function set + ...
	lcdEnable=1;
	lcdEnable=0;
	delay(nLocal);

Sometime it is a good Idea to connect a 3k pullupresistor between enable and
vcc.

-- 
MFG Gernot

Re: [Sdcc-user] pls help me to solve this unusual behaviour

[Jean-Paul Brodier <tchainick@fr...>]

On 25 Nov 2003 19:41:54 +0530, Ravi Kumar <ravivsn@...> wrote:

> Hi All,
> This is my first posting to the list.
> 	MC:AT89C51
>         SDCC : mcs51/gbz80/z80/avr/ds390/pic14 2.3.0 (Sep 20 2001)
> (UNIX)
> To test 89c51 board, I wrote a test program to generate clock on each
> port. I have attached the related c file and hex file.
>
> My problem:  when  loaded onto 89c51 I dont see any response of LEDs
> connected to P2. Observing P2 in oscilloscope shows me square waves on
> each pin of P2 but of different freq.

Looks like your processor is scanning external addresses on P2 (A8 to 
A15), looking for an external programme memory.

Would you mind checking the level of AE\ pin? It should be high if you're 
using the internal flash ROM.

> The same program when I write hex code and download onto 89c51 LEDs are
> blinking and showing same freq, with this obeservation I cannot suspect
> hardware.
> I strongly feel I am missing some thing in startup code or compiler
> options.
>
> sdcc -mmcs51 --model-small -c test.c
> sdcc -mmcs51 --model-small test.rel
> packihx test.ihx > test.hex
>
> Please help me out,
> Thanks in advance,
> Ravi Kumar CH
>



-- 
NEVER jump into a LOOP!

[Sdcc-user] pls help me to solve this unusual behaviour

[Ravi Kumar <ravivsn@ro...>]

Hi All,
This is my first posting to the list.
	MC:AT89C51
        SDCC : mcs51/gbz80/z80/avr/ds390/pic14 2.3.0 (Sep 20 2001)
(UNIX)
To test 89c51 board, I wrote a test program to generate clock on each
port. I have attached the related c file and hex file.

My problem:  when  loaded onto 89c51 I dont see any response of LEDs
connected to P2. Observing P2 in oscilloscope shows me square waves on
each pin of P2 but of different freq. 
The same program when I write hex code and download onto 89c51 LEDs are
blinking and showing same freq, with this obeservation I cannot suspect
hardware.
I strongly feel I am missing some thing in startup code or compiler
options.

sdcc -mmcs51 --model-small -c test.c
sdcc -mmcs51 --model-small test.rel
packihx test.ihx > test.hex

Please help me out,
Thanks in advance,
Ravi Kumar CH

[Sdcc-user] Keil pointer to Sdcc

[<mastermatic@ma...>]

Hi!
I need to convert  some utilities from Atmel that come for Keil C.

How can I get rid of this error : "pointer needed" in lines below?

//-------------------
#define __API_FLASH_ENTRY_POINT (*((const void(code*)(void)) 0xFFC0 ))
-
-
-
Uchar __api_rd_generic (Uchar command, Uchar dpl)
{
  api_command = command;
  api_dpl     = dpl;
 MAP_BOOT;
 __API_FLASH_ENTRY_POINT();               <------------------------ error :
Pointer required
 UNMAP_BOOT;

  return(api_value);
}

Any help will be appreciated

Thanks
J Barbosa

Re: [Sdcc-user] Plz help me out this working with LCD and MCU 8031 & Attachment File

[Erik Petrich <epetrich@iv...>]

On Tue, 25 Nov 2003, Jung-Hee Park wrote:

>  2 - I guess that maybe the issue lies at the delay time. But I could not
>  check yet. Does any have any suggestions?

/*---------------------------------------------------------------------*/
/*	This implements the delay function with the delay time will be */
/*	nDelay*1000 ~ 1ms					       */
/*---------------------------------------------------------------------*/
void delay(unsigned int nDelay)
{
	unsigned int j;
	do
	{
		for(j=0;j<1000;j++)
		{}
		nDelay--;
	}while(nDelay>0);
	return;
}

Since the inner for(j=0;j<1000;j++) loop apparently does nothing, SDCC
will not generate any code for it. What remains is:

void delay(unsigned int nDelay)
{
	do
	{
		nDelay--;
	}while(nDelay>0);
	return;
}

which will execute much faster than nDelay milliseconds. Thus your LCD
will not have enough time between E pulses. Closer to your intent would
be:

void delay(unsigned int nDelay)
{
	volatile unsigned int j;
	do
	{
		for(j=0;j<1000;j++)
		{}
		nDelay--;
	}while(nDelay>0);
	return;
}

By declaring j as volatile, you can force SDCC to retain the
for(j=0;j<1000;j++) loop. I doubt that each iteration will take
exactly 1 microsecond, but as long it is at least 1 microsecond,
the overall delay (greater than 2ms) should be long enough for the LCD.

  Erik

[Sdcc-user] Plz help me out this working with LCD and MCU 8031 & Attachment File

[Jung-Hee Park <jhee_park2002@ho...>]

 Hi,
Sorry for last email that I forgot to attach file.
1 - Could you guys kindly help me out this issue. Plz see the code attached
for details.
 The problem is that I could not see the result that I wanna: "TEST" on LCD.
 First, just care the basic working just to work with LCD than perfer
solutions such as checking busy status, etc.
 2 - I guess that maybe the issue lies at the delay time. But I could not
 check yet. Does any have any suggestions?

 More information:
 - MCU: 8031
 - LCD ACM1253 (~Hitachi 4400)
 - Crystal 11.9MHz
 - SDCC v2.3.0 under Window2k

 I am looking forward to hearing your help.
 Thanks so much for helps,

 sincerely yours

 This is J.H Park wrote from South of Korea

Re: [Sdcc-user] Plz help me out this working with LCD and MCU 8031

[Yuri Malinovski <yurasiku@pi...>]

Hi, mr. Park,

It seems like you forgot to attach files.
It would be much more helpful if you did attach these code files.

Yuri.

Jung-Hee Park wrote:

> Hi,
> 1 - Could you guys kindly help me out this issue. Plz see the code 
> attached for details.
> The problem is that I could not see the result that I wanna: "TEST" on 
> LCD.
> First, just care the basic working just work with LCD than perfer 
> solutions such as checking busy status, etc.
> 2 - I guess that maybe the issue lies at the delay time. But I could 
> not check yet. Does any have any suggestions?
>
> ---------------------------------
>
> More information:
> - MCU: 8031
> - LCD ACM1253 (~Hitachi 4400)
> - Crystal 11.9MHz
> - SDCC v2.3.0 under Window2k
>
> I am looking forward to hearing your help.
> Thanks so much for helps,
>
> sincerely yours
>
> This is J.H Park wrote from South of Korea
>

[Sdcc-user] Plz help me out this working with LCD and MCU 8031

[Jung-Hee Park <jhee_park2002@ho...>]

Hi,
1 - Could you guys kindly help me out this issue. Plz see the code attached 
for details.
The problem is that I could not see the result that I wanna: "TEST" on LCD.
First, just care the basic working just work with LCD than perfer solutions 
such as checking busy status, etc.
2 - I guess that maybe the issue lies at the delay time. But I could not 
check yet. Does any have any suggestions?

---------------------------------

More information:
- MCU: 8031
- LCD ACM1253 (~Hitachi 4400)
- Crystal 11.9MHz
- SDCC v2.3.0 under Window2k

I am looking forward to hearing your help.
Thanks so much for helps,

sincerely yours

This is J.H Park wrote from South of Korea

_________________________________________________________________
Help STOP SPAM with the new MSN 8 and get 2 months FREE*  
http://join.msn.com/?page=features/junkmail

[Sdcc-user] More on 89S8252 and EEPROM

[<jkue002@ec...>]

OK, strange. I've fiddled around with the code a bit, and found something=
 which=20
doesn't make sense (to me). This compiles fine:


void write_EEPROM (xdata unsigned char* address, unsigned char value) cri=
tical
{
    WMCON |=3D 0x18; //00011000 set EEMEN and EEWEN

    *address =3D value;
    while (!(0x02 & WMCON)); //wait for eeprom ready flag=20

    WMCON &=3D ~0x18;
}


but this gives a "Caught signal 11: SIGSEGV":


void write_EEPROM (xdata unsigned char* address, unsigned char value) cri=
tical
{
    WMCON |=3D 0x18; //00011000 set EEMEN and EEWEN

    while (!(0x02 & WMCON)); //wait for eeprom ready flag=20

    *address =3D value;
    while (!(0x02 & WMCON)); //wait for eeprom ready flag=20

    WMCON &=3D ~0x18;
}


The only difference being that in the former I'm checking for the ready/n=
ot=20
busy flag before I start to write...

Can anyone explain this?

Jeremy

Re: [Sdcc-user] Using printf() and printf_small()

[Paul Stoffregen <paul@pj...>]

Have you tried printf_fast ?  I wrote that one :-)


Paul




Murray R.Van Luyn wrote:

> I've just begun to use the latest win32 binary distribution of SDCC. I 
> can't seem to make printf or printf_small behave correctly on either 
> the s51 simulator or an AT89C51AC2.
>  
> void main(void)
> {
>  
>     int i;
>  
>     init_adc_highres(0x03);
>     init_sio_out();
>  
>     AN2 = 0; 
>     AN3 = 1;  
>
>     while(1)
>     {
>         for(i = 0; i < 256; i++)
>         {
>             printf_small("Sample %d is %d \n\r", i, 
> (int)read_adc_highres(0));
>         }
>     }
> }
>  
> In this case read_adc_highres() returns an unsigned long, but the 
> problem will occur just as readily if I have it return an int.
>  
> It seems that printf_small() will pre-pend minus signs to certain 
> ranges of numbers in both the loop counter and sampling routine return.
>  
> ie Sample -245 is 179
>    Sample 23 is -159
>  
> I gave up on printf as I couldn't make it work at all!
> I compile with the --stack-after-data option. 
>  
> If I were to do 3 printf_small statements in a row, the middle one 
> might work okay and the others not!
>  
> Can anyone see immediately where I might be going wrong, or possibly 
> have some printf\ printf_small experience or usage examples to share?
>  
> Regards,
> Murray.