Именно! На уровне 90% потребителей всех модулей, нужна поддержка стандартных АТ команд и спеков GSM, а вот в плане реализации встроенного TCP стека и прочих проприетарных вещей производитель, по моему мнению, должен максимально идти на встречу разработчикам. И здесь нет равных(ИМХО) Qectel. При этом Cadilo очень старается оказать максимальную поддержку пользователям как представитель Simcom, но сколько дракона не дергай за хвост, до головы это доходит очень долго. Вот потому и имеем 900R и конкурентную цену когда, как у нас говорят, жареный петух...

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

И по поводу долгосрочности. Модели телевизоров в СССР выпускали подолгу(берёзка, весна), но они были хуже любой импортной модели, которая выпускалась не более 2 лет.

Оно-то можно, а зачем? Собственными GPIO МК рулит куда быстрее.
Разве что модуль управляется какой-то 10-ножкой...

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

Например, если модулем управляет ПК через USB конвертер (FT232R).

...и не хватает собственных "верёвок" FT232R. Согласен!

Вот сейчас проект - модулем рулит АРМ стоногий. Нехватает! Так что халявные пины не помешают. Тем более что в модуле это просто дорожка к чипсету - если выкинуть то никакой экономии не будет.

Чем, однако, понравился SIM800 - так двусторонней распиновкой и отсутствием "лишнего". Хотя, конечно, не на все случаи жизни такой форм-фактор.

Без элементарной защиты от ESD производитель модуля вешает на себя некоторые дополнительные риски. А с ней - слегка растет себестоимость. Так что не совсем бесплатно это.

Зачем защита, если сигнал по плате дальше 5см не уходит? Или обратный варинт - что дасть защита от статики если я воткну пин в 12В? А если в 220? Так что ставить нужную защиту исходя из требований - это на совести разработчика, производитель модуля тут не при чем.

В общем чем дольше я пытаюсь запустить прототип на телите, тем глубже убеждаюсь, что для использования с UDP и datagram-oriented протоколами телит с его нынешним интерфейсом TCP/IP стека просто непригоден. Да и "проблески разума" появившиеся в последней прошивке использовать по сути невозможно.

Прямой и недвусмысленный вопрос к представителям Телита - насколько реально в обозримом будущем (т.е. не годы, не месяцы а недели) добиться от разработчиков хоть какого то юзабельного способа приема UDP датаграмм, который не будет смешивать их (в том числе пришедшее с разных IP) и валить в буфер без разбора? То что есть сейчас - это реплика того что сделано для TCP (где имеет право на жизнь), но для нормальной работы с UDP датаграммами (а не потоком данных) попросту непригодно.

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

PS: Волей-неволей понадобится и поддержка hardware flow control в коммандном режиме.

И все же не могу понять, зачем постоянно так мужественно преодолевать трудности... Ведь есть в сотню раз проще подход - взять Quectel ОЦПУ, написать 10-20 строчек обработки в callback-функции чтения (доступны и айпи-порт отправителя, и длина датаграммы, и сама датаграмма в ОТДЕЛЬНЫХ переменных), чтобы необходимые данные в УДОБНОМ для Вас формате выдавались в нужный UART на ваш внешний контроллер.
Легко можно и формат телита сэмулировать, и нужные АТ-команды САМОМУ дописать в ЛЮБОМ формате...
Вобще, в оцпу в паре с внешним процом несоизмеримо уменьшит затраты на разработку софта.

— …предлагаю вам взять несколько журналов — в пользу детей Германии! По полтиннику штука!
— Нет, не возьму.
— Но почему вы отказываетесь?
— Не хочу.
— Вы не сочувствуете детям Германии?
— Сочувствую.
— А, полтинника жалко?!
— Нет.
— Так почему же?
— Не хочу.

Да и решение мягко говоря неудачное. Представляете, будете поддерживать не одну прошивку, а две. И на производстве прошивать и процессор и модуль. А когда модуль проапгрейдится, так вообще зоопарк начнется.

Когда девайс выпускается в значительных количествах, то бывает такой парадокс - проще использовать более дорогие запчасти, но прошивать ОДИН процессор, чем ставить жменьку более дешевых и заниматься прошивкой Н запчастей на плате ( в данном случае двух ). Это разработчику тоже приходится учитывать.

Хехе. Опередили

Сообщение отредактировал butthead2 - Nov 9 2011, 09:30

Симкомовцы предложили в связи с уменьшением выводов сделать "only gprs" модуль в маленьком форм факторе с выводами по двум сторонам как в 800E. Сказали что МТК чипсет даже и не будут рассматривать для европейского региона и им проще сделать новый модуль в цену 800Е, чем потом отбиваться от того что он прожил пару тройку лет. Поэтому вместо поставок 800й серии будет еще один модуль в 900-й.
Кстати еще один из вариантов который они рассматривают, сделать пин-то-пин с М72, только добавить вход зарядного на место зарезервированых контактов.

Так что на рассмотрении сейчас три варианта.
пин-то-пин SIM900R, но с кучей пустых ножек
пин-то-пин М72 + зарядное
двустороннее расположение в максимально малом корпусе

если быстро закончим согласование, то увидим модули еще в этом году.

Не пора ли Симкому уже отказаться от идеи слепить нормальное зарядное? Всё равно все ставят внешнее... так хоть не пришлось бы платить дважды.