en1gma 0 9 ноября, 2017 Опубликовано 9 ноября, 2017 · Жалоба Для последующего контроля необходимо записывать ~6,5Mbaud непрерывный поток по RS485 на ПК под управлением Windows. Отображать - опционально. Суммарный объем передаваемых данных - не больше 500МБ. В качестве приёмника используется плата, которая точно умеет 18Mbaud в одиночных и коротких посылках и настраиваемое по уровню заполнения fifo прерывание. Откинув ПО, которое не умеет в произвольную символьную скорость, из широко распространённых остаются putty (и его форки) и terminal от bray++, но они вешаются (с прерыванием логирования) при визуализации данных. Мож кто что подскажет? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 184 9 ноября, 2017 Опубликовано 9 ноября, 2017 · Жалоба Мож кто что подскажет? Подсказать что? Берёте visual studio (например) и пишете всё что надо. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
k155la3 26 9 ноября, 2017 Опубликовано 9 ноября, 2017 · Жалоба Из готовых терминалов что подойдет можно определить только тестированием. Потому как они скорее всего не "гонялись" на скоростях более 115200. ---- Если надо сделать логгер - то самый простой и гарантированный способ - написать свою утилиту для приема таких массивов. Чтобы прикладная программа успевала по приему и записи на высоких скоростях, возможно надо запускать ее с приоритетом "реальное время". Хотя могобыть и с "нормальным" будет успевать. (вообще надо чтобы работа с драйвером COM шла с "реалтайм", а запись буферизированных данных - с "норм", 2 буфера). Могобыть я и не прав, но мой самопал работает так. (но скорость 57600, приоритеты не менялись) ps Чтобы "успевало" не надо это реализовывать с GUI. console / Win32 + ввод с клавиатуры ESC. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 184 9 ноября, 2017 Опубликовано 9 ноября, 2017 · Жалоба Чтобы прикладная программа успевала по приему и записи на высоких скоростях, возможно надо запускать ее с приоритетом "реальное время". Вы из какого года пишете? В нашем 2017-м скорость в 6МБит/с даже для ПК десятилетней несвежести - вообще ни о чём. Хоть по UART хоть с диском. Чтобы "успевало" не надо это реализовывать с GUI. Надо. Гуй тут не при чём. Если быдлокодер каждый принятый байт будет обновлять многомегабайтный битмап, который будет потом пытаться отображать на экран после каждого байта, то виноват тут явно не гуй. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
k155la3 26 10 ноября, 2017 Опубликовано 10 ноября, 2017 · Жалоба Вы из какого года пишете? В нашем 2017-м скорость в 6МБит/с даже для ПК десятилетней несвежести - вообще ни о чём. Хоть по UART хоть с диском. . . . За год точно не скажу, но помню - это было на "рассвете" Windows-XP. --- А GUI - не GUI - это на усмотрение ТС, с учетом Ваших замечаний. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
en1gma 0 10 ноября, 2017 Опубликовано 10 ноября, 2017 · Жалоба В нашем 2017-м скорость в 6МБит/с даже для ПК десятилетней несвежести - вообще ни о чём. Хоть по UART хоть с диском. в общем, допишу то, что стёр в заглавном посте.. есть несколько проблем с 1+Мбс потоками с uart.. драйвера у тупых устройств выкидывают прерывание по условию буфер не полон (ибо буфер маленький) и я упираюсь в скорость обработки прерываний windows (ибо прерывание по каждому символу).. расчехление mvs и использование стандартных api приведёт ровно к этому же. ethernet пропускает больший поток, ибо, как правило, прерывание идёт по фреймам, которые несколько больше одного байта... вторая трабла: большинство виндовых терминалов кидают "drawcall" по каждому принятому символу.. как правильно делать, я понимаю: аллоцировать память, складывать туда всё по dma, после окончания передачи и/или по команде пользователя этот массив медленно и верно складывать на накопитель. только вот глобальная проблема на этапе "складывать туда всё по dma" даже при условии настраивания в драйвере условия "взвода" прерывания.. Из готовых терминалов что подойдет можно определить только тестированием. Потому как они скорее всего не "гонялись" на скоростях более 115200. и даже на такой скорости про больших посылках всё зависает, проверено неоднократно при попытке сдампить fw по cat mdt0 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 184 10 ноября, 2017 Опубликовано 10 ноября, 2017 · Жалоба есть несколько проблем с 1+Мбс потоками с uart.. Я не знаю про какие тупые устройства Вы говорите, но я например в последнее время почти всегда отлаживаю свои устройства с логом на 921600бод. Это идёт либо на обычный USB-UART переходник (FTDI, CP2102, ...) либо на COM-порты на PCI-плате. И каких-то проблем не наблюдаю. драйвера у тупых устройств выкидывают прерывание по условию буфер не полон (ибо буфер маленький) и я упираюсь в скорость обработки прерываний windows (ибо прерывание по каждому символу Быстрые современные UART как правило имеют довольно приличное FIFO и срабатывание прерываний там можно выставить по определённому уровню. И явно не побайтно. Вот на компе, с которого я сейчас пишу, стоит PCI-ая COM-мультипортовка на 4 порта, с максимальными скоростями тоже вроде около 10МБит (или выше - не помню уже). В свойствах указано "16C950 High Performance UART". В настройках портов у неё указан размер FIFO (RX/TX) =128байт. И уровни срабатывания прерываний можно выставить какие угодно. И я очень сомневаюсь, что устройство на 18 Мбод будет генерить прерывания на каждый символ (с частотой больше 1МГц) и чтобы нельзя было уменьшить эту частоту выставив соответствующий порог в FIFO. Да и в любом случае, даже если это было бы так, то нагружалась бы система (частыми вызовами ISR), а не задача. Задаче-то какая разница с какой частотой процессор в прерывания дёргается? Вы под виндой с уровня приложения не имеете к этому доступа. как правильно делать, я понимаю: аллоцировать память, складывать туда всё по dma, после окончания передачи и/или по команде пользователя этот массив медленно и верно складывать на накопитель. Какое DMA? Вы вроде под программирование под виндой рассуждаете. Правильно напишите поток (отдельный от потока GUI), который в цикле вызывает WinAPI-шную ReadFile(), которая складывает полученные данные в кольцевой буфер и опять читает ReadFile(). Это и будет ваше DMA. Для работы с COM-портами нет никакого смысла лезть в дебри написания своих драйверов для винды - штатные вполне нормально работают. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
k155la3 26 10 ноября, 2017 Опубликовано 10 ноября, 2017 · Жалоба Вот чесслово, непобрезгуйте, потратьте время на эту ReadFile() и даже на ReadFileEx(). Это самый короткий вызов на драйвер, и соответственно быстрый. Функция должна работать в "блочном" режиме, те. не будет давать событие-прерывание на каждый байт. Я ставлю блок 100-200 kB. И не используйте готовых удобств в виде компонент, оберток итд. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
en1gma 0 11 ноября, 2017 Опубликовано 11 ноября, 2017 · Жалоба Какое DMA? Вы вроде под программирование под виндой рассуждаете. вот поэтому вы гуру, а я спрашиваю "в помощь начинающему". у меня под виндой исключительно однопотоковые консольные приложения.. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 184 11 ноября, 2017 Опубликовано 11 ноября, 2017 · Жалоба Работать с COM-портом нужно в отдельной задаче через ReadFile()/WriteFile(). Писать/читать в кольцевые буфера, а в GUI-тред передавать сообщения об изменении состояния этих буферов (добавление/удаление байт) и об ошибках. Уже GUI-тред, по мере возможности (необязательно), обрабатывает эти сообщения. Писать поток в файл - аналогично в отдельном треде. Тогда и не будет ничего тормозить. GUI по мере возможности захватывает текущие участки из потока для отображения на экране. Никаких блокировок потока на время каких-то действий GUI не должно быть. GUI должен получать время по мере наличия вычислительных ресурсов, не мешая потоковым задачам. Вобщем: в том треде, где вы тыкаете на кнопочки на экране и таскаете окошки, не должно быть никаких ReadFile()/WriteFile(). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
