Конечно далеко. Это моя первая программа на МК. Вряд ли я способен реализовать DMA
и даже работу с UART через прерывания. Я хотел, как мне казалось, сделать простую
вещь. Работая c UART в полудуплексе включить питание на SIM800, прочесть SMS, инициировать GPRS,
выполнить HTTP запрос, выключить питание.

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

Зато я могу поделится своими впечатлениями от стандарта GSM, его реализации в продуктах Simcom и о программах на МК, которые я видел. Очень краткое суждение - теперь мне понятно, почему сотовая связь столь ненадежно и криво работает.

P.S. Особую признательность вызывает URC. Если бы какой-нибудь программист с которым я работал сделал бы такое я бы его просто прибил. Надо же додуматься до такого - посылать неожидаемую нотификацию в последовательный порт, который работает в полудуплексе!
Чуваку, который это придумал, нужно подарить рацию, которая будет изредка самопроизвольно выходить на передачу с посылкой сигнала. Тогда бы он, наверное, смекнул, что напорол чушь.

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

Запомните одно великое правило - никогда не считайте Маловероятное - Невозможным!
И удачи в Ваших начинаниях.

Никого не хотел обидеть. Но Вы неправы по поводу тепличных условий. Дело не в этом. Очевидно, что тот кто придумал такую обработку URC не разу не программировал в многопоточной среде, где, как Вы метко выразились маловерояное ВСЕГДА возможно. Обработка URC в Simcom - классическая архитектурная ошибка. Нужно было сделать отдельный поток для оповещений. Отдельное прерывание для его чтение. Отдельный флаг состояния (регистр). Вообщем, все чтобы оповещения не блокировали передачу и прием данных через последовательный порт. Грубо, еще один UART, только односторонний.

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



Зачем? Каждое сообщение от модуля это цельная строка внутрь которой URC никогда не влазит. Принимай строки и обрабатывай каждую по отдельности и да прибудет с тобой шварц. Есть конечно особенности с GPRS, но на них тебе еще рано заглядывать.



При таком подходе получаешь отдельный геморрой со вторым UARTом который до недавнего времени был большой редкостью в МК. И ради чего?

Ага, и TCP тоже криво реализовали. Надо было отдельный канал делать для ACK и прочих пакетов...

И модем внешний на 1200 бод тоже опрометчиво сделали с всего с 1-м RS-232.
И MODBUS, CAN и прочие шины тоже дураки проектировали....

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

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

Да знаю я это. Правда примеров использования не видно нигде. А испытателем не хочется быть.


Если без прерываний и ухищрений типа DMA то не получится создать надежный код, который будет писать в UART и читать оттуда. Потому что в любой момент
вам может приехать URC и заблокирует запись. Чтобы повысить надежность мне пришлось перед записью проверять RXNE и читать. Короче, костыль.


А для чего сделали два UART? Не для того ли, чтобы сделать нормальный full duplex?



Согласен что никто мне ничего не должен. Так, болтовня это. Но вам бы прислушаться к взгляду со стороны.

У меня опыт программирования 15 лет на хреновой туче языков и такой же туче всяких фреймворков, IDE, библиотек и т.д.
Но то что я увидел в вашей сфере просто удручает. Как будто в 90-Х оказался.

Этот Keil - вчерашний век с текстовым редактором от 6 студии )). ST-link который не может прошить свой же чип.
(а еще его нужно запускать от имени администратора, но перед этим нужно об этом догадаться). Этот OpenOCD,
который просто не работает, а если и работает то только после ковыряния в его коде. А программы, программы...
Все в костылях и подпорках. С глобальными переменными и операторами goto!!! Эти даташиты в которых пишут
примеры с использованием умолчаний. Или просто не пишут примеров. Итак ведь понятно!

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


P.S. Что же вы не откопаете свой внешний модем. Присоединили бы его к RS 232 и выходили бы в инет.







Я на всякий случай Вам перевод кину Universal Asynchronous Receiver-Transmitter, UART. Так, чтобы поржать на досуге )))



Сообщение отредактировал an24 - May 19 2016, 15:43

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

Использовал бы по входящему потоку прерывание в котором входящие символы тупо кидал в буфер(к примеру FIFO) и не морочил бы себе голову с костылями.

Изначально второй UART был как технологический, отладочный и для возможности перезаписи модуля не борясь с МК.

Ни в коем случае. Первый UART и так нормальный full duplex. Да и при твоём построении программы без использования прерываний и передаче строки модулю тупым циклом, второй UART тебе не поможет потому как пока ты передаешь строку в один UART процессор занят исключительно этим и не обращает внимание ни на что, включая сообщения со второго UART-а.

Чего-то я вас не пойму: какой-такой "UART в полудуплексе" ?
Если вы решили придумать себе проблемы и потом их героически решать, то зачем обвинять разработчиков ?
Полудуплекс возможен только после управляющего МК, где будет ваш собственный простенький протокол.


В нормальном дуплексном режиме, да еще с сигналами управления потоком, все будет нормально работать.
Мухи(прием) отдельно, котлеты(передача) отдельно. Буферы отдельные. Управление потоком отдельно для обоих направлений.
Где проблемы?
DMA есть далеко не у всех МК, но и без него все работает.


Два УАРТА
- или один только для отладки.
- или один для команд управления модемом, а второй для данных (хотя и данные могут быть многопоточные, т.к. возможно несколько параллельных подключений, которые обслуживаются мультиплексным протоколом).

Конечно UART принципиально ПОЛНОдуплексный. Но в SIM800 он реализован как полудуплексный, так как буфер на прием
и передачу на стороне SIM один. И команда записи блокирует чтение и наоборот. Это мне объяснили
мудрые люди и я это опробовал на железе. Все так и есть. Когда я пишу и читаю со своей стороны я могу соблюсти
нужную последовательность. Но тут вмешивается SIM, который шлет мне неожидаемый (это их термин) код, который
блокирует запись. А я то этого не знаю.

Поэтому пришлось делать костыль.


Можно было делать по прерываниям или DMA, но я доделывал программу, написанную ранее.
Не хотелось все переписывать. Может быть и зря.

Фантастику вы пишете
Если бы так было, то ни у кого бы ничего не работало...

Или "мудрые люди" не то сказали или вы не то поняли. Вариантов тут не так уж и много.

ЗЫ. Я надеюсь Вы работаете не с включенным эхом?

Я вполне могу ошибаться. Вы все так уверенны... Может все таки дело в функциях HAL от STM.
Завтра еще раз вернусь к этому.



Я его выключил. Но меня тут обозвали лохом и я его обратно включил.

Кстати, интересное замечание. Я всегда эхо при начальной конфигурации сразу отключаю,
поэтому никогда не видел, как ведут себя SIMXXX-ы при одновременной подаче команды с эхом и вываливании из модема URC.
Это как-то должна разруливать операционка модема, но интересно как.

Не сталкивались?

+1
Это он еще про мультиплексор GSM 07.11 не слышал...



А как еще. Вполне себя и ведут. Какая разница, в каком месте станет так, что после подачи команды в приемном буфере окажется URC?
* Потому что не вычитали вовремя (перед подачей команды)
* Потому что в момент подачи команды в приемник валился URC
* Или в момент окончания передачи команды в буфере модема образовался URC.

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