Перейти к содержанию
    

Принять данные через COM порт и сохранить в файл

Just now, kovigor said:

По умолчанию объем приемного буфера драйвера в Windows - это всего-навсего 4096 байт. Управление потоком обязательно нужно использовать, и не только в терминалке, но и в вашей программе. Включите аппаратное управление потоком (т.е., RTS/CTS) ...

Если в больших пределах настроить нельзя, то, ИМХО, лучше свое написать.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

1 hour ago, Jurenja said:

А как насчёт другого порта и/или протокола?...

В конечном варианте весь поток будет сохраняться на CF карту.

Но пока печатная плата изготавливается, хотел по быстрому на ком порт слить.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

14 minutes ago, Arlleex said:

Если в больших пределах настроить нельзя, то, ИМХО, лучше свое написать.

Начинать надо всегда с простого. Задействуйте RTS/CTS. "Большая наука" - это если не помогут простейшие меры ...

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

1 hour ago, kovigor said:

Начинать надо всегда с простого. Задействуйте RTS/CTS. "Большая наука" - это если не помогут простейшие меры ...

Данные отправляет МК по uart (по двум проводам) на переходник USB<>COM реализованный на мс RT232R.

Предлагаете в настройках USB<>COM разрешить аппаратное управление потоком?

Это может помочь?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Не поможет. Управление потоком имеет смысл только если и источник посылок можно приостановить. Как вариант, сделать какое-то промежуточное устройство с буфером и двумя портами, заведомо не теряющее данные и без управления потоком.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

18 minutes ago, zombi said:

по двум проводам

Плохо. Очень плохо. Для RTS/CTS нужны четыре провода. Либо подпаивайте их, как это и положено, либо реализуйте XON/XOFF. Без управления потоком (лучше аппаратного по RTS/CTS, или к крайнем случае - программного по XON/XOFF) ваше соединение надежно работать не будет ...

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

9 minutes ago, rx3apf said:

Не поможет. 

Не помогло. Уже проверил.

Городить двухсторонний обмен нет ни желания ни времени.

 

А программу приёма я сам написал, но обнаружил потерю 4...6 байтов на общей посылке 256МВ.

До 32МВ принимаю без потерь.

Думал терминалку какую найти готовую.

Но как оказалось они теряют еще больше )))

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

9 minutes ago, zombi said:

Городить двухсторонний обмен нет ни желания ни времени.

Тогда придется мучиться, плеваться, материться и трепать себе нервы. Хозяин-барин ...

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

1 час назад, zombi сказал:

Предлагаете в настройках USB<>COM разрешить аппаратное управление потоком?

Это может помочь?

Не поможет.

Вы похоже слишком многого хотите от терминалок. Они обычно не пишутся с расчётом на приём таких больших потоков и внутри видимо есть баги, которые вылезают на таких потоках. Где-то немного томознула на выводе на экран или ещё в чём, а буфер в это время и переполнился. Я сам тоже как-то мыкался с подобной задачей - хотелось просто сохранить быстрый поток данных в комп с минимальными телодвижениями (в МК и компе). Перебрал многие терминалки - и ничего не нашёл стабильно работающего на больших потоках - все периодически теряли больше или меньше байт. В итоге пришлось писать своё.

Никакие управления потоками не помогут - если терминалка написана криво, и для работы с COM-портом не использует отдельные thread-ы с достаточной буферизацией в них, то стабильно работать никак не будет. А, как я понимаю, большинство терминалок такие кривые. Если не все....

Надеялся, что за прошедшее время что-то изменилось в лучшую сторону с терминалками. Но похоже что нет. Так что - только писать своё или использовать другой канал связи.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

3 часа назад, Arlleex сказал:

Если в больших пределах настроить нельзя, то, ИМХО, лучше свое написать.

Там можно увеличить очень значительно. Не говоря уже о том, что работу с каналами ввода/вывода под виндой нужно выносить в отдельные нити (thread) ОС, которые будут независимы от GUI-thread-а с его непредсказуемыми задержками. Без этого стабильно работать будет только с относительно медленными потоками. Но я предполагаю, что большинство пейсателей терминалок не парятся с этим  ;)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

58 минут назад, zombi сказал:

А программу приёма я сам написал, но обнаружил потерю 4...6 байтов на общей посылке 256МВ.

Значит - ищите баги в ней. Буфер для виндового драйвера какой ставили? Приём вели в отдельном потоке или в GUI-потоке? Как синхронизировали запись в файл с работой принимающего thread-а? какой приоритет ставили принимающему thread-у?

Какие размеры буферов ставили в SetupComm()? Какие значения таймаутов ставили в SetCommTimeouts()?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

У FT232RL объем приемного буфера составляет 256 байт, на скорости 2M он заполнится за 1.28мс при периоде обслуживания 1мс в наихудшем случае (USB FS).

ИМХО, не стоит рассчитывать на прием скоростного потока без потерь в отсутствие протокола и управления потоком.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Just now, jcxz said:

Там можно увеличить очень значительно. Не говоря уже о том, что работу с каналами ввода/вывода под виндой нужно выносить в отдельные нити (thread) ОС, которые будут независимы от GUI-thread-а с его непредсказуемыми задержками. Без этого стабильно работать будет только с относительно медленными потоками. Но я предполагаю, что большинство пейсателей терминалок не парятся с этим  ;)

Я почему-то предполагал, что работа с COM-портом, осуществляемая на потоках ОС, есть де-факто, ан-нет... Когда-то давно нашел пример многопоточного приложения для работы с COM под виндой, с тех пор только так и юзаю, на тот момент думал что "все так делают, так положено" =D

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

1 hour ago, aaarrr said:

У FT232RL объем приемного буфера составляет 256 байт, на скорости 2M он заполнится за 1.28мс при периоде обслуживания 1мс в наихудшем случае (USB FS).

А на скорости 3М буфер заполнится за ~0.85мс и работать не должно в принципе.

Но производитель уверенно заявляет : Data transfer rates from 300 baud to 3 Mbaud (RS422, RS485, RS232) at TTL levels.

Как такое возможно?

1 hour ago, jcxz said:

Буфер для виндового драйвера какой ставили?

4096 байт в настройках USB-COM если речь об этом.

1 hour ago, jcxz said:

Как синхронизировали запись в файл с работой принимающего thread-а?

никак. пишу в массив в озу. После окончания приёма сохраняю на диск.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

1 hour ago, jcxz said:

 какой приоритет ставили принимающему thread-у?

Не менял.

1 hour ago, jcxz said:

Какие размеры буферов ставили в SetupComm()? Какие значения таймаутов ставили в SetCommTimeouts()?

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...