ДЕЙЛ

Мне нужно в перспективе реализовать удалённую смену прошивки, а для этого нужен тот самый пользовательский загрузчик, ожидающий программу извне. Но т.к. в этом деле пока ноль, то хочу сначала освоить основы. Это как с освоением способов обмена данными между программой на ПК и МК: сначала учимся отправлять-принимать байт, потом групповую передачу массива байтов, потом осваиваем алгоритмы обнаружения ошибок и т.д. Мало кто сразу начинает с освоения протоколов, минуя этап лицезрения отправки байта. Вот и я сначала хочу азы освоить. Уже интереснее. :) Как это сделать в IAR? И можно ли таким способом по одному адресу раздельно записать загрузчик, а по другому программу? Т.е. по очереди два файла загрузить. Флеш полностью не стирается перед записью? UP1: В IAR нашёл настройку начальных адресов: Options -> Linker -> вкладка Config -> кнопка Edit

Пробежался по ссылкам. Я пока хочу понять сами основы, а не тонкости реализации. Пока понял так, что загрузчик и программе есть абсолютно независимые программы, связь между которыми в самом простом случае на уровне ассемблерной инструкции JMP Program_addres или JMP Bootloader_addres. Так? Если скомпилировать бинарный файл прошивки и записать его по нестандартному адресу флеш (не 0x0000, а, допустим, по адресу 0x30000, вставив по адресу 0x0000 инструкцию JMP 0x30000), то программа будет работоспособной или компилятор делает привязку к абсолютным адресам? Пока не рассматриваю конкретный МК. Как реализовать на Си запись данных во флеш по конкретным адресам в LPC1778? Интересно посмотреть пример кода. Можно даташит пожевать или у гугла спросить, но если кто-то может за пять минут сказать то, что я могу полдня искать, то лучше спросить. Иначе на форуме тогда не было бы смысла читать-писать :) я свои измышления пишу, в этой теме пока на нуле

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

В начале находится таблица векторов прерываний. Пока нет желания возиться с её переносом. Я так понял, что расположение загрузчика в памяти непринципиально? Главное не затирать код программы. И ещё попутный вопрос. Как в С сделать условный переход программы на определённый адрес флеш? На ассемблере это JMP adres, JMZ adres, JMN adres и т.п. Как это будет выглядеть на С?

Хочется понять, как работает эта штука? В моём представлении это маленькая программа, находящаяся где-то в хвосте флеш-памяти. При старте начинается выполнение программы с нулевого адреса, где проверяется выполнение какого-то условия, например, уровень на определённой ножке. Если условие выполняется, то следует инструкция вроде JMP Bootloader, т.е. переход в область флеш, содержащей команды загрузчика, которые выполняет ЦПУ. Загрузчик принимает данные в виде файла *.bin по какому-либо интерфейсу МК, эти данные он раскладывает во флеш-памяти, затирая старую версию прошивки. Причём в новой версии программы должна быть та же самая процедура перехода в область загрузчика на случай следующего обновления. Если в этом месте мысли правильные, то дальше имеются мысли по поводу организации самопального загрузчика: 1. Пишется программа загрузчика - процедуры приёма и раскладки данных в памяти, компилируется в виде файла *.bin. 2. Пишется программа для записи полученного файла куда-нибудь в дальний угол памяти, начиная с определённого адреса, допустим 0х1000000. Всё, загрузчик находится в памяти. 3. Пишем рабочую программу, которая в самом начале содержит условие с переходом вроде JMP 0x1000000. Размер прошивки должен быть всегда такой, чтобы не затёрся код загрузчика. Примерно такие у меня измышления. Насколько они правильные? Если правильные, то имеются попутные вопросы: 1. Как организовать запись байта по определённому адресу флеш на С в IAR? 2. В MSP430 перед изменением флеш нужно предварительно настроить контроллер флеш-памяти. Как обстоит дело в LPC1778? 3. Если в LPC1778 прошивка записывается через UART0, то там уже есть загрузчик? Если он есть, то можно ли его случайно стереть? Где можно подробнее почитать на эту тему с самого нуля с пошаговой инструкцией создания загрузчика? P.S Вынтернете гуглил на эту тему ровно несколько минут, попадались всякие описания загрузчиков планшетов, смартфонов и прочих девайсов.

Заработало :yeah: Как только дошло до железа, так сразу всё на своих местах оказалось. Пустой проект по последней сылке работоспособен в железе. Давно уже меня так сильно не подводил эмулятор. Или какие-то тонкости отладки операционки в симуляторе имеются?

Имеется код вот отсюда http://microsin.ru/content/view/1304/44/ int main( void ) { xTaskCreate( vTask1, "Task 1", 1000, NULL, 1, NULL ); xTaskCreate( vTask2, "Task 2", 1000, NULL, 1, NULL ); vTaskStartScheduler(); for(;; ); } void vTask1( void *pvParameters ) { int i; for(;; ) { i++; } } void vTask2( void *pvParameters ) { int j; for(;; ) { j++; } } как мне сделать так, чтобы он компилировался в IARе и работал в LPC1778? Хочется получить проект с минимальным набором файлов

в предыдущей урезке отладчик зависал в немаскируемом прерывании. В сегодняшней версии почему-то только именно в последней задаче висит. До железа пока руки не доходят. Интересно узнать, много здесь знающих спецов по FreeRTOS бывает? А то сам с собой тут разговариваю :rolleyes: FreeRTOS_______________________.rar

урезал текст файла main.c демо-проекта до минимума, затем этот текст вставил в чистый проект и стал добавлять файлы из папки пока компилятор не перестал материться. Вроде пока ошибок нет, но почему-то получилось пара десятков файлов вместо заявленных нескольких? И в отладчике почемуто ни в одну задачу не входит. Что нужно изменить, чтобы программа входила в задачи поочерёдно? Приоритет подправил, заменив на одинаковые. FreeRTOS___.rar

Ткнулся в переменную, дошёл в итоге до кода в файле FreeRTOSconfig #ifdef __ICCARM__ #include "LPC17xx.h" extern void vConfigureTimerForRunTimeStats( void ); #define portCONFIGURE_TIMER_FOR_RUN_TIME_STATS() vConfigureTimerForRunTimeStats() #define portGET_RUN_TIME_COUNTER_VALUE()[b] TIM0[/b]->TC #endif Что с ней дальше делать? В файле "LPC17xx.h" есть переменные LPC_TIM0 и LPC_TIM0_BASE, при замене которых вместо TIM0 выскакивают другие ошибки

Он показывает на строку с какой-то функцией, в которой этой переменной нет. Скрин сделать не могу, т.к. на рабочем компе IAR залез в тырнет, сломался и какую-то лицензию требует. Если не сложно, то попробуйте откомпилировать и ткнуть.

вернулся к копанию в FreeRTOS Пытаюсь собрать проект по самому минимум, пока показал 8 предупреждений, но они поправимы - тактирование можно вручную настроить. Совсем непонятно, на какие переменные "TIM0" ругается компилятор? Её нет ни в одном файле проекта, искал поиском по словам. RTOS_LPC.rar

Если имеется аккумулятор 4 вольта, а нужно получить 3, то самый простой вариант - последовательно с нагрузкой включить кремниевый диод или светодиод, который возьмёт на свой PN-переход часть напряжения. Можно скомбинировать последовательно кремниевый диод(0.6В) и два германиевых(по 0.2). На выходе будем иметь 3 вольта. Но лучше вычесть 0.8В, т.к. МК наверно имеет диапазон питающего напряжения до 3.3В, т.е. оставить запас для просаживания напряжения аккумулятора до 3.8..3.7В. На МК в этом случае напряжение упадёт с 3.2 до 3.0..2.9В.

Попробовал скомпилировать, при открытии проекта IAR два раза поругался, как видно на скринах, но компилируется нормально. Далее я почистил код, оставив пустые задачи. На этом этапе тоже скомпилировалось. Хотел добавить свой код - начал с добавления настроек тактирования и UART0. IAR тут же начал меня ругать, что переменные неопределены. Добавил библиотеку iolpc1778.h, но почему-то появилась другая ошибка. Что не так? И ещё хотелось бы иметь проект только с одной операционкой, которую можно наращивать. В скаченном файле слишком много лишних файлов, как мне кажется.

Попробовал записать в один из 16 регистров FIFO - записываю в один, меняется содержимое сразу во всех. У каждого регистра свой отдельный адрес. Как токое может быть? На скрине режим пошаговой отладки в железе.

Продолжаю ковыряться с SD-картой. С алгоритмом инициализации, чтения и записи самой карты в общих чертах разобрался. Теперь копаюсь с интерфейсом карты со стороны МК. В нём имеется буфер FIFO, с которым у меня появились непонятки. Насколько я понимаю, этот буфер проталкивает через себя 32битные слова от начала к хвосту по мере появления данных в начальной ячейке. Настроил срабатывание прерывания по каждому заполнению буфера, т.е. 16*4=64 байта. Тут всё нормально. Дальше в прерывании останавливаю SD_CLK, принятые данные копирую для передачи на ПК, сбрасываю флаг заполнения и опять включаю SD_CLK. Только почему-то получается такая ерунда, что во всех ячейках буфера одинаковые данные, причём такая картина и в режиме отладки, и в обычном режиме работы. Какая тут может быть причина? Можно было бы код приложить, но его от всего лишнего чистить нужно долго - там вся инициализация и команды чтения-записи выполняется с ПК через UART. Надеюсь, что кто-то из местных наблюдал у себя такую картину. Интересно было бы узнать, на что нужно обратить внимание.

Днём покопаюсь в коде, а пока читаю вот тут habrahabr.ru/post/213803/ Насколько правильно там всё описано? Я пока застрял на ожидании ответа на ACMD41 с установленными в аргументе битами 30 и 20(3.2 - 3.3В). Предполагаемого ответа в виде содержимого регистра OCR с установленной единицей в 31 бите пока не вижу. Только изменился бит 0 в ответе R1 на нулевой. UP1: Проблема в описании по ссылке - автор по памяти наверно писал и упустил один момент. Делал как тут http://we.easyelectronics.ru/AVR/mmcsd-i-a...tifikaciya.html и вроде дальше продвинулся, читаю дальше http://we.easyelectronics.ru/AVR/mmcsd-i-a...a-s-kartoy.html и вроде пока получилось считать регистр CSD.

Опять имеются непонятки. При отправке команды CMD0 в карту возвращается ответ с установленным битом In Idle State, т.е. говорит, что карта в нерабочем состоянии. Но карточка рабочая - телефон её видит. Этот ответ с установленным нулевым битом допустим? В одном из описаний процесса инициализации после команды CMD0 ожидается ответ 0x00, а у меня почему-то всегда 0x01. Что тут не так может быть? Для пробы отправлял заведомо левую команду - бит 2 устанавливался, т.е. карта сказала, что команда неправильная. Тут всё нормально, но и бит 0 тоже всё равно в единицу установлен. Карта 8 гигов. Надо полагать, что SDHC. Частота тактирования 300 кГц. UP1. Отправил CMD8 c аргументом 0x1AA, т.е. указал карте питание хоста 2.7-3.5В, ответ пришёл вроде нормальный, т.е. с 0x1АА в хвосте, но бит 0 в ответе всё равно остался установленным.

а не проще применить синхронный детектор? С ним можно добиться любой точности, которая ограничена только стабильностью частоты сигналов.

Читаю описание команд и пока непонятна разница между командами CMD и ACMD. К примеру, CMD10 означает, что в поле индекса команды записывается число 10 или 0xA, а в чём отличие команды ACMD10? http://habrahabr.ru/post/213803/ Т.е. команда ACMD10 равносильна последовательной передаче CMD55 с пустым аргументом и команды CMD10? Если так, то нужно ли ждать окончания ответа на команду CMD55 или сразу отсылать CMD10?

не стал вникать в код из первого сообщения, но так понял, что контроллер шлёт данные, а программа на компе иногда не видит некоторых символов. Если контроллер работает только на передачу и со стороны компьютера никаких запросов нет, то для начала нужно определиться с неисправным звеном - МК или ПК. Самый простой способ - распаралеллить данные с МК на два компьютера с запущенной принимающей программой и сравнивать. Если пропуски будут совпадать на обоих компах, то проблема в МК, если вразнобой, то косяк на стороне ПК. Если выяснится, что дело в контроллере, то нужно будет оставить только функцию отправки данных, отключить все лишние прерывания и в бесконечном цикле гнать заранее известные данные на ПК. Если опять будут встречаться пропуски, то дело может быть в частоте кварца и если эти пропуски раз в час-два, то тут уместно будет применить контрольную сумму, если есть возможность изменить программу на компьютере. Для проверки плавания частоты можно всю плату погеть феном, одновременно наблюдая за отправляемыми данными. упорядоченое описание на русском языке функций CMSIS есть в приложении к этой книге http://www.twirpx.com/file/1136980/ В продаже она есть в терраэлектронике.

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

Аналогичная ситуация и с другими модулями - если в регистре PCONP не установлен бит включения, то при чтении-записи регистров соответствующего модуля МК сработает криво.

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

Начал изучать алгоритм чтения-записи данных на карту SD, для этого перевёл соответствующий раздел из LPC178x/7x User manual Rev. 2.1 — 6 March 2013. Пдфка прикреплена к сообщению. Нет уверенности, что перевод безошибочный, поэтому хотелось бы иметь критику со стороны, т.е. просьба к здешним читателям-писателям почитать мой перевод и указать на принципиальные ошибки, если таковые имеются. Существует ли какое-то упорядоченное и подробное описание команд работы с SD-картой? Желательно на русском языке. А ещё интересно посмотреть демонстрационный пример работы с картой памяти объёмом больше 4 ГГб. добавил более позднюю версию перевода, в предыдущей забыл две таблицы вставить ________SD_______.pdf