On Wed, Apr 24, 2013 at 11:28 PM, Ruben J=F6nsson w= rote: > So you want to check at run-time, not compile-time. > It's my intent to check at compile time. This way only the relevant code gets included (and excluded for a production build). Of course, the consequences of compile-time decisions have a direct effect on the run-time behavior :) > Perhaps you can use some of the simulator limitations (such as AD, SSP or > weak > pull-up not working) which makes some registers behave different on the > simulator or perhaps a stimulus setting on a free IO to identify the > simulator. > Good point. I had not thought of that. A last resort, of sorts, but desperation has a way of happening. On closer inspection, this is very similar to... On Wed, Apr 24, 2013 at 11:27 PM, Brendan Gillatt < brendan@brendangillatt.co.uk> wrote: > Could you try a heuristic approach at run time? Perhaps query one of the > peripherals which is not implemented in the simulator to determine if the > code is simulating or runnning on hardware. While this is a bit of a nast= y > hack (and should to be _thoroughly_ documented) it might work for your us= e. > By similarity, we'll use my answer above. What's more interesting is the way I misread it (!) the first time. I thought you said to test for the various labels for the debuggers. Unfortunately, when I ran tests for such labels, I wasn't able to detect any, but there is some evidence of labels like __MPLAB_DEBUGGER_ICD2 that appear somewhere, in some IDE, with some compiler. In such a situation, if I test for all possible debuggers and don't come up with any, I could assume it's the SIM. Although I'd expect if I could find those labels I could find one for SIM as well. If only... --=20 http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist .