Flexz

Потому что далеко не все запросы прерываний сбрасываются очисткой соответствующего флага, например, прерывание от UART TXE (буфер передатчика пуст) очищается записью в DR. Видимо, аналогично и с SysTick, хотя что-то не вижу в документации явного указания, на то что это прерывание с автосбросом (да и вообще не вижу какого-либо упоминания о сбросе флага данного прерывания)

Действительно, дешево и сердито. Небольшим сюрпризом стал бинарник размером в 400метров, вместо 60кб Пришлось вспомнить про --remove-section=

Понадобилось сделать выравнивание массива по большому числу (ремап таблицы прерываний в рам в CortexM3) static InterruptHandler __attribute__((aligned(0x400))) isrTable[isrCount]; В map наблюдаем: *fill* 0x20002b34 0xcc 00 .bss._ZL8isrTable 0x20002c00 0x400 nvic.o При этом поле *fill* может гулять от малых значений до цифры близкой к 0x400, в зависимости от ручной перетасовки кода. Когда цифра маленькая еще туда-сюда, но когда она подбирается к 0x400 - это ж почти килобайт оперативки в пустую! Можно ли как-то заставить компилятор использовать область *fill* с пользой, причем только в данном месте?

Наимболее близкий пример "измерение частоты" в общей библиотеке \STM32F10x_StdPeriph_Lib_V3.5.0\Project\STM32F10x_StdPeriph_Examples\TIM\InputCapture espectro вариантов решения масса, хотя все они так или иначе завязываются на таймеры, я привел первый пришедший в голову. Ваш вариант может и прощее, однако он менее точен, т.к. между приходом первого импульса и запуском таймера может пройти некоторое время.

Например так: нужный канал таймера настраиваете в режиме Input capture и запускаете таймер, по приходу внешнего сигнала в Capture&Compare register автоматически записывается значение таймера на момент прихода импульса и вызывается соответствующее прерывание. Аналогично второй импульс - по разности получается число тиков таймера между импульсами, ну и время соответственно. Подробнее в RM, ну или в библиотеке пример есть.

Для "пощупать" достаточно и одной штуки. Непосредственно Вам я магазины не советовал, наоборот это вы пришли и начили зачем-то пиарить зарубежные склады. Согласитесь - весьма странно тому, кто живет в Москве или Питере и может получить заказ с местного склада черед день-два, советовать покупать образцы в Европе и ждать их несколько недель (почта, чем ближе к НГ, тем хуже работает). И ни в коем случае не обижаюсь, наоборот, стебусь. Хотя отсыл к возрасту собеседника по нынешним меркам сродни оскорблению ;) PS: а с Вас отчет по испытаниям.

Ничего не понял, снимите уже тюбетейку и расшифруйте по-русски. Если вы имеете ввиду, что местные поставщики продают со своих складов только оптом, то глубоко ошибаетесь. Внимательно читаем центральную колонку и медленно выдыхаем. http://www.terraelectronica.ru/catalog.php...e=2&PageS=1 По поводу где проще покупать, так это каждому свое.

Простите, и что там смотреть? Я очччень рад, что на каком-нибудь моузере с дигикеем огромный ассортимент, вот только efind.ru показывает наличие на складах местных поставщиков, в т.ч. розничных, причем тут, в Москве - поехал и купил. PS тюбетейку себе оставте.

Судя по efind-у первая партия процов STM32F405RGT6 уже на местных складах и готова к растерзанию. Если верить даташиту проц пин-ту-пин совместим с серией F2, так что у кого есть изделие под F2 в LQFP64 - флаг в руки :)

Сколько занимает целочисленное перемножение есть в мануалах обычно. Еще вот такая табличка существует: http://indemsys.ru/theoretical-electronics...s-embedded.html

44кГц для АЦП это не много. Серия stm32 имеет 12битный АЦП. Вопрос - что с этими данными потом делать. Выводить на индикатор, так AVR или MSP могут и не справиться (хотя у последнего есть DMA, ему попроще), если просто складывать в память, то SPI-флешки для такого потока сразу мало, нужно будет писать в NAND или на SD-шку. Вероятно, предложенный выше мини2440 - отличный вариант all-in-one.

Возможно стоит посмотреть в сторону OLED, они поярче будут. Но в любом случае это будет только до некоторого уровня освещения, любой светоизлучающий дисплей может "ослепнуть" если фон будет светить ярче (солнечный зимний день в горах). ИМХО тут стоит подумать над конструктивными решениями, типа высоких бортиков вокруг экрана. Обязательно нужен цвет? Может выйдет обойтись простой рефлективной ЖК панелью+подсветка. Посмотрите в сторону XBee. Вам нужно как можно дешевле или как можно меньше самостоятельной разработки?

Каверкать чужие слова, и выдавать свои мысли за чужие - дурной тон, завязывайте с этим. В ТЗ, кстати, было следующее "...отправить ответую посылку не позднее, чем через 10 битовых интервалов...", а сокрости работы от 19200 до 115200бод.

ILYAUL Пятница, вечер, кому-то пора отдыхать. И не читайте между строк, там ничего нет. Ясно написано, отправить ответ нужно "не позже", насчет "не раньше" и "сидим в прерывании" это вы сами придумали.

О каком планировщике речь? Я об ОСовом, который перервал бы тежелую обработку ОСД и отправил бы ответ, вы о нем же? зачем он? В перывании выставлялась задача для следующего цикла суперлупа и отправлялся ответ. Эквивалентно? Да! Так зачем планировщик? Ради религиозной цели несидения в перывании. Не плодите сущностей. Я совершенно конкретные примеры привел, где бывает. Продолжать похоже бессмысленно, если вы настаиваете на своих принципах, то с ними вас и оставлю.

Как хотите) 1. У ТС проблемы с временем выполнения, я предложил один из вариантов ускорения, просто как вариант. Так понимаю с обоснованностью в первом примере вопросв нет? Не поймите меня неверно, я не пропагандирую решение задачи на автоматах всегда и везде. Как-то раз приходилось приходилось дописывать чужую прогу реализованную подобным образом, там автоматы были весьма громоздкие и добавить еще пару команд оказалось довольно муторно. 2. Этот пункт касается моего второго примера? Если да, то, на первый взгляд, это эквивалентно. А посему включается религия, не позволяет вам сидеть в прерывании - делайте в суперлупе, мне позволяет. В целом же, вынос разбора из прерывания, т.е. добавление фифо, это добавление времени выполнения: слить в буфер, забрать из буфера. Да время небольшое, согласен, однако устранение данного буфера логичный этап оптимизации. Если, конечно, нет других критичных ко времени задач. Вообще, чего я все на ваши вопросы отвечаю? Давайте вы теперь, расскажите, чем же так плохо задерживаться в прерывании, если никто не торопит с выходом из него?

Ну поскольку у вас IAR то скорее всего стартап и скрипт линкера правильные (если, конечно, вы их не меняли руками), предположение об их корявости скорее относится к GCC, там каждый их или подбирает готовые на просторах инета или пишет свои. Действительно надо map смотреть. PS а процессором в настройках не ошиблись?

что, как других дилетантами обзывать так запросто, а как вас, так и обиделись? :) Примеры, да пожалуста: 1. Принимаем команды по наложению OSD, шина RS485 абонентов много, при получении команды не позже чем через нцать мкс (точное число ен помню больше 100 но меньше 500) следует отправить подтверждение приема. Других задач не выполняем. Формирование картинки работает не быстро - суперлуп длинный. Ну и? ради великой самоцели "малосидения в прерывании" делать еще и планировщик с тиком 100мкс? 2. Резервное устройство на батарейном питании, по команде дергаем клапан. Тут ключевой момент даже не время реакции, а потребление, проц работает ТОЛЬКО в прерывании, остальное время дрыхнет, вынос обработки в суперлуп увеличит потребление на величину отличную от нуля. Реальные примеры из практики, а не тупые суперлупы в вакууме. PS продолжим холивар или дадим ТСу решать свою задачу?

До входа в главную функцию (main) выполняется загрузчик, который и заполняет инициализировнные в коде переменные их значениями, а остальные нулями. Вообще похоже на неверный скрипт линкера и/или загрузчик. Один раз был похожий косяк, правда с gcc: в зависимости от размеров переменных или даже перетаскивания их по коду программа работал или валилась в Hard Fault, уже грешил на компилятор. В итоге оказалось что вектора прерывания сремапленные в оперативку были выровнены по неверному значению (0x100, а надо было по 0x400) Старый код работал на stmf100, где прерываний меньше и выравнивания 0x100 было достаточно, при переносе на stm32f2 используемых прерываний оказалось больше и некоторые не срабатывали.

Все относительно и ситуационно. Дилетантский подход в подавляющем большинстве случае - это возводить в абсолют время сидения в прерывании, ИМХО :) Часто минимизировать нужно именно время реакции системы, а перекладывание из буфера в буфер скорости не добавит.

При желании разбирать входные данные можно вообще безо всяких буферов, исключительно на конечных автоматах. Объем кода получится приличный, зато без затрат памяти и быстро - можно отрабатывать не выходя из прерывания.

Поток? тогда уж процессу приоритет поднимайте. Насколько я помню изменение приоритета пока влияет только на планировку управления в рамках процесса.

А сам процессор при этом что-нибудь делает или спит?

А можно использовать ОС. Контрольный поток проверяет рабочие на зависания, при обнаружении оного рабочий поток просто перезапускается.

Кстати, первое что сделал получив плату с stm32f217 - банальный ногодрыг, 60Мгц вывелись вполне успешно (без цикла, просто большая пачка последовательных записей в регистр)