День добрый.

Подключил плату-реле (http://www.kernelchip.ru/Ke-USB24R.php) к SK-AT91SAM9260. В устройство ttyACM0 пишу команды (к примеру $KE и завершаю кодами 13 и 10). Первая команда выполняется (получаю ответ #OK), а на последующие команды реле отвечает только #ERR не выполняя при этом команд.

Программа на Си++
// подключение
this->fd = open("/dev/ttyACM0", O_RDWR | O_NOCTTY | O_NONBLOCK);

// Установка параметров порта
tcgetattr(this->fd, &portoptions);
portoptions.c_cflag |= B9600; // 9600 скорость, хотя ему вроде всё равно
// Без контроля чётности, 8 бит, 1 стоповый
portoptions.c_cflag &= ~PARENB;
portoptions.c_cflag &= ~CSTOPB;
portoptions.c_cflag &= ~CSIZE;
portoptions.c_cflag |= CS8;

// выключить аппаратное управление потоком
portoptions.c_cflag &= ~CRTSCTS;
// Отключаем мэп CR в NL
portoptions.c_iflag &= ~ICRNL;
portoptions.c_oflag &= ~OCRNL;

tcsetattr(this->fd, TCSAFLUSH, &portoptions);

....
// передача команды
char command[6] = "$KE";
command[3] = 13;
command[4] = 10;
command[5] = 0;

printf("command: %s\n", command);

count_byte = write(this->fd, command,5);

printf("I write %d byte\n", count_byte);

....
// Чтение ответов
count_byte = read(this->fd, buffer, 1023);

write успешно отправляет указанное количество байт. read читает ответы от платы.
Только плата обрабатывает только первую команду.

И главное. Тот же код отлично работает на обычном компе (x86 + Linux), но на плате (ARM9 + Linux) нет.

Что может быть?
Где искать причину?

Цитата

И главное. Тот же код отлично работает на обычном компе (x86 + Linux), но на плате (ARM9 + Linux) нет.

А какие версии ядер на компьютере и на плате ?

а вы подаете пачку команд, потом читаете ответы?
попробуйте парами "команда-ответ".
может реле отработать команду не успевает, получая уже следующую?
попробуйте посылать к конце команды только 13, только 10, поменять местами, ничего не посылать.
программу запускаете из консоли или в rs.S или из inittab?

Проблема похоже решилась. Методом написания того же другим человеком.
Разницы в:
1) вместо одного открытия файла делаем два (отдельно на чтение и запись)
2) сразу после записи закрываем "файл" устройства. Без этого точно не работало
3) сразу после чтения ответа закрываем и второй "файл"
4) read и write заменили на fputs_unlocked и fgets_unlocked
5) убрали секундную задержку между записью команды и чтением ответа. Без этого тоже не работало.
Возможно что-то из этих пунктов на работу и не повлияло. Завтра попробую проверить.

Тут бы не мешало спросить - вы читали чтонибуть по теме работы с последовательным портом в linux ? то что вы описали в 1-5 это какой-то лютый изврат. Вам во первых нужно установить raw режим, во вторых использовать что-нибуть из серии poll/select при ожидания ответа. Я думал у вас драйвер не работает а вы там садомазо занимаетесь :)
http://cisco.opennet.ru/docs/RUS/serial_guide/

sasamy, эту статью я тоже читал (правда через строчку).
Вообще у меня это первый опыт с платами на ARM, с "периферией" (у меня тут кроме реле еще RFID есть, клавиатура (пока обычная USB), в планах что-нибудь вроде PIN Pad-а вместо клавиатуры, GPS еще в SIM508). Да и под Линукс я особо тоже не программил. Так что извращений еще много предстоит.
У меня пока цель "написать лишь бы работало" и показать прототип заказчику. "Как лучше" буду потом делать по мере развития мозгов.

Кстати, может кто-нибудь расскажет или ссылочку даст: чем отличается программирование виртуального COM-порта и настоящего?

В общем, путем исключения выяснил, что пункты с 1) по 4) не имели ни какого значения, а к ошибки приводила секундная задержка между записью команды и чтением результата.
count_byte = write(this->fd, command,13);
//sleep(1);
count_byte = read(this->fd, buffer, 1023);
За две недели все самые идиотские предположения проверил. Но на sleep ни разу даже не подумал :(

а буфер для чтения был какого размера?

Valentinus, если вы про мой буфер в count_byte = read(this->fd, buffer, 1023); то таким и был (1024 байта).
Если речь о каком-то другом, то где смотреть?