Перейти к содержанию
    

Flexz

Свой
  • Постов

    252
  • Зарегистрирован

  • Посещение

Сообщения, опубликованные Flexz


  1. Случайно набрел на сайте ST на новую чуду-юду

    Мануала пока не нашел, только даташит. Но и по нему уже выглядит интересно. Наконец-то 400МГц, целый мегабайт ОЗУ, по внутренним шинам и ДМА все капитально перетряхнули, аналоговую часть похоже от F3 взяли.

  2. Сначала подумал, что "трудности перевода" потом посмотрел на фудзиллу, на которую ссылается oszone - так там та же лажа, 64 битный чип и двух-уровневый кеш. Ничего из этого в оригинальном пресс-релизе от ARM нет. Ядро 32-бита, 64-битная только шина (AXI), кеш одноуровневый, хотя и два - инструкций и данных.

    Там же кстати написано

    In 2013, ARM's partners shipped some 3 billion ARM-based microcontrollers
    - 3 миллиарда чипов только за год! А тут какие-то 8 миллионов

     

    И где только журналюги берут исходные данные? сами выдумывают?

  3. Двигателями пробовали управлять с помощью Cortex-M4?

    Там толко одно название, что они заточены для этого, а в принципе их хватает только на пару примитивных векторных преобразований да несколько измерений с несложной фильтрацией.

    А вот подняв производительность раза в три уже можно безсенсорный функционал поднять в полный рост.

     

    Работа в открытом интернете и облаках тоже по сей день кортексам была тяжеловатой задачей.

    Но естественно она и останется тяжелой пока ST не научится к своим кортексам подключать DDRAM.

    Вот поэтому Freescale перспективней.

    Пробовал. Двигателями и на AVR-ке можно управлять, а когда заказчик требует использовать отечественную элементную базу, так и вовсе не до жиру.

    И поясните, откуда рост производительности в три раза? M4 - 1.27 DMIPS/MHz, а M7 - 2.14. х1.7 в сухом остатке, даже х2 не выходит с учетом прироста частоты.

     

    С облаками не работаю, но раз ST SDRAM осилил, глядишь и до DDR дорастет. Так ли заметна разница DDR/SDR на практике?

     

    PS Откровенно говоря, мой скептицизм к новому ядру отчасти основан на "неинтересной" реализации его от ST, возможно, конкуренты сделают чипы повеселее.

  4. Микроконтроллеры с FLASH как минимум обеспечивают хоть какую-то защиту дивайса от копирования пацанами из соседнего гаража.

    Потом с такой скоростью 200 МГц этот Cortex-M7 уделает уже 500 МГц i.MX и проч. уже не говоря о софт процесорах на ПЛИС.

    А плата будет несравненно проще, меньше и экономичней.

    Про скорость спорно, в каких-то приложениях может и уделает, но в целом скорее паритет будет. Причем i.MX только те, что на ARM9, старшие - уделовалка треснет.

    Софтпроцессоры это уже вы сами придумали, не знаю к чему.

     

    Тут не узковатая ниша, а просто пропасть сколько возможностей открывается в свете трендов IoT, wearable technology, мелких роботов и проч.

    По-вашему это все это сейчас недоступно для чипов на Cortex-M4?

     

    ну так граблей то нет. Вот если бы можно было натравить и тем самым например ядро остановить - это был бы номер, а так еще на уровне оформления кода все станет ясно....

    То что вы описали это уже не грабли, это... в общем за такое убить мало :)

  5. Посмотрел по-диагонали даташит на stm32f7, ничего особенного - старый проц на новом ядре.

    Из заметных изменений только QuadSPI, много оперативки и более совершенная организация шины. Мои любимые грабли (разместить данные в TCM, забыть об этом и натравить на них DMA) больше не будут бить по лбу :)

    В остальном от 42х/43х отличий минимум. DMA контроллер такой же печальный, FIFO на UARTе не появилось. Может хоть баги из ерраты поправят.

     

    По новому ядру.. если честно не очень понимаю зачем оно, узковатую нишу рисует воображение. Когда не хватает производительности M4, скорее всего нужен слон - DSP, А-серия, ПЛИС.

  6. ...GPIO_PinSource это число с 1 в разряде соответствующей пину то есть 0x800 соответствует 11 пину...

    Ничего подобного. GPIO_PinSource это число соответствующее номеру пина напрямую, т.е. GPIO_PinSource11 это 0xB, а не 0x800.

    См дефайны в stm32f2xx_gpio.h

    #define GPIO_PinSource0            ((uint8_t)0x00)
    #define GPIO_PinSource1            ((uint8_t)0x01)
    #define GPIO_PinSource2            ((uint8_t)0x02)
    #define GPIO_PinSource3            ((uint8_t)0x03)
    и т.д.

    Ненадо додумывать, что принимают те или иные функции у ST. Смотрите в примерах, как ими пользоваться. Благо примеров в достатке.

     

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

  7. Наверное, пока произойдет возврат из прерывания (там же восстанавливаются регистры из стека, по-моему, говорится о 12 тактах, или о 6, если в новое прерывание улетает?), конвейер освободится.

    12 тактов (на аппаратное восстановление регистров из стека) будет если нет запроса прерывания. А если новый запрос есть, или старый не успел сбросится - сработает правило Interrupt tail chaining и процессор сразу пойдет на исполнение запроса.

    Что бы не было повторной обработки прерывания используют барьеры - __DSB();

  8. У вас DMA2 еще что-то делает, помимо обслуживания камеры?

    В errata описана проблема при одновременной работы DMA2 с AHB и APB периферией.

    When the DMA2 is managing AHB Peripherals (only peripherals embedding FIFOs) and

    also APB transfers in a concurrent way, this generates a data corruption (multiple DMA

    access).

    When this condition occurs:

    ● The data transferred by the DMA to the AHB peripherals could be corrupted in case of a FIFO target.

    ● For memories, it will result in multiple access (not visible bythe Software) and the data is not corrupted.

    ● For the DCMI, a multiple unacknowledged request could be generated, which implies an unknown behavior of the DMA.

    AHB peripherals embedding FIFO are DCMI, CRYPTO, and HASH. On sales types without

    CRYPTO, only the DCMI is impacted. External FIFO controlled by the FSMC is also

    impacted.

  9. возможно что причина была в маленьких задержках при чтении флеш было заменено FLASH_ACR_LATENCY_5WS на FLASH_ACR_LATENCY_6WS, частота 168, напряжение питания 2,85

     

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

    Из личного опыта, при тех же 3.3В 168Мгц процессор успешно работает на 3WS, на неделю, конечно, не оставлял, но несколько часов - вполне держит. Так же все процессоры, которые пробовал - разгонялись до 250МГц при 7WS, отдельные экземпляры гнались и выше. Так что параметры задержек в доках даны с запасом. Хотя помониторить питание, конечно, стоит.

     

    Если дело действительно в просадке питания, то не забываем, что в ОЗУ нужно располагать не только сами вектора, но и всю таблицу прерываний.

  10. Из даташита

    The USB OTG HS supports both full-speed and high-speed operations. It

    integrates the transceivers for full-speed operation (12 MB/s) and features a UTMI low-pin

    interface (ULPI) for high-speed operation (480 MB/s). When using the USB OTG HS in HS

    mode, an external PHY device connected to the ULPI is required.

    Т.е. если использовать второй USB в FS режиме, то можно обойтись без внешней физики.

  11. Ну вы же с какой-то целью функцию в ОЗУ разместили? Вот компилятор и предупреждает, что не вся она будет из ОЗУ выполняться.

    Опасно может быть например тем, что некоторые процессоры выполняют бутлоадер исключительно из ОЗУ (т.е. во время обновления прошивки код из флеш вообще не может исполняться).

  12. Учитывайте что у флешки в этих МК широкая шина и за один цикл обращения считывается ЕМНИП 128 бит, применительно к F103. Поэтому простой линейный код не страдает от расположения во фшелке. А вот с ветвящимся не так однозначно, с одной стороны при ветвлениях будет возникать задержка по обращению к флешу (если код во флешке), а с другой - ветвящийся код обычно активно работает с данными, поэтому задержка будет возникать и на шине данных (если код в озу), а если с оперативкой еще и DMA контроллер работает - будет только хуже.

     

    Так что пишите код во флешку и не заморачивайтесь.

  13. Поигрался сейчас еще с тулзой, так вот - считает она вроде бы верно. При 8МГц кварце получил такие параметры

     *-----------------------------------------------------------------------------
     *        System Clock source                    | PLL (HSE)
     *-----------------------------------------------------------------------------
     *        SYSCLK(Hz)                             | 168000000
     *-----------------------------------------------------------------------------
     *        HCLK(Hz)                               | 168000000
     *-----------------------------------------------------------------------------
     *        AHB Prescaler                          | 1
     *-----------------------------------------------------------------------------
     *        APB1 Prescaler                         | 4
     *-----------------------------------------------------------------------------
     *        APB2 Prescaler                         | 2
     *-----------------------------------------------------------------------------
     *        HSE Frequency(Hz)                      | 8000000
     *-----------------------------------------------------------------------------
     *        PLL_M                                  | 8
     *-----------------------------------------------------------------------------
     *        PLL_N                                  | 336
     *-----------------------------------------------------------------------------
     *        PLL_P                                  | 2
     *-----------------------------------------------------------------------------
     *        PLL_Q                                  | 7
     *-----------------------------------------------------------------------------
     *        PLLI2S_N                               | 271
     *-----------------------------------------------------------------------------
     *        PLLI2S_R                               | 6
     *-----------------------------------------------------------------------------
     *        I2S input clock(Hz)                    | 45000000
     *                                               |
     *        To achieve the following I2S config:   |
     *         - Master clock output (MCKO): ON      |
     *         - Frame wide                : 16bit   |
     *         - Audio sampling freq (KHz) : 44,1    |
     *         - Error %                   : 0,0000  |
     *         - Prescaler Odd factor (ODD): 0       |
     *         - Linear prescaler (DIV)    : 2       |
     *-----------------------------------------------------------------------------
    

    Так вот, если посмотреть внимательно на окно экселя и вывод в файл - видим что в файое I2S input clock(Hz) 45000000, однако в экселе - 45.1667МГц, да и если просто посчитать - 1Мгц * 271 / 6 = 45166666Гц и 45166666Гц/ (256 * 4) = 44108Гц, что довольно близко к искомым 44100.

  14. Но для частоты кварца 8МГц на выходе I2S получается что то около 43556ГЦ и это режет слух. Как подобрать более точно частоту пока не нашел.

    А вы пользовались Clock configuration tool для подбора частоты I2S? Самому со звуком поработать не довелось, но вот в тулзе сейчас легко получил 44.1кГц с ошибкой 0.0011%

  15. кстати, если делать не на декодере, а на регистрах

    То получится тоже самое :) Если регистры фиксированы, и задаются только на ресете - при синтезе они заменятся на комбинаторику.

×
×
  • Создать...