Searching \ for 'Still more: Hi-Tech 7.83 and 17c756 bug?' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: techref.massmind.org/techref/index.htm?key=tech+783+17c756
Search entire site for: 'Still more: Hi-Tech 7.83 and 17c756 bug?'.

Truncated match.
PICList Thread
'Still more: Hi-Tech 7.83 and 17c756 bug?'
1999\03\25@121938 by silicontao_roy

flavicon
face
My pop3 server is down now, I can send mail but not receive it. So if
someone has found out the answer to my problem I hope to see that e-mail by
tomorrow.

New information.
I have a structure that I can not use if it is the first structure, when I
declare another sturct first then the one I want to use works, I just can
not use the first structure that I declare. Also I have an unsigned char
variable that I can not use called curValue, and if I rename it any thing
like curVxxxalue works fine. What is up with that. I am working on removing
the code that I am not allowed to show to people and I will send the striped
down version of the code, probably a main and a few variables just to see if
anyone else gets this problem when they compile it. I will send in about 2
hours. Thanks.

>From e-mail: More: Hi-Tech 7.83 and 17c756 bug?
I found the problem and don't know how to fix it. I have three struct's in
the code. One of them, if I rem it out it will compile properly and run
great. If I add the line back in the compiler says that it compiles ok but I
don't get a memory detail and the chip does not run.

>From e-mail: Hi-Tech 7.83 and 17c756 bug?
I am using the HT-Soft 7.83 C compiler and the PIC17c756 chips. The code
compiles ok, I think. The problem I am having is with large files, it does
not return any memory usage data. I use the same command line on a small app
and it will return the data but not on large files, why is that?

Large file command line and returns:
-------------------------------------------
Building 17C756.HEX...

Compiling 17C756.C:
Command line: "C:\HT-PIC\BIN\PICC.EXE -W9 -GMicrochip -D32 -E -17C756 -C
C:\PROGS\HEAD\17C756\17C756.C"
Enter PICC -HELP for help

Linking:
Command line: "C:\HT-PIC\BIN\PICC.EXE -INTEL -E -17C756 -o17C756.HEX
17C756.OBJ "
Enter PICC -HELP for help

Build completed successfully.
-------------------------------------------

Small file command line and returns:
-------------------------------------------
Building 17C756.HEX...

Compiling 17C756.C:
Command line: "C:\HT-PIC\BIN\PICC.EXE -GMicrochip -D32 -E -17C756 -C
C:\PROGS\HEAD\17C756\17C756.C"
Enter PICC -HELP for help

Linking:
Command line: "C:\HT-PIC\BIN\PICC.EXE -INTEL -E -17C756 -o17C756.HEX
17C756.OBJ "
Enter PICC -HELP for help

Memory Usage Map:

Program ROM   $0000 - $0003  $0004 (   4) words
Program ROM   $1FFA - $1FFD  $0004 (   4) words
Program ROM   $2000 - $2005  $0006 (   6) words
                            $000E (  14) words total Program ROM

Build completed successfully.
-------------------------------------------




Roy Souther
spam_OUTsilicontao_royTakeThisOuTspamtechnologist.com
ICQ# 1232391

1999\03\25@124531 by rgoodrich

flavicon
face
I have seen similar problems with this version of Hi-Tech C. I have a large
program that exhibits the same symptoms which can be fix be removing a couple of
comment lines at the beginning of one of the modules, NO CODE WAS CHANGED!.

In addition I have noticed another issue with this version of the compiler when
used with MPLAB. With previous versions, single stepping through a program
generally caused the MPLAB to step through one C statement at a time, which
generally corresponded with the execution of several assembly instructions. Now
single stepping seems to cause execution of a single assembly instruction, with
the further problem of confusion by MPLAB of which C source line corresponds to
the assembly instruction being executed. This results in each single step
causing the display to jump between source file windows to unrelated C-source
statements. This occurs in both MPLAB 3.4 and 4.0, both of which worked
corrected with previous versions of the compiler. Has anyone else experienced
this same problem with version 7.83 and MPLAB?

Roy Souther wrote:
{Quote hidden}

1999\03\25@232318 by Jim Ham

flavicon
face
MPLAB 5.00 and the HiTech C V7.83 behaves for me exactly as you describe
below. It seems clear that MPLAB cannot decode some of the debug
information provided by the linker. I've gotten an acknowledgement of this
problem from HiTech, but so far HiTech and MicroChip seem to be simply
pointing fingers at each other. It would be real pleasant if MicroChip
would wake up and understand that they are in the chip business so
supporting foreign compiler makers is in their best interest. I use a
PicMaster. It is a little clumsy since the debug info is not perfectly
understood, but I've gotten used to how it works. You can still zero in on
non-working code pretty easily. Breakpoints are put in the correct place.

I haven't seen the problem where the hex code is not produced correctly. I
have seen a perhaps related problem. Occasionally after making my project
(11 modules plus linking some libraries), MPLAB freezes. In Win95 I have to
use ctrl-alt-del to get to the task manager to kill MPLAB. Then I must
delete some (unknown which) intermediate files. I simply delete all of them
- .objs, hex. microchi. -- all the intermediate files. I then restart MPLAB
(no need to reboot), change one line in a module (insert a blank line for
instance), re-make and everything works. "Make" is a euphemism here, as
MPLAB always compiles every module. I've always considered this freezing to
be a MPLAB bug, but I suppose it could be the HiTech linker making
something that MPLAB doesn't understand. This usually happens after I've
been editing in a DOS window.

In any case, MPLAB should produce an error message rather than freezing. So
even if HiTech has a problem, Microchip has one also. The same thing goes
for the debug info. If MPLAB can't decode the info that HiTech supplies, it
should say so.

While we are on the subject of MPLAB, why do you suppose that MPLAB breaks
_after_ the line with the breakpoint? Other debuggers I've used always
broke (break?) before the breakpoint. Do you suppose there is some
technical reason? Or maybe the first version of MPLAB did it wrong and its
been like that ever since.

I'll add one more comment. Someone who is unfamiliar with the HiTech
compiler might read this and decide to use the Microchip one. Be very
careful here.  I tried to port my application to the Microchip environment
and spent _way_ too much time trying to make it work. I finally tried the
HiTech compiler and it was _easy_. Sure, there are a few problems, but on
the whole it works GREAT. I have found NO problems that will prevent me
from continuing.

Regards, Jim Ham



At 09:33 AM 3/25/99 -0800, you wrote:
>I have seen similar problems with this version of Hi-Tech C. I have a large
>program that exhibits the same symptoms which can be fix be removing a
couple of
>comment lines at the beginning of one of the modules, NO CODE WAS CHANGED!.
>
>In addition I have noticed another issue with this version of the compiler
when
>used with MPLAB. With previous versions, single stepping through a program
>generally caused the MPLAB to step through one C statement at a time, which
>generally corresponded with the execution of several assembly
instructions. Now
>single stepping seems to cause execution of a single assembly instruction,
with
>the further problem of confusion by MPLAB of which C source line
corresponds to
{Quote hidden}

striped
>> down version of the code, probably a main and a few variables just to
see if
>> anyone else gets this problem when they compile it. I will send in about 2
>> hours. Thanks.
>>
>> >From e-mail: More: Hi-Tech 7.83 and 17c756 bug?
>> I found the problem and don't know how to fix it. I have three struct's in
>> the code. One of them, if I rem it out it will compile properly and run
>> great. If I add the line back in the compiler says that it compiles ok
but I
>> don't get a memory detail and the chip does not run.
>>
>> >From e-mail: Hi-Tech 7.83 and 17c756 bug?
>> I am using the HT-Soft 7.83 C compiler and the PIC17c756 chips. The code
>> compiles ok, I think. The problem I am having is with large files, it does
>> not return any memory usage data. I use the same command line on a small
app
>> and it will return the data but not on large files, why is that?
>>
>>...
>
>
Jim Ham, Porcine Associates
(650)326-2669 fax(650)326-1071
"http://www.porcine.com"

1999\03\26@092234 by Andy Kunz

flavicon
face
>I'll add one more comment. Someone who is unfamiliar with the HiTech
>compiler might read this and decide to use the Microchip one. Be very
>careful here.  I tried to port my application to the Microchip environment
>and spent _way_ too much time trying to make it work. I finally tried the
>HiTech compiler and it was _easy_. Sure, there are a few problems, but on
>the whole it works GREAT. I have found NO problems that will prevent me
>from continuing.

My personal decision was to scrap MPLAB.  Chip vendors aren't very often
that skilled at providing GUI development tools, I've found.

Motorola and Intel have tons of 3rd party support for their products.
Microchip would do well to let MPLAB die a dignified death and be taken
over by someone who can really support it, someone who is motivated (by
hunger?) to do so.

I think the market speaks for itself - why are there several other IDEs for
Microchip's products, and all are doing quite well?

But that's just my opinion.

Andy

  \-----------------/
   \     /---\     /
    \    |   |    /          Andy Kunz
     \   /---\   /           Montana Design
/---------+   +---------\     http://www.montanadesign.com
| /  |----|___|----|  \ |
\/___|      *      |___\/     Go fast, turn right,
                              and keep the wet side down!

More... (looser matching)
- Last day of these posts
- In 1999 , 2000 only
- Today
- New search...