esaulenka

Возьмите последний кейл, полгода назад они анонсировали поддержку Cortex-M7. Тут можно картинки полистать: http://www2.keil.com/mdk5/cortex-m7/ Поддержка STLink в кейле встроенная, надо просто выбрать правильный отладчик (правда, откуда драйвер поставился, я не помню. Возможно, от штатной ST'шной утилиты).

Да что этот Шилдс понимает... :-) Я осваивал плюсы на scmRTOS ("кишки" довольно сложные, но снаружи всё просто и понятно) и на Qt (супер-понятный внешний интерфейс, в "кишки" даже не лазил). Рекомендую! После этого свои классы без особых проблем придумываются. При этом проекты не сказать, чтоб прямо сложные. Пара сотен килобайт исходников - это немного совсем...

Господа, подскажите пожалуйста: вход таймера ETR можно использовать для определения длительности/периода импульса? В документации вижу только возможность тактировать таймер. Может, как-то slave использовать можно?.. На готовой железке возникла необходимость измерять параметры импульсов, а на той ноге только ETR и есть...

Предлагаю прорывную нано-технологию. Цепляем к выходам датчика осциллограф (как выяснилось, они аналоговые. и то хорошо). Пальцем крутим вал. Глазами смотрим на осциллограф. Если видим там что-то похожее на две синусоиды (сдвинутые на 90 градусов), радуемся и пытаемся вспомнить школьную тригонометрию. Если видим там что-то похожее на меандр "включено-выключено", пытаемся приспособить этот датчик к чему-то ещё.

Нет. Значение SYSCFG определяет, на какую область памяти будет отображаться адрес 0. Т.е., выставляем в одно значение - и содержимое памяти по адресам 0x00000000 и 0x08000000 будет одинаковое (и так же одинаковым будут следующие N килобайт, цифирку за ненадобностью не помню). Выставляем другое значение - будут одинаковыми 0x00000000 и 0x20000000 и т.д. Но вот правда - бросайте Вы эти глупости. Мне кажется, этим ремапом никто толком и не пользуется. Разве что штатный загрузчик, да отладчики в режиме "загружать код в RAM" (этакий быстрый режим отладки для маленьких программ, чтобы флеш каждый раз не стирать).

Reset - это команда со стороны хоста. Виндовс при подключении устройства делает reset, потом считывает дескрипторы, потом снова reset, снова считывает дескрипторы, и только потом считает, что процедура подключения завершена. Почему так, видел какое-то внятное описание, но забыл где... PS должно сильно поспособствовать сравнение рабочего и нерабочего вариантов каким-нибудь сниффером. Я крайний раз пользовался "free usb analyzer". Не очень удобно, зато совесть чиста :-)

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

следующая тема, чувствую, будет опять "как в этой лапше выгадать 3 такта". Jenya7, предлагаю: - забыть слово "адресс" (а то придёт Herz, и научит Вас русскому языку) - написать модуль-прослойку, у которого на входе не некие странные "GPIOA+1", а вполне понятные "вход кнопка 1", "вход XXX". Тогда привязка функции входа к конкретной ноге будет ровно в одном месте. Не, ну можно, конечно, благо у STM'ок адреса разных портов GPIO различаются аж на 0x400. uint32_t get_input (uint32_t param) { GPIO_TypeDef * port = (GPIO_TypeDef *) (param & ~0x1F); uint32_t pin = param & 0x1F; return port->IDR & (1UL << pin); } ... get_input (GPIOA | 1); get_input (GPIOB | 31); Но всё равно, не надо так делать.

Пишите на с++, stm32tpl - образец компактности и лаконичности! typedef Pin<'C', 9> GreenLed; GreenLed::Mode (OUTPUT); GreenLed::On();

Отстаньте вы от человека! Он же сразу сказал - это спорт такой. Что-то вроде "я напишу hello world в N байт", только следующий уровень :-) Если _Ivana хватит упорства и знаний затолкать всё это в тиньку, он будет на порядок больше молодец, чем реализация того же ПИДа на stm32discovery.

С чего бы это? Растянуть импульсы с триггера, и готово. Другой вопрос, что придётся вешать табличку на энкодер "быстро не крутить" :-) (будет "проглатывать" импульсы).

Что-то типа того. Только ещё делители нужны на выходах. Энкодер, который предложил Plain, будет выдавать импульсы каждые 15 градусов. Точная настройка прибора будет довольно неудобной (это +/- 20 единиц легко накрутить; +/- 1 придётся делать очень аккуратно). В общем, самое время освоить какую-нибудь ардуину. На входе - энкодеры (статей "подключаем энкодер к ардуино" в сети десятки), на выходе - эмулятор 74hc4021 в лице SPI.

Имхо, вполне реальная задача. Если диагностический прибор цепляется только на разъем OBD2, никаких сверхъестественных сигналов передавать не надо. С одной стороны 1-2 CAN'а, с другой стороны 1-2 CAN'а. Ну ещё K-Line может быть. Настройка скорости - вручную (выбор диагностируемого авто) или автоматом. Зажигание может быть. Ещё J1850 может быть (я не в курсе специфики сельхоз. и строительной техники), туда свои драйвера надо ставить. Таймауты в автомобильных протоколах обычно с изрядным запасом. Чисто умозрительно, если связывать оба блока не через GPRS, должно взлететь.

(раз уж взялись оффтопить...) Руслан, а как этот logic16 на сотне мегасэмплов работает? Беглый гуглинг сообщает нам "у меня всё работает, ногодрыг с ардуины захватывается, больше мне ничего не надо" и "ничего не работает, сэмплы теряются напрочь"

Да, кстати. Загрузчик понимает, что код - в thumb mode, и program counter должен быть нечётным? Попробуйте сделать GO на адрес 0x02001001

Не знаю. Сделайте то же самое, но под отладчиком: char remap_flash[] = { 0x00, 0x4F ... }; ( (void (*)(void)) remap_flash) ();

Да это просто :-) Длина команды thumb2 - 16 бит или 32. 32-битная константа напрямую в эту команду не влезает (нужно же место под код самой команды). Можно положить константу рядом, и ссылаться на неё (что-то вроде LDR r0, [pc, #смещение-до константы]); компилятор так и делает. Но руками проще загрузить в регистр за два раза, благо у кортексов команда MOVT сделана, похоже, специально для этого.

Я тоже никогда не делал. Пришлось научиться :-) Берём 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 мужики развлекаются на полную катушку :-)