[EdgeAligned 80]

...и именно поэтому более продвинутые серии STM имеют дополнительные PLL и выбор источников тактирования различной периферии

[Forger 21]

12 minutes ago, Arlleex said:

когда на конкретные особенности МК внимания не обращал при закладывании в проект

Ну, конечно, в этом виноваты маркетологи, кто же еще

[Arlleex 160]

2 минуты назад, EdgeAligned сказал:

...и именно поэтому более продвинутые серии STM имеют дополнительные PLL и выбор источников тактирования различной периферии

Да, только до маркетологов вопли юзеров долетают через лет этак 10. Блок делителей - это не ахти сколько транзисторов, это не доп. SPI какой-нибудь, но нет же, нарекламируют с гору, а как начинаешь что-то поднимать отличное от ардуино-скетчей, начинают всплывать сюрпризы, как какахи собак по весне

[jcxz 220]

32 минуты назад, Arlleex сказал:

А МК не имел LPUART?

Не очень понимаю о чём Вы... Там все UART-ы тактируются от одной частоты, если что. Все одинаковые.

32 минуты назад, Arlleex сказал:

Кол-во разрядов, это, конечно, хорошо, но гораздо лучше, когда 8 разрядным делителем можно делить на коэф-ты 1...256 с шагом 1

Именно такой там и есть. Я же говорю - "8-разрядный делитель". Делитель любой в диапазоне 1...256.

[Forger 21]

5 minutes ago, Arlleex said:

Блок делителей

Опишите в концов конкретный реальный пример, где действительно очень нужны такие суперточные предделители ПЕРЕД перефирийными блоками.

[Arlleex 160]

9 минут назад, Forger сказал:

Ну, конечно, в этом виноваты маркетологи, кто же еще

Да, именно они. Я считаю, что при проектировании платы должно быть (по-хорошему) достаточно беглого взгляда на даташит МК.

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

И только спустя N дней ковыряния понимаешь, что где-то в референся где-то в закаулках главы конкретной периферии будет сноска: ой извините тут есть ограничение.
 

3 минуты назад, jcxz сказал:

Не очень понимаю о чём Вы... Там все UART-ы тактируются от одной частоты, если что. Все одинаковые.

Просто есть МК с периферией, разработанной специально для энергосберегающих приложений. В STM32 том же - LPUART, например. Он уже тактируется от 32-кГц генератора и работает вне зависимости от сна CPU.

Цитата

Именно такой там и есть. Я же говорю - "8-разрядный делитель". Делитель любой в диапазоне 1...256.

Вот - хороший МК значит, подумали о юзерах.

[dimka76 56]

On 10/12/2023 at 4:27 PM, Arlleex said:

Вот - хороший МК значит, подумали о юзерах.

В одном месте подумали, в другом - позабыли.
У другого производителя у другого МК найдутся свои оптимальные и неоптимальные сочетания.

[jcxz 220]

51 минуту назад, Сергей Борщ сказал:

В такой системе systick почти не нужен  Просто ищу наименьший timeout из активных и завожу на него будильник. А при пробуждении ОС вычитываю из будильника, сколько же прошло времени на самом деле (разбудить ведь мог не будильник, а какое-то другое прерывание) и подправляю системное время и оставшиеся timeout-ы. SysTick включаю только на время исполнения задач ОС, перед спячкой выключаю.

Примерно также делал в том проекте: по блокам контроля задач искал минимальное время сна; вычислял минимум между ним и 300 мсек; и ложился спать с будильником на это время. По факту просыпания - вычислял реальное время сна (так как разбудить могло и стороннее прерывание) и декрементировал счётчики сна задач на эту величину. Такая эмуляция tickless OS. 

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

[Arlleex 160]

46 минут назад, Forger сказал:

Опишите в концов конкретный реальный пример, где действительно очень нужны такие суперточные предделители ПЕРЕД перефирийными блоками.

USB/CAN-анализатор в несколько одновременных каналов, умеющий не только ряд предопределенных битовых скоростей CAN-шины.

[Forger 21]

3 minutes ago, Arlleex said:

USB/CAN-анализатор

Это пример не годится. Ищите другой.

Внутри любого нормального CAN модуля есть свой предделитель, который можно настроить как душе угодно.

"Стандартные" скорости выбираются просто определенными значениями этого предделителя, выбирайте нестандартные, никто не мешает. Особенно, если работать с регистрами напрямую.

 

[jcxz 220]

1 час назад, Arlleex сказал:

И только спустя N дней ковыряния понимаешь, что где-то в референся где-то в закаулках главы конкретной периферии будет сноска: ой извините тут есть ограничение.

Да, с STM это знакомо! 

Примерно с год назад принесли схему (уже с готовой платой  ) в которой стоял STM32L151. Предполагалось использование USB (кроме прочей периферии). Вроде USB там есть, да и сильно больших задач на него не возлагалось: так - одна изохронная точка на исходящий поток ~600 кБ/с. В мануале на этот МК гордо гарантируется: соответствует USB-FS. И уже только после поднятия USB-стека выясняется что..... не совсем оно соответствует USB-FS.  А точнее - вообще не соответствует. Так как память USB (Packet Memory) там размером всего 512 байт и ни байта больше!   А минимальная конфигурация для работы USB: 2 контрольные точки + 1 изохронная ep-in. И в этой памяти соответственн нужно иметь 3 дескриптора (для 3х точек) + память под два буфера равных размеру изохронной точки. Так как изохронные передачи работают в режиме обязательной двойной буферизации, с буферами переключаемыми аппаратно на границе кадра. И никак это не обойти - просто битик активного буфера read-only и переключается сам. И получается: (512-3*16)/2 = 232 байта - таков максимальный размер изохронной точки (всего 232 кБ/с максимум вместо требуемых 600 кБ/с). А по стандарту должен быть не менее 1023 байт.

Вот такая подстава.   И нигде в мануале про это явно не говорится. Человек, проектировавший плату изначально, до этого не дорыл конечно. Поэтому пришлось менять МК и всё переделывать.

1 час назад, Arlleex сказал:

Просто есть МК с периферией, разработанной специально для энергосберегающих приложений. В STM32 том же - LPUART, например. Он уже тактируется от 32-кГц генератора и работает вне зависимости от сна CPU.

Нет, LPC1758 он не позиционировался как энергосберегающий. Поэтому такого в нём нет - все UART тактируются от единой системной частоты. От которой и CPU (с доп.делителем только).

Да даже если бы и был - скорость требуемая по UART была - не менее 230400 бод. LPUART не потянул бы всё равно (почему и тактовая МК = 6 МГц, иначе поставил бы намного меньше).

[amaora 23]

5 hours ago, Arlleex said:

Нельзя. Адрес должен быть выровнен на гранулярность кэш-строки (32 байта?). Вернее, писать Вы туда можете что угодно, но биты [5...0] анализироваться не будут.

Это где-то явно указано в документации ST или ARM? Что можно писать что угодно?

[Arlleex 160]

36 минут назад, amaora сказал:

Это где-то явно указано в документации ST или ARM? Что можно писать что угодно?

Я когда-то (когда время от времени возился с ARM Cortex-A9 в цинке) видел документ, официальный, со всеми описаниями. Сейчас сходу не ищется, а у ARM в документации, действительно, сейчас я не вижу описания битовых полей.

Интереса ради открыл cachel1_armv7.h:

/**
  \brief   D-Cache Invalidate by address
  \details Invalidates D-Cache for the given address.
           D-Cache is invalidated starting from a 32 byte aligned address in 32 byte granularity.
           D-Cache memory blocks which are part of given address + given size are invalidated.
  \param[in]   addr    address
  \param[in]   dsize   size of memory block (in number of bytes)
*/
__STATIC_FORCEINLINE void SCB_InvalidateDCache_by_Addr (volatile void *addr, int32_t dsize)
{
  #if defined (__DCACHE_PRESENT) && (__DCACHE_PRESENT == 1U)
    if ( dsize > 0 ) {
       int32_t op_size = dsize + (((uint32_t)addr) & (__SCB_DCACHE_LINE_SIZE - 1U));
      uint32_t op_addr = (uint32_t)addr /* & ~(__SCB_DCACHE_LINE_SIZE - 1U) */;

      __DSB();

      do {
        SCB->DCIMVAC = op_addr;             /* register accepts only 32byte aligned values, only bits 31..5 are valid */
        op_addr += __SCB_DCACHE_LINE_SIZE;
        op_size -= __SCB_DCACHE_LINE_SIZE;
      } while ( op_size > 0 );

      __DSB();
      __ISB();
    }
  #endif
}

Обращаю внимание на закомментированную строку выравнивания адреса. Функция предполагает, что ей подпихнут выровненный адрес на 32-байтную границу. Да, это не подтверждает, что писать можно любой адрес, даже не выровненный, но подтверждает, что юзер должен оперировать строками кэша. Размещать рабочие буферы DMA так, что "по соседству" в одной кэш-строке могут оказаться какие-то другие переменные - весьма чревато. Так зачем испытывать судьбу и писать что-то невыровненное?

P.S. Искать тот документ сейчас вряд ли буду, т.к. у Xilinx и ARM их целая библиотека - это заняло бы какое-то неоправданное время🙂

[Arlleex 160]

4 часа назад, Forger сказал:

Это пример не годится. Ищите другой.

Внутри любого нормального CAN модуля есть свой предделитель, который можно настроить как душе угодно.

"Стандартные" скорости выбираются просто определенными значениями этого предделителя, выбирайте нестандартные, никто не мешает. Особенно, если работать с регистрами напрямую.

Пожалуй, соглашусь: для USB/CAN проблем, в общем-то, нет. Плохой пример.

Там был у меня не USB, а UART-ы на 2 Мбит ровно (потому что FT-шка из нестандартных умеет 2 Мбит). Проц молотил на 168 МГц (вернее, я так хотел), UART-ы на 2 Мбит нормально ложатся по предделителям (хотя и на разных шинах, не суть). А вот CAN-модули тактируются от APB1, максимальная частота на нем 42 МГц, соответственно. И как мне получить стандартный битовый рейт 800кбит/с? Прямой подсчет показывает, что 42 МГц / 800 кбит/с = 52.5. Т.е. уже НИКАКОЙ целый предделитель нормально ровные 800 кбит не установит. Пришлось немного снижать частоту CPU, благо это было возможно с запасом.

Пример с USB на F427/429: USB берет 48 МГц от постделителя Q основного PLL, этот Q можно настроить в пределах 2 ... 15. Итого, допустимые SYSCLK: 96 и 144 МГц. И к чему мне 144 МГц, когда проц заявлен на 180 честных МГц? 20% потенциальной мощности CPU просто вникуда! Что мешало добавить дробные делители или вовсе отдельный PLL, как это делают в, например, LPC1768? Почему на I2S и SAI выделили по отдельному PLL, а на USB - нет? Досрочный ответ я уже выше давал - потому что гладиолус - маркетологам виднее.

[Arlleex 160]

5 часов назад, jcxz сказал:

Так как память USB (Packet Memory) там размером всего 512 байт и ни байта больше!

А мы даже просто напарывались на то, что USB с CAN-ом в F103 одновременно не работают... Но это было настолько давно, что ныне это сочетание - один из исторических мемов STM32