Best way to count square wave pulses from circuit in Windows app—USB, serial, or GPIO?

I have a circuit design that outputs a square wave pulse; I want to record this information (press start and record number of pulses until stop) in some kind of basic windows application.. any thoughts on the I/O Scheme? I am thinking some kind of serial to usb adaptor, but I think there are probably easier ways...

Advice please!

Questions:

1. If all you want to do is count pulses, how about using a counter, or making one using something like the CD40110?
2. When you say, "basic windows application" do you mean a "simple" windows app or something like a Visual _Basic_ application? If the later, consider using RobotBASIC: http://www.robotbasic.org/ and then, yes, a serial to USB converter, or just a USB device that exposes one or more ports.
3. How about the Pololu datalogger: http://www.pololu.com/catalog/product/1623
4. What is the hi/low voltage, frequency, etc.?

Basically, it sounds like you're talking about a Data Logger. Something like:

http://www.testequipmentdepot.com/lascar/dataloggers/el-oem-3.htm

Steve,

Thank you for the quick reply!

The best solution I can see (thank you for validating it) is using a serial/usb cable as I have one already; I just need to determine the best means of collecting the data; do you happen to know if robotBASIC has limitations in terms of data retrieval frequency? What I would probably end up doing is writing code which will do something simple like this:

do
(query serial input#) /I don't know the coding for this
if query == high then count=count+1
loop until press$="q"
print count

I've never dealt with much intersystem I/O; is my approach way off base? It's ok, feel free to correct me

Is your cable an RS232-to-USB, or is it a USB with something like TTL inputs?

If I were designing this, especially if a high sample rate it required, I would use an RS-232 to USB (or SPI-to-USB or I2C-to-USB) cable along with a microcontroller. The microcontroller would monitor the input and accumulate rising edge or falling edge counts in an interrupt routine, and then send that sum, upon request, to the PC via the USB connection.

I might even consider using a "USB enabled" microcontroller, and by-pass the serial-to-serial converter (i.e. connect directly to USB).

But, if that's outside your experience domain, then what you are proposing should work, as long as the sample rate doesn't need to be too high -- but, no, I don't know what that threshold is. Perhaps you could contact the RobotBASIC people (or maybe they have a forum).

I also don't know if RobotBASIC can service interrupts from the USB port (probably more like an "Event"), but, if so, that would be the way to go.

I believe the one I have is RS232 to USB, but I could get any type for reasonably cheap. The kinds of cycle times I am looking at would be on the order of a 'sample' once every 20 miliseconds, which does not seem like a lot in retrospect.

A friend of mine suggested using an ardunio controller to regulate I/O, which also seems like a viable option, he also mentioned a usb to serial controller PCB, which came with a usb jack and had pinouts for various logical I/Os, which seemed ideal, although I know nothing about coding for that kind of PCB.,

Well, if you are willing to go the Arduino route, then I would think that be a fine solution. I've never used it, but I've read about it, and it seems to be designed for the beginner in mind and there is LOTS of support.

* http://arduino.cc/playground/Main/InterfacingWithSoftware
* https://www.google.com/search?q=arduino+shields&ie=utf-8&oe=utf-8&client=ubuntu&channel=fs [there are "shields" for just about everything!]

I still think the best way to do this is to task a microcontroller (e.g. an Arduino) with data collection and processing (i.e. the summing), and only involved the PC when there is a request to display the count. Even if you want to display a running count, it makes more sense for the PC to make an automatic request every second or so, otherwise, it's going to display an unreadable blur.