The code given below with the date from 2013 in the constant string was complied and exectued correctly in Februar 2013. SAB80C535 and LCD Modul in eight Bit Modus.
Today with the changed date for next year the code was compiled and linked witout any error message but does no longer execute properly on the hardware. Either the the display is not initialzied or the float value is not written to the dispaly or the float value is zero.
If the float operations are deleted, the remaining programm is executed properly.
If only sqrt is computed and written to the string, the string is correctly written to the display. All other char strings and their LCD operations deleted.
Compiling is in Large Code and Large Memory Model. Compiler is the same as in February. The SAB 80C535 has 56k external RAM. Hardware the same as before.
No clue what has happend since February. The project is unaltered in folders, projectfile and so on, except for the content of the one constant string with the date. And the length of the string is 19 characters plus /n as before.
#include <reg515.h> #include <lcd.h> #include <math.h> #include <stdio.h> void main(void) { char select; float x; xdata char zeile1[20] = "Berufskolleg Hilden"; xdata char zeile2[20] = " 15. November 2014 "; xdata char zeile3[20] = " Kreis Mettmann "; xdata char zeile4[20] = " IT-Abteilung "; xdata char zeile5[20] = " Mikrocontroller "; xdata char zeile6[20] = " Digitaltechnik "; xdata char zeile7[20] = " Schlüsselverfahren"; xdata char zeile8[20] = " "; init(1,1,0); display_on_off(1,1,0); entry(1,0); home(); clrscr(); lcdadr(0); datschreib(zeile1); lcdadr(63); datschreib(zeile2); lcdadr(20); datschreib(zeile3); x = sqrt(2.0); printf(zeile8 , "%14.6f" , x); do { switch(select % 5) { case 0 : { lcdadr(84); datschreib(zeile4); warte(2000); break; } case 1 : { lcdadr(84); datschreib(zeile5); warte(2000); break; } case 2 : { lcdadr(84); datschreib(zeile6); warte(2000); break; } case 3 : { lcdadr(84); datschreib(zeile7); warte(2000); break; } case 4 : { lcdadr(84); datschreib(zeile8); warte(2000); break; } } select++; }while(1); }
Inhalt von lcd.h
void warte (unsigned int zeit); void init(bit D, bit N, bit F); void clrscr(void); void home(void); void entry(bit ID, bit S); void display_on_off(bit D, bit C, bit B); void datschreib(char *z); void lcdadr(char a7);
Thnak you very much for your hints.
Hardware is unchanged. It is a teaching system from hps, already in use since 2000. The LCD Modules are those which we use for the last five years.
As said, testing in parts, first without floating point, all writng to the LCD works fine. Second test floating point sqrt alone with sprintf works fine.
Combination in the old file does not longer work.
To the best of my knowledge, the compiler is unchanged. There is no auto update I believe. I have no rigths to install software. That is done by the admin.
What I can see is, that the HEX files are no longer identical in there beginnings. But I have no explanation why. It is not possible to post the complete hex-files.
The complete HEX-Files are just 12k. 11.4k or 11.5k
Old Hexfile from 2012
:0417EB004100D600E3 :10177B00E4FDFCC3ED9FEC9E5015E4FBFA0BBB00A4 :0F178B00010AEB64374A70F50DBD00010C80E4D4 :01179A00222C
Old Hex File >b>2013
New Hexfile 2013
:10150D002531342E3666004265727566736B6F6CCD :10151D006C65672048696C64656E002031352E203E :10152D004E6F76656D626572203230313420002049 :10153D0020204B72656973204D6574746D616E6EFC :10154D002020002020202049542D41627465696CB3 :10155D00756E67202020002020204D696B726F630F :10156D006F6E74726F6C6C65722000092044696730 :10157D006974616C746563686E696B20200000206E :10158D005363686CFC7373656C7665726661687223 :10159D00656E0020202020202020202020202020CB :0715AD002020202020200077
to the best of my knowledge, the compiler is unchanged try to deoptimize, set it to 2. If your timing stinks, that could be the cause. If it is, fix your code.
Erik
What I can see is, that the HEX files are no longer identical in there beginnings. Comparing hex files as raw text typically only works well to answer the question "is this code exactly the same as that?" Once the answer to that is "no", you have to look at other files or use other tools to find out what those differences are.
The primary place to look at is the map file. Usually some functions and variables will have stayed in the same place, while some others have moved. E.g. as soon as a single function's size changes, all functions behind it in memory move around, causing a large number of benign differences in the hex file. The same happens if any variable's size changes (possibly to zero, because it's optimized away).
But in the end, all this only works to find small changes to the executable code. Which brings us back to things you'll have to check for yourself:
*) you have to look at all changes made to that program's source code over time. Without a properly working revision control scheme in place, that'll be hard. *) you have to debug the non-working code on real hardware, to see what exactly goes wrong. Inspect variables just before and after that sprintf() call, step into functions to see what they're doing, etc.