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

[a5021]

[uquote="Myp3ik",url="/forum/viewtopic.php?p=3392107#p3392107"]CMSIS от ARM откройте.[/uquote]
А вы куда его обычно портируете, я запамятовал?

[uquote="VladislavS",url="/forum/viewtopic.php?p=3392127#p3392127"]Уууу, как всё запущено. Кто же позволит менять stdio.h, если язык должен иметь совместимость.[/uquote]
Запущено. Осталось только узнать у кого. А пока потрудитесь объяснить, как тот же getс() и putс(), имея возвращаемым типом все тот же int, не испытывают никаких проблем с портабельностью.

[VladislavS]

Ага, здесь играем (портируем), здесь не играем (не портируем), здесь рыбу заворачивали
Причём тут доверяю, не доверяю? stdint.h был введён в сандарт C99 для решения конкретной проблемы языка, которая эмбэддеров касается напрямую. В своё время это был глоток чистого воздуха для разработчиков.

[a5021]

[uquote="VladislavS",url="/forum/viewtopic.php?p=3392146#p3392146"]Ага, здесь играем (портируем), здесь не играем (не портируем), здесь рыбу заворачивали [/uquote]
Вы, как и ваш визави, не ответили на неудобные вопросы, заменив ответ кривляниями и резким уводом темы. Я все понял.

[VladislavS]

Вам надергать примеров проблем портирования int? Бан в гугле?

[a5021]

Вы будете кривляться, а я подтверждения вашим словам искать? Офигеть идейка!

[VladislavS]

Считаю выше своего достоинства доказывать аксиомы.

PS:Попробуйте написать proposals, чтобы удалили stdint.h из языка. А то программисты не догадываются что он им не нужен

[a5021]

[uquote="VladislavS",url="/forum/viewtopic.php?p=3392169#p3392169"]Считаю выше своего достоинства доказывать аксиомы.[/uquote]
Из этого утверждения вроде бы выходит, что с достоинством что-то не то. У вас русский не родной?

Попробуйте написать proposals, чтобы удалили stdint.h из языка. А то программисты не догадываются что он им не нужен

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

[VladislavS]

Не, ну правда, зачем он нужен? С getc() то проблем нет.

[a5021]

Ответ вы знаете. Другого у меня для вас нет.

Теперь немного о сказках насчет крайне затратного приведения типов. Есть функция:

Код: Выделить всё

int8_t user_i2c_read(uint8_t dev_id, uint8_t reg_addr, uint8_t *reg_data, uint16_t len)

Число и тип параметров не я придумал, а небезызвестная Bosch Sensortec. Этот пример я здесь привожу только потому, что именно сегодня мне взбрело в голову поковырять BME280, а в коде от BOSH оно и всплыло. Смотрим на функцию и видим параметр len, который объявлен, как беззнаковое 16-битное целое. Сначала мне показалось (и небезосновательно), что 65535 значений это сильно "дофига" для чтения регистров BME280, которых всего 45 штук и разрядность у них -- ровно один байт у каждого. Пошерстил исходники -- так и есть -- все передаваемые значения -- исключительно 8-битные константы. Уже непонятно, кто там в этой BOSCH такое пишет, но да не об этом сейчас.

Попробовал менять тип последнего параметра на так любимый здесь многими uint8_t и столь же нелюбимый int. Вот какие варианты кода функции в итоге сварил компилятор (µVision V5.24.2.0, C Compiler: Armcc.exe V5.06 update 5 build 528) в области использования переменной len:

Код: Выделить всё

=== [ uint16_t ] ===========

   151:                 while (len > 0) { 
0x00000310 E035      B             0x0000037E
   152:                         if (--len == 0) { 
0x00000312 1E58      SUBS          r0,r3,#1
0x00000314 B280      UXTH          r0,r0
0x00000316 1E03      SUBS          r3,r0,#0
0x00000318 D103      BNE           0x00000322

=== [ uint8_t ] ============

   151:                 while (len > 0) { 
0x00000310 E035      B             0x0000037E
   152:                         if (--len == 0) { 
0x00000312 1E58      SUBS          r0,r3,#1
0x00000314 B2C0      UXTB          r0,r0
0x00000316 1E03      SUBS          r3,r0,#0
0x00000318 D103      BNE           0x00000322

=== [ int ] ================

   151:                 while (len > 0) { 
0x00000310 E034      B             0x0000037C
   152:                         if (--len == 0) { 
0x00000312 1E58      SUBS          r0,r3,#1
0x00000314 1E03      SUBS          r3,r0,#0
0x00000316 D103      BNE           0x00000320

Код работает во всех случаях, но есть нюансы. В листингах выше можно воочию наблюдать, что россказни будто тип переменной обязательно должен соответствовать разрядности использующихся данных, оказываются на поверку полной туфтой. Компилятор добавляет разрядность до наиболее комфортной процессору, т.е. до 32-х бит. uint8_t он расширяет командой UXTB, а uint16_t командой UXTH именно до 32-х бит. Зато 32-битный int используется без дополнительных преобразований. На снайпетах выше приводятся все случаи использования переменной len внутри функции и какие-либо "скрытые" или "неучтенные" причины приведения переменной к 32-м битам отсутствуют. Вот и сказочкам конец.

PS. Нашел еще один маленький перл в бошевской библиотеке. Кто-нибудь может перевести?:

Код: Выделить всё

temp_len = ((len * 2) - 1);

Мне по собственному скудомыслию кажется, что писавший сие и в школу-то никогда не ходил. Только этим я могу объяснить вложенные скобки. Внешние так и вовсе не могу объяснить. Помогите!

[prinv]

Я не поленился и заглянул в софт, который у меня на компе установлен и вот что получилось:
Atmel Studio 7 и Keil 5.23 (библиотеки HAL и CMSIS) используют типы из stdint.h
Code Composer Studio 8 от TI - использует стандартные типы int, char и т.д.

[Myp3ik]

prinv, как Вы считаете, удобнее работать с int, short, char или int32_t, int16_t, int8_t ? Понятно, что работать будет и так, и так, причем одинаково. Но ведь программы пишутся в первую очередь для человека, а потом уже для железа.

[prinv]

Я использую типы данных из stdint.h - как-то сразу и легко перешёл на них и не жалею.

[a5021]

[uquote="Myp3ik",url="/forum/viewtopic.php?p=3392826#p3392826"]prinv, как Вы считаете, удобнее работать с int, short, char или int32_t, int16_t, int8_t ? Понятно, что работать будет и так, и так, причем одинаково. Но ведь программы пишутся в первую очередь для человека, а потом уже для железа.[/uquote]
На любительском уровне вопрос не стоит обсуждения. Запись синонимична, в чем не трудно убедиться, глянув внутрь stdint.h (ARMCC):

Код: Выделить всё

    /* exact-width signed integer types */
typedef   signed          char int8_t;
typedef   signed short     int int16_t;
typedef   signed           int int32_t;

    /* exact-width unsigned integer types */
typedef unsigned          char uint8_t;
typedef unsigned short     int uint16_t;
typedef unsigned           int uint32_t;

[prinv]

Что бы себе голову не загружать в какой архитектуре int сколько бит - я перешёл на int32_t, int16_t, int8_t.
Потому что, например, в WinAVR int определён так

Код: Выделить всё

typedef int int16_t;

[a5021]

[uquote="prinv",url="/forum/viewtopic.php?p=3392859#p3392859"]Что бы себе голову не загружать в какой архитектуре int сколько бит[/uquote]
Нечем там голову загружать. При неспособности запомнить, какое количество байт занимают три разновидности целого, впору в управдомы переквалифицироваться.

[prinv]

А зачем? Только для того, что бы писать int и char, имея потенциальный гемор при переносе своих библиотек из одной архитектуры в другую?

[arkhnchul]

[uquote="a5021",url="/forum/viewtopic.php?p=3392265#p3392265"]Мне по собственному скудомыслию кажется, что писавший сие и в школу-то никогда не ходил. Только этим я могу объяснить вложенные скобки. Внешние так и вовсе не могу объяснить. Помогите! [/uquote]
это так называемая "культура написания кода", вещь среди эмбеддеров редко встречающаяся. Конкретно тут - здравый подход "explicit > implicit", сиречь явное указание действия (здесь - последовательности вычислений) вместо неявного (которым займется компилятор сам по себе).

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

и какое количество байт занимает каждая из них - не на конкретной железке с конкретным компилятором, а вообще?)

[a5021]

имея потенциальный гемор при переносе своих библиотек из одной архитектуры в другую?

А вы, простите, сколько и каких своих библиотек из одной архитектуры в другую перенесли? Я почему спрашиваю -- в теме я вроде уже не первый год, а никуда ничего не переносил. Задачи разные, решения разные, никаких общих библиотек не получается. Проблема высосана из пальца.

Как я уже упоминал, вчера взялся смотреть бошевскую библиотеку для BME280. Там сходу обнаружился просто тихий ужас -- в процессе произведения одного измерения совершается вызов нескольких десятков функций. Все это для того, чтобы записать в датчик пять байт и прочитать оттуда шесть. Здесь я говорю не для красного словца, а называю точные цифры. Изумительная функция null_ptr_check() вызывается из разных мест семнадцать (!) раз. Проверяет она значения четырех одних и тех же указателей, которые в это время не могут быть изменены ни намеренно, ни случайно. Там в библиотеке даже кода нет, который бы мог изменить их значения. Програмистская шизофрения в чистом виде.

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

это так называемая "культура написания кода"

Бред это собачий. Скобками устанавливаются приоритеты арифметических действий, которые повторяют правила начальной школы. Следующим этапом в этом же направлении будет цитирование учебника арифметики для второго класса в комментариях. Культура, фигли. Не попрешь. Наружные, кстати, скобки имеют объяснение с позиций "культуры написания кода" ?

не на конкретной железке с конкретным компилятором, а вообще?)

Вопрос в такой постановке не имеет смысла. Никто не пишет код "вообще", не применительно ни к какой платформе.

[prinv]

[uquote="a5021",url="/forum/viewtopic.php?p=3392898#p3392898"]А вы, простите, сколько и каких своих библиотек из одной архитектуры в другую перенесли? Я почему спрашиваю -- в теме я вроде уже не первый год, а никуда ничего не переносил. Задачи разные, решения разные, никаких общих библиотек не получается. Проблема высосана из пальца.[/uquote]
Ну Бога ради, никто не запрещает вам так считать. Я считаю, что мне лично удобнее и понятнее использовать типы данных из stdint.h

[a5021]

Так и я так считаю. Спора здесь нет. Я просто был против мнения, что stdint.h -- наше все и по другому быть не может.