[uquote="Asmodey",url="/forum/viewtopic.php?p=4060370#p4060370"]С ST не соскучишься [/uquote]
Я считал, что F303 — сравнительно свежий чип (не старее F072). Но, судя по Errata, это просто жесть какая-то!!!
Linux rules! Windows must die. Здравомыслящий человек добровольно будет пользоваться мастдаем лишь в двух случаях: под дулом автомата или под влиянием анального зонда. Я на гитхабе, в ЖЖ
[uquote="Asmodey",url="/forum/viewtopic.php?p=4060370#p4060370"]Зато в цирк ходить не нужно. С ST не соскучишься [/uquote]
Вот только от производителя чипов ожидаешь вменяемой документации и железа, а не цирка!
Хотя вы правы, для таких как я (да и Эдди, похоже) они идеальны: всегда есть что героически превозмогать.
[uquote="Eddy_Em",url="/forum/viewtopic.php?p=4060415#p4060415"]Я считал, что F303 — сравнительно свежий чип (не старее F072). Но, судя по Errata, это просто жесть какая-то!!![/uquote]
Когда последний раз Errata для F072 открывал? Она даже чуть больше, чем для F303, хотя последний сложнее, а год выпуска у серий одинаковый.
Там ничего принципиального для меня нет, поэтому я ее давно полистал, увидел, что мне ничего страшного не грозит (т.к. всякие экзотические режимы я не использую) и забил.
А вот у F303 сразу в глаза бросается, например, "ADEN bit cannot be set immediately after the ADC calibration is done" — забавный глюк, надо иметь в виду. Вот это: "Imprecise VREFINT calibration values" не может не "радовать".
Вот еще жесть: "BSY bit may stay high at the end of a SPI data transfer in slave mode". Хочешь работать в SPI slave? Отрубай SPI после каждой передачи, а как BSY упадет, можешь включать обратно!
Вроде, больше особых косяков в errata на STM32F303 не заметил. У 072 ни одного такого серьезного косяка нет!
Linux rules! Windows must die. Здравомыслящий человек добровольно будет пользоваться мастдаем лишь в двух случаях: под дулом автомата или под влиянием анального зонда. Я на гитхабе, в ЖЖ
[uquote="Eddy_Em",url="/forum/viewtopic.php?p=4060467#p4060467"]А вот у F303 сразу в глаза бросается, например, "ADEN bit cannot be set immediately after the ADC calibration is done" — забавный глюк, надо иметь в виду. Вот это: "Imprecise VREFINT calibration values" не может не "радовать".[/uquote]
Так ведь и сам ADC у F3 намного сложнее, тем более у предыдущих серий такого не было, так что даже если бы F3 были новее это бы не сильно помогло.
Eddy_Em писал(а):Вот еще жесть: "BSY bit may stay high at the end of a SPI data transfer in slave mode". Хочешь работать в SPI slave? Отрубай SPI после каждой передачи, а как BSY упадет, можешь включать обратно!
SPI у STM32 в принципе жесть, особенно в режиме слейва, а конкретно этот баг есть и у новых G0/G4, видимо его исправление не самая приоритетная задача.
На F072 у меня никаких проблем с SPI-slave не было, Rx/Tx по DMA.
А вот чего реально не хватает, так это каналов DMA!!! Их нужно хотя бы 32. Но лучше бы — 64. С семью каналами F072 далеко не уйдешь. Да и у F303 всего-то на 5 каналов больше. Тоже мне…
Если нужно одновременно работать с обоими SPI, I2C и четырьмя USART'ами, то вариант полностью отдать ненужные потуги на DMA не прокатывает ☹
А еще ведь бывает нужно таймеру регистры менять при помощи DMA (+складывать захваченное в массив — для того же 1-wire) или генерировать ЦАПом что-нибудь…
В общем, за малое количество каналов DMA жирнейший минус ST!
Linux rules! Windows must die. Здравомыслящий человек добровольно будет пользоваться мастдаем лишь в двух случаях: под дулом автомата или под влиянием анального зонда. Я на гитхабе, в ЖЖ
[uquote="Eddy_Em",url="/forum/viewtopic.php?p=4060490#p4060490"]А вот чего реально не хватает, так это каналов DMA!!! Их нужно хотя бы 32. Но лучше бы — 64. С семью каналами F072 далеко не уйдешь. Да и у F303 всего-то на 5 каналов больше. Тоже мне…[/uquote]
Есть G0 у который 3 SPI, 3 I2C, 6 USART, 2 LPUART и 13 таймеров, не считая всякие SysTick, а каналов DMA всего 12, хотя DMAMUX позволяет связать любой канал с любой периферией. Возможно это не каналов мало, а концепция их использования не совсем верна
COKPOWEHEU, Tx у меня всегда по DMA, а с Rx, конечно, чаще по прерыванию буфер наполняю, но вот при работе на скоростях под мегабод нужно DMA. Для понимания, что строка закончилась, использовать прерывание по символу '\n'.
С SPI на F072 и Rx, и Tx по DMA очень удобны. Вот с I2C DMA нет смысла использовать, т.к. обычно посылки короткие, а отрабатывать NAK'и на этапе адресации все равно придется.
А вот это:
Есть G0 у который 3 SPI, 3 I2C, 6 USART, 2 LPUART и 13 таймеров, не считая всякие SysTick, а каналов DMA всего 12
считаю вообще издевательством над пользователями! На кой черт такая прорва периферии, если даже половину нельзя одновременно запустить? 3 SPI убьют 6 каналов DMA, если даже в USART'ах только на Tx использовать DMA, то все каналы уже кончились!
А примеров, когда нужно одновременно (еще и порой на разных скоростях) несколько усартов использовать, придумать можно множество. Вот, делал как-то хронометр для соревнований. Там одновременно три усарта (GPS, дальномер и канал служебных сообщений; по USB — основной канал). А в планах было два дальномера втыкать + еще блютус (через USART) и GSM для общения СМСками старта и финиша. Если же захочется экономить на общении, то вместо SMS нужно будет еще один усарт в качестве модема использовать (т.е. дозвонился один раз финиш до старта и держит связь), либо ШИМ'ом делать частотную модуляцию!
Linux rules! Windows must die. Здравомыслящий человек добровольно будет пользоваться мастдаем лишь в двух случаях: под дулом автомата или под влиянием анального зонда. Я на гитхабе, в ЖЖ
[uquote="Eddy_Em",url="/forum/viewtopic.php?p=4060589#p4060589"]А примеров, когда нужно одновременно (еще и порой на разных скоростях) несколько усартов использовать, придумать можно множество. Вот, делал как-то хронометр для соревнований.[/uquote]
Хронометр - медленное устройство, если он сотые считает, то между ними будет 480 тыс. тактов, там DMA не нужен, а если сильно хочется, то 7 каналов точно хватит.
static inline void gpio_setup(){
RCC->AHBENR |= RCC_AHBENR_GPIOAEN | RCC_AHBENR_GPIOBEN; // for USART and LEDs
GPIOA->ODR = 0; // don't work without this!
GPIOB->MODER = GPIO_MODER_MODER0_O | GPIO_MODER_MODER1_O;
GPIOB->ODR = 1;
}
Если закомментировать строчку с GPIOA->ODR=0, ничего не работает (хотя блымк на PB0/PB1, а тактирование GPIOA включаю для настройки USART)!
А если и мигает светодиодами, то зависает на первом же прерывании USART RXNE.
Linux rules! Windows must die. Здравомыслящий человек добровольно будет пользоваться мастдаем лишь в двух случаях: под дулом автомата или под влиянием анального зонда. Я на гитхабе, в ЖЖ
Eddy_Em а зачем столько DMA? Медленные процессы же нормально по IRQ обрабатывать и все это у людей сто лет даже совсем без DMA работало, еще и гибче намного. Представляю себе как скорость радостно поделится на 64. А дебажить это, когда раз в год все 64 одновременно ломанутся, и окажется что вот так оно не успевает обслуживать кого-то - не задолбаетесь потом? А там еще процессор на это претендует. Нехилая гирлянда. Если все это по внешним событиям и проч то средний и наихучший случай могут быть 2 разницы. И даже просто прикинуть его в гирлянде с 64 участниками + проц как-то не очень. И это при том что смысл небольшого микроконтроллера в предсказуемости?
У как минимум некоторых STM32F1xx есть еще DMA2, правда, там только 5 каналов, но 12 каналов на подобный чип ближе к верху разумного предела как мне кажется. С точки зрения адекватного поведения системы без лишней провокации странных вещей. И как минимум F1xx не созданы под огромные потоки данных. F0/G0/L0 еше более не для этого, чисто структурно, по шинам и памяти. Такой аппетит просит кучу шин и независимых банков памяти с кучей матриц коммутаторов и проч, т.е. большой и крутой чип. Может вам FPGA на самом деле хотелось вообще?
Прошерстил уже и линкер-скрипт: ничего страшного не нашел. Попробовал решить глюк с "мыргаю-не мыргаю" добавлением паузы после включения тактирования RCC_AHBENR_GPIOBEN. В общем, почему-то вот так работает:
static inline void gpio_setup(){
RCC->AHBENR |= RCC_AHBENR_GPIOAEN | RCC_AHBENR_GPIOBEN; // for USART and LEDs
for(int i = 0; i < 10000; ++i) nop();
GPIOB->MODER = GPIO_MODER_MODER0_O | GPIO_MODER_MODER1_O;
GPIOB->ODR = 1;
}
А без паузы - нет!
Ни у F0x2, ни у F103 такого глюка не встречал!
USART1 проверил - работает.
Linux rules! Windows must die. Здравомыслящий человек добровольно будет пользоваться мастдаем лишь в двух случаях: под дулом автомата или под влиянием анального зонда. Я на гитхабе, в ЖЖ
По виду этого костыля все выглядит как будто RCC_AHBENR_GPIOBEN почему-то возымел эффект не сразу и до этого включаемый блок либо не был активен, либо глючил. А код на ассемблере там адекватный получается в этом месте? Компилер ничего не переупорядочил/оптимизнул там?
Даже интересно. Ладно, когда запускается генератор, ему нужно время, чтобы частота устаканилась. Но тактирование периферии, по идее, мгновенно должно срабатывать, так как по сути это должно быть разрешение сигналом с регистра проходить тактирующему сигналу через вентиль.
Кстати, хорошо бы ещё проверить, а что будет, если эту паузу в самое начало программы поставить.
[uquote="Eddy_Em",url="/forum/viewtopic.php?p=4061406#p4061406"]А без паузы - нет![/uquote]
Видимо порты не успевают включиться, а ты их сразу инитишь. Убери паузу и проверь что в MODER записалось. HAL-ие макросы после включения периферии читают из регистра, чтобы удостовериться, что запись завершена.
Т.е. каждый раз ожидаю, а если проблема - возвращаю 0 (в этом случае включаю HSI и там по периоду видно, т.к. в этом случае системная шина на 48МГц, а не 72). В асме все нормально.
А еще у меня не получается FPU активировать. Добавил простую float переменную и выражение сложения. FPU активирую:
TRUE_INLINE void enable_FPU(){
SCB->CPACR |= ((3UL << 10*2)|(3UL << 11*2)); /* set CP10 and CP11 Full Access */
}
Однако, фигвам! Несмотря на асмовские инструкции для FPU, МК "уходит в себя".
Linux rules! Windows must die. Здравомыслящий человек добровольно будет пользоваться мастдаем лишь в двух случаях: под дулом автомата или под влиянием анального зонда. Я на гитхабе, в ЖЖ
[uquote="Eddy_Em",url="/forum/viewtopic.php?p=4060589#p4060589"]на скоростях под мегабод нужно DMA[/uquote]
У меня юарт на 2Мбит лупашит. Кроме DMA пришлось прикрутить аппаратную детекцию таймаута по Rx, чтобы максимально быстро ловить пакеты. еще крутится спай, эзернет стек, CAN, отладочный юарт. даже работает.
А уходит в себя - случайно не hardfault какой-нибудь, который не получился и активировался deadlock? Вроде это единственный эффективный способ совсем повесить ARM. И да, может с wait states что-то не так? Так наверное и настоящий deadlock можно поймать, если "что-то не так" будет и с обработчиком исключения.
И кстати конструкция вида #define WAITWHILE(x) do{StartUpCounter = 0; while((x) && (++StartUpCounter < 0xffffff)){nop();}; if(x) return 0;}while(0) мне не очень нравится. Вы для принятия решения проверяете хардварный регистр, дважды, при том что никто не обещал что хардварный регистр не поменяется сам по себе. Что-то типа if (StartUpCounter >= 0xffffff) -> таймаут было бы логичнее чем уповать на то что там в хардварном регистре. Просто потому что StartUpCounter не может меняться сам по себе, в отличие от. В данном случае проблема конечно не в этом, но может лучше так не делать лишний раз?
Откуда ж я знаю: хардфолт там или нет? Даже если б я и хотел gdb запустить, ни один из этих 10МК не работает с SWD. Про это я уже писал: прошиваю через бутлоадер.
Что до проверки регистра, то без разницы: счётчик или содержимое регистра проверять.
А если регистр настроек меняется "сам по себе", то такой МК нужно выкинуть!
Linux rules! Windows must die. Здравомыслящий человек добровольно будет пользоваться мастдаем лишь в двух случаях: под дулом автомата или под влиянием анального зонда. Я на гитхабе, в ЖЖ
[/uquote]
