Flexz

С точки зрения процессора бесконечный цикл это обращение исключительно к памяти команд, которое происходит в обход BusMatrix, т.е. точно никому не мешает. А прерывания отличаются от опроса разве что наличием сохранения/загрузки контекста, вот тут утверждать не буду, но предположу, что блочное сохранение регистров может быть burst-ом на шине.

Наверное дело все-таки не в самих прерываниях, а в том, что когда появляется работающий код, DMA начинает делить шины с ядром и другой периферией. А арбитраж-то по схеме round-robin.

Можно поинтересоваться - зачем? Программа минимум - скопипастить инициализацию из семпла, вообще ничего изучать не надо. А если знать регистры - зачем вам структура и функция?

Coding convention такой, попытка сокрытия реализации. Не очень удачная правда. Ну и свою библиотеку для stm32 я писал ориентируясь на полноту и последовательность действий в ст-шных либах. Все-таки в некотором смысле документацию они дополняют, может даже заменяют.

Чипселект можно снимать при получении последнего RXNE. Еще перед началом передачи стоит вычитывать DR дабы удостовериться, что прерывание RXNE не возникнет сразу после включения SPI.

Ну дело ваше, конечно, но на вашем месте прежде чем делать что-то посложнее я бы разобрался с простым. А именно с работой с уартом, ибо в коде полная ахинея. Вот это: for(int i=0; i<8; i++) { if(USART_ReceiveData(USART1) != 0xFF) { result |= (1<<i); } } не считает 8 байт по уарту, а 8 раз считает одно и тоже значение из регистра DR, нафига оно вам 8 раз? Отправка данных выглядит примерно так (копипаст из семплов) USART_SendData(USARTy, data1); /* Loop until USARTy DR register is empty */ while(USART_GetFlagStatus(USARTy, USART_FLAG_TXE) == RESET) { } соответсвенно прием: /* Loop until the USARTz Receive Data Register is not empty */ while(USART_GetFlagStatus(USARTz, USART_FLAG_RXNE) == RESET) { } /* Store the received byte in RxBuffer */ data2 = USART_ReceiveData(USARTz); PS: аппноут, кстати, почитал - интересно, не знал что с 1-wire можно работать через uart

не читал и не работал. Зато достаточно работал с уартом, что бы видеть что код у вас нерабочий. Перед тем как читать DR надо дождаться того что бы там что-то появилось, а перед тем как писать в него надо дождаться пока из него все будет отправлено (задержки у вас там именно за этим стоят, причем почему то не везде). Аппноуты это конечно здорово, но документацию на контроллер тоже читать надо.

Загляните внурь функций USART_SendData/USART_ReceiveData Думаю вопросы отпадут.

Я правильно понимаю, что вы SPI на скорости 36Мбит запускаете? Согласно даташиту максимальная скорость - 18Мбит/с

Флеш работает с циклами ожидания, но благодаря акселератору (предвыборка, кеш, широкая шина флешки) - ядро работает без циклов ожидания. Как-то так.

Возможно, если архитектура поддерживает bit-banding.

Что мешает скачать "Standard Peripheral Library", с которой идет уйма примеров обо всем, и поизучать/позапускать их? http://www.st.com/internet/com/SOFTWARE_RE...dperiph_lib.zip

Программа решает одну или несколько задач связанных с неким тех-процессом, так? Вот и нарисуйте алгоритмы решения этих задач. А делать схему алгоритма всей программы вместе с GUI дело неблагодарное, все равно в таком монстре черт ногу сломит. Еще у нас последнее время более популярно словесное описание алгоритмов работы: режимы работы, списки возможных воздействий, реакции системы, результаты - эдакое ТЗ преросток. Такое легко составлять вместе с заказчиком еще на начальных этапах работы и поддерживать в разы проще чем схемы. PS а схемы алгоритмов заказчику вообще зачем? Часом не просто в архив положить? Если так, то все решается банальной отпиской - нарисовать что-то близкое к реальности и по госту, все довольны.

А давно Unreacheable code ошибкой стал? или вы компилируете в режиме "Считать ворнинги ошибками"?

Возможно и так, сам возникновение ORE встречал только в тяжелом проекте - много прерываний+кривая расстановка приоритетов, в итоге иногда RXNE не успевал обработаться.

Последнее предложение не осилил, вы к чему это вообще? типовая последовательность обработки прерывания - 1. считать регистр статуса 2. обработать статус(ы) (в данном случае считать DR) При этом ORE тоже сбросится. Это ошибка которую просто нужно обработать. ТС видимо только читает DR, не глядя на статус, вот прерывание и виснет.

Флаг ORE вызывает прерывание RXNE.

Насколько жесткие требования к потреблению в спящем режиме? и какой именно из stm32? Вообще в штатном Sleep-е останавливается ядро но периферия работает, может это вам подойдет, но сильной экономии не добиться, скажем 10мА против 70. Если цель - батарейное питание, то лучше смотреть в сторону stm32l151 у них заявлены уже микроамперы при активной периферии.

не, F2xx нету такой штуки как AFIO. Точнее коммутация альтернативных функций теперь встроена в контроллер GPIO, где ей и место.

У меня мыслей больше нету.. Я там скосячил несколькими постами выше, неглядя скопипастил не то должно быть RCC_APB2PeriphClockCmd(RCC_APB2Periph_SDIO, ENABLE); а не RCC_AHB1PeriphClockCmd(SD_SDIO_DMA_CLK, ENABLE); Кстати, насчет новых МК, с f103 были преценденты - вроде рабочий код, а глючит, перепаиваем другой проц - работает. Толи непропай, толи проц битый, но было несколько раз.

stm32f217zgt6, пользую отладочную плату от стартеркита, пока свои ждут комплектации. Еще один шальной комент у вас в коде заметил //SDIO_InitStructure2.SDIO_ClockDiv = 0x76; но, вроде бы и без него клок должен быть, хотя и слишком быстрый для инициализации

Попробовал сейчас у себя, да клок начинает выдываться сразу после SDIO_ClockCmd(ENABLE);

Вообще-то да, на любую периферию клоки надо включать предварительно. F103 помнится вообще HardFault влетал, если начать настраивать что-то не включая клок. А примеры внимательнее читать надо :) (либо может они у вас старо-глючные) вот код деинита из сэмплов void SDIO_DeInit(void) { RCC_APB2PeriphResetCmd(RCC_APB2Periph_SDIO, ENABLE); RCC_APB2PeriphResetCmd(RCC_APB2Periph_SDIO, DISABLE); } вкл-выкл что? резет, а не клоки. А перед деинитом вызывается SD_LowLevel_Init() который настраивает ноги и включает клок на SDIO: RCC_AHB1PeriphClockCmd(SD_SDIO_DMA_CLK, ENABLE);RCC_APB2PeriphClockCmd(RCC_APB2Periph_SDIO, ENABLE); без этого не работает. У вас отладочная плата есть или только своя?

Кхм.. а клоки на SDIO действительно не включаете?

Аналогично, серьезных проблем не обнаружил, работаю без дебага. Разве что Code Analysis сносит башню от плюсового кода с активным использованием шаблонов и он заливает весь код ошибками. Коллега настраивал отладку с gdb - были какие-то сложности, т.к. настройка отличалась от предыдущих версий, но я не сильно вникал, да и вроде бы все разрешилось в итоге.