In this example sketch you have in setup 'Wire.begin' and 'rtc. attach.' In reference to 'Wire.begin' it is suggested that this be called only once. If you are using your serial monitor this would be called every time you opened the serial monitor.
I am using the ds323x rtc as part of another sketch. The whole sketch works fine if you don't use the serial monitor to see what is going on.
Wouldn't it be better to include before set up '#include<wire.h>' so then you would be free to use your serial monitor without interfering with the running of the program?
Would this work or do you have to do this. Upload your sketch including 'Wire.begin. Then delete wire begin and upload again. Then you are free to use the serial monitor.
The problem with this is when you turn off power to you MCU (nano) you have to go through the whole thing again. If you have '#include<wire.h>' before set up this could be avoided.
Peter, I think that you are confused
The #include statement must be before any functions involving the library, such as begin() are used and the normal place to put it is near the top of the sketch
Once the sketch is compiled and uploaded none of its code will change even if the board is powered down and restarted or reset whilst powered up
I am going to make a wild guess here, but you mention using an rtc. Is the problem that you are having that when restarted the sketch always resets the time to the same values ? This, of course, will happen if you open the Serial monitor on many Arduinos
If that is the problem then use a small sketch to set the time, upload it then do not upload another sketch that changes the time and the RTC will keep time for you based on what it was originally set to
If that is not the problem then please describe it in more detail and post your problem sketch so that we can see what it does
No problem with setting the time on the rtc Bob. You set the time and then upload it. Then you delete the time setting in set up and upload again. If you don't delete the original time setting every time you use the serial monitor the time is going to be set again to the original setting.
I can see the same problem with 'Wire.begin' which is in set up. Someone said on this forum that this should only be called once as otherwise it resets the program. This is why it might be better to leave it out altogether and just include '#include<wire.h>' at the very beginning. This is not done in the ds323x rtc example.
Opening serial monitor will reset your Arduino; that is the standard behaviour.
Which Arduino are you using?
I don't see this happening.
Here is the code for Wire.begin( ) from the avr board package which is used by boards like the uno, nano, and mega.
void TwoWire::begin(void)
{
rxBufferIndex = 0;
rxBufferLength = 0;
txBufferIndex = 0;
txBufferLength = 0;
twi_init();
twi_attachSlaveTxEvent(onRequestService); // default callback must exist
twi_attachSlaveRxEvent(onReceiveService); // default callback must exist
}
The twi_init() function which is called is here:
void twi_init(void)
{
// initialize state
twi_state = TWI_READY;
twi_sendStop = true; // default value
twi_inRepStart = false;
// activate internal pullups for twi.
digitalWrite(SDA, 1);
digitalWrite(SCL, 1);
// initialize twi prescaler and bit rate
cbi(TWSR, TWPS0);
cbi(TWSR, TWPS1);
TWBR = ((F_CPU / TWI_FREQ) - 16) / 2;
/* twi bit rate formula from atmega128 manual pg 204
SCL Frequency = CPU Clock Frequency / (16 + (2 * TWBR))
note: TWBR should be 10 or higher for master mode
It is 72 for a 16mhz Wiring board with 100kHz TWI */
// enable twi module, acks, and twi interrupt
TWCR = _BV(TWEN) | _BV(TWIE) | _BV(TWEA);
}
I don't see any resetting of the program. Calling twi_init() multiple times without any calls to twi_end( ) may waste some processor time, but I don't see any resetting.
Can you provide a link to the forum posting you saw which talked about the resets?
There seem to be possible workarounds
- Modify boards.txt to prevent serial monitor from reseting the Arduino; see Platform specification - Arduino CLI. This does not (seem to) work in IDE 2.x.
- Use a 3rd party terminal program that allows you to configure the DTR and RTS behaviour.