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

Memory organisaion problems

how to organize memory to avoid erratic behaivour of code during runtime?

I am accumulating input, averaging it and then calculating address from input to fetch data from multi-dimensional array in code memory.
Input is given to a particular channel, i hav given selection for type of sensor at input.
For a particular selection of sensor, I need to process the averaged input and fetch data from code array.
My code is logically correct but it is skipped during runtime after input is varied beyond a particular value, so the display freezes, but program resumes if i change the sensor type.
This erratic behaivour is observed for a particular selection of sensor type.

Parents Reply Children
  • i can see the processed values on display and input isn't out-of-range, when i execute the same code in turboc it executes correctly so i can say that code is good.

  • OR is the behaviour related to stack?

  • Turbo C is a different compiler running on a different environment.

    Turbo C follows the C requirement of always converting all values to "at least" int before making computations. C51 normally tries to avoid integer propagation since you have an 8-bit processor and the int type is 16 bit large. Integer propagation on the 8051 is very expensive, while you get it for free on a 16-, 32- or 64-bit x86 processor.

    1) Have you made sure that the numeric range is enough for your selected data types?

    2) Have you made sure that you don't get an out-of-bounds array access?

    A program that explodes is harder to debug than a program that just starts to produce bogus results - verify at what step your computations produces an invalid result.

    Start with contracts programming - each function promises to deliver a correct result if you promises to supply only valid data. Assert that all promises hare held - are all input data (not just sensor input data, but all parameters to all functions, and all global variables) holding valid information? Are all produced results (also internal intermediate results) valid?

    Starting to write skelleton code with error handling is way more efficient when tracking down problems, than to write a "working" program, and then spend time trying to figure out when/why something goes wrong.

    In a very large number of cases, your processor can be able to validate data at full real-time speed, which means you may even manage to have all validation steps active in the production code.

  • I do agree that processor types are different, and there is no point in saying that the code works on TurboC.
    But it is also true that numeric data type was selected taking care of the fact that the input does not overflow the bound of the data type and further the processing operation on input do not produce results exceeding the boundary of the data type.
    Now regarding the boundary of the array, if operations on the input produce results that exceed the boundary of the array, then the problem is simple.
    I'll hav to look a bit carefully, Thnx anyways.

  • But are you aware of the big difference involved about integer promotion? Do you have integer promotion turned on or off in C51?

  • Sorry, I am not aware of integer promotion, and if there is an option for the same how do i use it?

  • integer promotion is defined in the C standard. It is behavior that must be respected by all C compilers (at least, the not-hacked ones...!)

  • alright if c51 has a option to turn on/off integer propagation, what section of user guide should i refer for the same?

  • if c51 has an option for integer propagation how do i turn it on?

  • Have you tried Google?

    For example using the search words "keil c51 integer promotion"?

    That should tell you:
    - what integer promotion is.
    - that Keil C51 can turn on/off integer promotion
    - how to turn on/off integer promotion
    - sample generated code with integer promotion active/inactive