Hi, I'm running a small testapp to see if my 80c32 uP is running fine. Therefore, I toggle P1_0 and next to this, I'm writing a value to a var defined in external RAM. The RAM starts at address 0x0 and is 2kB long, so the end is at 0x7FF. I define those ranges via 'Options - Options for Target 'Target 1' - Target' - Off-chip Xdata memory. However, I see something very strange: when I declare my variable (for fun) at a fixed location outside the given range (e.g. unsigned char xdata testvar _at_ 0x850;), then I don't get a warning, even if I'm working outside the range. Most strange of all, the variable is written and read correctly too (I'm toggling another pin if comparison is failing and I'm observing this pin with a scope, but I don't see any toggling => value exchange seems to be correct...)! Can't understand this... Anyone any idea? --Geert
"For projects with a lot of memory-mapped peripherals (that are accessed using _at_) it does not make sense to warn the develop that they are accessing memory that wasn't specified to the linker for variables. That's one of the major reasons to use _at_." Very true. The Triscend E5 (may it rest in peace), had a lot of system registers mapped into the top 256 bytes if XDATA space - beyond the physical memory actually implemented in the silicon. One would set up the tools with the "XDATA memory size" set to the size of the physical RAM actually present - so that the tools would not try to automatically locate variables where no RAM existed. The extra system registers would be accessed via "_at_" variables - obviously one would not want the tools to give warnings for these, and one would also not want to have to "lie" about the RAM size just to be able to access them! I seem to remember that Keil "broke" this a few versions ago, which meant that we did start getting warnings for the system registers! :-( It's all fixed again now. :-)
Thanks all of you, guys. I have the picture now... It's indeed my responsibility the moment I'm starting to use the _at_ keyword. If something would go wrong, I can't blame the compiler/linker. Keil is doing it correctly: if I do another test, for instance defining an array with size 0x801, it will complain (error L 107: Space Overflow) because that doesn't fit in the available external RAM. That is, 1 byte too much in my example, knowing that RAM is located between 0x000 and 0x7FF. Should I stop having fun now??? ;-) --Geert
"Should I stop having fun now??? ;-)" Maybe you should just get out a little more... ;-)
Should I stop having fun now??? ;-) There are many fine hobbies you may find to pass away the hours between learning esoteric compiler trivia. My first suggestion would be beer tasting! It's relatively inexpensive and there are many fun games you can play with other beer drinkers. For example: who can drink the most, who can drink the most before a bathroom break, who can drink the most and still write a comprehensible and working program, and so on. Jon
"Should I stop having fun now??? ;-)" May I suggest "bar rowing" You line up 2 teams at the bar, each member with a beer. At the start signal member 1 of both teams drains his beer and hold it upside down over member 2s head, then member 2 drain his beer and hold it .... and so on. This get to be real fun if a team insist on winning (try to be member 1) Erik