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

a5021

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

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

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

Реклама

isx

Я думаю у каждой платформы есть свое время. Вот жил я раньше на тиньках и мегах - то тут хер поджимаешь чтоб таймеров хватило, то внешних прерываний не хватает, то ног (городишь мультиплексоры внешние :facepalm:

). А потом ХОП... и стали доступны STM32F030xx за 1 бакс (на то время даже тинька самая сранная стоила в два раза дороже), да и с нереальным функционалом. Конечно же я все новые проекты на них стал делать/переучиваться.Вот и до сих пор преимущественно использую эту серию, для простеньких проектов.
А делать универсальную платформу...Зачем?? :dont_know:

Реклама

Satyr

isx писал(а):

А делать универсальную платформу...Зачем?? :dont_know:

А если изделие со сроком жизни больше 3 лет ? Это эпоха в контроллеростроении.
Или изделие в нескольких исполнениях, для которых оптимально подходят разные контроллеры, а функциональная часть софта процентов на 70 едина ?

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

isx

Satyr писал(а):

А если изделие со сроком жизни больше 3 лет ?

Если вы делаете изделие, то для него должно быть соответствующее ТЗ, под которое подгоняется имеющийся на данный момент МК (или что-то другое). Если предполагается усовершенствование проекта, то нужно заранее это предусматривать (если у вас в корпусе LQFP64 не хватит ног, то как вы планируете совместить плату с LQFP100?). Конечно, если собрав часы-будильник, вдруг захочется сделать на их основе автопилот для коптера, то взаимозаменяемые платформы необходимы

.

Реклама

Выбираем индустриальные и медицинские источники питания MEAN WELL в открытом исполнении

Использование модульных источников питания открытого типа широко распространено в современных устройствах. Присущие им компактность, гибкость в интеграции и высокая эффективность делают их отличным решением для систем промышленной автоматизации, телекоммуникационного оборудования, медицинской техники, устройств «умного дома» и прочих приложений. Рассмотрим подробнее характеристики и особенности трех самых популярных вариантов AC/DC-преобразователей MW открытого типа, подходящих для применения в промышленных устройствах - серий EPS, EPP и RPS представленных на Meanwell.market.

Подробнее>>

a5021

Satyr писал(а):

А если изделие со сроком жизни больше 3 лет ? Это эпоха в контроллеростроении.
Или изделие в нескольких исполнениях, для которых оптимально подходят разные контроллеры, а функциональная часть софта процентов на 70 едина ?

Хорошо это выглядит только на абстрактных примерах и только издалека. На деле я вижу три вайфай маршрутизатора DIR-300, в двух из которых установлены камни разных поколений одного производителя, а в одном и производитель другой. Отсюда возникает вопрос -- так ли нужна какая-то софтовая совместимость, если D-Link даже одну модель не стремается лепить на совсем разных процах?

Реклама

Satyr

isx писал(а):

Если вы делаете изделие, то для него должно быть соответствующее ТЗ, под которое подгоняется имеющийся на данный момент МК (или что-то другое).

Что значит "имеющийся" ? имеющийся где и у кого ? Обычно поле имения - это все, что доступно на рынке. И это выбор МК подгоняется под ТЗ, а не наоборот.
А далее периодически смотрится по чем сейчас покупаем комплктуху, какие и почем есть аналоги на рынке и соотносится, сколько еще есть перспектива продать, разница в цене между МК и объем работы по переходу.
Если с последним пунктом сильно облажать с привязкой к регистрам, то получения профита предъявляет намного бОльшие требования к предыдущему и предпредыдущему пунктам -))

Реклама

Распродажа паяльного оборудования ATTEN!
Паяльные станции, паяльники и аксессуары по самой выгодной цене.

По промокоду radiokot скидка 10%

Satyr

a5021 писал(а):

Отсюда возникает вопрос -- так ли нужна какая-то софтовая совместимость, если D-Link даже одну модель не стремается лепить на совсем разных процах?

Именно по этому и нужна. И это именно то, что я имею ввиду.
Сам по работе ровно так же делаю - меняется даже производитель МК и флеша в рамках формально одного продукта :)))

Это нормальная практика - хочешь не уменьшать прибыль - адаптируйся по поставщикам.

СОФТ то и функциональнасть та же самая. И поддержку и фиксы к софту под предыдущее железо в рамках гарантийного срока никто не отменял.
чем больше % общих исходников под все платы, тем ниже трудозатраты (=деньги) на поддержку.

isx

Satyr писал(а):

Что значит "имеющийся" ? имеющийся где и у кого ? Обычно поле имения - это все, что доступно на рынке. И это выбор МК подгоняется под ТЗ, а не наоборот.

Так и я о том же

.

Satyr писал(а):

А далее периодически смотрится по чем сейчас покупаем комплктуху, какие и почем есть аналоги на рынке и соотносится, сколько еще есть перспектива продать, разница в цене между МК и объем работы по переходу.

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

).

Satyr писал(а):

Это нормальная практика - хочешь не уменьшать прибыль - адаптируйся по поставщикам.

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

Satyr

isx писал(а):

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

В масштабе месяцев нет.
А если говорить полугодями, а то и кварталами - вполне себе семечки.
Стандартная практика, когда новое семейство у производителя по цена/жирность лучше предыдущего. Иначе чего ради все ?
Обновки у всех производителей не синхронно, так что период старое у одного - новое у другого может быть много меньше, чем период выброса новинок в рамках одного производителя.

Реклама

Pnjom-Penb

a5021 писал(а):

Так даже между разными камнями в одном семействе переносить код может оказаться геммором еще тем.

Хороший Вы выбрали пример для обоснования отказа от переносимости:

a5021 писал(а):

Хорошо это выглядит только на абстрактных примерах и только издалека. На деле я вижу три вайфай маршрутизатора DIR-300, в двух из которых установлены камни разных поколений одного производителя, а в одном и производитель другой. Отсюда возникает вопрос -- так ли нужна какая-то софтовая совместимость, если D-Link даже одну модель не стремается лепить на совсем разных процах?

Не знаю, как там именно в DIR-300, но обычно в этих железках 99% ПО составляет к.-л. линукс, и в DIR-300, скорее всего, та же история. А в самом этом линуксе 99% кода писаны на C/C++ и именно в целях переносимости.
© "Вот, как-то так..."

На мой взгляд, решение о том, делать код переносимым или писать "в лоб", зависит от размеров проекта - для небольших проектов стоимость усилий по написанию переносимого кода может оказаться сравнимой со стоимостью собственно разработки кода, а-то и превышающей его

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

КРАМ

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

Pnjom-Penb

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

Дело тут не в размере проекта, а в его типичности.

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

Satyr

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

Скажем, вот такую чтуку по 95$ продают

Поскольку во многом похоже на вещь, что сейчас мастерю, могу сказать, что то, что вы видете в кадре в сборе тянет на <20$ НЕ считая проектирования (тысячи $), пары версий прототипов (~500$ каждый) и подготовки производства (~1000$).

Если надо пару десятков изделий - что дешевле "20$" или 95$ ? -)))

Andrew Martin

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

Так вот мой вопрос про SPI в STM32F030F4P6.
От оного модуля требуется общаться с контроллером дисплея от нокии 3410. Используются только линии MOSI и SCK, ногу D/C контроллера дёргаю вручную.
Размер данных 8 бит, режим SPI - Transmit-only mode, MSB first.

Тема избитая, но тем не менее ни чтение форумов, ни статьи, ни изучение RM0360 ничего не дало. Должно работать, а не работает!

Код:

align 2
lcd_spi_init:
   push   {r0-r2,lr} 
   ldr   r0,[lcd_spi_cblock.start_delay]
    @@:
   subs   r0,1
   bne   @r   
   ldr   r0,[lcd_spi_cblock.rcc_base]
   virtual at r0
   .rcc   RCC_TypeDef
   end virtual
   ldr   r2,[.rcc.AHBENR]      ;enable GPIOA clock
   ldbit   r1,RCC_AHBENR_GPIOAEN
   orrs   r2,r1
   ldbit   r1,RCC_AHBENR_DMAEN      ;enable DMA clock
   orrs   r2,r1
   str   r2,[.rcc.AHBENR]
   ldr   r2,[.rcc.APB2ENR]      ;enable SPI clock
   ldbit   r1,RCC_APB2ENR_SPI1EN
   orrs   r2,r1
   str   r2,[.rcc.APB2ENR]
   
   ldr   r0,[lcd_spi_cblock.gpioa_base]
   virtual   at r0
   .gpioa   GPIO_TypeDef         ;GPIO structure
   end virtual
   
   ldr   r2,[.gpioa.OSPEEDR]      ;high speed
   ldr      r1,[lcd_spi_cblock.gmask_2]
   orrs     r2,r1
   str   r2,[.gpioa.OSPEEDR]
   
   ldr   r2,[.gpioa.MODER]      ;alternative function
   ldr      r1,[lcd_spi_cblock.gmask_3]
   bics   r2,r1
   ldr      r1,[lcd_spi_cblock.gmask_1]
   orrs     r2,r1
   str      r2,[.gpioa.MODER]
   
   ldr   r2,[.gpioa.AFRL]         ;select AF0 in GPIOA7, GPIOA5 
   ldr      r1,[lcd_spi_cblock.gmask_4]
   bics   r2,r1
   str   r2,[.gpioa.AFRL]
   
   
   ;SPI configuration
   ldr   r0,[lcd_spi_cblock.spi_base]
   virtual at r0
   .spi1   SPI_TypeDef
   end virtual
   
   ldr      r1,[lcd_spi_cblock.cr1_mask]
   strh   r1,[.spi1.CR1]
   ldr      r1,[lcd_spi_cblock.cr2_mask]
   strh   r1,[.spi1.CR2]
   
   movs   r1,SPI_CR1_SPE         ;enable SPI
   ldrh   r2,[.spi1.CR1]
   orrs   r2,r1
   strh   r2,[.spi1.CR1]
   
   pop   {r0-r2, pc}
   
   
align 2
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
    @@:
   ldrh   r2,[.spi1.SR]
   tst   r2,r3
   bne   @r
   
   movs   r3,SPI_SR_TXE
    @@:
   ldrh   r2,[.spi1.SR]
   tst   r2,r3
   beq   @r
   
   strb   r0,byte [.spi1.DR]
   pop   {r0-r3,pc}

align 4
lcd_spi_cblock:
.rcc_base   dw RCC_BASE
.gpioa_base   dw GPIOA_BASE

.gmask_1   dw GPIO_MODER_MODER7_1+GPIO_MODER_MODER5_1+GPIO_MODER_MODER6_0      ;alternative function on PA5, PA7 and output on PA6
.gmask_2   dw GPIO_OSPEEDR_OSPEEDR7+GPIO_OSPEEDR_OSPEEDR5+GPIO_OSPEEDR_OSPEEDR6
.gmask_3   dw GPIO_MODER_MODER7+GPIO_MODER_MODER6+GPIO_MODER_MODER5
.gmask_4   dw GPIO_AFRL_AFR7+GPIO_AFRL_AFR5

.spi_base   dw SPI1_BASE
.cr1_mask   dw SPI_CR1_MSTR+SPI_CR1_BR_0+SPI_CR1_BR_1+SPI_CR1_BR_2+SPI_CR1_SSM+SPI_CR1_SSI
.cr2_mask   dw SPI_CR2_DS_0+SPI_CR2_DS_1+SPI_CR2_DS_2   ;PCLK/256

.dma_base   dw DMA1_BASE
.dma1_ch3   dw DMA1_Channel3_BASE
.dma_dest   dw SPI1_BASE+SPI_TypeDef.DR
.dma_src   dw lcd_buffer
.dma_cnt   dw VBUF_SIZE
.dma_ccr   dw DMA_CCR_DIR+DMA_CCR_MINC

.start_delay   dw LCD_RESET_DELAY*LCD_SYS_FCLK/4
   

В софтварной реализации на тех же ногах всё работает. В хардварной не хочет никак.

Satyr

Инит, на жирном арме, на асме ? :shock:

Ладно, просто сделаю вид, что не видел :))

Andrew Martin

Satyr писал(а):

Инит, на жирном арме, на асме ? :shock:

Ладно, просто сделаю вид, что не видел :))

На жирном??? Не смешите :))

У Cortex-М0 набор инструкций скромнее, чем у AVR, соответственно пространства для оптимизации у сишных компиляторов немного. Да и асм не какой-нибудь - модификация FASM, рассчитанного на Большого Брата.

Вопрос собственно по SPI, который нужно правильно инициализировать. Задача вроде бы тривиальная, да и режим самый простой что может быть. Должно работать, а не работает.
Если можете, подскажите что не так с CR1 и CR2.
Хорошо бы увидеть чистый сишный код, без всяких SPL.

SPI что-то передаёт, на SCK есть какие-то импульсы. Но почему-то дисплей не реагирует

Уже и скорость сбавил до минимума, а толку нет.

dosikus

STM32F030F4
фрэйм 8 бит. Инит на низкой скорости( SD карта).

Код:

RCC->AHBENR |=RCC_AHBENR_GPIOAEN ;                                              
     GPIOA->MODER &=~
              
      GPIO_MODER_MODER4 |
      GPIO_MODER_MODER5 |
                GPIO_MODER_MODER6 |
                GPIO_MODER_MODER7 
                                   ;
      GPIOA->MODER|= 
             
              GPIO_MODER_MODER5_1|
              GPIO_MODER_MODER6_1|
              GPIO_MODER_MODER7_1 ;
                  
      GPIOA->MODER|=(GPIO_MODER_MODER4_0);                           
                  
      
      GPIOA->OSPEEDR|=
           
               GPIO_OSPEEDER_OSPEEDR4|
               GPIO_OSPEEDER_OSPEEDR5|
               GPIO_OSPEEDER_OSPEEDR6|
               GPIO_OSPEEDER_OSPEEDR7
                                     ;
                                   

   
      RCC->APB2ENR |=RCC_APB2ENR_SPI1EN;
   
                     
      SPI1->CR1 |= 
                   SPI_CR1_BR_0 |     // 
                   SPI_CR1_BR_1 | 
                   SPI_CR1_BR_2 | 
                   SPI_CR1_MSTR |
                   SPI_CR1_SSI    |             
                   SPI_CR1_SSM 
                   ;   
   SPI1->CR2  = 0x700;   //  8 bit
   SPI1->CR2 |= SPI_CR2_FRXTH;
   SPI1->CR1 |= SPI_CR1_SPE;   

Satyr писал(а):

Ладно, просто сделаю вид, что не видел :))

Тем кто кал пользует лучше не только глаза закрыть, толку 0...

Satyr

Andrew Martin писал(а):

У Cortex-М0 набор инструкций скромнее, чем у AVR, соответственно пространства для оптимизации у сишных компиляторов немного.

Чем набор инструкций ортогональней (у идеального сферического RISC в вакууме - ровно 90 градусов -))) ) - тем менее интеллектуальность компилятора влияет на производительность полученного кода (до этапа перестановки кода для оптимизации прохождения конвейера).
Последние сишные компилеры, во всяком случае ИАР 7.40 уже оптимизируют так, что редко что можно руками улучшить. И уже не чисто за счет кода, а больше корректировка схемы организации алгоритма.

Писать от и до на асме - это не признак профессионализма, а скорее наоборот - неспособность адекватно выбрать инструменты для решения задачи.

КРАМ

Satyr писал(а):

Писать от и до на асме - это не признак профессионализма, а скорее наоборот - неспособность адекватно выбрать инструменты для решения задачи.

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

Andrew Martin

Dosikus,
PA6 у вас отведён под MISO, мне же ничего принимать не нужно, т.к. дисплей нем как рыба. Поэтому эта нога у меня используется как обычный пин GPIO (программно переключающий шину D/C дисплея).

Код:

.gmask_1   dw GPIO_MODER_MODER7_1+GPIO_MODER_MODER5_1+GPIO_MODER_MODER6_0      ;alternative function on PA5, PA7 and output on PA6

PA4 у вас также настраивается на пушпульный выход, у меня этот пин пока вообще не задействован.
В остальном инициализация порта А такая же как и в вашем примере.

Записываемые значения в CR1 и CR2

Код:

.cr1_mask   dw SPI_CR1_MSTR+SPI_CR1_BR_0+SPI_CR1_BR_1+SPI_CR1_BR_2+SPI_CR1_SSM+SPI_CR1_SSI  ;PCLK/256, master
.cr2_mask   dw SPI_CR2_DS_0+SPI_CR2_DS_1+SPI_CR2_DS_2   ; = 0x700, 8 bit

соответствуют тем, что у вас в примере

Код:

SPI1->CR1 |= 
                   SPI_CR1_BR_0 |     // 
                   SPI_CR1_BR_1 | 
                   SPI_CR1_BR_2 | 
                   SPI_CR1_MSTR |
                   SPI_CR1_SSI    |             
                   SPI_CR1_SSM 
                   ;   
   SPI1->CR2  = 0x700;   //  8 bit

Единственный непонятный момент

Код:

SPI1->CR2 |= SPI_CR2_FRXTH

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

Бит SPE у меня также поднимается в последнюю очередь.

CPOL=0, CPHA=0 т.к. дисплей защёлкивает данные по возрастающему фронту.

Отправка байта на передачу

Код:

strb r0,byte [.spi1.DR]

в дизасме выглядит правильно (то, что доктор прописал - byte access)

Код:

strb r0,[r1,12]

где r0 - данные (только младший байт), r1 - адрес структуры SPI, 12 - смещение DR.

А не работает

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

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