johnwasser:
I have not yet found that in the 328P datasheet (https://www.microchip.com/wwwproducts/en/ATmega328P). Could you tell me what section it is in? The closest text I could find is in 23.5.2 ADC Voltage Reference. It says "The first ADC conversion result after switching reference voltage source may be inaccurate, and the user is advised to discard this result." but that has to do with changing reference voltage, not changing input pin.
The sheet has changed language and look a tiny bit. 28.5 - 28.5.1 tells about changing channels but I did a stop-n-think that in all likelyhood the Arduino analogRead() won't let you violate any of that, like digitalRead() only less overall inefficient.
28.4 has 1st read after ADC start takes 25 ADC cycles is not about changing pins and Arduino analogRead() is faster than that.
I assure you that, on the AVR-based Arduinos, the serial output is interrupt driven. I've read the core code that does it. Only if interrupts are disabled and the output buffer is full does Serial.write() poll the UART status.
It's easy enough to test:
void loop()
{
Serial.println("If this text shows up, the output must happen before loop() ends.");
while(1){}
}
The text shows up for me on my Arduino UNO so it can't be being held until loop() returns.
Right. What then is that function that runs when loop() ends? We're supposed to be able to put our own in.
Was this the same before IDE 1.0?
GoForSmoke:
What then is that function that runs when loop() ends? We're supposed to be able to put our own in.
The only one currently available is 'serialEvent()'. If you declare it and if there is serial input available when loop() exits, your serialEvent() function will be called. It's like putting "if (Serial.avalable())" at the top of loop() but it's more awkward and harder to follow.
GoForSmoke:
Was this the same before IDE 1.0?
From the release notes it looks like serial receive has been interrupt driven for a LONG time but serial transmit was only made interrupt driven in 1.0.0.
johnwasser:
The only one currently available is 'serialEvent()'. If you declare it and if there is serial input available when loop() exits, your
serialEvent() function will be called. It's like putting "if (Serial.avalable())" at the top of loop() but it's more awkward and harder to follow.
Agree, and not older-user-memory-friendly, remember a name for something you can do for yourself.
From the release notes it looks like serial receive has been interrupt driven for a LONG time but serial transmit was only made interrupt driven in 1.0.0.
Apparently there were bad old days. I started on 0022 and stayed on 0023 that let me program chips until 1.5.something>3.
Serial don't get cramped then, is good.
Unless your process has analogRead() it can be divided into very light run steps done in a few hundred cycles at most and not take noticeably longer than run as a start to end block only the block don't allow other code to run smooth.