esaulenka

Я тоже никогда не делал. Пришлось научиться :-) Берём gcc. Пишем: void remap_flash () { asm volatile( "mov r0, #(0x40074000 & 0xFFFF) \r\n" "movt r0, #(0x40074000 >> 16) \r\n" "movs r1, #2 \r\n" "str r1, [r0] \r\n" ); } Вызываем из main(). Смотрим листинг: 080103d8 <remap_flash()>: _Z11remap_flashv(): ... main.cpp:25 asm volatile( "mov r0, #(0x40074000 & 0xFFFF) \r\n" "movt r0, #(0x40074000 >> 16) \r\n" "movs r1, #2 \r\n" "str r1, [r0] \r\n" ); 80103d8: f44f 4080 mov.w r0, #16384; 0x4000 80103dc: f2c4 0007 movt r0, #16391; 0x4007 80103e0: 2102 movs r1, #2 80103e2: 6001 str r1, [r0, #0] 80103e4: 4770 bx lr 80103e6: bf00 nop

Почему же не сработает? Это просто инструкция ядру "запиши по адресу", дальше пусть все эти bus matrix думают, к какому именно устройству Вы хотели обратится. Можно, конечно, написать микро-программку, загрузить её в ОЗУ, сказать Go(нужный адрес). Только мне неочевидно, что произойдёт после завершения этой программы. Подозреваю, обратно в загрузчик надо возвращаться принудительно.

Ох, как-то замороченно у них получилось... Оставили б альтернативные адреса (например, флеш живёт по адресу 0x0800 0000, по спец-команде дополнительно мапится на 0), и всем было б хорошо... Писать/читать регистры периферии можно командами "write to ram" и "read memory".

Да, очереди/семафоры/sleep() с остановленным шедулером не работают. Я поначалу кинулся расставлять проверки "планировщик работает" прямо в код операционки (мне кажется, это правильнее, чем тыкать во все возможные места xTaskGetSchedulerState() ), но потом просто перенёс большую часть кода в задачи (до того у меня вся инициализация железа была в main() - осталось только самое необходимое).

Заранее извиняюсь, что лезу в общий форум с обсуждением правил и модераторов, но постараюсь на личности не переходить :-) На мой взгляд, codebox в его текущей реализации очень неудобен. Зачастую, 90% смысла сообщения - в исходном коде, а чтобы его рассмотреть, приходится вглядываться в это микро-окошко и постоянно скроллить его вверх-вниз. В идеале, конечно же, нужен нормальный просмотр кода - чтобы его можно было растянуть по собственному желанию, с подсветкой и прочими плюшками. Но я, к сожалению, не умею... Давайте хотя б просто пользоваться обычным code ? Пожалуйста! :-)

Как минимум, ошибка здесь: ARR[15:0]: Prescaler value ARR is the value to be loaded in the actual auto-reload register. The counter is blocked while the auto-reload value is null

Попробуйте другую FT232 (или какой-то другой адаптер, вариантов много). Можно попробовать передавать в себя же, замкнув rx-tx. Для начала можно просто принятые байты считать. Если есть осциллограф, стоит посмотреть на линию usart'а, измерить длину бита; проследить что она не меняется, когда приём вдруг ломается. Правда, это маловероятно - только если кварц сбивается, и процессор продолжает работать от встроенного RC-генератора. У меня так получается, только если ткнуть в ноги кварца пинцетом. PS USART1->SR &= ~USART_SR_TC; делать не нужно. Во-первых, он и так скинется при повторном заходе в эту функцию. А во-вторых, правильно делать USART1->SR = ~USART_SR_TC;

Ещё можно https://en.wikipedia.org/wiki/X_Macro вспомнить. Я довольно активно использую разновидность этого метода; разве что вместо #define LIST ... использую отдельный файл со списком. Также вместо X(name) можно использовать несколько разных идентификаторов, и, в зависимости от места, разворачивать их в одинаковые или разные конструкции (например, "указать, какие поля надо сохранять"). PS на stackowerflow мужики развлекаются на полную катушку :-)

Ага-ага, либо вот так, либо common rail. Насос механический в обоих случаях.

Влезу с рекламой-не-в-тему. Есть такая замечательная штука, как 010 editor. Позволяет быстро накидать шаблоны структур, а потом разобрать большой бинарный файл в соответствии с этими структурами. Как использовать в данном случае: - читаем спецификацию на FAT - читаем хелп от этого редактора, пишем соответствующие шаблоны (впрочем, для FAT16 уже есть в комплекте) - пишем для контроллера функцию, которая позволит сохранить дамп памяти этой датафлеш. - сидим и смотрим структуру дампа, получается очень наглядно.

Советики: 1) подозреваю, космодром.ком.уа нагло врёт, и в аккумуляторе схемы заряда нет, есть только схема защиты. Поэтому нужен ещё либо отдельный модуль заряда, либо модуль заряда с низким входным напряжением (есть ли такие у китайцев?..) вместо Вашего "DC-DC-BOOST-MOD-GREEN". 2) если "светодиод пиранья" напрямую воткнуть в литиевый аккумулятор, из него пойдёт дым. Нужно стабилизировать ток.

Удивительная штука эти кокосы... Либо этот файл не используется, либо никто никогда не пробовал с этими исходниками работать. Вопросы: этот кусок вызывается? (проще всего проверить - поставить внутрь брекпоинт). чему равны адреса _sdata, _edata, _sbss, _ebss, _sidata ? Можно посмотреть в map-файле. Заодно можно посмотреть их объявления в скрипте линкера. PS а вообще - давно пора самый минимальный пример куда-нибудь на гугл-диск выложить...

Извините, некогда разбираться. Но именно такую задачу решал полгода назад. С использованием библиотек AHTOXA https://github.com/antongus/stm32tpl получилось примерно так: typedef STM32::TIM::Timer<STM32::TIM::TIM_3> tmr; void Init () { tmr::EnableClocks (); // вход - PC7, TIM3_CH2 // частота таймера - 10 кГц tmr::TIMx->PSC = CLOCK_APB1_TIM / 10000- 1; tmr::TIMx->ARR = 0xFFFF; tmr::TIMx->CR1 = TIM_CR1_CKD_1; // предделитель на 4 для фильтров tmr::Ch2::CCMRx = tmr::Ch1::CCMR_CCS_IC1_CROSS | // первый канал - на второй вход tmr::Ch2::CCMR_CCS_IC1 | // второй канал - туда же tmr::Ch1::CCMR_CCS_FILTER * 15 | // фильтр - восемь сэмплов на 1/32-й частоты tmr::Ch2::CCMR_CCS_FILTER * 15; // убирает импульсы короче 57 мкс tmr::TIMx->CCER = tmr::Ch1::CCER_CCxE | // включаем оба канала tmr::Ch2::CCER_CCxE | tmr::Ch2::CCER_CCxP; // второй канал - по заднему фронту tmr::TIMx->SMCR = TIM_SMCR_TS_0 * 6 | // trigger input - filtered timer input 2 TIM_SMCR_SMS_0 * 4; // slave mode - reset mode // прерывание по сбросу таймера tmr::UpdateInterrupt::Enable (); NVIC_EnableIRQ (tmr_irq); tmr::Enable(); } void IrqProcess () { tmr::UpdateInterrupt::Clear (); int32_t cur_period = tmr::TIMx->CCR2; int32_t on_time = tmr::TIMx->CCR1; int32_t off_time = cur_period - on_time; // тут был кусочек пред-обработки // перезапускаем таймер - импульсы идут stop_tmr.Restart (); } И да, Сергей дело говорит - если инициализировать регистр сразу, "кучей", это и читается легче, и выполняется быстрее (хотя кому этот десяток байт нужен? :-) ), и вот таких опечаток не будет: TIM2_CCER |= TIM2_CCER_CC2P & ~TIM2_CCER_CC2NP; //TI1FP2 falling edge PS полистайте ещё раздел "PWM input mode" reference manual'а. Я по нему делал (с учётом более удобного синтаксиса библиотеки).

Ну так подключение таймеров (кроме RTC) к EXTI не предусмотрено. Вот тактирование обычных таймеров на STM32Lxxx от часового кварца - это интересная штука, буду иметь в виду. Но что с этим делать, если они один фиг разбудить контроллер не могут - непонятно...

Для решения этой задачи надо объявить хэндлер (который присваивается в CreateTask() глобальным. Заодно осознать, что хэндлер - это просто переменная (пусть и "хитрого" типа). Как использовать переменную в двух модулях одновременно, написано во всех букварях (первая же ссылка - http://www.c-cpp.ru/books/extern ). А "как правильно" написано в статьях Курница (гуглится "Курниц FreeRTOS"). Очень рекомендую. Ещё очень рекомендую инструкцию от scmRTOS - просто и понятно расписаны все принципы микро-операционки. Вот кстати необязательно. Авторы FreeRTOS очень любят указатели на void. Соответственно, можно наворотить всякой фигни, и оно успешно соберётся. Работать, конечно же, это не станет.

http://elm-chan.org/fsw/ff/en/appnote.html Limits FAT sub-types: FAT12, FAT16 and FAT32. Number of open files: Unlimited. (depends on available memory) Number of volumes: Upto 10. File size: Upto 4G-1 bytes. (by FAT specs.) Volume size: Upto 2T bytes at 512 bytes/sector. (by FAT specs.) Cluster size: Upto 64K bytes at 512 bytes/sector. (by FAT specs.) Sector size: 512, 1024, 2048 and 4096 bytes. (by FAT specs.)

А эта задача в принципе честно решается? Ну получим мы функцию, которая точно не изменяется после прохождения сертификации. Но никто ж не обещает, что данные ей на вход будут поступать без обработки. Или что вообще будет использоваться эта функция, а не соседняя, "слегка доработанная". Так это от уровня дизассемблера зависит. Если он развернёт команду "branch по адресу 0xabcd" в "branch в функцию def()", в дизассемблере, действительно "ничего не поменяется" :-)

Слово "HAL" я пропустил. Вас ждёт масса удивительных открытий. Например, отсутствие нормальных семафоров: #if (USE_RTOS == 1) #error " USE_RTOS should be 0 in the current HAL release " #else #define __HAL_LOCK(__HANDLE__) \ do{ \ if((__HANDLE__)->Lock == HAL_LOCKED) \ { \ return HAL_BUSY; \ } \ else \ { \ (__HANDLE__)->Lock = HAL_LOCKED; \ } \ }while (0) #define __HAL_UNLOCK(__HANDLE__) \ do{ \ (__HANDLE__)->Lock = HAL_UNLOCKED; \ }while (0) #endif /* USE_RTOS */ В особо неудачном случае оно действительно может повиснуть. Правда, это старая версия, возможно, за год что-то поменялось... * @file stm32f1xx_hal_def.h * @author MCD Application Team * @version V1.0.0 * @date 15-December-2014 PS повторюсь. Не зная, как и что ломалось, гарантировать "вот теперь-то точно всё будет хорошо" нельзя.

Ок. Извините. У Вас проблема в том, что полностью отсутствуют средства диагностики. Настоятельно рекомендую разобраться, что такое hardfault, в какие регистры надо при этом смотреть (для начала - скопировать обработчик с сайта freertos, погуглить "hardfault cortex site:electronix.ru -redirect"). Также при работе с RTOS необходимо знание, сколько куда памяти уходит. Во фриртос это почти что встроенная штука (почему-то в heap'е нет диагностики, но это легко поправить). Без диагностики можно долго "исправлять" методом тыка, и оно опять развалится в самый неподходящий момент...

1) Хорошим тоном является наличие не обычного флажка, а семафора. Или очереди. В этом случае задача не будет крутиться впустую. 2) Также хорошим тоном (а в случае "где-то у меня память течёт" - необходимым средством) является использование snprintf() вместо sprintf(). sprintf() легко и непринуждённо портит память, лежащую сразу после выходного буфера (сколько раз сам на это наступал...). Ну отлично просто. Но пока мы не увидим, где и что конкретно повисло, результаты разглядывания кофейной гущи будут точнее, чем разглядывание кода. Т.е. ссылка в 4-м сообщении - непонятная, а ссылка в 9-м - понятная? Удивительное дело, ведь ведут они в конечном итоге в одно и то же место.

Ну, если Вы можете чётко сказать "в задаче А столько-то свободного стека, в задаче Б - столько-то, хипа используется столько-то", в эту сторону копать не стоит. А пока "я не знаю, переполняется что-то или нет", копать есть куда. И много... Ну так создание/удаление очередей-задач - это чистейший маллок/фрии. А heap_2 - это плохо. Оно нормально работает только при выделении/удалении элементов одинакового размера. Ну и было б неплохо вместо "проц виснет" описать "вываливается в hardfault, link-register указывает на функцию ааа(), там у меня происходит ...". Начинать читать здесь: http://www.freertos.org/Debugging-Hard-Fau...ontrollers.html

Для этого надо вдумчиво прочитать документацию и провести эксперименты. Маловероятно. Скорее всего, проблема где-то глубже. Кроме того, heap1 очень ущербный - там в принципе нет free(). С ним можно работать, если у Вас задачи-массивы-проч создаются один раз, статически. Если же пользоваться malloc()/free() при работе, операционка довольно быстро повиснет.

Господа, а вы с новыми TI'шными камнями, Cortex-Mx + bluetooth, не работали? Там стек такой же ужас-ужас, или всё ж таки переделали? Я туда смотрел (но вплотную не работал), выглядит не очень страшно. Извиняюсь за оффтопик.

Самый лаконичный способ, на мой взгляд. Как бы в GCC такое сделать?..

Что-то кажется мне, что запускаться эта передача должна таймером. Соответственно, пусть таймер и дёргает стробом.