Arduino.ru

Ко вчерашнему разговору о ресете.

Измерил ток при замыкании RST пина на землю - на моем А6 примерно 55 ма.  Но, что любопытно,  даже при непосредственном замыкании этих контактов модем рестартится не всегда. А иногда после рестарта больше не отзывается на команды. Короче, какой-то этот процесс мутный.

Вопрос как делать рестарт - напрямую или через ключ - остался открытым. И непонятно, стоит ли вообще с ним связываться, если он не всегда срабатывает.

Да. Как ни странно. Глянул доку. "Module hardware RESET pin, this PIN when using low level <0.05V, current is 70ma, recommends using NMOS control;" Странный какойто ресет, силовой ))) Вы правы, моп-транзистор нужен.

Снова о ресете на А6.

В выходные повозился, собрал несколько схем и наконец победил хардварный ресет. Сперва пробовал ключ на биполярных транзисторах, но самый лучший вариант выдал на RST пин модема только 0.09в, а по даташиту нужно < 0.05. Модем не ребутнулся. Очень не хотелось возиться с пайкой крохотных мосфетов в корпусе SOT23. но пришлось :) Причем мосфеты тоже годятся не всякие, а лишь низкомные, так как по условию при токе 70ма падение на мосфете должно быть < 0.05в, то есть сопротивление открытого канала < 0.7 Ом. В итоге остановился на FDN337N - с ним заработало.

И на 115200 тоже заработало после этого. А значить теряет смысл шаманить смену скорости.

Правда с 115200 возник один моментик интересный. Если на остальных скоростях было ясно что узкое место - uart, ну после победы над ClrScr(); оно стало таковым ;) То на 115200 данные по уарту не идут уже непрерывным потоком, между блоками по 1400 байт паузы наглаз равные длительности передач. По светодиоду на Tx видно. Т.е. средняя скорость осталась около половины от 115200, а тормозит чтото до uart. Что - хз. Может оператор, может сам А6.

Logic

дошли руки покопать TCP стек на моем модеме - до вас мне далеко, конечно, но может будет интересно

CIPSEND у меня работает в строгом соттветсвии с мануалом, который вы цитировали в #11 :

//Вот это все у меня работает именно так, как описано.

А версия прошивки в модеме у Вас какая? Если 1.0.3 - как бы нормально что соответствует доке. Мой говорит что он V03.03.20161229019H03

Формат AT+CIPSEND=5,”12345” - предполагает отсутствие ID открытого соединения, а AT+CIPSEND=0,5,”12345” - попытку сендить через соединение номер 0. Оно же задается при открытии, закрытии и ресиве. Похоже добавили поддержку нескольких соединений одновременно. Все хочу проверить это, да руки не доходят. Возможно из-за этого и буфер поделили на всех возможных. Хотя вобщем цифра 1400 выходит из принципа тунелирования пакетов по TCP, например здесь - http://wiki.dieg.info/gre

Туннелирование увеличивает нагрузку на систему и сеть, потому что добавляются дополнительные IP-заголовки. Таким образом, если обычный размер пакета (MTU) в сети равен 1500 байтам, то при пересылке по туннелю, пакет будет меньше, 1476 байт для GRE и 1480 байт для IPIP. .... Cisco рекомендует устанавливать MTU в 1400 байт вне зависимости от того работает GRE поверх IPSec в туннельном или в транспортном режиме.

Ну вобщем сиське видней :) Я по этому параметру не парюсь. Парюсь по другой проблеме. Сделал подряд 6 запросов друг за другом (открытие-сенд-ресивы-закрытие со стороны сервера) к гисметео мобильной версии (немобильная на https, с ней не по балуеш;). И получил нестабильность ((( 2-3 запроса проходят, а иногда и все 6. И виснет на ожидании ответа. Грешу на питание, потому как больше не на что. Открыл спеку на А6 - там питание до 4,2В, надо привести к норме.

Добрый день.Вопрос может не в эту ветку.Этот модуль или подобные дружат с RS 485 ?И где А и В? Заранее спасибо.

Как говорят девочки "не туда!!"

  String reply = "";
.....
  return reply;
}

В этом коде нет ошибки - строка (в данном случае "") не располагается на стеке, она или в области кода или в области данных. Поэтому храни адрес на нее хоть в локальной переменной, хоть возвращай наружу - все норм.

Но будь моя воля я б вобще запретил String как класс )) ХЗ какая у него конкретно реализация, нужно смотреть, но он обязан шаманить с памятью, например при склейке строк, соответсвенно будет фрагментация памяти, и плохо прогнозируемое потребление инструкций CPU. И все это замаскировано под тип данных. Сделано для чайников, чтобы было проще писать Hello World, а правильные девелоперы должны отслеживать подобные вещи, в явном виде, типа используя strncat и strncpy.

В официальных доках String тоже не рекомендуют к использованию.

Мне еще ни одна нормальная либа с String для ардуины на попадалась. Если видишь либу и там используется String вместо char[] - сразу выкидывай )) И дело даже не в самом String, а в том что автор чайник, там скорее всего и другие проблемы будут. У чайников такой бред в башке бывает...

У меня вот какая проблема - пытаюсь работать с HTTP запросами на A7 (это A6+GPS), использую либу TinyGSM https://github.com/vshymanskyy/TinyGSM на MCU STM32F103C, +CIPRCV отдает HTTP header нормально, но HTTP body не всегда (ваще редко). HTTP body идет вторым блоком +CIPRCV, и такое ощущение что A7 проглатывает начало этого второго блока, то есть собственно заголовок +CIPRCV и часть данных.

Но иногда HTTP body приходит нормально. Никак не пойму в чем дело, куда копать...

  String reply = "";
.....
  return reply;
}

Это я не прав - действительно если вернуть String на стеке, то программа зависает )) Мда, хорошие грабли придумали с этим String...

Да. Грабли знатные. String заманивает кажущейся простотой применения, за которой скрывается низкая эффективность работы и ресурсоемкость и в финале добивает подобными граблями. Правда о всем ардуино в целом тоже это можна сказать ;) Я String не использую, другим не советую.

К сожалению, или к счастью, нет )) Я тоже про это первым делом подумал, но у меня чип STM32F103C, там 3 хардварных serial, так что в софтовом нет необходимости нет. На ATmega328P у меня уже были танцы с бубном с SoftwareSerial, я так понял модем на нем привернуть можно, но я не осилил

Я пока забил на этой проблеме - http header отдается всегда ок, мне его оказалось достаточно. Сервер Traccar отвечает минимальным http response, там все поминимум, весь ответ с http хидером 38 байт.

Я несколько библиотек перепробовал для модема, лучшее что нашел TinyGSM, но меня все равно не полностью устраивает, из-за синхронных вызовов. Асинхронных библиотек для модема пока не видел, что странно. Я на твой код глянул, вроде фильтры там, то есть обработка событий от модема правильней реализована?

В идеале хотелось бы либу для встравивания в машину состояний, чтобы можно было команды слать в модем асинхронно, не дожидаясь ответа. Так никто не делает что-ли?

Но вообще действительно похоже на потерю части буфера.  Типа не успеваю вычитывать с порта модема? Типа в самом модеме буфер переполняется...

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

"Асинхронную библиотеку" нужно будет использовать в асинхронной среде программирования, а поскольку примерно 70% пользователей ардуино не знают, что такое "машина состояний" и пишут исключительно синхронный код - таких библиотек и нет.

ну почему "никто" - вы всегда можете взять готовую библиотеку и переписать ее под себя. Я под свой проект писал асинхронные вызовы для модема А6 на основе библиотеки для SIM900 - но это большая работа, да и то полностью распараллелить вызовы не удается. Более простой путь - использовать RTOS-системы, тем более что для СТМ32-дуино FREERTOS идет прямо из коробки.

Кстати, вы используете либу TinyGSM с хардварный портом, хотя сама библиотека написана под софтваре-сериал, как я вижу. В этом может быть источник проблем, так как замена софтового на железный сериал в библиотеке может давать странные эффекты, особенно на СТМ32.

Точно, нужно попробовать скорость поменьше выставить, у меня сейчас на модеме 115200. 

В примерах TinyGSM написано что на Arduino Mega можно использовать хардварный порт, может даже тестили )) Под STM32 я допиливал, из коробки не идет, но вроде я видел в инете народ использует на STM32

Про FreeRTOS я тоже начал думать, есть опыт работы с другими RTOS. Но этот проект добью как есть, в следующем проекте посмотрю.

У меня уже сейчас код занимает 90% флеша (от 64к), с FreeRTOS скорее всего будет больше. Похоже скоро придется смотреть что из ардуиновского рантайма место жрет.

по поводу обьема кода и расхода оперативки - думаю, вам надо настроить опции компиляции. Выигрыш в размере - в разы. Почитайте вот это ссообщение.

У меня весьма обьемный проект занимает 31к флеша и всего 2к ОЗУ, хотя без настройки наверно уже было бы как у вас.

ЗЫ это уже офф-топ в этой теме, пишите в тему про СТМ32

Спасибо, почитаю. Тут пока копал в инете про модем, попался пост про оптимизацию кода, типа выкидывать либы от printf, что весьма резонно.

Про freeRTOS - оказывается она есть и на 8 битных MCU AVR, это ж круто. Я раньше про freeRTOS даже не рассматривал, думал это для больших проектов. Теперь буду переходить на FreeRTOS стопудово, этот ардуиновский детсад надоел. Вижу есть даже FreeRTOS либа для Arduino IDE https://github.com/feilipu/Arduino_FreeRTOS_Library, но думаю буду в консоли работать, или Eclipse, Arduino IDE это ужас в плане редактирования кода.

Я когда-то пытался использовать Eclipse для C кода, показалось не очень, но все же лучше чем Arduino IDE.

Почитаю пока доки по FreeRTOS.

Не теряйте время на хххRTOS. Решыв одну проблему Вы себе несколько новых породите, например синхронизация потоков при доступе к периферие, и пр. И если без ОС 90% памяти ушло, то с ней вобще не влезет. Откройте библиотеки заюзаные. Там почти гарантировано мрак что творится. Это и есть Ваш основной ресурс оптимизации. Пример асинхронной работы с модемом на первой странице. Ничего там сложного нет, ну по крайней мере для человека забившего память STM-а не должно быть ;) Из этого кода выросла у меня либка с асинхронной работой и без буферизации обмена. Но она пока для внутреннего применения.

printf - зло. Это давно известно.

По поводу размера бинарника я не напрягаюсь, интуитивно понятно что это лечится убиранием зависимостей на ардуиновкий рантайм.

Не то слово - поставил скорость порта модема 9600, теперь данные от модема не теряются, но теперь подглючивает TinyGSM, там таймауты на это не расчитаны )) Мне как раз и не нравится в синхронных реализациях что там почти шаманство на таймаутах, что-то то работает то не работает.

Вашу мысль я  понял по поводу FreeRTOS, буду иметь ввиду. Я работал одно время с RTOS в моторольных телефонах (когда еще андроида не было), представляю во что превращается код размазанный по машине состояний, но опыт показывает что поддерживать его проще.

Так то я свою машину каждый раз прописываю, на коленках (и в текущем проекте тоже), но мысль о том что FreeRTOS как раз об этом, мне не приходила. Хочу пощупать в след раз, есть ощущение что оно мне надо ))

Вот кстати нагуглилась крутая GSM либа (синхронная и асинхронная), для RTOS: http://majerle.eu/projects/gsm-at-commands-parser-for-embedded-systems и там используют Protothreads http://dunkels.com/adam/pt/about.html , первый раз такое вижу, впечатлен. Я так понял реализация синхронных вызовов в среде RTOS, поверх асинхронных, используя C continuations, шаманство на свитчах и макросах. Че творят черти, нужно глянуть ))

//Я так понял реализация синхронных вызовов в среде RTOS, поверх асинхронных,

А чего ж еще им остается! ))) Смотрите что выходит, допустим есть два потока RTOS один опрашивает пусть датчик, другой поток работает с модемом. Независимы аж страшно ))) Каждый сам посебе делает свое дело и получает результат, который надо на экран вывести. Но экран один, шина одна и вывод данных от одного потока не должен влезть посреди вывода другого. Получается надо делать синхронизацию, блокировать вывод от одного до тех пор пока второй не освободит шину. Пока один выводит, второй ждет, простаивает и уже не такой и независимый. Можна конечно начать химичить очередь (расход ОЗУ), делать поток работы с экраном (и синхронизацию с ним при работе с очередью). Ну допустим. А если на той же шине экрана еще какой устройство висит и иногда занимает и блокирует шину? Прийдется поток экрана делать блокирующим. Вывод получается такой: синхронные потоки при доступе к внешним устройствам блокируют друг друга, попытка решения приводит к архитектуре с чередующимися синхронными и асинхронными потоками с буферированием между ними. Оно работает, но из-за блокировок асинхронные не совсем независимы, реалтайм не прогнозируемый (например светодиоды пиксельные очень проблемно поддержать) а издержки на потоки (контексты хранить чего стоит) и их синхронизацию просто неадекватные. ИМХО, оно того в МК не стоит, даже если 64К памяти. Вот когда несколько МБ памяти, тогда да, там ОС нужна. Там задачи серёзней и отношение затрат на решение задачи и на многопоточность становится приемлемыми.

ИМХО, оно того не стоит. И я пишу машинки состояний, как и Вы. А что делать. Эффективность оправдывает некоторую сложность поддержки. Но пока пишеш сам себе и для себя - поддержать реально. А когда система взрослая с линуксом и др. понтами - ну там и подход многопоточный естественно.

Не, холивар устраивать не будем, думаю он уже случился на заданную тему 100500 раз )) Я согласен, это диалектика, нужно то и то.

С FreeRTOS у вас был опыт работы, сравниваете на собственном опыте?

По поводу управления пиксельными LED - эта тема меня также интересует, пробовал к ардуине цеплять, и есть планы по этой теме, поэтому и спрашиваю - я не очень понял какая может быть проблема с ними под RTOS? Речь о том чтобы формировать управляющие пакеты для каскада WS2812? Просто не догоняю, не думал что с ними могут быть проблемы... Если есть, то буду благодарен за инфу.

Холиварим тут периодически, то да. А как иначе выработать общепринятую точку зрения облегчающую поиск решения неопытным.

RTOS - почитал доки и исходники, трогать не стал по описаным соображениям. Если видите эффективные пути решения описаных проблем - пишите, могу и попробовать. Я не вижу таковых. Вот и выходит что на атмеге 328 разве что поморгать 3 диодами удастся. Чего серезного, например вытянуть с сайта по http строку нужную, как в коде выше, непотянет просто.

Про ws2812b. Мое здесь - http://arduino.ru/forum/proekty/pokhvalimsya-khudozhestvennoi-samodeyatelnostyu-na-ws2812

Там протокол такой, что надо импульсы с периодом около 1мкс на один бит формировать с точностью в 0,15мкс. пусть 60 светодиодов на 24 бита 1,5мсек непрерывного формирования импульсов с заданой точностью. На атмеге аппаратно нет решения, только програмно.   Переключения потоков недопустимы, пауза в 50мкс расценивается как старт последовательности сначала. А если больше светодиодов? Другие потоки в это время вынуждены стоять и соответственно теряют смысл. Например управление с ИК пульта - уже проблема, в многопоточном не решаема, в однопоточном - решается, хоть и криво.

глянул на Вашу тему с ws2812 - ассемблер, это жесть )) Я подцепил стандартную либу https://github.com/adafruit/Adafruit_NeoPixel  и лента ws2812b заработала "из коробки", проверял на srandtest, на ардуино нано (atmega 328р). Щас глянул - там тоже сплошной асм

Там кстати рекомендуют кондер и резистор вешать, ну если Вы не в курсе (в той теме вроде нет инфы) https://github.com/adafruit/Adafruit_NeoPixel/blob/master/examples/stran... у меня правда и так работало, 5ти метровая лента на 150 диодов ))

Я смотрю там сделали порт и для ESP8266, это круто, можно делать wifi контроллер для гирлянды на нем.

Вообще тема со спецэффетками с pixel led интересная, сейчас на диодах иллюминации все больше делают. Было бы круто сделать набор эффектов и чтобы ими можно было управлять с пульта. Ну а если еще учитывать пространственное расположение ледов, для объемных эффектов - ну тут есть где развернуться )) Сделать конструктор эффектов прямо на пульте (в андроидном телефоне, в приложении), и можно их шарить через базу в инете...

Про управление ледами под RTOS - теперь я понял о чем речь, я почему-тодумал что FreeRTOS с кооперативной многозадачностью, соотвественно тогда этой проблемы бы не было (но были бы другие))

Первое что приходит на ум - делать по прерываниям от таймера, на время формирования пакета все остальные прерывания отключать. Если частота MCU позволит вписаться в точность 0.15мкс - то должно быть ок. На 72Mhz STM32F103 вроде норм, про атмегу ХЗ, рискну предположить что если там приходится шаманить на ассемблере чтобы вписаться в 0.15мкс - то такое не прокатит ))

Если говорить конкретно про RTOS, то там есть фича зарубания шедулера  http://www.freertos.org/a00134.html, соотвественно можно воткнуть критичный код по формированию пакетов. Остануться только прерывания, ну их зарубать если будут мешать.

Ну, че не так? ))

Можно попробовать синхронизировать время модема по GSM сети, нашел в TinyGSM такой код: 

    void syncNetworkTime(){

А, про это - ну да, тут ничего не сделаешь, если частота не позволяет. Если на атмеге она не позволяет это делать параллельно, без RTOS, то под RTOS это тем более невозможно. Нужен MCU с частотой которая позволит и то и то делать, например по таймерам (ну или тикам, их можно уменьшить, но до мкс  это пожалуй жесть, хотя на 72Mhz может и ничего), а в оставшееся процессорное время крутить остальные неважные таски типа UI )) 

Ну тогда жить можно. А если железо не позволяет, то тогда изголяться программируя на асме, высчитывая каждый тик процессора, какой тут нафиг шедулер ))

Вариант - использовать какой-нибудь MCU с доп ядром DSP, их специально для таких задач делают где нужно по времени уложится. Какие конкретно чипы - ХЗ, самому интересно. Знаю в АРМ есть такое, но это уже не сегмент бюджетных MCU. Ну типа этого: http://www.microchip.com/design-centers/16-bit/products/dspic33f-e

Не совсем в тему - у меня похоже в программе какая-то порча памяти случается. Есть какие тулзени посмотреть стек не переполнился? какие-нибудь ключи компиляции? Что вообще народ делает в таких случаях ))

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

Мужики, вы очень интересные вещи обсуждаете, но к модему А6 они никаким боком уже... Создайте отдельную тему. что ли.

На ESP8266 интересно вроде, но для оперативного управления пульт ИК удобней вебинтерфейса. Интересно было бы эффекты расчитывать на сервере и кадры брать онлайн, но десяток раз в секунду и стабильно загружать очередной кадр малореально, хотя... Если грузить блоки из нескольких десятков кадров, буферировать, то должно работать. Так другая фигня - у ESP8266  с реалтаймом тоже не все гладко, если поток долго активен, то траблы: отпадает от WiFi, зависает и ребутится по вачдогу. Похоже там внутри чегото многопоточное шивелится. Выполная код пользователя и поддержку WiFi. Вобщем неуверен я в успехе.

Думаю и прерывания таймера не успеют. Там скорость совсем не в 72/16 выше. Тоже холиварили както. Про отмегу Х3 -  а ХЗ )))) Я её не знаю. У STM можна чего нашаманить с DMA.

Прерывания запрещать однозначно.  Это кстати и шедулер остановит, он на прерывании пашет.  Оно конечно остоновить все потоки можна, а нафига тогда многопоточная ОС?

Вот и приходим к выводу о RTOS - ресурсы жрет, сделать с ней нельзя то что без неё можна. Требует более быстрого проца. Печально вобщем с ней.

И зачем мне небюджетное, да еще и новые камни в хозяйстве?! Разводить зверинец только. Мне удобней иметь 2 варианта: 328-й и линуксовый орандж. И ESP для мелких проектов завязаных на сеть, допускаю, он может постепенно вытеснить 328-й (уже бы вытеснил, если бы не троаблы с реалтаймом и портов поболе).  Покрывает все и сразу. Накрайняк в связке друг с другом. Дешево и сердито. Хоть светодиодом моргай, хоть СУБД реплицируй или HD на телик выводи. А для RTOS я лично не вижу применений. Даже UI не так и сложно делать на 328-м.

Все, все, все..... разбегаемся :)

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

Сейчас вроде у всех основных российских операторов время в сети есть. Раньше да, у кого-то не работало. Как универсальное решение да, не катит. Зато работало бы без инета ))

так вы возьмите и проверьте. Я пробовал - всего несколько месяцев назад в Москве ни один из операторв "большой тройки" (Мегафон, МТС, Билайн) - время по команде CLTS не давал. Из тех симок, что я пробовал - только тверской Билайн дает время таким способом. Причем нестабильно - иногда дает, иногда нет.

Мы с Logic команду CLTS уже обсуждали, поищите поиском.

Зато с телефона управлять понтов больше )) Ну и самое главное - экономия на железе )) Ну и телефон сложнее потерять, а то эти ИК пульты которые нужны 1 раз в 100 лет...

Про рендеринг эффектов на сервере - я чето в таком ключе не думал, мне казалось что рендеринг не должен сильно жрать CPU, тут же нет задачи уложится в 0.15мкс, можно делать в свободное от ледов время ))

Ну типа рендерер на MCU, к нему на входе параметры эффектов например бегущий огонек - скорость, цвет, и тп. Что, неохота городить в односредном варианте, нужен RTOS? ))

Я и не знал что есть Атмега ХЗ ))

Зато ARM ассемблер покруче в плане оптимизаций, как раз для любителей, не будем показывать пальцем )) я с ARM когда-то разбирался. С командами AVR я правда не знаком, вдруг он круче...

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

И пишут что под RTOS есть какие-то средства для дебага, типа контроль стека и хипа.

А вообще есть отладчики для MCU, для атмеги 328р или STM32F103? Не думаю что это мне сильно поможет, но вдруг...

@Logik, про pixel LED - случайно заметил в STM32F1 либах есть порт либы NeoPixel, использует STM32 SPI DMA. Если интересно: https://github.com/rogerclarkmelbourne/Arduino_STM32/tree/master/STM32F1/libraries/WS2812B

gmixaz - писать все подряд в одну тему - неправильная привычка. Это не одноклассники и не чат.

b707, подскажите, пожалуйста, где найти схему хардверного ресета? Если не сложно, нарисуте, пожалуйста. И покажите, пожалуйста, кусок кода программы, где используется ресет модуля А6.

А проконсультируйте плиз, что такое хардварный ресет на А6 модеме?

понится был у меня проект (щас разобрал) нормально вроде ресетился

void a6resetmodem() {
  // reset modem
  digitalWrite(_a6_reset_pin, HIGH);
  unsigned long delp = millis(); while ((millis() - delp) <= 500);
  digitalWrite(_a6_reset_pin, LOW);
}

void a6resetmodem() {
  // reset modem
  digitalWrite(_a6_reset_pin, HIGH);
  unsigned long delp = millis(); while ((millis() - delp) <= 500);
  digitalWrite(_a6_reset_pin, LOW);
}

Пин Ардуины напрямую подключен к Ресету модема?

(хардверный - это аппаратный reset.) В документации написано: Module hardware RESET pin, this PIN when using low level <0.05V, current is 70ma, recommends using NMOS control. 

void a6resetmodem() {
  // reset modem
  digitalWrite(_a6_reset_pin, HIGH);
  unsigned long delp = millis(); while ((millis() - delp) <= 500);
  digitalWrite(_a6_reset_pin, LOW);
}

lantari - пин ардуины управляет мосфетом - у меня же выше даже написано, каким именно.

А код - вот вам andycat предоставил, вполне достаточно для ресета.

да, проработало больше года, пока недавно не разобрал из-за ненадобности.

что-то вы, наверно, путаете. Даже если вы рискнули управлять Ресетом напрямую (хотя там заявленный ток порядка 70мА) - все равно для рестарта пин надо прижимать к земле, а в вашем коде он управляется высоким уровнем. Больше похоже на то. что это код управления мосфетным ключом.

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

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

скиньте. Совершенно непонятно, как Вы пин Ресета управляли высоким уровнем напрямую.

вот нашел, февраль 2018, качество так себе, но внизу видно желтый или черный провод (там где rst) от модема идут сразу на Ардуино

нашел покачественнее

ищите в инете "ключ на n-mosfet"

вместо лампочки - модем, на  Vin - сигнал с ардуины.

Rin = 300-500ом, Rgs = 10-100к