are core Serial APIs implemented in C++, Java or both?

I'm using the Arduino IDE 1.0.5-r2 and made a simple sketch for my Nano (v3.0).
Using Windows 7 (64bit) and Visual Studio, made a small C# app to read/write to the Nano.

In the C# code I'd write a few bytes to the Nano, Sleep for 20 milliseconds and then call System.IO.Ports.ReadExisting(). This ReadExisting call doesn't have a timeout value but it already has a sleep before it so there should be bytes available when its called.

Only a few bytes (6) are being read/written on either end. But I noticed if I reduced the Sleep below 20 ms that there may or may not be enough time for the bytes to be available. Which seemed kind of slow from my newbie-perspective.

Which led me to my real question: are the Serial functions listed in http://arduino.cc/en/reference/serial implemented in C++?
I did a cursory look at the sources, specifically 'Arduino\hardware\arduino\cores\arduino\HardwareSerial.cpp', and found what may be the implementation for 'available()', read() and write(). But I don't see the other APIs and am probably looking in the wrong place altogether.

Is there some documentation that maps the APIs to the source directories? Does Java come into play for any of the "core" Serial APIs?

In the C# code I'd write a few bytes to the Nano, Sleep for 20 milliseconds and then call System.IO.Ports.ReadExisting(). This ReadExisting call doesn't have a timeout value but it already has a sleep before it so there should be bytes available when its called.

There are other methods in the class that tell you how much data is available to read, and there are events fired when there is data (even specific data, like a CR in the stream) to be read. So, there is no need to hope that there is data to be read.

are the Serial functions listed in http://arduino.cc/en/reference/serial implemented in C++?

C, C++, and assembler.

Is there some documentation that maps the APIs to the source directories?

No. That comes from experience.

Does Java come into play for any of the "core" Serial APIs?

No, thank dog.

The HardwareSerial objects inherit behaviors from Stream and Print:

class HardwareSerial : public Stream {

using Print::write; // pull in write(str) and write(buf, size) from Print
};

See:
Stream.h
Stream.cpp
Print.h
Print.cpp
Printable.h

PaulS:
There are other methods in the class that tell you how much data is available to read, and there are events fired when there is data (even specific data, like a CR in the stream) to be read. So, there is no need to hope that there is data to be read.

Yes that was an unrefined approach for passing data. But it was enough to demonstrate latency times.

Is there some documentation that maps the APIs to the source directories?

No. That comes from experience.

Ok

Does Java come into play for any of the "core" Serial APIs?

No, thank dog.

That IS good to know. Thanks!

johnwasser:
The HardwareSerial objects inherit behaviors from Stream and Print:

class HardwareSerial : public Stream {

using Print::write; // pull in write(str) and write(buf, size) from Print
};

See:
Stream.h
Stream.cpp
Print.h
Print.cpp
Printable.h

Thanks for the direction! I'll check them out.

But it was enough to demonstrate latency times.

I'm sorry, but sleeping is NOT a good way to demonstrate latency times. It's a great way to CAUSE latency issues.

PaulS:

But it was enough to demonstrate latency times.

I'm sorry, but sleeping is NOT a good way to demonstrate latency times. It's a great way to CAUSE latency issues.

You're right! Learned something new today. I figured that if the C# thread was sleeping for X ms, when it woke up then enough time would have elapsed for the Nano to have sent bytes back. And the bytes would be waiting to be read by the C# thread.
But as I varied the amount of sleep - the results were inconsistent. Unless it was a large value for sleep (20 ms).
So instead of sleeping I just let the thread spin waiting for BytesToRead() to indicate the bytes had arrived. And the time between sending bytes to the Nano and receiving the response is a consistent 2 milliseconds. So that is cool!
Thanks for the tip!

skippyV:
when it woke up then enough time would have elapsed for the Nano to have sent bytes back.

Two separate issues are in play here - how long it takes to send data and when the data is sent. As you have found the only way to deal with the problem reliably is to check if the data has arrived. Just like waiting for UPS to deliver your new Arduino.

By the way I can't see what difference it would make what programming language they were written in ??

...R