I dunno what version you are using. I use the old version, without the X.
I am pretty sure I have experienced something potentially similar/same. And I believe it happens whenever:
1.file>save as...
2. the window opens, and the name of the original file is at the bottom under "file name:" in blue highlight. Let's say the name of this file is "header file."
3. But instead of changing the name there to "header file v2," by keyboard, I instead click on another copy I have made of this file which was named "header file v1," as if I want to save over it... but actually I just did it in order to make "header file v1" pop up so I could edit just 1 number, if you know what I mean?
I can't be positive this is related. But this is something I obviously avoid doing, now.
*And no, I don't know how to fix it, after the fact. To this day I have some major projects where I can't change the file name... I assume I could fix it by building a new project, but meh...
One workaround I happen to prefer anyhow is to use directives to conditionally assemble (I assume works same for compiling; it's been a long time since I compiled any C code):
single universal header file.inc
If headerfile.revision.constant == 0x01
(header file for revision 1)
endif
if headerfile.revision.constant ==0x02
(header file for revision 2)
endif
Then at the top of my main code page, I define these constants.
Constant headerfile.revision.constant = 0x01 ; note to self: valid range 0x01 to 0x02
On the surface, this is more work. And it makes the code less legible (in assembly, it's not particularly legible, to begin with) But on to the pro's:
This is especially nice if, say, most of the header file is the same, anyway. And there are only select changes that need to be made. When you edit the header, you have access to all variations in one file. Most importantly, and this is the real key, is that all your "options" (assembly/compiling variants which in my case have included memory defines, code, eeprom initialization, even device type, etc etc in order to cover firmware variations, board revisions, and component changes) are contained in one place within your constant defines in your main code file. Whereas your actual "#include"'s would have to be scattered around to their respective places. And chasing them down would be annoying. You may even forget these options exist unless you say document their existence at the top of your main code page.... which is also where you can simply place these constant defines.
Home
Help
Search
Login
Register
