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
  • 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.

Reply
  • 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.

Children