high speed pin high/low controlled by pc

Hey guys, I have a case in which i want to be able to control one output pin between high and low. Now this has to happen via the computer (C++).

I managed to do so via serial and high speed FTDI, but response time is still too slow. The time form when the command is sent to the arduino until it is actually set high is too big. (the arduino loop just listens on the serial in a loop without delay)

I was wondering if anyone had any ideas which kind of hardware i could use to do this. is there a possibility to set a usb pin high and low somehow? Is there something that is much faster than the arduino as in reaction time wise? all i need is one pin (5v preferably but doesnt matter) that can go high and low with as little delay as possible. Maybe a highspeed digital I/O module somebody could recommend? I tried the µCHAMELEON (http://www.starting-point-systems.com/) which seems to be a bit faster, but still not fast enough.

Cheers

You don't really say what "too big" is, but have you considered the good ol' parallel printer port?
(Yes, yes, I know not many PCs have them these days, but if the application's worth buying and discarding an Arduino for, it might be worth fitting one)

A reaction time from my C++ program to pin high of less than 10ms would be good.

Only have laptops, but maybe a parallel printer port over usb?

Ten milliseconds?
Where is your time going - that's time to fit in another Ice Age!

One character at 9600bps takes just over one millisecond to transmit.

What sort of rate are you issuing commands?

I think your problem is mis-specified to begin with. There is no guarantee that after clicking a button or pressing a key on the PC that ANYTHING happens within 10 ms. It's not a real-time operating system.

I think you need to off-load the real-timeness of whatever it is you're trying to do onto the board and off the PC.

115200 at the moment.

Actually I need a reaction time of around 1 ms.

What do you think the response time of an arduino should be with the example code below when "h" is send over the serial until pin1 is set high? I have a feeling my problem lies completely somewhere else =)

#define PIN_SWITCH 7

void setup()
{
  pinMode(PIN_SWITCH, OUTPUT);
  digitalWrite(PIN_SWITCH, LOW);
  Serial.begin(115200); // open serial
  Serial.println("Press 'h");
}

void loop()
{
  int cmd;

  while (Serial.available() > 0)
  {
    cmd = Serial.read();

    switch (cmd)
    {
    case 'L':
      {
        digitalWrite(LPIN_SWITCH, HIGH);
        delay(5); 
        digitalWrite(PIN_SWITCH, LOW);
        break;
      }
    default:
      {
        Serial.println("You must press 'h");
      }
    }
  }
}

Well, call me picky, but..

 case 'L':
..
..
Serial.println("You must press 'h");

Seriously, what Rugged Circuits said - do you need the PC?
If you do, get one with a proper real-time OS.
Could you put the prompt on an LCD connected to the Arduino, or simply light a light?
A character sent at 115200 bps takes under a 100 microseconds to transmit.

I would expect the arduino to respond within a millisecond but, as mentioned earlier, not the PC. Serial is a low priority task on a PC and there is no guarantee of how long your PC OS will take to send the character down the wire. What is triggering the action on the PC, I am curious why you need a MS reaction time.

Also remember that both your PC and Arduino have uart buffers, so guaranteeing a response time is as likely as the weather without more work on your part.

Assuming you have access to push the data on your pc,

void loop()
{
  int cmd;

while (Serial.available < 1)
{
    // Keep Checking for data
}

//Now Execute

  while (Serial.available() > 0)
  {
    cmd = Serial.read();

    switch (cmd)
    {
    case 'H':
      {
        digitalWrite(PIN_SWITCH, HIGH);
        delay(5);
        digitalWrite(PIN_SWITCH, LOW);
        break;
      }
    default:
      {
        Serial.println("You must press 'H'");
      }
    }
  }
}

That seems like it should maximize your response time.

BRuTus, why do you think that code will be faster with that extra check?

I think the fastest code (without bypassing Arduino serial routines) is this:
void loop()
{
if( Serial.read() == 'H';
{
digitalWrite(PIN_SWITCH, HIGH);
delay(5);
digitalWrite(PIN_SWITCH, LOW);
}
}

But the difference in performance between this and the code posted by the OP would not be significant. As posted above, the problem will
be on the PC side.

I am still curious what the OP is doing

Re-reading that first bit, I admit I read it wrongly. :-[

I missed the actual WHILE portion of it, even after a copy and paste.

I think the OS (as previously mentioned) is the real issue here anyways to be honest.

Well, let's qualify that statement in itself.

You are asking for a system to take a human reaction (avg ~200ms) and act on that reaction within 1ms, and only produce an actual 5ms timed event? (And even then, if they press a key other than h, you give them time to press a different key...)

Like everyone else, I'd like to know what exactly the point of the system is with those parameters.

it is mainly a proof of concept and I couldnt understand why i cant get response times closer to 1ms rather than the current estimated 150ms. I found that on the c++ side one of the biggest problems was the buffer as mentioned. Reducing this buffer to an array of size 2 brings quite an improvement. It was mainly an experiment and I was wondering where I am loosing the time. I also found the FTDI lib to be faster than windows serial, despite the same baud rates.

For those who interested, this project was about my arduino mouse trap. Being quite intrigued by the speed of these little guys I added my laptop filming everything. For fun I wanted to write a C++ program which controls the trap based on visual input. Having only a 60fps camera to begin with, speed was certainly going to be limited. However I was surprised when I noticed the delay of a very simple serial command being sent to arduino using c++. The arduino solution is of course much faster, but as I said, just for fun.

Thanks a lot for all the input.