• State Not Answered
  • Locked Locked
  • Replies 24 replies
  • Subscribers 21 subscribers
  • Views 3550 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Use c51 v3.4 compiler with windows XP.

Bea Ruiz

Hello.
I'm trying to obtain a *.hex file using WXP and C51 Compiler V7.0 or upper like the file that was obtained using W98 and C51 Compiler V3.4. I have the following file *.bat:
… SET c51bin=c:\c51_v340\bin
SET C51LIB=C:\C51_v340\LIB
SET C51INC=C:\C51_v340\INC

c:\c51_v340\bin\fmake
…

But there is a problem called "stack overflow" when I execute this *.bat from DOS. The instruction "c:\c51_v340\bin\fmake" is not well received.
I try to compilate using uVision and changing the tool folders but the program doesn't respond.
I can do it using VWARE, a W98 emulator but I want to know if I can do it without this application.
Did anybody try something like this? Can anybody help me?
Thanks!

Parents
  • 0 in reply to erik malund

    I don't think people are suggesting that you can make a change with no testing at all. What they are suggesting is that most of the object code doesn't change (in a binary sense) then you're very confident you've introduced no new bugs, regardless of the test results.

    You're assuming that just because a product passes the test suite, then there are no bugs. In reality, test suites are often highly fallible, and fail to detect many bugs.

    So, new code that is only slightly different that passes regression 100% is still less likely to have new bugs than new code that's completely different from the old that also passes the same regression suite 100%. The old code has been passing the real-world test suite of actual operation, while the new code has not.

    Testing is necessary but not sufficient to insure quality.

    The second step after this one is to realize that if the old code doesn't change, for a given amount of finite testing effort, you can concentrate that effort -- not exclusively, but preferentially -- on the part of the code that didn't change, thus making it more likely that you find the new bugs. You may not want to do so -- maybe you'd rather look for old bugs, too -- but at least you have a choice. If every byte in the hex file changes, then you have to retest evenly.

Reply
  • 0 in reply to erik malund

    I don't think people are suggesting that you can make a change with no testing at all. What they are suggesting is that most of the object code doesn't change (in a binary sense) then you're very confident you've introduced no new bugs, regardless of the test results.

    You're assuming that just because a product passes the test suite, then there are no bugs. In reality, test suites are often highly fallible, and fail to detect many bugs.

    So, new code that is only slightly different that passes regression 100% is still less likely to have new bugs than new code that's completely different from the old that also passes the same regression suite 100%. The old code has been passing the real-world test suite of actual operation, while the new code has not.

    Testing is necessary but not sufficient to insure quality.

    The second step after this one is to realize that if the old code doesn't change, for a given amount of finite testing effort, you can concentrate that effort -- not exclusively, but preferentially -- on the part of the code that didn't change, thus making it more likely that you find the new bugs. You may not want to do so -- maybe you'd rather look for old bugs, too -- but at least you have a choice. If every byte in the hex file changes, then you have to retest evenly.

Children