Цитата(CADiLO @ Jun 4 2013, 18:31)

Итак документ
http://microchip.ua/simcom/SIM900x/SIM900/...esign_V2.04.pdfСтраница 18 рисунок 1 - рекомендуемая схема поверкея.
Это не я придумал. Не хотите - не придерживайтесь.
Если они в схеме нарисуют рекомендуемый контроллер -- что, всем точно такой же ставить? Или рекомендуемую батарейку. А у них ещё рекомендуемый источник питания. Всем на таком делать? Не надо чепухи. Рекомендуемая схема даётся для примера, а не для обязательного повторения.
Цитата
А вот шанс получить глюки - имеется.
Преимущественно при неправильном программировании и использовании МК. Принципиальных проблем здесь нет. Вы на них указать не можете. Про защитные диоды я ответил. Можно ставить точку.
Вариант с транзистором и аж тремя резисторами через-чур расточительный по габритам. У них там по-приличней вариант был с одним MOSFET, на это ещё можно пойти и, не буду спорить, проще лишний транзистор, чтоб не забивать голову всякой чепухой. Но повторюсь -- принципиальной разницы между транзистором встроенным в МК я не вижу, за исключеним ряда ньюансов. Дьявол кроется в мелочах, как всегда.
Цитата
Ну и еще - сами говорите о новизне, а пользуетесь древним, неподдерживаемым hitech-C 9.51pl2
При том что Хайтек давно продался Микрочипу.
Кошек еще уметь готовить нужно прежде чем говорить что XC глючные.
Кошки уже давно изготовлены, ещё до того как. А XC8 просто не работает, как и не работала никогда PRO версия со сколько-нибудь большими проектами -- это суровая правда жизни. Как и то, что микрочипу на это наплевать. Кому нужно пользуют STD версии. Не работает оно на выражениях x=y со словами "too complex expression", я уж не знаю что тут упрощать. Насколько я понимаю, люди из hitech software не осилили свой "omniscent optimizer" и сейчас там проект не поддерживают, а больше поддерживать его некому. И XC8 -- это лишь переименованная и перекрашенная на новый лад всё та же старая PRO версия. Changelog это прекрасно подтверждает -- никаких принципиальных изменений за последние три года, добавили новые .h файлы и такие мелочи всё больше. Подталкивают потребителей на PIC24.
Любите сравнивать -- сравните любой код с плавающей точкой STD версии и PRO. Будете неприятно поражены... Это вот где был нужен ассемблер.
Цитата
Я уже пару раз приводил пример проекта сделаного на асме. Если повторите на том же контроллере на C - ставлю ящик коньяка.
Есть какая-то неуловимая всё разница, между проектами для реальной жизни и чемпионскими достижениями на ассемблере, не находите? Последние хороши только для соревнований.
И ящика определённо мало. Столько я не выпью.
Цитата
>>>>Максимальная длина SMS -- 140 байт (160 7-битных символов). Что занимает около 600 байт ОЗУ: 140 * 4 ибо передача в HEX и UCS2.
А конвертировать на лету не пробовали? Или тоже дилетанство?
Таки да, дилетанство. Овчинка определённо не стоит выделки. Вагон коньяка никто за это не предложит. Для Apollo Guidance Computer -- такое решение имело бы смысл. Но у нас тут не NASA и сейчас не 1966 год. Можно было бы и процессор свой сделать на микросхемах 1533 серии. Но зачем? Так и в странной архитектуре ПО, где все слои смешаны, смысла нет. Проще поставить достаточное количество ОЗУ и сократить время разработки.
Цитата(CADiLO @ Jun 4 2013, 18:55)

>>>Таки дилетантство. Он потребуется даже в AT+CMGS
Дилетанство это тратить память и ресурс на вызов не нужной функции, когда можно из таблицы побайтно в порт/из порта в цикле.
Как вариант. Есть и другие решения и тоже без стандартных функций.
Стандартные функции существуют для того, чтобы не изобретать свои самодельные велосипеды с кривыми квадратными колёсами. Дилетанство -- это отрицать этот очевидный факт. В объёме реального проекта, я приводил цифры, объём printf'а не заметен.
Цитата(_Артём_ @ Jun 4 2013, 18:38)

Что без принтф строчку в UART послать никак-чтоли?
printf нужен для преобразования из числовой формы в текстовую. Для HEX-кодов и десятичных чисел (в CMGS параметром идёт длина PDU).
Цитата
Кодировать в PDU можно не всю сразу а по мере отправки. Тогда 600 байт не надо.
Я про приём. Для отправки 160 байт нужно вообще 140 байт (плюс заголовок). И для отправки 70 символов русского текста те же 140. Возможно 280, потому, что поддержка извращения с кодированием (не в PDU, только HEX) на лету занимает сильно непропорционально больше программной памяти, чем экономит ОЗУ.
В обратную сторону так просто не получится потому, что чтобы разбирать PDU нужно вначале разделить ответы модема. Есть конечно теория, которая говорит нам, что любой недетерминированный конечный автомат можно превратить в детерминированный с очень большим числом состояний -- но проверять это на практике: овчинка выделки точно не стоит.