Does the 'millis counter' keep counting or stop counting during Serial.printing?
It keeps counting. It's driven by an interrupt. When you Serial.print you are just adding data to an outgoing ringbuffer. If that buffer is full it just sits in a while() loop waiting for the serial interrupt to empty it enough. That serial interrupt just loads the next character from the ringbuffer into the serial peripheral, which takes a fraction of a fraction of a millisecond.
majenko:
It keeps counting. It's driven by an interrupt. When you Serial.print you are just adding data to an outgoing ringbuffer. If that buffer is full it just sits in a while() loop waiting for the serial interrupt to empty it enough. That serial interrupt just loads the next character from the ringbuffer into the serial peripheral, which takes a fraction of a fraction of a millisecond.
I ask because when I watch the serial output with the Arduino serial window or with Putty one minute's worth of loop processing in my sketch takes about one minute, as timed on my stop watch. The output displayed shows the elapsed time as well and I just compare the two.
However I've been trying to write a serial reading application in VB .NET and the same output read into my VB application's window shows about 3 seconds of processing, as recorded by millis() on the Arduino, is taking nearly one minute .. such a big difference you really don't need a stop watch.
I checked the trace to see if any of the output is going missing and it isn't. It simply appears to be held up by the VB serial reader, stuck in the Arduino and the millis counter stops for a bit...
It doesn't make good reading about the SerialPort class in .NET 
You really have to read in one thread and then use another for the display. Reading a byte at a time is disgraceful - probably the context switching between threads eats up more time than the reading and displaying. Reading into your own buffer is better and reading a line at a time is almost acceptable but won't be so good for binary data which is what I eventually need to handle.
It simply appears to be held up by the VB serial reader, stuck in the Arduino and the millis counter stops for a bit
No, serial transmission takes its time, Arduino buffers just 64 characters, but on the PC side the buffer is BIG.
Arduino can easily be fast enough to send continuously at 115200 or faster.
If you read character by character in you VB main controls loop, that can take a while.
If Arduino has sent a lot in the mean time, it's all buffered on the PC ...
This is an issue of your VB.net program and you found the solution already.
michael_x:
It simply appears to be held up by the VB serial reader, stuck in the Arduino and the millis counter stops for a bit
No, serial transmission takes its time, Arduino buffers just 64 characters, but on the PC side the buffer is BIG.
Arduino can easily be fast enough to send continuously at 115200 or faster.
If you read character by character in you VB main controls loop, that can take a while.
If Arduino has sent a lot in the mean time, it's all buffered on the PC ...
This is an issue of your VB.net program and you found the solution already.
Back to original question... can we assume then the millis counter stops?
michael_x:
It simply appears to be held up by the VB serial reader, stuck in the Arduino and the millis counter stops for a bit
No, serial transmission takes its time, Arduino buffers just 64 characters, but on the PC side the buffer is BIG.
Arduino can easily be fast enough to send continuously at 115200 or faster.
If you read character by character in you VB main controls loop, that can take a while.
If Arduino has sent a lot in the mean time, it's all buffered on the PC ...
This is an issue of your VB.net program and you found the solution already.
Hmm... buffered up on the PC? if I send what would be one minutes worth of "Arduino output" but my PC says it has processed only 3 seconds does that mean 57 seconds worth is stuck somewhere? Given my observations of the output this doesn't seem right
michael_x:
It simply appears to be held up by the VB serial reader, stuck in the Arduino and the millis counter stops for a bit
No, serial transmission takes its time, Arduino buffers just 64 characters, but on the PC side the buffer is BIG.
Arduino can easily be fast enough to send continuously at 115200 or faster.
If you read character by character in you VB main controls loop, that can take a while.
If Arduino has sent a lot in the mean time, it's all buffered on the PC ...
This is an issue of your VB.net program and you found the solution already.
I've probably found out how to best use VB .NET but it isn't as good as what Putty or Arduino IDE are capable of. I wonder what they are coding in?
Putty is written (I believe) in C or C++. The IDE is written in Java with a serial abstraction layer called RXTXSerial that is written in C with Java stubs.
VB is great at creating pretty interfaces for those that are too lazy to program them manually, but I wouldn't use it for anything real 
I put a 250ms delay into the VB receiver code...
Slows to a crawl of course and millis is not incrementing... pity that. I would have much preferred it to have been different.
Excuse my ignorance but I guess that the serial communications has a 'handshake' of some sort and the code is not calling/executing an interrupt while waiting for this????
acboother:
Does the 'millis counter' keep counting or stop counting during Serial.printing?
No but the count resets to zero when the serial port is opened (auto-reset is triggered).
Is your Visual Basic code structured so the port is opened / closed often?
Port remains open.
Have reduced cross thread calls in code and can now get nearly 22secs Arduino processing for every 1 minute of real time...
A couple of questions just to clear some things up.
- Are you using Hardware or Software serial?
- If hardware, are you using an RS-232 or a CDCACM interface? I.e., Uno/Mega etc, or Leonardo?
- Can we see some example output from a proper terminal program like Putty, TeraTerm, etc. so we know what we're dealing with?
- (follows on from 3) What quantity of serial data constitutes 3 seconds of processing?
I'm testing as these messages are flying about and I think I've found the villain...
The textbox is a multi-line thingy used to display the accumulated output. Each line is appended to what is there already using
txtReceived.AppendText(sInput & vbCrLf)
but if I simply write to a single line textbox and clear the contents first with
txtReceived.Clear()
txtReceived.Text = sInput
The VB app can keep up with the Arduino... at least at 19200 baud...
You might need an Application.DoEvents to force all the text to update. Otherwise it is put into a buffer until ?
The VB app can keep up with the Arduino... at least at 19200 baud...
sure.
VB.net is about the same speed as C#, it's just a syntax many people consider ugly.
majenko:
VB is great ... but I wouldn't use it for anything real
- As soon as you open a Serial line in .net , usually the Arduino resets, and everything it sends then, is buffered on the PC side.
- You can easily read Serial data, coming in at 112500, into a memory buffer in a separate thread.
How to display this amout of data conveniently on a screen, should be solved separately. - Keep synchronisation simple, that separate thread would need delegates to access Textboxes and other controls.
Not sure if VB.net would hide such delegation behind the scenes.
Easier let a timer control access the received data in the other thread's variable
acboother:
I'm testing as these messages are flying about and I think I've found the villain...The textbox is a multi-line thingy used to display the accumulated output. Each line is appended to what is there already using
txtReceived.AppendText(sInput & vbCrLf)but if I simply write to a single line textbox and clear the contents first with
txtReceived.Clear()
txtReceived.Text = sInput
The VB app can keep up with the Arduino... at least at 19200 baud...
Sounds like appendText takes time proportional to the existing text, not just the new bit appended,
so that accumulating characters this way becomes O(N^2).
Enhanced Serial Monitor - Version 3.1.3 UPDATE - Interfacing w/ Software on the Computer - Arduino Forum for version 1 of a little serial monitor tool.
Woe woe and thrice woe... Microsoft development guys must have lost the plot... in my opinion they've made their toolsets overly complex...