Serial.available fails to acknowledge received data

Development Tools IDE 1.x
1

This discussion builds on this thread (or diversion thereof).

Whilst working on another fellow's problem here, I just could not get the Pro Mini to acknowledge incoming serial information. I tied "Serial.available()" to the status LED and no matter what I threw at it using the serial monitor or minicom, fiddling with permissions in /dev and such (unnecessary), it simply would not recognise it. (But the Serial Monitor received data OK.)

So I swapped over to using "serialEvent()" setting a flag and got it working - but that is a rather crude hack for obvious reasons. I am beggared by this situation - everything else worked, I could equally simply do a "Serial.read()" and check for a "-1" flag (since I do intend to use the data on the spot) and could presumably do so in future as a workaround. I am using 1.0 and it was suggested that this could be a problem, there was clearly a library problem somewhere; it's not the PC end of things.

Subsequently, the problem has (apparently spontaneously) disappeared making it all the more difficult to determine. Continuing the discussion with bperrybap as to what is/ was to blame ...

bperrybap:

Paul__B:
there is no flow control of any sort (or at least, not hardware) on the Arduino end. Between the USB bridge (CP2102) and the Pro Mini are just two data lines - TX and RX. Unless you can explain to me otherwise, there is no way the PC can tell whether the data that goes out from the USB bridge on that single wire is being "seen" by the "Serial.available()" function or the "serialEvent()" function, yet the latter does "see" the data and the former does not.

(This really should be on its own thread)

OK.

bperrybap:
Whenever a USB to serial interface is used, there is always flow control.
[ Explanation of flow control ]
True, while the host can't tell if there is anything actually receiving the serial bit stream output, there is still the possibility of flow control as mentioned above shutting down the host output. In the case of the CP2102, it supports hardware flow control on the serial output side, which could flow control the host sending of data if the host enabled h/w flow control.
When the CP2102 is connected to an Arduino, normally the CTS line is not controlled by the Arduino, however if h/w flow control is active, the CTS input pin is active. That means that the CTS pin on the CP2102 needs to be driven properly. If not, it could cause the host to stop sending characters. If h/w flow control is not going to be used, then the CTS pin needs to strapped to ground.
If the pin has been left floating on your CP2102 board, then that could cause issues. It might unpredictably assert flow control to the host.
(Maybe that is what happened in your case)
I'd go check the CP2102 CTS line and make sure it is strapped appropriately. It is pin 23. It should be strapped to ground or connected to FTDI header pin 2. Otherwise, if the host enables h/w flow control on the device, it is likely that no characters will be sent.

I follow that you are suggesting that what I was experiencing was an entirely random association between a floating CTS input on the CP2102 and my successive tests with "Serial.available()" and "serialEvent()" which were correspondingly unsuccessful, and successful. By now, I cannot clearly recall to what extent I swapped back to "Serial.available()" at that time, though I thought I had.

Nor have I ever had such a problem downloading code. (Problems yes, all to do with that "reset" matter.)

It is notable that the Pro Mini deliberately(?) straps the FTDI ~CTS to ground though neither the Nano nor the Duemilanove trouble to do so. Of course the CP2102 is a different chip but the datasheet clearly specifies on page 10 "Notes: 3. Pins can be left unconnected when not used." and I would have thought that (since most of the modules sold have this pin either entirely unconnected or brought out to an unpopulated pinout) that there would be an avalanche of complaint if there was such a problem with intermittent operation.

{As it is presently working, there is little point in my further experimentation with ~CTS. :(}

bperrybap:
As long as you install your libraries under your sketchbook, which is the recommended way,
and point all your versions to the same sketchbook directory, then they will all share
the same libraries.

I shall look into that.

2

Paul__B:
Of course the CP2102 is a different chip but the datasheet clearly specifies on page 10 "Notes: 3. Pins can be left unconnected when not used." and I would have thought that (since most of the modules sold have this pin either entirely unconnected or brought out to an unpopulated pinout) that there would be an avalanche of complaint if there was such a problem with intermittent operation.
{As it is presently working, there is little point in my further experimentation with ~CTS. :(}

I saw that too, but it was ambiguous to me as to how to interpret it.
It is the "when not used" part that is ambiguous to me.
When not connected, it isn't being used on the serial side,
but when the host asks for h/w flow control, the host is asking to use it.
In this situation one end is asking to use it but the other end left
it unconnected and isn't using it.
My guess is that the signal will be used in this situation as the
chip has no real way of knowing that the serial side didn't
connect the pin to anything.
What wasn't stated is if the signal is internally pulled up or down
to know how it will behave with an unterminated signal.
I tested it a few years ago and h/w flow control definitely worked;
however, I never tested the specific case of leaving the pin disconnected but having
the host ask for it to be used.
I also just went through the FTDI documents. They also don't
specify what happens in this case. In their chips it is a bit
more complicated in that their chips have many configuration options
and can even be loaded with custom f/w so it can be difficult to predict
the specific behavior.
I've actually used FTDI's MPROG tool in the past to change how the pins worked
to alter the way the status leds worked to fix a "broken" design on
a USB to serial device I have.

bperrybap:
As long as you install your libraries under your sketchbook, which is the recommended way,
and point all your versions to the same sketchbook directory, then they will all share
the same libraries.

I shall look into that.
It has a been a life saver for me.
That is what allows me to do testing on many different IDE versions.
I checkout/clone and use repositories directly in my local libraries directory.
(each library is its own repo)
That allows me to do development of my own stuff and track modifications to
other libraries and it is all available to all versions of the IDE.
I have a mix libraries using git, hg, and svn although I prefer and use git
for my own libraries.
Here is my recommendation:
Wherever your sketchbook is,
create 3 directories:
hardware
libraries
sketches
added cores will go under hardware
your local directories will be under libraries
put your sketches under sketches by creating a seperate
subdirectory or even more subdirectories if you like for
organization. You must name the final sketch directory
and the .pde or .ino file the same name.
The IDE will locate everything and then if you click on [File]->[Sketchbook]
you will see your local library examples, and your sketches in a nice
heirarchy.