В общем упростил схему для понимания. Ошибка сохранилась. Ошибка "Код исключения: c0000005". Попеременно чередуются с "эксепшн, кеннот рид мемори трын-дын-тын". Поиск секретным компилятором с кодом -Fадрес_ошибки ссылается на system.pas .
ComAsync удобен именно тем, что умеет отслеживать символ окончания посылки и знает сколько символов пришло. Видимо виноват он, но может можно как-то его приструнить? На одноядерном компе проблем не заметил. Буду рад любым подсказкам...
code_32984.txt
Этот топик читают: Гость
Ответов: 704
Рейтинг: 7
|
|||
карма: 0 |
| ||
файлы: 1 | code_32984.txt [3.5KB] [291] |
Ответов: 8948
Рейтинг: 824
|
|||
[b]Neo[/b], а такой есть?
|
|||
карма: 19 |
| ||
Голосовали: | Neo |
Ответов: 704
Рейтинг: 7
|
|||
Леонид, сейчас поставлю и проверю на нем.
------------ Дoбавленo в 23.00: Может я не знаю чего-то? Вроде начинает работать, и все заканчивается разрывом ответов даже в синхронном режиме приема. Может ему буфер какой нужно соорудить? А иногда тупо не отвечает ничего на сообщение. Видать буферы забиваются обрывками... ComAsync в в этой же схеме таких ошибок не дает. Только с двумя ядрами у него проблемы. ------------ Дoбавленo в 00.20: Выходит что ответ режется иногда. И дальше программа шлет новую команду, пока еще передается старая - ошибка на девайсе. COMEX неправильно определяет конец ответа. ![]() |
|||
карма: 0 |
|
Ответов: 8948
Рейтинг: 824
|
|||
Neo, почитайте соседнюю тему COM с управлением потоком XON/XOFF, вдруг поможет
![]() |
|||
карма: 19 |
|
Ответов: 704
Рейтинг: 7
|
|||
Эта схема решает проблему когда com режет ответы. Тестирую на баги с COMEX
![]() code_32985.txt ------------ Дoбавленo в 16.18: Глупости это были, то неправильная схема. Вот кубик, который ставится на выходе из порта и выпрямляет кривые ответы. Окончание здесь по символу 13.
|
|||
карма: 0 |
|
5