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

Improper fixup

Hi

I am receiving:

*** ERROR L121: IMPROPER FIXUP

MODULE: C:\KEIL\C51\LIB\C51C.LIB (PRINTF)

SEGMENT: ?PR?PRINTF?PRINTF

OFFSET: 0068H

I have tryied to read threads about this, but cannot understand it since it appears in a .LIB file

Any help? Really needing it.
Thanks for your time
Dario

Parents
  • Erik,

    Since you insist, I'll give you one final comment on the subject ...

    You appear to be so blinded by your own 'I do efficient' self-belief that you simply ignore the real point which I've been making.

    I will not just keep repeating the same statements in different ways just to give you something to whinge about.

    Please read my previous postings - You might actually learn something.

    ps For some reason, when seeing your posts, the words old dogs and new tricks keep springing to mind! I wonder why?

    The end.

Reply
  • Erik,

    Since you insist, I'll give you one final comment on the subject ...

    You appear to be so blinded by your own 'I do efficient' self-belief that you simply ignore the real point which I've been making.

    I will not just keep repeating the same statements in different ways just to give you something to whinge about.

    Please read my previous postings - You might actually learn something.

    ps For some reason, when seeing your posts, the words old dogs and new tricks keep springing to mind! I wonder why?

    The end.

Children
  • During my MS-DOS programming days, I now and then made use of the compact, medium or even large memory models. I understand that this makes me unworthy of continued posting on this site.

    The only thing I can say to my defense is that I never used the huge memory model. Just a huge-declared array now and then, when I really needed it.

     * 5A3266E3-82B2-4DCB-8A0C-23BE1236021C walks shamefully home with tail between legs.

  • You appear to be so blinded by your own 'I do efficient' self-belief
    whether I do efficient (which I do) or not is totally irrelevant. The point is that '51 code should be efficient. Of course if the choice of the '51 for a given app is wrong in the first place, then any point about '51 code is moot.

    Since you insist, I'll give you one final comment on the subject ...

    You keep giving me comments how about an answer!!!

    from last post: You stated that the above problem was a fault of my design and to that I replied "please advuse how to predict which deviations from the standat=rd an unknown (maybe not even made yet) product x will have"

    That you have never answered Instead you keep inmsulting me by stating that such a problem is a fault of my design ("that would be serious indication of poor quality").

    Erik

  • During my MS-DOS programming days, I now and then made use of the compact, medium or even large memory models. I understand that this makes me unworthy of continued posting on this site.

    Not at all, my comments re memory model are strictly related to the '51 where the architecture makes the penalty for choosing the large model many times more severe than for e.g. an x86.

    Also an x86 app is typically a "processor" rather than a "controller" app and who gives a hoot if a "process" is complete im 10uS or 10mS. for a "controller' app that, however can be the difference between success and failure.

    Erik

  • During my MS-DOS programming days, I now and then made use of the compact, medium or even large memory models.

    Whoops - Now you mention it, so did I.

    Oh dear, that must make me a habitual un-optimized coder ;)

  • The point is that '51 code should be efficient.

    Why?

    If I have a 9600 baud serial port, it doesn't matter if the code is capable of handling 20k characters/second.

    If I need to read a voltage every second, it doesn't matter if the ISR is able to process 8k samples/second or not.

    If the application fits in available memory, it doesn't matter if there is 1kB or 10kB code space free.

    Only if the application hits (or may hit) a limit is it meaningful to make a decision if it is better to try to squeeze/speed up the code, or switch to faster/larger iron.

    The main thing is to write correct code that is also easy to maintain. The need for optimization is more a project-to-project decision, depending on the requirements.

    In some cases, the customer may want a new "applet" or feature within a couple of days in a unit with remote update capability. They may want to show off a "cool feature" on a fair.

    In some cases, the code may be expected to run unchanged for many years in multi-k products which would require transport to factory if they contain a major error.

    In some cases it is ok to switch to a $100 more expensive processor since the end product may cost $10k will all external hardware, making the processor price insignificant.

  • Oh dear, that must make me a habitual un-optimized coder
    not at all, as I replied to Per, what you did with DOS (hopefully) has no bearing on what you do with the '51.
    I, for one, do not apply the same practices to an ARM as I do to a '51, e.g. while I consider using a RTOS for the '51 totally ridiculous, I see nothing wrong with using one on an ARM.
    I do not recall what I did in my DOS days, but may, very well, be as 'guilty' as you.

    Erik

  • I, for one, do not apply the same practices to an ARM as I do to a '51, e.g. while I consider using a RTOS for the '51 totally ridiculous, I see nothing wrong with using one on an ARM.

    On that point, I would certainly agree.

  • The point is that '51 code should be efficient.

    Why?

    If I have a 9600 baud serial port, it doesn't matter if the code is capable of handling 20k characters/second.

    If I need to read a voltage every second, it doesn't matter if the ISR is able to process 8k samples/second or not.

    If the application fits in available memory, it doesn't matter if there is 1kB or 10kB code space free.

    all the above is (partially) correct; however applying such thinking will, very likely, hit you in a large muscle when the next feature is to be added for MKII of your product.

    Also, if you habitually code efficient, you will not have to 'fight' when a project comes up that absolutely require efficient coding.

    In some cases it is ok to switch to a $100 more expensive processor since the end product may cost $10k will all external hardware, making the processor price insignificant.
    Absolutely, I have always stated "use the right processor for the job, do not try to make the '51 an 'universal' solution".

    Erik