I have a page on the subject that may help.

Peter, that seems to describe what is happening. For me, the question is answered and I guess I'll have to just comment out that #include in addition to setting the #define false. Thanks for everyone's help.

Not exactly.
I'm trying to save the 1244 bytes that Wire.h adds to the sketch even when it's not defined.
The fact that it's not "compiled in enough" to satisfy Wire.begin is interesting, buy if you try the sketch as I have it in the first post,
compile it and note record the sketch size,
and then comment out the #include and note the sketch size again, you will see a 1244 byte difference.

I'm using this construct in another sketch that is close to the wall, and I'd like to avoid this overhead by setting a #define.
That's what I'm trying to achieve but it's looking unlikely.

Thanks Keith, I appreciate your help.

I tried adding

Code:

/*
 * BOF preprocessor bug prevent
 * insert me on top of your arduino-code
 */
#define nop() __asm volatile ("nop")
#if 1
nop();
#endif
/*
 * EOF preprocessor bug prevent
*/

before the sketch I first posted with the same results - 1710 bytes and 466 bytes if the #include is commented out.
Unless I missed something in that example, that should be the workaround.

It appears that the precompiler makes one pass and seems to handle #includes before #defines.

The sketch I posted is the entire sketch.

Like this?

Code:

//#define ADD_WIRE

#ifdef ADD_WIRE
#include <Wire.h> // <<< can only comment out to not include
#endif

Same thing.

Just a simple question for those who know more.

Given this code

Code:

// This construct doesn't work. Wire.h will be included no matter what.
// So 1244 bytes are always added unless the #include is commented out.

#define ADD_WIRE   false

#if (ADD_WIRE)
#include <Wire.h> // <<< can only comment out to not include
#endif

void setup(){
}

void loop(){
}

I was surprised to find that Wire.h is always included regardless of the setting of the #define.
If it's not the right way to do this, is there a way that works?

Just FWIW, here is a solar powered wireless radiation monitor with build information.

That sounds good.
You can download it here
https://dl.dropbox.com/u/3572198/X10.zip
Example should explain it enough to get you going.
John

Quick reply . . .
I've been testing some libs from the guy who was kind enough to do the integration. The receive function seems to be working fine, but I seem to have reliability issues with the original send functions. I need to test more but I have been busy.

For some reason the X10 lib has been changed to follow the Wire functions and the repeat parameter was removed. He added repeat back in, but transmit still seems inconsistent to me.

Maybe I should post what I have and get another opinion on it.
John

I can't figure out why the TM751 would be safer than the TW523 but experiences vary.

I've been completely satisfied with my 'home automation' for several years now. Consequently I don't get out much anymore regarding X10.
However I was surprised to see that the PSC05/TW523 have all but disappeared in my absence. Those left seem to sell at scalping prices.

Enddoc, please feel free to use whatever you wish from my blog under the condition that you don't call me Mr. ;-)

BTW, I have been working with someone who is adding my PSC05/TW523 'receive' code into Tom Igoe's x10.lib. Finally, send and receive will both be in one lib.

John

There are several other ways to skin that cat without resorting to the CP290.

http://brohogan.blogspot.com/search/label/Home%20Automation

Yes it will.

@flamturpolt

I've been writing Geiger counter SW for quite a while now. Indrek's circuit should work with what i have, when connected as Mike suggested. (It would connect to INT0 - pin 2) Your welcome to take a look at it on this page.

It uses a rolling average for CPM, and has lots of goodies. I expect it should just drop in. Should give you some ideas at the least.
John

Note: The Digikey link given is for the non-"P" version. It's tricky . . .
ATMEGA328-PU-ND != ATMEGA328P-PU-ND