Ассемблер работа с ADC.

[Скептик]

Пробую работать с ADC на ассемблере. Не получается. Программа виснет на 65-ой строчке.
Не пойму, где ошибка.

main_ADC.asm

[Реклама]

Реклама: ООО ТД Промэлектроника, ИНН: 6659197470, Тел: 8 (800) 1000-321

[Гар]

Не могу с телефона прочитать твой файл. Раскодируй, сделай попроще. В jpg например 

[Реклама]

20% скидка на весь каталог электронных компонентов в ТМ Электроникс!

Акция "Лето ближе - цены ниже", успей сделать выгодные покупки!

Плюс весь апрель действует скидка 10% по промокоду APREL24 + 15% кэшбэк и бесплатная доставка!

Перейти на страницу акции

Реклама: ООО ТМ ЭЛЕКТРОНИКС, ИНН: 7806548420, info@tmelectronics.ru, +7(812)4094849

[Скептик]

А так читается?

main_ADC.txt

[Реклама]

Особенности хранения литиевых аккумуляторов и батареек

Потеря емкости аккумулятора напрямую зависит от условий хранения и эксплуатации. При неправильном хранении даже самый лучший литиевый источник тока с превосходными характеристиками может не оправдать ожиданий. Технология, основанная на рекомендациях таких известных производителей литиевых источников тока, как компании FANSO и EVE Energy, поможет организовать правильный процесс хранения батареек и аккумуляторов. Подробнее>>

Реклама: АО КОМПЭЛ, ИНН: 7713005406, ОГРН: 1027700032161

[Скептик]

Прошу прощения, не понял пока почему, но заработало...

[Реклама]

Выбираем схему BMS для корректной работы литий-железофосфатных (LiFePO4) аккумуляторов

 Обязательным условием долгой и стабильной работы Li-FePO4-аккумуляторов, в том числе и производства EVE Energy, является применение специализированных BMS-микросхем. Литий-железофосфатные АКБ отличаются такими характеристиками, как высокая многократность циклов заряда-разряда, безопасность, возможность быстрой зарядки, устойчивость к буферному режиму работы и приемлемая стоимость. Но для этих АКБ, также как и для других, очень важен контроль процесса заряда и разряда, а специализированных микросхем для этого вида аккумуляторов не так много. Инженеры КОМПЭЛ подготовили список имеющихся микросхем и возможных решений от разных производителей. Подробнее>>

Реклама: АО КОМПЭЛ, ИНН: 7713005406, ОГРН: 1027700032161

[Гар]

Ну и слава богу...

[nml]

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

На АВРках это уже стало несущественно, перешел на Си и был удивлен - более менее приличные программы, ну не мигание светодиодиком, а этак на несколько десятков кб кода - на Си получились по сути по объему кода ну может процентов на 5-10 больше.  Но скорость разработки... Несравнима

А вот на СТМках писать на асме - ЗАЧЕМ??? Там производительность (ну, по сравнению даже с АВРками, например) просто бешеная. 

Разве что курсовая... 

[Огонёк]

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

Но скорость разработки... Несравнима

А куда спешить? Пусть всё будет красиво. Каждый байт. С точностью до бита - там и так, как задумал ты, а не неведомый автор библиотеки.

Изменено 20 октября, 2022 пользователем Огонёк

[Lexter]

2 часа назад, nml сказал:

Но скорость разработки... Несравнима

Вопрос спорный.

Весь интернет завален вопросами "Почему не срабатывает прерывание", "По DMA идут не те данные", "Как настроить фьюзы, чтобы...", "По SPI теряются байты" .... И тянутся такие обсуждения месяцами, и очень часто без результатов. Догадайтесь с трёх раз, на каком языке они пишут?

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

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

Изменено 20 октября, 2022 пользователем Lexter

[BARS_]

6 часов назад, Lexter сказал:

Весь интернет завален вопросами "Почему не срабатывает прерывание", "По DMA идут не те данные", "Как настроить фьюзы, чтобы...", "По SPI теряются байты" .... И тянутся такие обсуждения месяцами, и очень часто без результатов. Догадайтесь с трёх раз, на каком языке они пишут?

На языке "я не умею читать документацию и не умею думать, поэтому возьму кривые готовые библиотеки". И отвечают им в темах точно такие же знатоки, как они сами. Как правило, если внимательно читается документация, то проблем не возникает. Ну разве что в каких-то вот прям уникальных случаях.

 

16 часов назад, Скептик сказал:

Не пойму, где ошибка.

Основная ошибка в написании когда для ARM на ассемблере. Зачем? Весь потенциал АЦП полностью реализуется на Сях, нафига там ASM? Ладно бы вы ОС писали, там еще AMS полезен, но в простейшем опросе АЦП, который у STM делается полностью аппаратно (связка ADC+DMA в помощь. Причем можно еще и частоту дискретизации триггером таймера задать), он нафиг не уперся...

6 часов назад, Lexter сказал:

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

Ассемблер то сюда каким боком? ARM ядро предполагает написание объемных программ в тысячи строк кода, т.к. обладает приличной производительностью и даже спокойно крутит довольно неплохие ГИП. Вы предлагаете писать это все на ASM? Смысл? Максимум, что на нем можно написать - ядро ОС, не более.

[nml]

8 часов назад, Lexter сказал:

Догадайтесь с трёх раз, на каком языке они пишут?

На Си, естественно. Потому что на Си пишут 99,9% разработчиков. И совсем уж непонятна связь между знанием асма и железа. Как работает железо, знать надо в любом случае.

[colorad]

17 минут назад, nml сказал:

связь между знанием асма и железа

асм это почти тоже,  что и цифровая логика ,   те же регистры и биты . 

[BARS_]

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

асм это почти тоже,  что и цифровая логика

Ну вот вообще ничего общего...

[nml]

2 часа назад, colorad сказал:

 те же регистры и биты . 

Если вы имеете в виду регистры и биты периферийных устройств, то и в Си они те же самые. Если РОН процессора - то зачем мне напрягать мозги, что куда и как распределить - когда это делает компилятор, при этом гарантировано безошибочно?

[colorad]

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

ничего общего...

2 часа назад, nml сказал:

РОН процессора

Возможно это мои дилетантские  ассоциации ,  но 32 РОН  у AVR,  когда я начал изучать МК , мне удобней было представлять как цифровые микросхемы .   

 И задавать им работу как счетчикам , дешифраторам . 

3 часа назад, nml сказал:

Если РОН процессора - то зачем мне напрягать мозги

РОН у  AVR   , как кеш позволяет увеличить скорость . Иногда актуально .

 

[AVI-crak Home]

В 20.10.2022 в 20:19, Скептик сказал:

Прошу прощения, не понял пока почему, но заработало...

Ваш код на Си, я тоже в больших сомнениях.

    RCC->AHB1ENR = RCC_AHB1ENR_GPIOAEN | RCC_AHB1ENR_CCMDATARAMEN;
    RCC->APB2ENR = RCC_APB2ENR_ADC1EN;
    GPIOA->MODER = _VAL2FLD(GPIO_MODER_MODER7, 3); 
    ADC1->CR2 = ADC_CR2_EOCS;
    ADC1->SQR3 = _VAL2FLD(ADC_SQR3_SQ1, 7);
    ADC1->CR2 = ADC_CR2_EOCS | ADC_CR2_ADON;
    volatile register uint32_t ADC_dat asm ("r2");
    do{
        ADC1->CR2 = ADC_CR2_EOCS | ADC_CR2_ADON | ADC_CR2_SWSTART;
        while (!(ADC1->SR & ADC_SR_EOC));
        ADC_dat = ADC1->DR;
    }while(1);

Во первых вы наглухо отключаете SWD интерфейс отладки в первых строчках, как и большую часть всего остального.

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

В-третьих, на Си код получился компактнее и проще.

 

[Геннадий]

С последним утверждением позвольте не согласиться. Для программиста ДА, компактнее и проще к пониманию. Для микроконтроллера - вопрос.

[jam_yps]

5 минут назад, Геннадий сказал:

Для программиста ДА, компактнее и проще к пониманию

При нынешних MCU и типичных задачах это весьма важно. Особенно когда этих строчек десятки тысяч (для более-менее средних и больших проектов). Объем результирующего .asm может быть на 30% больше, по быстродействию - от 10% до нескольких раз медленнее, но - "время запуска" проекта сильно-сильно меньше и можно блоками писать (и отлаживать).

9 минут назад, Геннадий сказал:

Для микроконтроллера - вопрос

Ему пофиг. Он проглотит, лишь бы рабочей код был.

[Геннадий]

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

[Скептик]

Ну вы и расписались, господа.
А дело было так.
Я изучаю STM32 на примере F407VGT и одновременно практикуюсь на типовых примерах в среде STM32CUBEIDE. Один из типовых примеров работы с ADC не получился. Узнав, что в среде редко, но встречаются ошибки, решил проверить на ассемблере. Код выложил без надстроек для компактности, там, где ошибка. Сделал элементарную ошибку по невнимательности, глаза замылились и обнаружил её лишь на следующий день.

Однако следующую проблему решить не смог, поэтому снова прошу помощи у искушённых корифеев.
В настройках ADC есть параметр преобразования - односигнальное/непрерывное, управляемое флагом ADC_CONT. В многочисленных примерах приведен запуск ADC без прерывания и DMA в непрерывном режиме. У меня не получилось. CUBE-код осуществляет только одно преобразование, asm-код 2 преобразования. Потом последовательность заканчивается.
Одна из ссылок на пример: http://mypractic.ru/urok-27-rabota-s-acp-cherez-registry-cmsis-osnovnye-rezhimy-preobrazovaniya.html
подпункт "Один канал, непрерывное преобразование."
Руководствовался RM0090.

Если поможете, буду рад.

[Геннадий]

Почитайте тут. https://narodstream.ru/programmirovanie-mk-stm32/

[Скептик]

37 минут назад, Геннадий сказал:

Почитайте тут. https://narodstream.ru/programmirovanie-mk-stm32/

Прочитал. Как я понял, режим Continuous Conversion Mode исользуется только совместно с DMA. Отдельно невозможно?

[BARS_]

В 22.10.2022 в 14:08, Скептик сказал:

практикуюсь на типовых примерах в среде STM32CUBEIDE.

Это главная ошибка. О калокубе надо сразу забыть и никогда не вспоминать. Единственная полезная функция в нем - просмотр периферии на выводах и расчет коэффициентов для PLL. Все остальное крайне рекомендую делать исключительно с применением CMSIS.

 

В 22.10.2022 в 17:03, Скептик сказал:

Continuous Conversion Mode исользуется только совместно с DMA.

К DMA он никакого отношения не имеет. Хочешь используй DMA, хочешь - просто читай данные из регистра данных. Так же и прерывания. RM же есть, там все это описано.

 

В 22.10.2022 в 14:08, Скептик сказал:

Потом последовательность заканчивается.

А в каком состоянии вот этот бит (это можно прямо под отладчиком посмотреть в real time)?

Если он в 1, то в случае, когда до начала нового преобразования не был прочитан регистр DR, АЦП выпадет вот в эту ошибку:

И не будет продолжать работу до тех пор, пока бит OVR не сброшен.

 

В 21.10.2022 в 22:01, Геннадий сказал:

Для микроконтроллера - вопрос.

Никаких вопросов. Современные компиляторы довольно неплохо научились работать с кодом и Си при грамотном написании работает не сильно медленнее ASM. Тем более никто не мешает в критических ко времени выполнения участках кода использовать ASM вставки. Си прекрасно с ними дружит. В тех же RTOS это активно используется.

[Скептик]

3 часа назад, BARS_ сказал:

Единственная полезная функция в нем - просмотр периферии на выводах и расчет коэффициентов для PLL.

Отладчик и прошивальщик там очень соблазнительные.

[BARS_]

3 минуты назад, Скептик сказал:

очень соблазнительные.

Чем? Прошивальщик там стандартный, это вообще внешний плагин и работает он с любой IDE. Отладчик тоже стандартный, такой же как в Keil и VisualStudio. Только Keil и VisualStudio работают шустро, а куб работает на JAVA и крайне неспешно. Плюс IDE это же у них выкидыш глючного Эклипса?

[Скептик]

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

А в каком состоянии вот этот бит (это можно прямо под отладчиком посмотреть в real time)?

Если он в 1, то в случае, когда до начала нового преобразования не был прочитан регистр DR, АЦП выпадет вот в эту ошибку:

И не будет продолжать работу до тех пор, пока бит OVR не сброшен.

Проверил в отладчике. Он сразу устанавливается вместе с флагами STRT и EOC. После чтения из ADC_DR флаг EOC как положено, сбрасывается. Преобразование останавливается. Запуск ADC писал на C , устанавливая флаги командами типа *adc_cr2 |= 1<<30      /* SWSTART=1, (при EOCS,CONT,ADON=1) */, что бы не пропустить следующего преобразования.