Эксперимент покажет что все работает- неработает на ДАННОМ ЭКЗЕМПЛЯРЕ контроллера.
Для правильного эксперимента нужно сделать не так. Нужно взять контроллер, вывести на ножку частоту и контролировать ее частотомером - для контроля текущей частоты. Через уарт общатся с модулем. И напрмер по нажатию кнопки менять на некоторый шаг тактовую частоту контроллера. И в обе стороны по частотомеру определить при каком отклонении обмен начниает сбоить.

Совет: забудьте о безкварцевой конфигурации, иначе потом в серии будут проблемы, это уже проверено. Причем проблемы будут весьма труднолокализуемые: обмен будет сбоить не каждый раз, а иногда. И много дней уйдет на поиски причин спонтанных отказов.
Лично я только сторонник экономии: например, никогда ключи не ставлю на управление диодами, не тратюсь на ненужное согласование уровней и т.п.
Но это - не тот случай, поверьте.

Безкварцевая конфигурация -- это, скорей, когда используется часовой кварц, по которому постоянно подстраивается внутренний генератор. Часовой кварц, причём, постоянно работающий (его запуск занимает ещё более значительное время). Безкварцевая конфигурация актуальна только для микропотребляющих приборов с часами реального времени. И смысл отсутствия кварца на XX МГц в ней даже не снижение себестоимости, а экономия энергии.



Вдогонку. Проценты погрешности считать нужно и для самого модема тоже и складывать с погрешностью генератора PIC. В итоге ситуация нерадостная оказывается.

Если заеду в одну из местных контор - сфоткаю ценник с кварцем - вышлю ;-)


Это единственное что по теме хотелось бы услышать - что с внутренними генераторами работать будет нестабильно на основании массового опыта. Все. Рассуждения об экономике меня вообще не касаются.



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



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

Это уже когда генератор заработал и уровень сигнала достиг порога. С этого момента - еще 1024 такта. А полное время - существенно больше. Поэтому в батарейных приложениях бывают сложности.




И опять же неправда. Если у генератора нет встроенных конденсаторов, то внешние - необходимы. Согласно даташиту.


Вы, наверное, удивитесь, но у PC-шных COM-портов тоже вовсе не точные значения...

Согласно даташиту - да. Но согласно практике, на тысячах устройств на PIC работает все без конденсаторов с кварцами, посталяемыми Гаммой, в частности. Вот тут как раз можно и сэкономить.

Экономьте, экономьте... Дарю ценную идею - еще можно "съэкономить" на блокировочных кондендансаторах в цепи питания. Их много, а и без них работает. Потребитель будет очень благодарен...

Сообщение отредактировал rx3apf - Oct 20 2011, 17:08

Честно говоря очень удивлюсь. В стандартном контроллере rs232 ( интел как его там, запамятовал ) стоял кварц 1,8432МГц. Откуда взяться неточным значениям? Хотя могли уже давно все извратить...

Так то ж в стандартном...Теперь обычно 24 MHz/13. Погрешность незначительна, но тем не менее. Подозреваю, что и у модуля тоже опорник вовсе не кратный...

Дык и нецелые коэффициенты деления никто не отменял. А с ними можно загнать погрешность в такие исчезающе малые проценты, что на фоне фронтов физического сигнала никто и не догадается. Да и смысла добиватся менее 0,1% нету - работать и так будет всегда.

тогда опять вопрос - 0,1% погрешности - это нормально и работать будет. А сколько уже не будет? 0,2% - уже не будет.
Мне просто интересно - обычно на практике сколько допустимо отклонение. Например, 1% - это много?

Старт-бит, 8 инфобит, стоп-бит. Синхронизация приемника проводится в начале каждого байта по началу старт-бита. Выборка, будем считать, проводится в средине предполагаемого инфобита. Будет сбоить, если в конце байта выборка будет произведена или в предыдущем бите, или в стоповом. Итого: за время передачи 9 бит ошибка не должна превышать полбита (абсолютный максимум !). Итого плюс-минус 5% - критическое значение.

И еще (из практики) - в виду особенности UART PIC, при использовании неточных (целых) кварцев, лучше сделать скорость передачи БОЛЬШЕ рассчетной, чем меньше. Иначе UART PIC дает сбои приема в первую очередь (более чувствителен, чем UART модулей SIMCOM).

Сообщение отредактировал GeGeL - Oct 20 2011, 18:29

Только проверять. Типично UART свободно переваривает отклонение на пару процентов (все должно работать, даже если с обоих сторон уйдет на два процента в разные стороны). Но про модули от SIMCOM рассказывают какие-то страсти-мордасти, мне лично кажущиеся сомнительными. Однако, есть такая неприятная вещь, как автодетект скорости, который и при точном (почти) совпадении скоростей не очень-то стабильно работает. И нисколько не удивлюсь, если при более-менее существенном отклонении возникнут проблемы. По-хорошему, надо зафиксировать скорость (+IPR=), и потом проверять надежность при отклонении скорости передатчика. Ну, и то же самое с включенным автодетектом, чтобы знать наверняка, кто виноват и что делать. Ну, это кому нужно, пусть и делает...

Сообщение отредактировал rx3apf - Oct 20 2011, 18:28

Да с автодетектом у SIM900 писали что и так проблемы есть. Я делаю программирование на 9600 (мне достаточно) сразу. Да и вообще записываю это на "постоянку" в &W. Блин ну ладно тогда будет время потестим и это.

Я с этим лично столкнулся на sim900. На 115200 не хотел слушать в режиме по умолчанию, пока не дал чуть ЗАНИЖЕННУЮ скорость с PIC. А автодетект там вобще какой-то странный, не так совсем, как в сим300.
Было принято решение на старте пика каждый раз давать AT+IPR=57600 (чтобы "чистый" модуль фиксировать на эту скорость) наскорости чуть НИЖЕ 115200, а затем переключать UART PIC на скорость чуть ВЫШЕ 57600, и далее все шло ОК. Извраты...

Сообщение отредактировал GeGeL - Oct 20 2011, 18:56