Jump to content
    

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

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

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

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

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

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

 

Share this post


Link to post
Share on other sites

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

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

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

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

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

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

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

Share this post


Link to post
Share on other sites

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

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

image.thumb.png.5f1e9a6205b6184b56641d775afd6325.png

Share this post


Link to post
Share on other sites

Коллеги, 

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

 

Edited by ELSE

Share this post


Link to post
Share on other sites

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

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

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

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

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

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

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

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

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

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

 

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

Share this post


Link to post
Share on other sites

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

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

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

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

 

Share this post


Link to post
Share on other sites

22 hours ago, jcxz said:

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

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

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

Share this post


Link to post
Share on other sites

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

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

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

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

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

Share this post


Link to post
Share on other sites

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

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

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

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

Edited by ELSE

Share this post


Link to post
Share on other sites

18 minutes ago, jcxz said:

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

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

Share this post


Link to post
Share on other sites

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-сервера. Что может быть непонятного?

Share this post


Link to post
Share on other sites

27 minutes ago, jcxz said:

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

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

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites

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

Пример: XMC4504

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

Share this post


Link to post
Share on other sites

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

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

image.thumb.png.7ee796efb26e3dcef222db184add586c.png

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

image.thumb.png.a698973953416f543c5486ba0ce0f4dc.png

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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...