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

Разводка линий UART обмена с SIMCOM 7682/A7672 на скоростях 921600- 3686400 бод

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

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

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

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

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

 

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


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

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

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

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

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

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

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

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

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


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

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

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

image.thumb.png.5f1e9a6205b6184b56641d775afd6325.png

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


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

Коллеги, 

изначально я создал вопрос про длины линий 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 сам по себе я даже не знаю чтобы мог здесь добавить к тому что описано везде.

 

Изменено пользователем ELSE

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


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

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

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

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

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

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

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

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

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

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

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

 

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

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


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

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

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

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

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

 

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


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

22 hours ago, jcxz said:

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

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

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

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


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

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

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

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

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

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

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


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

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

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

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

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

Изменено пользователем ELSE

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


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

18 minutes ago, jcxz said:

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

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

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


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

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

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

И зачем тут FC?

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

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

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

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

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

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

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

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

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


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

27 minutes ago, jcxz said:

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

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

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


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

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

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

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

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


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

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

Пример: XMC4504

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

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


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

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

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

image.thumb.png.7ee796efb26e3dcef222db184add586c.png

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

image.thumb.png.a698973953416f543c5486ba0ce0f4dc.png

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

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


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

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

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

Гость
К сожалению, ваш контент содержит запрещённые слова. Пожалуйста, отредактируйте контент, чтобы удалить выделенные ниже слова.
Ответить в этой теме...

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

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

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

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

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

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