[CADiLO 9]

Давайте переспросим ТС

Возможно он просто некорректно описал задачу. 

Потому что взаимодействие UART модуля с контроллером двоякое.

Для АТ команд, достаточно RX/TX и это локальное соединение модуля с контроллером, там подтверждения не нужны.

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

 

[jcxz 184]

7 минут назад, CADiLO сказал:

Давайте переспросим ТС

Спрашивали уж. Молчит как партизан на допросе в гестапо. А калёного железа, в инструментарии форума, не предусмотрено.  

Секретная видимо разработка...

7 минут назад, CADiLO сказал:

Для АТ команд, достаточно RX/TX

Кста (оффтопик, но раз уж зашёл разговор про GSM-модули...): Вы не в курсе планов по SIM33ELA? Сколько он ещё будет доступен и когда появится SIM32ELA (он вроде ему на замену должен идти)?

[CADiLO 9]

SIM33ELA официально еще выпускается, но когда мы попытались их заказать, то сказали брать SIM32ELA, так 33-й можно ждать очень долго.....

Я уже кидал роадмап - то что слева от красной черты можно забывать.

[ELSE 0]

Коллеги, 

изначально я создал вопрос про длины линий VS скорости. Ответ получил. 

Далее, тема уже пошла в русло почему не работает FC с A7672. Это я протестил нашел в чем проблема. Вопрос закрылся.  А далее пошла тема  "для чего нужен HW Flow Control" - мне лично и так понятно для чего и я не отвечаю вам @jcxz потому что видно по вашим ответам, что вы не сталкивались с этим а без матчасти кидать в вас Спецификациями мне не следует с моим маленьким опытом. Примеров, которые приводит @CADiLO, видимо, также вам недостаточно для понимания. Далее, я только могу повторить все что написано выше. 

@jcxz вы пишете про TCP что вы на любом участке можете отработать проблему. Но не отработаете ее на уровне переполнения буфера DCE. А если UDP? а если вообще в канале связи не IP.

 @CADiLO абсолютно прав. Я хочу достичь цели - доставить данные через всю классическую схему "DTE-DCE-канал связи-DCE-DTE", где может как на удаленном конце так и на локальном возникнуть buffer overflow на L1 из-за канала связи.  Я не описываю эту задачу - так как мне понятно какими средствами это решать на каждом уровне  OSI. Проблема возникла в частной реализации на участке локального интерфейса UART между МК и Модемом SIMCOM.

Ну и опять же вернусь - в самое начало - у меня нет опыта разводки платы под UART на таких "высоких" для меня скоростях.

Мне кажется, уже тема не туда просто пошла. Про HW FLOW CONTROL на RS-232/UART сам по себе я даже не знаю чтобы мог здесь добавить к тому что описано везде.

 

Изменено 29 августа, 2023 пользователем ELSE

[jcxz 184]

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

Примеров, которые приводит @CADiLO, видимо, также вам недостаточно для понимания.

Он приводил примеры совсем о другом. Не о том, о чём вы писали. Если конечно вы понимаете разницу....

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

вы пишете про TCP что вы на любом участке можете отработать проблему. Но не отработаете ее на уровне переполнения буфера DCE.

Какая "проблема"? Почему "не отработаю"? И откуда какое-то "переполнение буфера DCE" - ничего не понятно.  

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

А если UDP? а если вообще в канале связи не IP.

Опять пошли "кони в вакууме". Вы не знаете что у вас в канале? TCP, UDP или что-то иное?  

Насчёт "неотработаю": как писал выше - работал с кучей разных каналов, в том числе и быстрых. И везде отрабатывал и потребности в RTS/CTS почти ни разу не возникло.

 

PS: Вобщем вывод - проблема явно надуманная. И похоже кроется в общем не понимании вами принципов работы вашего же канала.

[ELSE 0]

Так вам пишут же что речь идет о медленных каналах, а не быстрых, или быстрых с деградацией скорости НИЖЕ скоростей на удаленных концах в интерфейсах UART.

Какие кони в вакууме? Вам неоднократно написали о канале GSM. EDGE пусть будет примером. 

Про буферы в FIFO RS-232/UART, переполнение и управление потоком.

https://studfile.net/preview/3515876/page:5/

 

[vit496 0]

22 hours ago, jcxz said:

в каких это случаях обсуждаемые модемы могут передать файл размером 100 кБ локально ?

открыли html страничку используя TCP стек модема и получили поток данных

+RECEIVE,3,1348:
..... data ....
+RECEIVE,3,1400:
..... data ....
+RECEIVE,3,803:
..... data ....

[jcxz 184]

6 минут назад, vit496 сказал:

открыли html страничку используя TCP стек модема и получили поток данных

+RECEIVE,3,1348:
..... data ....
+RECEIVE,3,1400:
..... data ....
+RECEIVE,3,803:
..... data ....

Во-первых: Это не локальная передача модем-МК.

Во-вторых: Чем в этом случае поможет FC для условий озвученных ТС в первом сообщении?

[ELSE 0]

11 минут назад, jcxz сказал:

Во-первых: Это не локальная передача модем-МК.

Во-вторых: Чем в этом случае поможет FC для условий озвученных ТС в первом сообщении?

В том случае когда на UART между DCE -DTE будет выставлено 1842000 и прошивка будет литься рекой, а канал с TCP (особенно с UDP) внезапно в процессе уже установленного соединения  LTE упадет до 10кБит/с или замрет, а потом внезапно снова восстановится до скажем 10Мбит/с. Например, машина въехала с терминалом в условия плохого сигнала или БПЛА вылетел из уверенного покрытия.

Изменено 30 августа, 2023 пользователем ELSE

[vit496 0]

18 minutes ago, jcxz said:

Во-первых: Это не локальная передача модем-МК.

Непонятна ваша фраза. Это данные от модема на пине TX. Остановить их можно подняв CTS

[jcxz 184]

16 минут назад, ELSE сказал:

В том случае когда на UART между DCE -DTE будет выставлено 1842000 и прошивка будет литься рекой, а канал с TCP внезапно в процессе соединения упадет до 10кБит/с или замрет, а потом внезапно снова восстановится до скажем 10Мбит/с

И зачем тут FC?

И что такое "прошивка"? Почему она "льётся рекой"? Через какой такой протокол? И куда эта прошивка потом девается (в МК)?

Опять кони в вакууме.....  

Вот когда сможете связно ответить на все эти вопросы, то скорей всего (90% вероятность) окажется что RTS/CTS совсем не нужны.  

PS: Не надо думать что вы - первый в мире, кто реализует какие-то загрузки через быстрый канал. Как писал уже выше - 100500 раз реализовывал разные передачи через разные протоколы (через UART), и в RTS/CTS очень редко возникала реальная необходимость.

PPS: Насчёт больших объёмов & etc через UART: у меня в работающем сейчас проекте ESP8266 подключен к МК через UART на 1843200 бод. Файлы (от HTTP или HTTPS -сервера) качаются - иногда размером до нескольких гигабайт. От ESP8266 при этом приходит поток сообщений, вида подобного описанному выше vit496. На макс. скорости, без каких-либо FC. И... ни одного байта не теряется. ЧЯДНТ? 

4 минуты назад, vit496 сказал:

Непонятна ваша фраза. Это данные от модема на пине TX. Остановить их можно подняв CTS

Это данные не от модема, а от удалённого HTTP-сервера. Что может быть непонятного?

[vit496 0]

27 minutes ago, jcxz said:

при этом приходит поток сообщений, вида подобного описанному выше

Как сказать модему, чтобы остановил этот поток, поделитесь пожалуйста.

[jcxz 184]

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

Как сказать модему, чтобы остановил этот поток, поделитесь пожалуйста.

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

[dimka76 42]

On 8/28/2023 at 5:35 PM, jcxz said:

Пример: XMC4504

Вы опять про свои "шпингалеты" ?  

[adnega 10]

В 30.08.2023 в 11:03, jcxz сказал:

о скорей всего (90% вероятность) окажется что RTS/CTS совсем не нужны.

Практика показывает что нужны.

Тестировал на +GMR:A011B05A7672M7_F