"валенок"

Это один из вопиющих примеров идиотской организации интерфейса с пользователем, характерный для коммерческой продукции, ориентированной на широкую аудиторию. Если профессионал пишет для таких же, как он, не считая их глупее себя, то он даёт полный контроль или хотя бы общепринятое представление информации, а коммерческий ширпотреб такую терминологию использует и такое выдаёт порою...

Tomset91, Вид - Палитра элементов

Ок, спасиб нашёл А можно как нить сделать что бы при смене скорость порт сам инициализировался?

Это ВАША задача, кто тут у нас программу пишет? Это буквально один элемент добавить.

Да только хаб добавить

code_25989.txt
Хотя в чем проблема, так и не понимаю.
comport1.rar

С компонентом порта разобрался, теперь хочу делать программу для взаимодейсвия с ПК... Сегодня решил сделать такое: нужно вывести 7 числовых значений в разных полях на форме... Допустим контроллер отравляет строку ReadUARTStart, получив эту строку "программа ПК" понимает что после неё нужно считать 7 байт из порта и разложить каждый байт в своё поле на форме в десятичном формате (0-255). Я так понимаю что с порта нужно циклически читать по 20 байт, и только есть 13 первых байт соответствуют строке "ReadUARTStart" то 7 последующих выводим, так будет правильней? Это лишь пример алгоритма, можете предложить свой более рациональный и я опробую его в железе. Цель понять как это сделать в HiAsm...

опытом поделись

Полагаю, что надо читать порт в соответствии с установленной скоростью, полученные строковые данные склеивать с предыдущими, искать Вашу стартовую строку, по нахождении -- извлекать данные и удалять из склеенной строки обработанное.

И вот объясни -- на кой хрен это делать, если данные идут не непрерывным потоком, а, скорее всего, так оно и есть
На мой взгляд делается все проще -- постоянно читаем 13 байт, если не соответстуют нашей команде, чистим буфер и читаем дальше, если команда совпала, дочитываем остаток в 7 байт, можно не меня установку в 13 байт, все рано прочитает, но с небольшой задержкой.
Можно и 20 байт читать постоянно, будут маленькие задержки у порта на чтение, но это несущественно, тогда еще проще -- считал строку обрезал по 13 байтам, проверил на соответствие команде, совпала -- отправил остаток на обработку, не совпала -- оставил все "как есть" до следующей порции данных, следующая обработка все запишет поверх предыдущих.
Точно по такому же принципу у меня работает система уже четвертый год -- ловятся данные и затем уже парсятся и проверяются на соответствие, и, причем, не один канал, а несколько.

А я бы применил такую систему:
@ReadUARTStart=ХХХХХХХ# - где ХХХХХХХ - данные, а "@" - знак начала команды (стартовый), "#" - знак конца команды (стоповый) и читал бы по одному знаку. Стартовые и стоповые знаки можно выбрать любые, какие понравятся.
При таком подходе, команды и данные могут быть переменного размера.

Это не моё изобретение - на таком принципе делают дистанционное управление трансиверами Kenwood с клавиатуры по COM-порту.
Правда там в качестве стартового применяют комбинацию <Ctrl+C> (код 03), а в качестве стопового <CTRL+D> (код 04)

Все правильно, а если длина постоянная, то смысла читать по одному байту я совсем не вижу. Однобайтовое чтение хорошо работает с контроллерами, но в буферизированной системе смысла в этом никакого нет. К тому же, чтение строки целиком происходит быстрее, чем побайтное чтение той же строки. Я проверл разные режимы чтения, но все же остановился на фиксированном чтении определенной длины, отличной от 1 байта

nesco, ты меня извини, но подгонять все команды под 13 знаков, а данные под 7 - это идиотизм (другого слова нет).
И - это "рванное" чтение.