STM32 новичку в ARM что к чему

Satyr

КРАМ писал(а):

А если программист может писать и на АСМе и на Си, но затрудняется делать существенные вставки на АСМе?

Он не МОЖЕТ, он ДОЛЖЕН. Если мы говорим о системном (как область обязанностей, не обязательно единственное занятие) программисте

Цитата:

Тогда такой программист пишет либо на Си, либо на АСМе - в зависимости от задачи.

Вот именно об этом и речь.
С оговоркой, что задача - это не проект целиком, а проект - совокупность задач =))

Реклама

Satyr

КРАМ писал(а):

АРМ архитектура по сути не совсем архитектура реального времени из-за неопределенного времени исполнения команд и входа в обработчик прерываний. Из-за чего требуется более высокая частота работы

Тут уж не архитектура АРМ. Даже не говоря о том, что у АРМ чтото по Фон-нейману, чтото по Гарвардской... Каждое ядро со своим конвеером и тесно интегрированной переферией, типа контроллеров прерывания и памяти, с точки зрения определенности исполнения - уже 'своя архитектура'.

Ну а прерывания... Если критично - брать самые младшие кортексы и с макс частотой - у них конвеер короче, меньше латентность обработки прерывания. Или те ж адкие гибриды M3/4/7+M0 в одном корпусе, что те ж NXP давно начал делать, да и не только они :)))

Да, и если латентность важна - ISR функции в SRAM. Флеш с контроллерах выше ~20-30Mhz чтука архилатентная. Ну и использовать свой стек для ISR.

Реклама

Andrew Martin

КРАМ писал(а):

Но для СТМ32, учитывая особенности исполнения команд, писать на чистом АСМе, на мой взгляд, действительно идиотизм... АРМ архитектура по сути не совсем архитектура реального времени из-за неопределенного времени исполнения команд и входа в обработчик прерываний. Из-за чего требуется более высокая частота работы, чтобы минимизировать неопределенности исполнения кода и большой набор разнообразной периферии для привязки кода к реальному времени с высокой точностью.

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

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

У кортексов М0 время исполнения инструкций чётко оговорено в соответствующем документе (arm v6m technical reference manual). Время входа/выхода из обработчика тоже оговорено (с учётом приоритетов и вложенности, и возможности прерывания ldm/stm).
Латентность флеш памяти тоже оговорена, но на малых тактовых частотах можно считать нулевой. Других источников неопределённости я не знаю :dont_know:

Satyr

Andrew Martin писал(а):

Думаю что при нормальном трансляторе асма с мощными макросами скорость разработки будет не на много ниже, нежели на си с "регистровым" подходом.

Таки есть трансляторы асма с код мувингом и инстракшн шеддулингом ? :)))

Реально, я не в курсе современного, я представлял себе компилер асма чисто как предпроцессор+транслятор их мнемонического кода в машинный.
Дело в том, что времена, когда можно было генерировать оптимальный код с табличкой по циклам единичной инструкции прошли.
Важен порядок инструкций при котором они пойдут по конвееру с минимальными задержками. Напомню, кортексы начиная с M3 суперскалярны.

Да и про архитектуру системы памяти тоже нельзя забывать. Было дело, поднял производительность процентов на 30% тормознув ядро по частоте на 12% -))

Реклама

Эиком - электронные компоненты и радиодетали

Satyr

Andrew Martin писал(а):

У кортексов М0 время исполнения инструкций чётко оговорено в соответствующем документе

Вот, собсно, граница, на которой все просто почти "как на AVR", я бы очертил M0 на 24Mhz.

Реклама

Andrew Martin

Satyr писал(а):

Andrew Martin писал(а):

У кортексов М0 время исполнения инструкций чётко оговорено в соответствующем документе

Вот, собсно, граница, на которой все просто почти "как на AVR", я бы очертил M0 на 24Mhz.

Так и есть. Выше по частоте уже латентность флеша, но она, как я понял из умных доков, тоже величина вполне определённая. Но можно же код исполнять из ОЗУ - AVR такое и не снилось

Правда таблица векторов всё равно жестко сидит во флеше, но обработчики тоже ведь можно затолкать в ОЗУ. Это на случай если латентность жмёт.

Разговор сейчас именно о М0, посему не будем упоминать М3 и старше зря.
Кто-нибудь прояснит вопрос по SPI?

Реклама

Andrew Martin

Satyr писал(а):

Andrew Martin писал(а):

Думаю что при нормальном трансляторе асма с мощными макросами скорость разработки будет не на много ниже, нежели на си с "регистровым" подходом.

Таки есть трансляторы асма с код мувингом и инстракшн шеддулингом ? :)))

Реально, я не в курсе современного, я представлял себе компилер асма чисто как предпроцессор+транслятор их мнемонического кода в машинный.
Дело в том, что времена, когда можно было генерировать оптимальный код с табличкой по циклам единичной инструкции прошли.
Важен порядок инструкций при котором они пойдут по конвееру с минимальными задержками.

Воно каких слов понабирались, да всё заграничных - "код мувингом и инстракшн шеддулингом" :)))

Загляните в дизасме на сишный код. Я смотрел на выхлоп кейла, общая идея построения такая же, как в моём куске кода. В частности, большие 32битные константы хранятся в конце, после выхода из функции, а не в теле (перемежаясь с переходами).

Например сишный код Досикуса

Код:

SPI1->CR1 |= SPI_CR1_SPE

а у меня

Код:

   movs   r1,SPI_CR1_SPE         ;enable SPI
   ldrh   r2,[.spi1.CR1]
   orrs   r2,r1
   strh   r2,[.spi1.CR1]

И ЧТО тут оптимизировать?

В М0 на конвейер влияют только вызовы/переходы, арифметика/логика исполняется одинаково.

dosikus

Andrew Martin писал(а):

Код:

SPI1->CR2 |= SPI_CR2_FRXTH

Но этот бит относится к приёмному буферу, а у меня принимать нечего и event генерировать не нужно, поэтому я и оставил этот бит в нуле.

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

Satyr

Andrew Martin писал(а):

Загляните в дизасме на сишный код. Я смотрел на выхлоп кейла, общая идея построения такая же, как в моём куске кода. В частности, большие 32битные константы хранятся в конце, после выхода из функции, а не в теле (перемежаясь с переходами).

Это особенность Thumb кода - непосредственно адресуется +-2Кб вокруг SP. Поэтому Не делаются отдельные сегменты кода и сегменты данных, они перемежаются мелкими кусками.
Не знаю, как нынче Keil компилирует. И какие настройки оптимизации использованы. IAR с высокой степень оптимизации код так размывает, что родной дебагер уже перестает по сишному коду идти, т.к. кода с исходниками уж теряет структурную связь :)))

Хотя, даже если "выхлоп кейла, общая идея построения такая же, как в моём куске кода", то уже идея писать на асме, на котором производительность разработчика на порядок ниже, становится сомнительной.

Реклама

dosikus

Satyr, вся "крутость" адептов HAL и SPL и других недолиб неизбежно приводит убогих в тупик.
Здесь первостепенно знание железа ...

Satyr

dosikus писал(а):

Satyr, вся "крутость" адептов HAL и SPL и других недолиб неизбежно приводит убогих в тупик.
Здесь первостепенно знание железа ...

кто такие убогие, где и какой тупик и, главное, как связаны неэффективные инструменты и знание железа ?

Andrew Martin

dosikus писал(а):

Andrew Martin писал(а):

Код:

SPI1->CR2 |= SPI_CR2_FRXTH

Но этот бит относится к приёмному буферу, а у меня принимать нечего и event генерировать не нужно, поэтому я и оставил этот бит в нуле.

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

Не вполне ясно.
Ещё раз повторюсь, приёма нет т.к. нечего принимать и линия MISO настроена как обычный IO пин.

SPI тупо должен выплюнуть байт через MOSI и всё. Так можно? Или обязательно нужно что-то мутить с приёмом?

Есть одна функция передачи

Код:

spi_tx:   ;r0 = 8-bit input
   push   {r0-r3,lr}

   ldr      r1,[lcd_spi_cblock.spi_base]

   virtual at r1
   .spi1   SPI_TypeDef
   end virtual

   movs   r3,SPI_SR_BSY               ;ожидаем пока BSY не сбросится в 0
@@:
   ldrh     r2,[.spi1.SR]
   tst       r2,r3
   bne     @r
   
   movs   r3,SPI_SR_TXE                  ;ожидаем пока TXE не установится в 1
@@:
   ldrh     r2,[.spi1.SR]
   tst       r2,r3
   beq     @r
   
   strb   r0,byte [.spi1.DR]                ;отправляем байт

   pop   {r0-r3,pc}

Andrew Martin

Satyr писал(а):

Andrew Martin писал(а):

Загляните в дизасме на сишный код. Я смотрел на выхлоп кейла, общая идея построения такая же, как в моём куске кода. В частности, большие 32битные константы хранятся в конце, после выхода из функции, а не в теле (перемежаясь с переходами).

Это особенность Thumb кода - непосредственно адресуется +-2Кб вокруг SP. Поэтому Не делаются отдельные сегменты кода и сегменты данных, они перемежаются мелкими кусками.

Хотя, даже если "выхлоп кейла, общая идея построения такая же, как в моём куске кода", то уже идея писать на асме, на котором производительность разработчика на порядок ниже, становится сомнительной.

Ну вот, точно этот самый адепт

Во-первых не +-2кБ, а только +1кБ, во-вторых не SP (стек-то тут при чём?), а относительно PC.

На порядок, уважаемый, это в 10 раз. Не надо утрировать. "На порядок" возможно только тогда, когда человек всю жизнь сидел на HLL и вдруг начал пробовать асм и соответственно смотреть на него, извините, как баран на новые ворота, да плюс к тому если у него череззадничный транслятор вроде родного но неуважаемого ARMASM.

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

Поэтому не нужно разводить холивар, лучше бы с SPI помогли.

dosikus

Andrew Martin писал(а):

Не вполне ясно.
Ещё раз повторюсь, приёма нет т.к. нечего принимать и линия MISO настроена как обычный IO пин.

SPI тупо должен выплюнуть байт через MOSI и всё. Так можно? Или обязательно нужно что-то мутить с приёмом?

Для одиночных транзакций, даже если не принимаем :

Данные в буфер
Ждем флаг RXNE
Вычитываем буфер

С BSY :

проверяем TXE
Данные в буфер
Проверяем BSY

Но BSY больше подходит для блочных транзакций ...

Andrew Martin

dosikus писал(а):

Andrew Martin писал(а):

Не вполне ясно.
Ещё раз повторюсь, приёма нет т.к. нечего принимать и линия MISO настроена как обычный IO пин.

SPI тупо должен выплюнуть байт через MOSI и всё. Так можно? Или обязательно нужно что-то мутить с приёмом?

Для одиночных транзакций, даже если не принимаем :

Данные в буфер
Ждем флаг RXNE (BSY)
Вычитываем буфер

Вот оно что! :shock:

А в RM0360 об этом ни слова :dont_know:

В чём прикол не понял, но нужно будет попробовать...

А ежели выплёвывать байты с помощью DMA? Тогда как?

a5021

dosikus писал(а):

Для одиночных транзакций, даже если не принимаем :

Данные в буфер
Ждем флаг RXNE (BSY)
Вычитываем буфер

Что-то новенькое. Какое мне дело до флага приема и на кой вычитка буфера ? До такого даже индусы в SPL не додумались.

dosikus

Andrew Martin писал(а):

А ежели выплёвывать байты с помощью DMA? Тогда как?

C DMA - в прерывание от Transfer Complete DMA ждем освобождение Fifo SPI , ждем BSY .
Здесь посылка буфера в TIC55.

Код:

void DMA1_Channel4_5_IRQHandler (void)
{
  
  if(DMA1->ISR & DMA_ISR_TCIF5)
  {
    DMA1->IFCR |=DMA_IFCR_CTCIF5;
    DMA1_Channel5->CCR&=~DMA_CCR_EN;
   while(((SPI2->SR & SPI_SR_FTLVL_0))|| ((SPI2->SR & SPI_SR_FTLVL_1))){}    
   while((SPI2->SR & SPI_SR_BSY)){} 
   SPI2->CR1 &= ~SPI_CR1_SPE;
          LOAD_ON;         
          LOAD_OFF;
    
  }    

a5021 писал(а):

Что-то новенькое.

Клоуну невтерпеж снова в своем дерьме изваляться? :)))

a5021

dosikus писал(а):

Клоуну невтерпеж снова в своем дерьме изваляться? :)))

На конкретный вопрос по теме ответить не судьба? Сразу в персональную атаку? Валяйте, мне не привыкать делать из вас посмешище.

dosikus

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

Andrew Martin

dosikus писал(а):

Andrew Martin писал(а):

А ежели выплёвывать байты с помощью DMA? Тогда как?

C DMA - в прерывание от Transfer Complete DMA ждем освобождение Fifo SPI , ждем BSY

Получается в этом случае нужно только дождаться окончания передачи (чтобы не потерять данные) и всё?
Это я уже видел в мануале.

STM32 новичку в ARM что к чему

Кто сейчас на форуме