esaulenka

На самом деле, ходило оно по пустому TIM5_IRQHandler(). Просто в startupXXX.s есть особая ассемблерная магия - все обработчики прерываний объявлены с одним и тем же телом - "B ." (оно же - бесконечный цикл). Так что да, при объявлении обработчиков надо быть очень внимательным, при опечатках линкер без каких-либо предупреждений подсунет "пустышку".

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

Здравствуйте. Хочется "посмотреть" обмен низкочастотных (125 или 134 кГц) RFID устройств. Передавать ничего не надо, считыватель и метка уже готовые, осталось только разобраться, что же между ними происходит :-) Я правильно понимаю, что мне стоит начинать с приёмной катушки (как оно считается? просто как "индуктивность без сердечника"?), фильтра (на сколько?..), детектора и компаратора (порог придётся настраивать, видимо). Что-то в духе приёмной части http://www.serasidis.gr/circuits/RFID_read...RFID_reader.htm. Принимать для начала можно и на осциллограф. И сразу чайницкий вопрос: почему эта конструкция не "глохнет" от 50 Гц из розетки? Вроде б должна... Update. Здесь http://forums.parallax.com/discussion/1058...est-rfid-reader пишут, что глубина модуляции маленькая совсем, руками подкрутить подстроечный резистор никак не выйдет... Соответственно, надо как-то автоматически подстраивать...

Сергей, а какие претензии-то? libopencm3 - действительно, весьма приятная библиотека. Тот же USB написан значительно проще и понятнее, чем в обоих вариантах ST'шных библиотек. И слоёв там меньше, и профили не засунуты в сердину библиотеки. В общем, я тоже рекомендую, даже с учётом отсутствия там STM32F07x "из коробки"

Точно! К этой вот штуке http://ru.telma.com/produits/fonctionnement надо примотать изолентой реле с базара. Самое лучшее решение. Отличная плавная регулировка, 100% надёжность!

Код выглядит нормально. Разве что, не очень понятно, что содержится в rcc_Clocks. Можно легко и просто испортить дефайны, чтобы там оказалось что-то не то. Единственное замечание: у STM'ок есть кэширование регистррв таймера (в т.ч. ARR). Чтобы принудительно его обновить, надо сделать TIMx->EGR = TIM_EGR_UG; PS дурацкий вопрос: это точно STM32F103 ? Не китаец? ;-)

В RTC у STMа есть особенность, что они довольно критичны к качеству кварца. Точнее, к самому кварцу, его обвязке (в лице двух конденсаторов) и монтажу (количеству флюса вокруг). В погоне за микропотреблением узел получился весьма нежным. Можно вывести на ногу CLKOUT частоту кварца (подробности - в reference manual) и проверить осциллографом, что оно работает стабильно. Напрямую в ноги часового кварца тыкать бесполезно - сразу же останавливается. Очень похоже, что кварц постоянно останавливается-запускается.

Так а где виснет-то?! Отключить ватчдог, смоделировать, остановить в отладчике - не? А vbus (оно же "отрубание шнура") чудесно видно на соотв. ноге. Просто как gpio.

А что именно надо? По-хорошему, надо загружать не бинарник, а elf - это перспективнее, чтобы заработал отладчик. Непонятно, что такое "удалось организовать чтение-запись". gdb (+openocd, видимо) уже умеет писать в NAND ? Так это прекрасно, осталось пролистать http://openocd.org/doc/html/General-Commands.html и сделать load_image. Или о какой программе речь?

Больше самостоятельности! LCDstring("1234567890123456", 16); - работает? sprintf (lcd_buf, "1234567890123456"); LCDstring(lcd_buf, 16); - работает? (кстати, почитайте про sprintf - буфер нужен чуть больше: в конец ещё нолик пишется) int a = 10; sprintf (lcd_buf, "%d", a); LCDstring(lcd_buf, 16); - работает? float b = 12.34; sprintf (lcd_buf, "%f", B); LCDstring(lcd_buf, 16); - работает? И только потом смотреть на логарифмы... Ну и код этого самого LCDstring() вместе со всем, что оно вызывает, надо смотреть.

Извините за резкость, но, может быть, стоило разик подумать?.. В даташите прямо картинками нарисовано, даже читать особо не надо: - записать адрес регистра0 - считать мусор - записать адрес регистра1 - считать данные регистра0 uint8_t TM_MFRC522_ReadRegister(uint8_t addr) { uint8_t cmd[2]; uint8_t answ[2]; cmd[0]=cmd[1]= (addr << 1) | 0x80; HAL_GPIO_WritePin(GPIOE, GPIO_PIN_12, GPIO_PIN_RESET); HAL_SPI_TransmitReceive(&hspi1, cmd, answ, 2, 20); HAL_GPIO_WritePin(GPIOE, GPIO_PIN_12, GPIO_PIN_SET); return answ[1]; }

Так. Ещё раз, медленно и по буквам. Упрощаю до предела. Пишем void DoIt (char * p) { for (int i = 0; i < 5; i++) p[i] = i; } .... char data[10]; DoIt (data); // data больше не используем Вы утверждаете, что DoIt() будет записывать не в data[], а портить стек? Как интересно... (да, я в курсе, что особо умный компилятор не будет делать НИЧЕГО - выкинет и массив, и функцию заполнения. Но изначальный этот HAL_SPI_Receive() выкинуть так просто нельзя - у него внутри volatile много).

Судя по словам IgorAVR2 ("подключил к питанию, а оно всё равно сбрасывается"), ST'шники сделали определённую работу над ошибками. Как минимум, резистор последовательный поставили :-) А так - да, смотреть RCC->CSR (или аналог, я с F437 не общался) и выводить хоть куда-нибудь, хотя бы размахиванием ножкой (нужно несколько свободных ног). Игорь, обратите внимание на несколько странную процедуру чтения этого регистра (описана в документации).

Кажется, половину дискуссии надо б отрезать в "обсуждение форума". И там уже требовать галку "отображать факт редактирования" для "не-своих". Подозреваю, она по недосмотру пропала, без всякого злого умысла.

Меджикивис, а я наблюдаю кнопки "отредактировать" у Герца и "отправить" у Вас. ... и при нажатии кнопки "Edit" -> полное редактирование вижу обсуждаемую галку.

Как минимум, printf("%i") ждёт int, а не float. Но тогда бы мы услышали "работает, но какую-то ерунду выводит".

И зачем же в разделе начинающих такие инициативные товарищи?

Хост может вогнать устройство в suspend, если устройство ему скажет "я умею энергосбережение". Ну и вернуть, соответственно. Я таких устройств не делал :-) Более того, виндовс любит делать suspend на долю секунды при считывании дескрипторов.

Винда загоняет "неисправное" устройство в suspend, обычно у железки-девайса есть такой статус. SOF'ы в этом случае тоже пропадают, насколько я помню. С не-виндой не экспериментировал.

Надёжное решение - хост ловит dev_changed, закрывает-открывает устройство (у автора нашей софтины получилось плохо, пришлось требовать админские права и перезапускать usbserial.sys; c FTDI было как-то попроще), девайс ловит состояние suspend и делает реконнект. И ESD защита по соотв. линиям, конечно же. И всё работает. От разрядов в неск.киловольт рядом с кабелем связь теряется, конечно, но через пару секунд успешно восстанавливается.

Задачу комплексно надо решать. Можно, конечно, встать в гордую позу "USB - дрянь, у меня будут только RS-485 (оптика, CAN, mil-1553, ...)". Только клиент мгновенно убежит к конкурентам - ему, клиенту, очень часто не лень раз в пол-года переткнуть шнурочек. А вот обеспечить надёжность, чтобы этот пользователь не перетыкал шнурок после каждого чиха... Ну так это и есть наша работа - подобрать компоненты, подумать над программными возможностями перезапуска...

Не надо счётчики сбрасывать. Если очень вдумчиво почитать спецификацию от Боша, выяснится, что счётчики - штука информационная. Если шина "живая", счётчики автоматически уменьшаются, через некоторое время передатчик включается автоматически.

https://github.com/antongus/stm32tpl - макросы Аскольда Волкова, которые творчески допилил АНТОХА.

Ну хорошо, решение на DMA. Но с тем же FIFO. - настраиваем DMA на приём USART2 в circular mode, постоянно складывать данные в буфер. Этот DMA будет работать вечно. - делаем в FIFO указатель put (из регистра приёмного DMA->NDTR) и указатель get (программный). - делаем функцию запуска DMA на передачу в USART3. Надо рассмотреть два варианта: put "впереди" get - обычная передача, и get впереди put - буфер "закольцевался", надо передать данные двумя кусочками. - периодически проверяем, что указатели FIFO не равны, и запускаем передающий DMA (если не запущен). Простейший вариант - по таймауту (не более времени заполнения FIFO). Более сложно - по флагам из прерываний "Tx DMA complete" и "Rx Idle". А манипуляции аж с тремя буферами выглядят странно... И опрос NDTR надо вылечить. Как-то очень подозрительно, что туда пишется USART2_Idx_local (который всегда разный, но меньше buf_SIZE), а читается всегда buf_SIZE.

Почитал-почитал, и ничего не понял. Я бы сделал: - буфер FIFO с методами Put(байт) и Get(байт). - прерывание Usart2_RXNE, которое делает Put() - прерывание Usart3_TXE, которое делает Get() Дальше немного магии с разрешением прерывания от уарта3: - в обработчике Usart3_TXE, если FIFO пустой, TXE выключаем; - в обработчике Usart2_RXNE всегда включаем TXE И никаких переливаний из пустого в порож..., простите, я хотел сказать "никаких memcpy". Ах, да, freertos'а в моём решении тоже нет :-)