Для последующего контроля необходимо записывать ~6,5Mbaud непрерывный поток по RS485 на ПК под управлением Windows. Отображать - опционально. Суммарный объем передаваемых данных - не больше 500МБ.
В качестве приёмника используется плата, которая точно умеет 18Mbaud в одиночных и коротких посылках и настраиваемое по уровню заполнения fifo прерывание.

Откинув ПО, которое не умеет в произвольную символьную скорость, из широко распространённых остаются putty (и его форки) и terminal от bray++, но они вешаются (с прерыванием логирования) при визуализации данных.
Мож кто что подскажет?

Подсказать что? Берёте visual studio (например) и пишете всё что надо.

Из готовых терминалов что подойдет можно определить только тестированием.
Потому как они скорее всего не "гонялись" на скоростях более 115200.
----
Если надо сделать логгер - то самый простой и гарантированный способ - написать свою утилиту
для приема таких массивов. Чтобы прикладная программа успевала по приему и записи на высоких скоростях,
возможно надо запускать ее с приоритетом "реальное время". Хотя могобыть и с "нормальным" будет успевать.
(вообще надо чтобы работа с драйвером COM шла с "реалтайм", а запись буферизированных данных - с "норм", 2 буфера).
Могобыть я и не прав, но мой самопал работает так. (но скорость 57600, приоритеты не менялись)
ps
Чтобы "успевало" не надо это реализовывать с GUI.
console / Win32 + ввод с клавиатуры ESC.

Вы из какого года пишете? В нашем 2017-м скорость в 6МБит/с даже для ПК десятилетней несвежести - вообще ни о чём. Хоть по UART хоть с диском.


Надо. Гуй тут не при чём. Если быдлокодер каждый принятый байт будет обновлять многомегабайтный битмап, который будет потом пытаться отображать на экран после каждого байта, то виноват тут явно не гуй.

За год точно не скажу, но помню - это было на "рассвете" Windows-XP.
---
А GUI - не GUI - это на усмотрение ТС, с учетом Ваших замечаний.

в общем, допишу то, что стёр в заглавном посте..

есть несколько проблем с 1+Мбс потоками с uart..
драйвера у тупых устройств выкидывают прерывание по условию буфер не полон (ибо буфер маленький) и я упираюсь в скорость обработки прерываний windows (ибо прерывание по каждому символу).. расчехление mvs и использование стандартных api приведёт ровно к этому же. ethernet пропускает больший поток, ибо, как правило, прерывание идёт по фреймам, которые несколько больше одного байта...
вторая трабла: большинство виндовых терминалов кидают "drawcall" по каждому принятому символу..

как правильно делать, я понимаю: аллоцировать память, складывать туда всё по dma, после окончания передачи и/или по команде пользователя этот массив медленно и верно складывать на накопитель. только вот глобальная проблема на этапе "складывать туда всё по dma" даже при условии настраивания в драйвере условия "взвода" прерывания..


и даже на такой скорости про больших посылках всё зависает, проверено неоднократно при попытке сдампить fw по cat mdt0

Я не знаю про какие тупые устройства Вы говорите, но я например в последнее время почти всегда отлаживаю свои устройства с логом на 921600бод.
Это идёт либо на обычный USB-UART переходник (FTDI, CP2102, ...) либо на COM-порты на PCI-плате.
И каких-то проблем не наблюдаю.


Быстрые современные UART как правило имеют довольно приличное FIFO и срабатывание прерываний там можно выставить по определённому уровню. И явно не побайтно.
Вот на компе, с которого я сейчас пишу, стоит PCI-ая COM-мультипортовка на 4 порта, с максимальными скоростями тоже вроде около 10МБит (или выше - не помню уже). В свойствах указано "16C950 High Performance UART".
В настройках портов у неё указан размер FIFO (RX/TX) =128байт. И уровни срабатывания прерываний можно выставить какие угодно.
И я очень сомневаюсь, что устройство на 18 Мбод будет генерить прерывания на каждый символ (с частотой больше 1МГц) и чтобы нельзя было уменьшить эту частоту выставив соответствующий порог в FIFO.
Да и в любом случае, даже если это было бы так, то нагружалась бы система (частыми вызовами ISR), а не задача. Задаче-то какая разница с какой частотой процессор в прерывания дёргается? Вы под виндой с уровня приложения не имеете к этому доступа.


Какое DMA? Вы вроде под программирование под виндой рассуждаете.
Правильно напишите поток (отдельный от потока GUI), который в цикле вызывает WinAPI-шную ReadFile(), которая складывает полученные данные в кольцевой буфер и опять читает ReadFile().
Это и будет ваше DMA.
Для работы с COM-портами нет никакого смысла лезть в дебри написания своих драйверов для винды - штатные вполне нормально работают.

Вот чесслово, непобрезгуйте, потратьте время на эту ReadFile() и даже на ReadFileEx().
Это самый короткий вызов на драйвер, и соответственно быстрый.
Функция должна работать в "блочном" режиме, те. не будет давать событие-прерывание
на каждый байт. Я ставлю блок 100-200 kB.
И не используйте готовых удобств в виде компонент, оберток итд.

вот поэтому вы гуру, а я спрашиваю "в помощь начинающему". у меня под виндой исключительно однопотоковые консольные приложения..

Работать с COM-портом нужно в отдельной задаче через ReadFile()/WriteFile(). Писать/читать в кольцевые буфера, а в GUI-тред передавать сообщения об изменении состояния этих буферов (добавление/удаление байт) и об ошибках. Уже GUI-тред, по мере возможности (необязательно), обрабатывает эти сообщения.
Писать поток в файл - аналогично в отдельном треде.
Тогда и не будет ничего тормозить.
GUI по мере возможности захватывает текущие участки из потока для отображения на экране. Никаких блокировок потока на время каких-то действий GUI не должно быть. GUI должен получать время по мере наличия вычислительных ресурсов, не мешая потоковым задачам.
Вобщем: в том треде, где вы тыкаете на кнопочки на экране и таскаете окошки, не должно быть никаких ReadFile()/WriteFile().