Изучаем STM32 Cortex M3 - Страница 539

dgrishin · 13.08.2018, 13:44

Сообщение от Passer_by

имеется серьезный источник ошибок,
связанный с неатомарностью битовых операций с регистрами ядра и периферии.

ИМХО это не так. Если у вас есть лёгкая паранойя по этому поводу, то можно модификацию (побитно) регистров периферии делать через bit banding (сам так никогда не делал т. к. меня конструкция а-ля

Сообщение от Passer_by

RCC-›CR |= RCC_CR_PLLON;

всем устраивает.
Периферия (если верить programming manual) попадает в bit band region

Passer_by · 13.08.2018, 15:08

Сообщение от scorpi_0n

В STM32...

Текст полностью холливарный - игнорируется...

Passer_by · 13.08.2018, 15:15

Сообщение от dgrishin

ИМХО это не так. Если у вас есть лёгкая паранойя по этому поводу, то можно модификацию (побитно) регистров периферии делать через bit banding (сам так никогда не делал т. к. меня конструкция а-ля

всем устраивает.
Периферия (если верить programming manual) попадает в bit band region

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

scorpi_0n · 13.08.2018, 15:29

Сообщение от Passer_by

Я говорил исключительно об атомарности битовых операций.

Ну что же, подведём итоги вашего разговора.

1. Си, например, вообще не знает о битах. У него даже понятия такого нет. И АRМ, в первую очередь, заточен под Си.
2. Не путайте регистры ядра и периферии. Первые от АRМ, вторые от STM. Поэтому и поведение их при операциях с битами может быть разным. Загляните в RM. Одни биты сбрасываются/устанавливаются нулём, другие - единицами, третьи - чтением регистра, четвёртые - чтением совершенно другого регистра, пятые - сбрасываются/устанавливаются хардварно и т.д. Везде ли нужна атомарность в вашем понимании?
3. Над битовыми операциями, в основном, рыдают адепты ногодрыга и унылых восмибитных решений, не понимая, что все эти решения вынужденные из-за ограниченности восьмибитных МК и никому уже сегодня не интересны. Тем более производителю МК.
4. Проблема атомарности реальна, но не настолько как вы её разрисовали в данном случае. Это больше от недопонимания или поверхностных знаний архитектуры. Но в наличии она всегда и везде, в любом МК. Просто надо об этом не забывать.

scorpi_0n · 13.08.2018, 15:37

Сообщение от Passer_by

Я бы поступил несколько иначе.
Обложил бы обращение к битовым полям макросами запрета прерываний до обращения к битам и разрешения прерываний - после.
Но не в прерываниях с наивысшим приоритетом, как в моем примере для CortexM0.

Самый глупый вариант из всех возможных. Хотя, порой, и единственный. Это прокатывало от безнадёги на старых PIC и AVR. На CortexM0 я не помню таких случаев, чтобы этим приходилось пользоваться. Всегда находились более изящные решения.

Сообщение от Passer_by

А по поводу легкой паранойи - если бы я не попался на этом - не говорил бы...

Это не повод орать "караул" и "всё пропало", а тем более выдумывать какие-то там сказки про "дыры". Попались? Сами и виноваты!

Passer_by · 13.08.2018, 15:47

Сообщение от scorpi_0n

Самый глупый вариант из всех возможных. Хотя, порой, и единственный. Это прокатывало от безнадёги на старых PIC и AVR.

На старых PIC-ах такого нет. Там обращение к битам - атомарно.

Сообщение от scorpi_0n

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

Примеры есть? Или это секрет?

Сообщение от scorpi_0n

Это не повод орать "караул" и "всё пропало", а тем более выдумывать какие-то там сказки про "дыры". Попались? Сами и виноваты!

Это как раз повод. На других CPU работает, а на Cortex-e - нет. А про дыры - это не сказки, а суровая действительность.

Passer_by · 13.08.2018, 16:30

Сообщение от scorpi_0n

Ну что же, подведём итоги вашего разговора.
1. Си, например, вообще не знает о битах. У него даже понятия такого нет.

Теперь уже моя очередь удивляться...
Объявление:

Код:

typedef union
{
	UINT32 ErrorReg;
	UINT8 ErrorBytes[4];
	struct
	{
		UINT32 UV3n3:1;
		UINT32 OV3n3:1;		
		UINT32 UV5:1;
		UINT32 OV5:1;
		UINT32 UV12:1;
		UINT32 OV12:1;
		UINT32 SlvUV3n3:1;
		UINT32 SlvOV3n3:1;		
		UINT32 SlvUV5:1;
		UINT32 SlvOV5:1;
		UINT32 SlvUV12:1;
		UINT32 SlvOV12:1;
		UINT32 RdUV3n3:1;		
		UINT32 RdOV3n3:1;		
		UINT32 RdUV5:1;
		UINT32 RdOV5:1;
		UINT32 RdUV12:1;
		UINT32 RdOV12:1;		
		UINT32 QErr:1;
		UINT32 SlvQErr:1;
		UINT32 RdQErr:1;
		UINT32 UsartPE: 1;
		UINT32 UsartFE: 1;
		UINT32 UsartOVE: 1;
		UINT32 UsartNE: 1;
		UINT32 UsartTOE: 1;
		UINT32 UsartPRSE: 1;
	}ErrorBits;
} ERRORS;
ERRORS Errors;

Обращение к биту:

Код:

Errors.ErrorBits.UsartPE=0;

Обращение к байту:

Код:

Errors.ErrorBytes[0]=0x05;

Обращение к слову целиком

Код:

Errors.ErrorReg=0;

Странно, компилятор не знает, что это не С...
Собирает все без ошибок.

Сообщение от scorpi_0n

2. Не путайте регистры ядра и периферии. Первые от АRМ, вторые от STM. Поэтому и поведение их при операциях с битами может быть разным. Загляните в RM. Одни биты сбрасываются/устанавливаются нулём, другие - единицами, третьи - чтением регистра, четвёртые - чтением совершенно другого регистра, пятые - сбрасываются/устанавливаются хардварно и т.д. Везде ли нужна атомарность в вашем понимании?

Понятно, пуговицы отдельно, рукава отдельно.
Что из этого выходит - нам прекрасно объяснил великий комик.
Атомарность должен обеспечить разработчик микроконтроллера.
А нужна она мне, или только желательна - второй вопрос.
А RM на STM32F0 - отдельный разговор.

Сообщение от scorpi_0n

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

Основная задача микроконтроллера - как раз "ногодрыг" (ШИМодрыг, АЦПдрыг, SPIдрыг и прочий дрыг) в жестком реалтайме. А уж чего там внутри 8, 16, или 32 бита не имеет никакого значения.

Сообщение от scorpi_0n

4. Проблема атомарности реальна, но не настолько как вы её разрисовали в данном случае. Это больше от недопонимания или поверхностных знаний архитектуры. Но в наличии она всегда и везде, в любом МК. Просто надо об этом не забывать.

В этом МК эта проблема значительно актуальнее, чем в других, поскольку приводит к ошибкам, которые очень трудно отлавливать.

NewWriter · 13.08.2018, 16:51

Если хочется атомарности битовых операций, есть bit-banding. Он работает и для области SRAM. Ну, там, где бит-бандинг вообще есть, конечно

)) А то вот M7 битбандинга уже не имеет.
Битовые операции же даже на ассемблере не шибко то хорошо отражены. Если сбросить бит можно одной инструкцией bic, то для установки бита аналогичной инструкции нету. Есть другие, но они не аналогичны.

Да и вообще, проблема атомарности битовых операций актуальна лишь там, где один и тот же регистр (слово, байт) вы будете изменять как в общей проге, так и в обработчике прерывания.
Кстати, и тут вы можете защититься - оградить неатомарную операцию командами-функциями disable_irq() / enable_irq(), представляющими сишные обертки ассемблерных инструкций.
Как бы и фсё. возрадуйтесь и не спорьте

NewWriter · 13.08.2018, 16:58

Passer_by, вообще-т, я чет не врубаюсь - вам не нравится ARM-ядро? Ну и не используйте, делов то. Фигня вопрос

) И хотя линейку МК с ядром ARM нынче имеют практически все производители микроконтроллеров, можно найти МК и с проприетарным (собственной разработки) АЛУ. Пожалста - кушайте с маслом.

NewWriter · 13.08.2018, 17:12

Сообщение от Passer_by

Основная беда всех ARM-ов - отсутствие работы с битами на уровне команд процессора,

Ошибаетесь. Этих команд - полтора десятка штук. Хотите взглянуть?
Вот половина из них:

и еще несколько штук разбросаны по другим группам. В том числе есть интересные инструкции реверса порядка бит.
Да, нет полной аналогии набору PIC16/18, но это не слишком мешает. По крайней мере, не всегда. А если учесть, что в ARM вообще другая архитектура рабочих регистров ядра, то никакой схожести с PIC16.

Сообщение от Passer_by

что на захудалом PIC-е выполняется за одну команду, в ARM-е требует не менее 3-х.

А во-первых, сначала вспомните, сколько периодов тактовой частоты занимает одна команда в PIC-е? Ааа, вот то-то же! 4! Это раз.
Во-вторых, команды Thumb-2, в отличие от PIC16/18, имеют очень навороченный второй операнд инструкции, который может представлять собой тоже инструкцию, исполняемую параллельно. Благодаря этому за один такт может исполняться даже две инструкции, а не 0,25, как в PIC. Так, например инструкция сохранения может иметь в качестве второго операнда команду инкремента регистра-указателя, и благодаря этому заполнение какого-то массива выполняется с быстродействием "одна инструкция на один элемент массива". Попробуйте проделать это на PIC-е! А вот потом и будете выражать "неудовольствия"

Ну а схема быстрого переноса в ядре ARM? Матрица 32х32 линии. Знаете, что это такое? А вот то-то же! быстрый сдвиг на произвольное число бит по ширине слова.
Вы в PIC-е как сможете выполнить сдвиг влево на 5 позиций? Ну да, 5 раз примените инструкцию сдвига влево - rls. А как в ARM? Да один раз lsl r0, r1, #5. Причем, есть разновидности сдвига - арифметический, логический, по кольцу.
Найдите это в PIC16?