Перейти к содержанию
    

Redguy

Участник
  • Постов

    42
  • Зарегистрирован

  • Посещение

Репутация

0 Обычный

Информация о Redguy

  • Звание
    Участник
    Участник
  • День рождения 14.05.1986

Контакты

  • ICQ
    Array

Информация

  • Город
    Array

Посетители профиля

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

    Добрый вечер, я особо не в курсе, но немного знаком с PIC32. Здесь читали? Я посмотрел бегло, там есть формула зависимости напряжения от температуры. Напряжение исходя из настроек АЦП получить можно, остальное либо константы, либо настраивается. Точной формулы нет и не будет, написано, что зависит от настроек источника тока, как от параметра, поэтому у каждой настройки своя уникальная формула пересчета.
  3. Сначала пробовали и СС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, как к слишком замороченной/засекреченной оси. Ни чихнуть, ни плюнуть там нельзя толком, для обычного пользователя может хорошо, что минимум разрешенного, но для разработчика руки и ноги связываются конкретно. Но это в большей степени относится к части приложения, а не к железке.
  4. Для начала я бы ушел от процентного представления занятой памяти. Более точно все-таки в байтах в map-файле посмотреть сколько конкретно занимает ваша программа. Второй момент нужно посмотреть linker файл после того, как вы установили смещение, убедиться, что смещение происходит действительно на нужное количество байт. А потом посмотреть чисто математически укладывается ли программа в предоставленный ей объем. Самое главное: а ошибку-то какую получаете, ошибку компилятора или линковщика, какую конкретно? Компилятор не компонует код, он только формиует рабочие куски кода с определенными входными аргументами, выходными параметрами, определенной длины. А вот линковщик уже эти готовые рабочие (100% проверенные) куски размещает в памяти по правилам заданным в линкер-файле и настраивает взаимосвязи между ними.
  5. Добрый день! Контроллеру абсолютно все равно в какой кодировке вы "закодировали" текст. Компилятор ему подсовывает конкретные значения в зависимости от кодировки настроенной в среде. По умолчанию MPLab использует Win-1251 для конвертации. Точно не помню, но по-моему, этот параметр можно изменить в настройке проекта, опять же это может зависеть от версии среды 8 или X. Что в первом, что во втором случае в вашем коде это будет интерпретировано одинаково. Ответ по проблеме неправильной конвертации при выводе на LCD кроется в самом драйвере LCD, который вы используете, т.е. вся магия происходит после вызова функции viewStr. Что там такое и какая таблица для декодирования символов в пиксели заложена у вас искать надо там.
  6. Выскажу частное предположение. Может быть затык связан с битами конфигурации? Например, в hex-файл они не включены, и при заливке они тягаются из значений по умолчанию, а в разных версиях среды они разные. Чтение с залитых в двух случаях чипов hex и сравнение должно дать ответ по каким адресам различия начались, и собственно почему контрольная сумма отличается.
  7. Добрый день! Самому мне не приходилось ни разу заниматься сверкой контрольных сумм, независимо от версий всегда заливалось на ура. Но при этом, я регулярно практикую заливку готового 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 для всех (до конца неуверен, что для всех, не проверял) программаторов и чипов.
  8. И теоретически и практически такое возможно. Причем это выполнимо не только для PIC32, а для микроконтроллеров в целом. Но эта задача не настолько проста, и сколько тут всплывет подводных камней даже предположить сложно. Я бы пошел следующим путем. Накатал какую-то минимальную программу, которая будет по SPI читать основной код, подгружать его в оперативку или во внутреннюю flash и запускать его на выполнение, при этом возможно использовал бы DMA. Тут возникает много моментов: насколько большой должен быть выполняемый код, будут ли в нем пересечения с обслуживающей программой по ресурсам, как регулярно надо запускать обслуживающую программу, нужно ли на неё постоянно переключаться для какого-либо монитора ситуации (по принципу работы операционки) и т.д. По сути bootloader на этот вариант похож - по определенным командам/условиям запускается, загружает что надо, запускает загруженное и самоустраняется. Реально у меня до такой ситуации и доходило: максимум - загрузка нового образа рабочей программы на внешнюю Flash, ее контроль на целостность и замена текущей программы на новый образ с последующим запуском и инициирование загрузки новой прошивки по команде полученной через USART.
  9. Добрый день. Я так думаю в тексте опечатка и модуль не GSM900R, а SIM900R. Если да, то тогда для поиска проблем с аппаратной частью лучше обратиться к ветке http://electronix.ru/forum/index.php?showforum=130 Причем там уже есть огромное количество тем и с проблемами и с решениями по использованию конкретных модулей. Рекомендую сначала воспользоваться поиском и, если результаты не удовлетворят, то создать новую тему с просьбой покритиковать схему.
  10. На самом деле, если повнимательней приглядеться к настройкам проекта, то симулятор для этого контроллера не совсем в конечном варианте. Присутствует желто-зеленый значок, а при наведении надпись, что он еще в beta-состоянии. beta она и в Африке beta :) Вот оттуда могут быть и разногласия
  11. Открыл проект, скомпилил, запустил отладчик. Все работает как часы, как написано в программе. Никаких глюков не замечено. До команды movwf TRISA все ножки порта А настроены на вход, после: только RA3 - вход, остальные - выход. У меня версия MPLABX 2.26.
  12. Так и есть. У PIC в регистрах TRIS значение "0" настраивает ножку на выход, поэтому симулятор не врет
  13. В терминале отображается формат 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
  14. В мануале на 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 — невозможно определить
×
×
  • Создать...