Jump to content

    

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

Just now, kovigor said:

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

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

Share this post


Link to post
Share on other sites
1 hour ago, Jurenja said:

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

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

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

Share this post


Link to post
Share on other sites
14 minutes ago, Arlleex said:

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

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

Share this post


Link to post
Share on other sites
1 hour ago, kovigor said:

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

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

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
18 minutes ago, zombi said:

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

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

Share this post


Link to post
Share on other sites
9 minutes ago, rx3apf said:

Не поможет. 

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

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

 

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

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

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

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

Share this post


Link to post
Share on other sites
9 minutes ago, zombi said:

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

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

Share this post


Link to post
Share on other sites
1 час назад, zombi сказал:

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

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

Не поможет.

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

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

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

Share this post


Link to post
Share on other sites
3 часа назад, Arlleex сказал:

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

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

Share this post


Link to post
Share on other sites
58 минут назад, zombi сказал:

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

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

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites
Just now, jcxz said:

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

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

Share this post


Link to post
Share on other sites
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-а?

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

Share this post


Link to post
Share on other sites
1 hour ago, jcxz said:

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

Не менял.

1 hour ago, jcxz said:

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

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now