Reply by Nathan Johnston June 27, 20042004-06-27

Robert was very close in his suggestion below...  It turns out that cbuf.lib was modified sometime between DC7.33P3 and DC 8.x, and the opcodes for the new codes were all in upper case (all ZWorld asm I have seen is in lower case). There was a poorly named #define in the code I was working on for ADD which of course, caused the problem.

 

Thanks to Robert and others for their suggestions.

 

Cheers,

Nathan

 

-----Original Message-----
From: Robert Richter [mailto:r...@hildalecity.com]
Sent
:
Tuesday, 22 June 2004 2:44 AM
To: r...@yahoogroups.com
Subject: Re: [rabbit-semi] DC7.33P3 -> DC8.30 Difficulties (cbuf.lib)

 

Is there a #define in your program for "SBC", "HL", or "BC"?

----------
> From: Nathan Johnston <n...@dominion.net.au>
> To: Rabbit eGroup (r...@yahoogroups.com)
> Subject: [rabbit-semi] DC7.33P3 -> DC8.30 Difficulties (cbuf.lib)
> Date:
Sunday, June 20, 2004 8:49 PM
>
I'm trying to get an application that ran OK in DC7.33P3 to run in DC8.30
and I've come across a weird one...

I'm only getting two error messages:
line  499 : ERROR CBUF.LIB     : Bad or Missing Opcode                 
line  499 : ERROR CBUF.LIB     : Syntax error - or garbage at end of
program.

Both are from the cbuf.lib library (a DC library), which I have not touched
(I've also tried on another PC's installation of 8.30). Here are the
relevant lines from the library:

498      SBC     HL,BC
; (back-front+1+mask)&mask
499      ADD    HL,DE
;
500      INC     HL
;

Does anyone have any idea what could be going on here? I'm really
scratching
my head over this one, especially when the only error messages are coming
from the Dynamic C libraries. "ADD" is definitely a valid opcode :-).

(I also added a #class static to program given that it had been written
before the class change).

Regards,
Nathan





Reply by Nathan Johnston June 23, 20042004-06-23

Matt,

 

I wasn't questioning that serEopen would be causing a problem by itself. I've used it many times before in other projects. It's just a case of DC misreporting a problem that it has found, but finding that problem is proving extremely difficult. In the process trying to get the code working in v8.x, the newer version of DC picked up a few little things that DC7.33P3 did complain about. Improvements to the compiler are always great, but when the "improvements" can't correctly report the problem it's damn annoying. Usually we'd stick with the same DC version for the duration of the products life, but in this case there is a need for separate I&D space, which has been a bit flakey with older versions of DC, hence the move to DC8.

 

I'm going to have to try devise a way to track the problem down. The application is a port of an ANSI C application and contains ~90 libraries, so with DC misreporting the error/s, it's going to be a tedious task. I'm open to suggestions from anyone with any bright ideas though.

 

Cheers,

Nathan

 

PS: Robert: I have confirmed that serEopen is called before and other serE* functions... Thanks anyway.

 

----Original Message-----
From: mlinder [mailto:m...@micro-controls.com]
Sent
:
Tuesday, 22 June 2004 10:10 PM
To: r...@yahoogroups.com
Subject: RE: [rabbit-semi] DC7.33P3 -> DC8.30 Difficulties (cbuf.lib)

 

I tried the following on my dc8.30

#define ISA_PORT_BAUD 19200
#define EINBUFSIZE 127
#define EOUTBUFSIZE 127

int main(void)
{
int c;
c = serEopen(ISA_PORT_BAUD);
}

Compiles fine. I am guessing that the error is somewhere else, if you
havent noticed DC can easily point to a line which is fine. When there
is an error I look at the line its says, then if it looks ok, go
backwards.

Matt

--Original Message Text---
From: Nathan Johnston
Date: Tue, 22 Jun 2004 17:31:01 +1000

I went through the tedious task of commenting out things in main and delving through functions until
I found a trigger to reproduce the problem. I ended up trying DC8.51 incase it was a problem with
DC8.30 to no avail. 

If I comment out this line, which is in a function hidden away in a library, DC compiles the program
(there is still parts of main commented out): 

c = serEopen(ISA_PORT_BAUD); 

ISA_PORT_BAUD has been defined elsewhere as 19200L . 

I tried changing it to serBopen for the sake it but was the same problem (the target is a RCM3100). 

I tried messing around enabling and disabling separate I&D as well as experimenting with changing
DATAORG with no luck. 

I also tried declaring a static variable in the function before the line at fault to see if it
shifted the reported error line in the DC library and it didn't. 

I'm kinda running out of ideas as to what to try. I may be forced to continue using DC7.33P3 though
I was hoping to change the project to use DC8. 

Can anyone think of anything else to try? 

Regards, 

Nathan 




Reply by Robert Richter June 22, 20042004-06-22
Sometimes, DC acts strange if you call library functions out of order--that
is, if I have a function declared before main

void foo() {
tcp_tick(NULL);
}

main() {
sock_init();
}

I'm not sure if the above example will do it, but it explains what I am
talking about; I haven't documented the actual cases where I have run into
this trouble--let's say for discussion that the above gives trouble.
sock_init may need to be run across in your code before tcp_tick. I have
had strange things happen in their libraries when calling out of order.
Make certain in your code that serXopen (whatever port), is run across in
the compiling process before any function that may use functions on that
serial port. Even if you must put in idle code to get the pointer of a
function to get a call to serXopen first

void foo() {
fPtr=serEopen;
// Really don't want to call serialEopen here, but doing this because
the actual function to open the serial port is somewhere else
}
----------
> From: Nathan Johnston <nathanj@nath...>
> To: 'rabbit-semi@'rab...'
> Subject: RE: [rabbit-semi] DC7.33P3 -> DC8.30 Difficulties (cbuf.lib)
> Date: Tuesday, June 22, 2004 12:31 AM
>
I went through the tedious task of commenting out things in main and
delving
through functions until I found a trigger to reproduce the problem. I ended
up trying DC8.51 incase it was a problem with DC8.30 to no avail.

If I comment out this line, which is in a function hidden away in a
library,
DC compiles the program (there is still parts of main commented out):

c = serEopen(ISA_PORT_BAUD);

ISA_PORT_BAUD has been defined elsewhere as 19200L .

I tried changing it to serBopen for the sake it but was the same problem
(the target is a RCM3100).

I tried messing around enabling and disabling separate I&D as well as
experimenting with changing DATAORG with no luck.

I also tried declaring a static variable in the function before the line at
fault to see if it shifted the reported error line in the DC library and it
didn't.

I'm kinda running out of ideas as to what to try. I may be forced to
continue using DC7.33P3 though I was hoping to change the project to use
DC8.

Can anyone think of anything else to try?

Regards,
Nathan -----Original Message-----
From: Robert E. Griffith [mailto:bobg@bobg...]
Sent: Tuesday, 22 June 2004 1:40 PM
To: rabbit-semi@rabb...
Subject: RE: [rabbit-semi] DC7.33P3 -> DC8.30 Difficulties (cbuf.lib)

Try commenting out your entire 'main'.c file and then bringing it back in a
little at a time until you get these errors back. If it comes back on the
line that includes a .lib, repeat the process in that file (unless it's a
DC
lib). This way you can track the offending line down despite the unhelpful
and probably misleading message.

--BobG

-----Original Message-----
From: Nathan Johnston [mailto:nathanj@nath...]
Sent: Monday, June 21, 2004 7:06 PM
To: 'rabbit-semi@'rab...'
Subject: RE: [rabbit-semi] DC7.33P3 -> DC8.30 Difficulties (cbuf.lib)

I hadn't thought of that, but I checked, and no there aren't. I suspect if
there was there would be a lot more errors listed.

-----Original Message-----
From: Robert Richter [mailto:robertr@robe...]
Sent: Tuesday, 22 June 2004 2:44 AM
To: rabbit-semi@rabb...
Subject: Re: [rabbit-semi] DC7.33P3 -> DC8.30 Difficulties (cbuf.lib)

Is there a #define in your program for "SBC", "HL", or "BC"?

----------
> From: Nathan Johnston <nathanj@nath...>
> To: Rabbit eGroup (rabbit-semi@rabb...)
> Subject: [rabbit-semi] DC7.33P3 -> DC8.30 Difficulties (cbuf.lib)
> Date: Sunday, June 20, 2004 8:49 PM
>
I'm trying to get an application that ran OK in DC7.33P3 to run in DC8.30
and I've come across a weird one...

I'm only getting two error messages:
line 499 : ERROR CBUF.LIB : Bad or Missing Opcode
line 499 : ERROR CBUF.LIB : Syntax error - or garbage at end of
program.

Both are from the cbuf.lib library (a DC library), which I have not touched
(I've also tried on another PC's installation of 8.30). Here are the
relevant lines from the library:

498 SBC HL,BC
; (back-front+1+mask)&mask
499 ADD HL,DE
;
500 INC HL
;

Does anyone have any idea what could be going on here? I'm really
scratching
my head over this one, especially when the only error messages are coming
from the Dynamic C libraries. "ADD" is definitely a valid opcode :-).

(I also added a #class static to program given that it had been written
before the class change).

Regards,
Nathan

<http://us.ard.yahoo.com/SIG9vup7o6/M)8184.5022502.6152625.3001176/D=gr

oups/S06554205:HM/EXP87962022/A!64339/R=0/SIGe2d64in/*http:/www.n

etflix.com/Default?mqso`183348> click here <http://us.adserver.yahoo.com/l?M)8184.5022502.6152625.3001176/D=groups/S=

:HM/A!64339/rand4752268>

_____

> Service.




Reply by mlinder June 22, 20042004-06-22
I tried the following on my dc8.30

#define ISA_PORT_BAUD 19200
#define EINBUFSIZE 127
#define EOUTBUFSIZE 127

int main(void)
{
int c;
c = serEopen(ISA_PORT_BAUD);
}

Compiles fine. I am guessing that the error is somewhere else, if you
havent noticed DC can easily point to a line which is fine. When there
is an error I look at the line its says, then if it looks ok, go
backwards.

Matt

--Original Message Text---
From: Nathan Johnston
Date: Tue, 22 Jun 2004 17:31:01 +1000

I went through the tedious task of commenting out things in main and delving through functions until
I found a trigger to reproduce the problem. I ended up trying DC8.51 incase it was a problem with
DC8.30 to no avail.

If I comment out this line, which is in a function hidden away in a library, DC compiles the program
(there is still parts of main commented out):

c = serEopen(ISA_PORT_BAUD);

ISA_PORT_BAUD has been defined elsewhere as 19200L .

I tried changing it to serBopen for the sake it but was the same problem (the target is a RCM3100).

I tried messing around enabling and disabling separate I&D as well as experimenting with changing
DATAORG with no luck.

I also tried declaring a static variable in the function before the line at fault to see if it
shifted the reported error line in the DC library and it didn't.

I'm kinda running out of ideas as to what to try. I may be forced to continue using DC7.33P3 though
I was hoping to change the project to use DC8.

Can anyone think of anything else to try?

Regards,

Nathan



Reply by Nathan Johnston June 22, 20042004-06-22

I went through the tedious task of commenting out things in main and delving through functions until I found a trigger to reproduce the problem. I ended up trying DC8.51 incase it was a problem with DC8.30 to no avail.

 

If I comment out this line, which is in a function hidden away in a library, DC compiles the program (there is still parts of main commented out):

 

c = serEopen(ISA_PORT_BAUD);

 

ISA_PORT_BAUD has been defined elsewhere as 19200L .

 

I tried changing it to serBopen for the sake it but was the same problem (the target is a RCM3100).

 

I tried messing around enabling and disabling separate I&D as well as experimenting with changing DATAORG with no luck.

 

I also tried declaring a static variable in the function before the line at fault to see if it shifted the reported error line in the DC library and it didn't.

 

I'm kinda running out of ideas as to what to try. I may be forced to continue using DC7.33P3 though I was hoping to change the project to use DC8.

 

Can anyone think of anything else to try?

 

Regards,

Nathan

 

 

-----Original Message-----
From: Robert E. Griffith [mailto:b...@junga.com]
Sent
:
Tuesday, 22 June 2004 1:40 PM
To: r...@yahoogroups.com
Subject: RE: [rabbit-semi] DC7.33P3 -> DC8.30 Difficulties (cbuf.lib)

 

Try commenting out your entire 'main'.c file and then bringing it back in a little at a time until you get these errors back. If it comes back on the line that includes a .lib, repeat the process in that file (unless it's a DC lib). This way you can track the offending line down despite the unhelpful and probably misleading message.

 

--BobG

 

-----Original Message-----
From:
Nathan Johnston [mailto:n...@dominion.net.au]
Sent:
Monday, June 21, 2004 7:06 PM
To: 'r...@yahoogroups.com'
Subject: RE: [rabbit-semi] DC7.33P3 -> DC8.30 Difficulties (cbuf.lib)

 

I hadn't thought of that, but I checked, and no there aren't. I suspect if there was there would be a lot more errors listed.

 

-----Original Message-----
From: Robert Richter [mailto:r...@hildalecity.com]
Sent:
Tuesday, 22 June 2004 2:44 AM
To: r...@yahoogroups.com
Subject: Re: [rabbit-semi] DC7.33P3 -> DC8.30 Difficulties (cbuf.lib)

 

Is there a #define in your program for "SBC", "HL", or "BC"?

----------
> From:
Nathan Johnston <n...@dominion.net.au>
> To:
Rabbit eGroup (r...@yahoogroups.com)
> Subject: [rabbit-semi] DC7.33P3 -> DC8.30 Difficulties (cbuf.lib)
> Date:
Sunday, June 20, 2004 8:49 PM
>
I'm trying to get an application that ran OK in DC7.33P3 to run in DC8.30
and I've come across a weird one...

I'm only getting two error messages:
line  499 : ERROR CBUF.LIB     : Bad or Missing Opcode                 
line  499 : ERROR CBUF.LIB     : Syntax error - or garbage at end of
program.

Both are from the cbuf.lib library (a DC library), which I have not touched
(I've also tried on another PC's installation of 8.30). Here are the
relevant lines from the library:

498      SBC     HL,BC
; (back-front+1+mask)&mask
499      ADD    HL,DE
;
500      INC     HL
;

Does anyone have any idea what could be going on here? I'm really
scratching
my head over this one, especially when the only error messages are coming
from the Dynamic C libraries. "ADD" is definitely a valid opcode :-).

(I also added a #class static to program given that it had been written
before the class change).

Regards,
Nathan









Reply by Robert E. Griffith June 22, 20042004-06-22

Try commenting out your entire ‘main’.c file and then bringing it back in a little at a time until you get these errors back. If it comes back on the line that includes a .lib, repeat the process in that file (unless it’s a DC lib). This way you can track the offending line down despite the unhelpful and probably misleading message.

 

--BobG

 

-----Original Message-----
From: Nathan Johnston [mailto:n...@dominion.net.au]
Sent:
Monday, June 21, 2004 7:06 PM
To: 'r...@yahoogroups.com'
Subject: RE: [rabbit-semi] DC7.33P3 -> DC8.30 Difficulties (cbuf.lib)

 

I hadn't thought of that, but I checked, and no there aren't. I suspect if there was there would be a lot more errors listed.

 

-----Original Message-----
From: Robert Richter [mailto:r...@hildalecity.com]
Sent:
Tuesday, 22 June 2004 2:44 AM
To: r...@yahoogroups.com
Subject: Re: [rabbit-semi] DC7.33P3 -> DC8.30 Difficulties (cbuf.lib)

 

Is there a #define in your program for "SBC", "HL", or "BC"?

----------
> From: Nathan Johnston <n...@dominion.net.au>
> To: Rabbit eGroup (r...@yahoogroups.com)
> Subject: [rabbit-semi] DC7.33P3 -> DC8.30 Difficulties (cbuf.lib)
> Date:
Sunday, June 20, 2004 8:49 PM
>
I'm trying to get an application that ran OK in DC7.33P3 to run in DC8.30
and I've come across a weird one...

I'm only getting two error messages:
line  499 : ERROR CBUF.LIB     : Bad or Missing Opcode                 
line  499 : ERROR CBUF.LIB     : Syntax error - or garbage at end of
program.

Both are from the cbuf.lib library (a DC library), which I have not touched
(I've also tried on another PC's installation of 8.30). Here are the
relevant lines from the library:

498      SBC     HL,BC
; (back-front+1+mask)&mask
499      ADD    HL,DE
;
500      INC     HL
;

Does anyone have any idea what could be going on here? I'm really
scratching
my head over this one, especially when the only error messages are coming
from the Dynamic C libraries. "ADD" is definitely a valid opcode :-).

(I also added a #class static to program given that it had been written
before the class change).

Regards,
Nathan







Reply by Nathan Johnston June 21, 20042004-06-21

I hadn't thought of that, but I checked, and no there aren't. I suspect if there was there would be a lot more errors listed.

 

-----Original Message-----
From: Robert Richter [mailto:r...@hildalecity.com]
Sent
:
Tuesday, 22 June 2004 2:44 AM
To: r...@yahoogroups.com
Subject: Re: [rabbit-semi] DC7.33P3 -> DC8.30 Difficulties (cbuf.lib)

 

Is there a #define in your program for "SBC", "HL", or "BC"?

----------
> From: Nathan Johnston <n...@dominion.net.au>
> To: Rabbit eGroup (r...@yahoogroups.com)
> Subject: [rabbit-semi] DC7.33P3 -> DC8.30 Difficulties (cbuf.lib)
> Date: Sunday, June 20, 2004 8:49 PM
>
I'm trying to get an application that ran OK in DC7.33P3 to run in DC8.30
and I've come across a weird one...

I'm only getting two error messages:
line  499 : ERROR CBUF.LIB     : Bad or Missing Opcode                 
line  499 : ERROR CBUF.LIB     : Syntax error - or garbage at end of
program.

Both are from the cbuf.lib library (a DC library), which I have not touched
(I've also tried on another PC's installation of 8.30). Here are the
relevant lines from the library:

498      SBC     HL,BC
; (back-front+1+mask)&mask
499      ADD    HL,DE
;
500      INC     HL
;

Does anyone have any idea what could be going on here? I'm really
scratching
my head over this one, especially when the only error messages are coming
from the Dynamic C libraries. "ADD" is definitely a valid opcode :-).

(I also added a #class static to program given that it had been written
before the class change).

Regards,
Nathan





Reply by Robert Richter June 21, 20042004-06-21
Is there a #define in your program for "SBC", "HL", or "BC"?

----------
> From: Nathan Johnston <nathanj@nath...>
> To: Rabbit eGroup (rabbit-semi@rabb...)
> Subject: [rabbit-semi] DC7.33P3 -> DC8.30 Difficulties (cbuf.lib)
> Date: Sunday, June 20, 2004 8:49 PM
>
I'm trying to get an application that ran OK in DC7.33P3 to run in DC8.30
and I've come across a weird one...

I'm only getting two error messages:
line 499 : ERROR CBUF.LIB : Bad or Missing Opcode
line 499 : ERROR CBUF.LIB : Syntax error - or garbage at end of
program.

Both are from the cbuf.lib library (a DC library), which I have not touched
(I've also tried on another PC's installation of 8.30). Here are the
relevant lines from the library:

498 SBC HL,BC
; (back-front+1+mask)&mask
499 ADD HL,DE
;
500 INC HL
;

Does anyone have any idea what could be going on here? I'm really
scratching
my head over this one, especially when the only error messages are coming
from the Dynamic C libraries. "ADD" is definitely a valid opcode :-).

(I also added a #class static to program given that it had been written
before the class change).

Regards,
Nathan


Reply by Nathan Johnston June 21, 20042004-06-21

I'm trying to get an application that ran OK in DC7.33P3 to run in DC8.30 and I've come across a weird one...

 

I'm only getting two error messages:

line  499 : ERROR CBUF.LIB     : Bad or Missing Opcode                 

line  499 : ERROR CBUF.LIB     : Syntax error - or garbage at end of program.

 

Both are from the cbuf.lib library (a DC library), which I have not touched (I've also tried on another PC's installation of 8.30). Here are the relevant lines from the library:

 

498      SBC     HL,BC                                                                         ; (back-front+1+mask)&mask

499      ADD    HL,DE                                                                         ;

500      INC     HL                                                                                           ;

 

Does anyone have any idea what could be going on here? I'm really scratching my head over this one, especially when the only error messages are coming from the Dynamic C libraries. "ADD" is definitely a valid opcode J.

 

(I also added a #class static to program given that it had been written before the class change).

 

Regards,

Nathan