Redguy

Почему так ? SSP2CON1bits.SSPEN = 0; В разделе 19.3.4 написано: UPD. Ах, да. Позже разглядел включение после всей настройки. Но все равно не понял, зачем два раза сбрасывать бит.

Добрый вечер, я особо не в курсе, но немного знаком с PIC32. Здесь читали? Я посмотрел бегло, там есть формула зависимости напряжения от температуры. Напряжение исходя из настроек АЦП получить можно, остальное либо константы, либо настраивается. Точной формулы нет и не будет, написано, что зависит от настроек источника тока, как от параметра, поэтому у каждой настройки своя уникальная формула пересчета.

Сначала пробовали и СС2640 (128 кБайт ROM и 8 кБайт RAM), и даже выпустили несолько прототипов на них. Проблемы возникли сразу. Сначала долго разбирались, как прошивать свои платы, потом при некотором стечении обстоятельств окирпичили несколько штук, пока не нашли зависимость и вроде приловчились. Потом вышла очередная версия IARа, которая сама стала кирпичить ЦЦхи, но и тут нашли как выкручиваться. Потом дело дошло до того, что мы уперлись в потолок по памяти, главным образом по ОЗУ. Если следовать рекомендациям по распределению памяти от самих же TI, то для работы с iOS там требуется очень большой кусок в оперативе для heap, тогда там мало чего остается для нашего приложения. Но у каждого свои потребности. Программатор-отладчик жутко тормозит, что в заливке, что в пошаговой отладке, пока он там каждую новую инструкцию переваривает, проходит много времени. Поэтому было принято решение перейти на nRF52832, у нее памяти намного хватит (512 кБайт ROM, 64 кБайт RAM). Тут все практически здорово. Получили отладку, несколько дополнительных сэмплов чипов, открываем проект, компилим, все компилится СРАЗУ, а не как у ТИ через одно место пока не пролезешь. Собрали на макетке свой референс, все шьется, работает СРАЗУ. С периферией и все, что необходимо по для запуска BLE разобрались за три дня. Все устраивает. Есть одна нерешенная проблема - в отладке IAR невозможно тормозить в точке останова, если включен блютус стек, иначе вываливается в hard fault, приходится либо использовать UART, либо косвенными методами, либо кусками отлаживать. Сейчас собрали уже несколько вариантов устройств и все работает нормально. Да, еще понравилось у nRF, что можно залит программу и все. Хочешь дальше отлаживай, хочешь сразу запускай, а у СС для отладки надо один бит выставлять, и переключение из релиза в дебаг и обратно требует постоянной перезаливки прошивки полностью. Документация и у тех и у других хромает, есть много пробелов или непонятностей. Правда, есть очень хорошие форумы поддержки, на которых либо уже эти проблемы решены, либо, помогут решить их специалисты или коллеги, попавшие в такую же яму. Хотя было несколько раз, что "спасение утопающего..." сам на свои же вопросы и отвечаешь. На ЦЦ, читали на их сайте, что можно добиться до 300кбит/с, но это максимум по определенному алгоритму. Реально не проверяли, но думаю, со служебной информацией будет все на порядок ниже. Да и новый BLE stack вышел недавно, может что-то изменилось. На nRF до недавнего времени было что-то типа 150кбит/с достижимо, опять же при определенных условиях SD v2.0 страницы 79-80. Заливали обновление прошивки их стандартными средствами (т.е. вагон служебной информации, необходимые запросы-ответы, алгоритмы по сохранению и пр.) ~100кБайт секунд за 30 льется. Но совсем недавно вышла новая версия SoftDevice v3.0 страницы 81-83, говорят, что скорость повысилась до 700-800 кбит/с. Проверить увеличение скорости пока не удалось, руки не дошли. Испытывалось на sumsung glaxy s3 и iphone 5c. :bb-offtopic: Нарекания есть только к iOS, как к слишком замороченной/засекреченной оси. Ни чихнуть, ни плюнуть там нельзя толком, для обычного пользователя может хорошо, что минимум разрешенного, но для разработчика руки и ноги связываются конкретно. Но это в большей степени относится к части приложения, а не к железке.

Для начала я бы ушел от процентного представления занятой памяти. Более точно все-таки в байтах в map-файле посмотреть сколько конкретно занимает ваша программа. Второй момент нужно посмотреть linker файл после того, как вы установили смещение, убедиться, что смещение происходит действительно на нужное количество байт. А потом посмотреть чисто математически укладывается ли программа в предоставленный ей объем. Самое главное: а ошибку-то какую получаете, ошибку компилятора или линковщика, какую конкретно? Компилятор не компонует код, он только формиует рабочие куски кода с определенными входными аргументами, выходными параметрами, определенной длины. А вот линковщик уже эти готовые рабочие (100% проверенные) куски размещает в памяти по правилам заданным в линкер-файле и настраивает взаимосвязи между ними.

Еще вариант посмотреть SIM800F

Добрый день! Контроллеру абсолютно все равно в какой кодировке вы "закодировали" текст. Компилятор ему подсовывает конкретные значения в зависимости от кодировки настроенной в среде. По умолчанию MPLab использует Win-1251 для конвертации. Точно не помню, но по-моему, этот параметр можно изменить в настройке проекта, опять же это может зависеть от версии среды 8 или X. Что в первом, что во втором случае в вашем коде это будет интерпретировано одинаково. Ответ по проблеме неправильной конвертации при выводе на LCD кроется в самом драйвере LCD, который вы используете, т.е. вся магия происходит после вызова функции viewStr. Что там такое и какая таблица для декодирования символов в пиксели заложена у вас искать надо там.

Выскажу частное предположение. Может быть затык связан с битами конфигурации? Например, в hex-файл они не включены, и при заливке они тягаются из значений по умолчанию, а в разных версиях среды они разные. Чтение с залитых в двух случаях чипов hex и сравнение должно дать ответ по каким адресам различия начались, и собственно почему контрольная сумма отличается.

Добрый день! Самому мне не приходилось ни разу заниматься сверкой контрольных сумм, независимо от версий всегда заливалось на ура. Но при этом, я регулярно практикую заливку готового hex на партию устройств не с помощью MPLab, а с помощью спец.программ идущих с программатором. Например, у меня PicKit2 и PicKit3, для них есть соответствующие программы PicKit2.exe и PicKit3.exe. Они весят меньше, ИМХО с ними проще и быстрее. Что бы я делал в вашей ситуации: 1. Слил бы самую последнюю версию MPLAB IDE (вкладка Downloads Archive) . На текущий момент 8.92. Версии 8.12 на офф.сайте я не увидел. Если это был баг среды, то скорее всего они его исправили. 2. Вариант попробовать MPLAB X. Он очень прожорливый и неповоротный для "медленных" компов, но как вариант тоже сгодится. 3. С MPLabX в комплекте идет программа MPLAB IPE - универсальная программа заливки hex для всех (до конца неуверен, что для всех, не проверял) программаторов и чипов.

И теоретически и практически такое возможно. Причем это выполнимо не только для PIC32, а для микроконтроллеров в целом. Но эта задача не настолько проста, и сколько тут всплывет подводных камней даже предположить сложно. Я бы пошел следующим путем. Накатал какую-то минимальную программу, которая будет по SPI читать основной код, подгружать его в оперативку или во внутреннюю flash и запускать его на выполнение, при этом возможно использовал бы DMA. Тут возникает много моментов: насколько большой должен быть выполняемый код, будут ли в нем пересечения с обслуживающей программой по ресурсам, как регулярно надо запускать обслуживающую программу, нужно ли на неё постоянно переключаться для какого-либо монитора ситуации (по принципу работы операционки) и т.д. По сути bootloader на этот вариант похож - по определенным командам/условиям запускается, загружает что надо, запускает загруженное и самоустраняется. Реально у меня до такой ситуации и доходило: максимум - загрузка нового образа рабочей программы на внешнюю Flash, ее контроль на целостность и замена текущей программы на новый образ с последующим запуском и инициирование загрузки новой прошивки по команде полученной через USART.

Добрый день. Я так думаю в тексте опечатка и модуль не GSM900R, а SIM900R. Если да, то тогда для поиска проблем с аппаратной частью лучше обратиться к ветке http://electronix.ru/forum/index.php?showforum=130 Причем там уже есть огромное количество тем и с проблемами и с решениями по использованию конкретных модулей. Рекомендую сначала воспользоваться поиском и, если результаты не удовлетворят, то создать новую тему с просьбой покритиковать схему.

На самом деле, если повнимательней приглядеться к настройкам проекта, то симулятор для этого контроллера не совсем в конечном варианте. Присутствует желто-зеленый значок, а при наведении надпись, что он еще в beta-состоянии. beta она и в Африке beta :) Вот оттуда могут быть и разногласия

Открыл проект, скомпилил, запустил отладчик. Все работает как часы, как написано в программе. Никаких глюков не замечено. До команды movwf TRISA все ножки порта А настроены на вход, после: только RA3 - вход, остальные - выход. У меня версия MPLABX 2.26.

Так и есть. У PIC в регистрах TRIS значение "0" настраивает ножку на выход, поэтому симулятор не врет

В терминале отображается формат ASCII, где цифры представляются в виде 0x30-0x39 (0-9). Соответственно, если надо получить нужно число, то надо сначала проверить принятые байты на этот диапазон, а потом из каждого байта вычесть 0x30 (48), тогда получатся значения разрядов десятков и единиц. Далее первое полученное число умножить на 0x0A (10) и прибавить к этому второе, то получится значение в одном байте, а уж дальше формат преставления зависит только от вас, как вам больше нравится. В терминале у вас приходят a=0x32 и b=0x34, тогда a = a - 0x30 --> a = 2 b = b - 0x30 --> b = 4 с = a * 10 + b --> с = 24 или с = a * 0x0A + b --> с = 0x18 (dec 24) Такой вариант тоже вполне подходит, ведь если отбросить старшую тетраду, на конечное значение цифры это никак не повлияет, но тут если нет предварительной проверки на допустимый диапазон, то можно на символы 'C' (0x43) и 'S' (0x53) подумать ту же самую '3' (0x33). не уверен, что сразу после сложения двух байт, которые содержат значения меньше h'10' (после операции 'И' c B'00001111'), получится значение h'24' Как написать на ассемблере подумать можно, но что-то я подзабывать его стал. Хотя по формату команды похоже на PIC16

В мануале на AT команды сказано, что идет два параметра: <rssi> и <ber>. Меня всегда интересовал только <rssi>, значения выводятся в десятичном формате по следующему принципу: 0 => -115 dBm или меньше 1 => -111 dBm 2...30 => -110... -54 dBm 31 => -52 dBm или больше 99 => невозможно определить Иными словами, если у вас получилось rssi = 23, то уровень сигнала составляет -68дБм. Про второй параметр написано, что отображается процентах и для подробностей идет ссылка на таблицу стандарта GSM05.08 в пункте 7.4.2 В инете гуглопоиском нашел следующее: bit error rate (в процентах) 0 — менее 0.2% 1 — 0.2% до 0.4% 2 — 0.4% до 0.8% 3 — 0.8% до 1.6% 4 — 1.6% до 3.2% 5 — 3.2% до 6.4% 6 — 6.4% до 12.8% 7 — более 12.8% 99 — невозможно определить

Хотелось бы увидеть ассемблерный код, сгенерированный компилятором. У меня скомпиленный код содержит следующее: ... BCF 0xF81, 0, ACCESS //сбрасывает 1-й вывод в 0 MOVLW 0xA3 MOVWF 0x5, ACCESS MOVLW 0x55 DECFSZ 0xFE8, F, ACCESS BRA 0x7FBA DECFSZ 0x5, F, ACCESS BRA 0x7FBA MOVLW 0xFD //сбрасывает 2-й вывод в 0 MOVWF 0xF81, ACCESS ... тут четко видно, что прописано обращение к конкретному 0-му биту. никак не ко всему порту.

Честно говоря, не очевидна проблема! Автор, сформулируйте, в чем проявляется проблемка. Но на первый беглый взгляд видно, что в комментариях речь идет про один контроллер, а в коде обозначается другой (может это не сильно принципиально, но все ж, комментарии должны соответствовать телу кода). Второе, что мне кинулось в глаза - начало программы располагается директивой ORG 0 и далее поехали... А как же ветор прерывания, который должен располагаться по адресу 0x04? ИМХО Должно быть что-то вроде этого: org 0 ; Начать выполнение программы с 0-го адреса PC. goto Start Start bsf Status,RP0 ; Переход в 1-й банк. movlw 9 ; Установка стандартной скорости обмена: movwf SSPAdd ; Fosc/{4*(SSPAdd+1)}=4Мгц/40=100 Кгц. ... И тогда компилятор переместит этот участок кода туда куда можно, чтобы не наехать на подпрограмму обработки прерывания. Или, если необходимо жестко указать где должен располагаться код, то перед меткой Start добавить, например, org 0x200

Да, согласен. RBIE только на прерывания IOC на портах RB4-7 влияет, я просто отвлекся от основной мысли вот на это А по INT0-2 должно по идее всего хватать. Единственная мысль еще промелькнула, что там может как-то завязано на IPEN и PEIE. По умолчанию IPEN=0, PEIE тоже перевести в 1, поскольку прерывание PORTB тоже прерывание от периферии. И второй вариант попробовать IPEN=1, INT0 при этом будет иметь высокий уровень прерывания, тогда надо GIEH=1 и отладчик в прерывание должен вывалиться в 0х0008. Вроде так. Давно работал с PIC18F45K22, тоже не сразу все получилось, немного поразобраться пришлось.

В том же регистре INTCON бит RBIE в 1 надо еще перевсти. Если не поможет, еще подумаем. PIC надежные, проверено годами! У 16 и 18 серии ни разу с отказами не встречался, и в космос запускали - не подводили.

После настроек необходимых параметров и до чтения файла нужно установить соединение: AT+SAPBR=1,1 // установка GPRS связи для ID = 1 AT+SAPBR=2,1 // получение состояния соединения +SAPBR: 1,1,«x.x.x.x» // для ID = 1 состояние «is connected» с текущим IP = x.x.x.x +SAPBR: 1,3,"x.x.x.x" // для ID = 1 состояние «is closed» (0 – is connecting, 1 – is connected, 2 – is closing, 3 – is closed) AT+FTPCID=1 // переключение ftp-функций на соединение с ID = 1 AT+SAPBR=0,1 // разорвать GPRS соединение с ID = 1

Никто от этого не застрахован. У меня МТС также "шутил" (я был в гневе ) - подключил меня без моего ведома на десяток смс-рассылок общей ценой за 50руб/день. Рассылок не было, потому не сразу понял, что происходит. В личном кабинете на их сайте всё отключил и такое больше не повторялось.

Я сразу после покупки свежего модуля настраивал скорость AT+IPR, а затем уже все что угодно можно настроить по мануалу... Если не ошибаюсь, то для UDP/TCP соединения необязательно.

Когда-то мне необходимо было установить сокетное соединение, для себя составил небольшую таблицу, может отражено, конечно, не все, но может чем-то поможет. А на счет AT+SAPBR? мне казалось, что эти настройки необходимо проводить, если собираешься использовать FTP или HTTP. GSM_module.doc

А тут случайно не происходит перекрывания глобальной "int i" и локальной "unsigned char i"?

Возвращаясь к теме своего поста, нашлась одна небольшая статейка (в приложении). Может кому понадобится для ознакомления. ____________1101.pdf