Когда я работал с МК серии STMF10x так и было. Но с STM32F071 вышло интересно. Когда я только делал первые шаги с платой VLDiscovery я поначалу вообще тактированием не заморачивался. Работало на "по умолчанию". Здесь же при попытке отконфигурировать выходы управления 4-х разрядным 7-сегментным индикатором, не принимая во внимание тактирование, приводила к случайной конфигурации вкл/выкл выходов, причём на манипуляции с регистром ODR в отладчике Кейла эти выходы не реагировали. Но "вис" МК не из-за этого. В библиотеках Hal, как, ЕМНИП, и в StdPeriph, после запуска HSE или LSE идёт проверка соответствующего бита xxxRDY в регистрах RCC. Проверка происходит в цикле while, и пока вышеуказанный бит не станет 1, программа из цикла не выйдет. Имеем зависание.
_________________ Нужно добиваться того чего хочется. В противном случае останется лишь довольствоваться тем, что есть.
Можно на 100% доверять конфигам периферии от Куба? Для F0, если проблемы с HSE, разве не включается автоматически HSI? Если я случайно перегрел при пайке выводы входов тактирования.
как делает куб:
Код:
LL_RCC_HSE_Enable();
/* Wait till HSE is ready */ while(LL_RCC_HSE_IsReady() != 1) {
/* Wait till HSE is ready and if Time out is reached exit */ do { HSEStatus = RCC->CR & RCC_CR_HSERDY; StartUpCounter++; } while((HSEStatus == 0) && (StartUpCounter != HSE_STARTUP_TIMEOUT));
Приветствую всех! Решил подключить RFID-RC522 по SPI (только он и выведен) к STM32, но сразу столкнулся с проблемой - нигде нет описания протокола общения с чипом. Да что там протокола, я даже настроек для SPI не нашел. Все что удалось найти в даташите по настройке:
Цитата:
Data bytes on both MOSI and MISO lines are sent with the MSB first. Data on both MOSI and MISO lines must be stable on the rising edge of the clock and can be changed on the falling edge. Data is provided by the MFRC522 on the falling clock edge and is stable during the rising clock edge.
Из этого я сделал вывод, что порядок передачи байт - MSB, но как настроить биты SPI_CR1_CPOL и SPI_CR1_CPHA так и не понял. Впервые сопрягаю устройство по SPI, поэтому такие тупые вопросы (удалось добиться обмена информацией на одном МК по двум SPI интерфейсам, теперь перехожу на сторонние устройства). Если еще подскажете какими командами запросить у чипа RC522 данные с UID, то вообще помру от счастья . P.S. Даташит читаю, но яснее пока от этого ситуация не становится
Инженеры КОМПЭЛ провели сравнительное тестирование аккумуляторов EVE и Samsung популярного для бытовых и индустриальных применений типоразмера 18650.
Для теста были выбраны аккумуляторы литий-никельмарганцевой системы: по два образца одного наименования каждого производителя – и протестированы на двух значениях тока разряда: 0,5 А и 2,5 А. Испытания проводились в нормальных условиях на электронной нагрузке EBD-USB от ZKEtech, а зарядка осуществлялась от лабораторного источника питания в режиме CC+CV в соответствии с рекомендациями в даташите на определенную модель.
Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре.
Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.
Еще один вопрос. Вот настроили мы SPI. Дальше чтоб прочитать, к примеру, тот же регистр 0x14, то что нужно сделать? Как объяснить что мы именно читать хотим, а не писать в него. Какую последовательность байт отправить для чтения этого регистра? Что-то не могу найти описание процедуры чтения/записи в даташите. Или может туповат - оно написано, а я не понимаю
Добавлено after 6 hours 52 minutes 45 seconds: Что за хрень происходит с моим камнем? Работаю на STM32F3Discovery и пытаюсь присобачить RFID RC522. Впервые серьезно взялся за SPI (так как RFID работает именно через него) и пол дня угробил на непонятный глюк. Настроил SPI как положено, но ответа от подчиненного нет. Несколько часов колдовал с даташитами и ераташитом, но решения не нашел. Решил подцепить логический анализатор к шине и оказалось, что ответ таки идет, но SPI в МК его почему-то не принимает. Опять стал колдовать с тех. документацией, пока через несколько часов не заметил, что ответ в регистре есть, но он какого-то хрена смещен на 8 бит влево!!! Если вживую попереключать в отладчике бит CPOL и CPHA, а потом выставить обратно как и было, то иногда SPI начинает правильно отображать принятые данные в младшем байте регистра DR. Что с ним такое происходит? Я рукожоп или это особенность периферии камня, так как нигде нет упоминания о том, что входящие данные хранятся именно в старшем байте регистр? Вот настройки SPI:
Код:
SPI2->CR1 |= SPI_CR1_BR; //Baud rate = Fpclk/256 SPI2->CR2 |= SPI_CR2_RXNEIE; // RX buffer Not Empty Interrupt Enable; SPI2->CR1 &= ~SPI_CR1_CPOL; //Полярность тактового сигнала SPI2->CR1 &= ~SPI_CR1_CPHA; //Фаза тактового сигнала SPI2->CR2 |= SPI_CR2_DS_0 | SPI_CR2_DS_1 | SPI_CR2_DS_2; //8 бит данных SPI2->CR1 &= ~SPI_CR1_LSBFIRST; //MSB передается первым SPI2->CR1 |= SPI_CR1_SSM; //Программный режим NSS SPI2->CR1 |= SPI_CR1_SSI; //Аналогично состоянию, когда на входе NSS высокий уровень SPI2->CR1 |= SPI_CR1_MSTR; //Режим Master SPI2->CR1 |= SPI_CR1_SPE; //Включаем SPI2
Вот с такими функциями я принимаю нормальный байт от слейва:
Код:
void SPI2_send_byte (uint8_t Byte) { while(!(SPI2->SR & SPI_SR_TXE)); SPI2_NSS_LOW; SPI2->DR = Byte; //Пишем в буфер передатчика SPI2. После этого стартует обмен данными }
И забыл упомянуть самое главное - если отключиться от слейва и перемкнуть выводы МК MOSI и MISO, то байт приходит как положено - в младший байт регистра DR. При этом, логический анализатор при общении МК со слейвом показывает, что они обмениваются реально только по одному байту (0x80 - это правильный отклик слейва):
Проблема оказалась в непонятной особенности работы со SPI в восьмибитном режиме. Решение подсказал товарищ nahimovv на казусе. Надеюсь никто не будет против копи-паста, может кому пригодится:
Цитата:
При освоении STM32F0XX новички часто испытывают трудности запуска SPI в режиме 8бит и ниже. Причиной этому является значительное расширение возможностей модуля SPI, по сравнению с предшественниками, и некоторые изменения в работе модуля.
Что делать:
1. По умолчанию доступ к SPIx->DR 16бит. Чтобы получить доступ к SPIx->DR как к регистру 8бит пишем:
Код: #define SPI1_DR_8bit (*(__IO uint8_t *)((uint32_t)&(SPI1->DR))) #define SPI2_DR_8bit (*(__IO uint8_t *)((uint32_t)&(SPI2->DR))) Теперь обращаемся к регистру данных так:
Код: SPI1_DR_8bit = 0x34; SPI2_DR_8bit = 0x78; 2. По умолчанию и при запрещённых установках DS [3:0]: Data size регистра SPIx_CR2 устанавливается длина данных 16бит (1111: 16-bit). Поэтому при настройке длины данных логичнее сбрасывать, а не устанавливать определённые биты. Иначе при любой попытке записи некорректного значения, регистр SPIx_CR2 автоматически восстановит длину данных 16бит. Т.е. для того чтобы установить длину 8бит нужно просто сбросить старший бит DS [3:0] регистра SPIx_CR2.
3. Также встречались жалобы на непонятное поведение бита RXNE. Всё дело в бите FRXTH регистра SPIx_CR2, при работе с данными 8бит требуется его установить .
После решения этой проблемы появились новые (кудаж бл* без них ). Основная беда - это нога NSS. Как только я не пытался заставить МАСТЕРА ее дергаться аппаратно, но он все время показывал мне неприличный жест. В итоге я забил на это и реализовал аппаратный ногодрыг. Но и тут проблемы не закончились. Имеются у меня такие функции записи в регистры слейва данных:
Так вот между посылками команд проходит очень мало времени, из-за чего строб NSS получается ничтожно маленьким. Это сбивает дальнейшее общение по шине. Я сделал топорное решение и после каждой отправки байта в регистр запихал программную задержку в несколько тактов:
Код:
SPI2_write_reg(0x02, 0x0F); // RESET while (Tempi < 100000) {Tempi++;} Tempi = 0;
RC522_write_register(0x2A, 0x8D); while (Tempi < 2) {Tempi++;} Tempi = 0;
RC522_write_register(0x2B, 0x3E); while (Tempi < 2) {Tempi++;} Tempi = 0;
После таких извращений данные передаются и я получаю нормальный ответ от слейва. Собственно вопрос: Как правильно контролировать длину строба NSS между транзакциями, чтоб она не была слишком мелкой? Может есть какие флаги или хитрости? Я пробовал работать с BSY, но толку нет.
Посмотрите какая вам нужна задержка, если хватает пару тактов, то их можно внутри дефайна спрятать.
Дык в том то и дело, что мне программные задержки вообще не нужны. И циклы while в функции SPI2_send_byte я тоже через прерывания потом переделаю. Касаемо программных задержек - у меня паранойя. Я уже и забыл последнюю программу, в которой они у меня были. Все исключительно через прерывания и таймеры .
Myp3ik писал(а):
Для начала, есть флаги:
Ну дык поглядите в мою функцию SPI2_send_byte. Там как раз все через эти флаги и работает. Выход из нее происходит только после очистки RXNE, а к этому времени TXE уже точно сброшен. Вот и получается, что при стробе оба флага уже очищены.
dosikus писал(а):
почитай мои посты начиная отсюда
Ушел читать .
Добавлено after 37 minutes 2 seconds: Прочел, но что-то не нашел ответа. И функция вроде такая же была. Только при DMA появились новые флаги, но DMA у меня пока нет....
Это понятно. У меня же в функции записи есть return (*(__IO uint8_t *)((uint32_t)&(SPI2->DR))); . А проблему решил таки. По RM строб у SPI должен быть длительностью не менее одного периода тактовой частоты (на практике оказалось, что работает и с длительностью в пару раз меньше), но у меня он был меньше раза в 3. В настройках SPI биты SPI_CR1_BR были установлены все, что означало делитель тактовой частоты в 256. При 8МГц тактовой ядра мы получаем частоту тактирования SPI примерно 31КГц и период около 32 мкс. Время перехода от конца до начала функции (оно же время строба NSS) у меня составило около 6 мкс. с проверками флагов, чего было явно недостаточно. Решение: тупо увеличиваем частоту SPI установкой битов SPI_CR1_BR, чтоб период составил не менее 6мкс. (в моем случае).
P.S. С этими бесконтактными картами оказалось все не так просто. Сейчас создам отдельную тему, если кого заинтересует - милости просим .
Здравствуйте! Есть контроллер STM32F103ZGT6, который ведет себя как-то странно: При определённом размере программы может перестать запускается, для того что бы его оживить нужно в произвольном месте программы добавить любую функцию – например delay, или в массивах начинает появляется непонятные значения – мусор. Подозрение что у микроконтроллера битая ОЗУ. Можно ли как-нибудь проверить память контроллера?
Попробуйте для начала полностью стереть память чипа. В Кейле для этого нужно в настройках отладчика во вкладке Flash Download в разделе Download Function выбрать Erase Full Chip. Также, если работаете на высокой частоте, то проверьте делитель для низкоскоростной шины и FLASH. Либо просто прогоните программу на восьми мегагерцах.
Не хватает флага перехода на PLL. А может и ещё чего (ночь, мозги тормозят ). У меня сначала переключается FLASH, а потом PLL. Я всегда пользуюсь таким блоком кода:
И не только его. Похоже, из-за этого и были глюки при запуске. Попробовал ваш код - частота упала в два раза. Только потом дошло что PLL, запитан от внутреннего генератора. Спасибо! Теперь вроде разобрался.
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 16
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения