Нужно ли гнаться за разрядностью МК?

[HHIMERA]

Дык... я ж без фанатизма... 8L-ки в целом неплохи...
Прикалывает...
Нет поддержки 64-бит...
Только один канал ДМА... который поддерживает полную адресацию...
Покоцанные предделители таймеров...
Большие индейцы... но в принципе... терпимо...

[kalobyte]

Другое дело, что платы с дорожками 0.3 мм и зазорами 0.2 мм утюжить не очень весело.

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

а теперь пользуясь случаемпередаю привет хотел спросить у гур 32 бит, хотя я это уже спрашивал в тематическом разделе, но никто не ответил

если у меня переменная 8 бит, то стоит мне использовать чар или же инт и инт там по умолчанию 32 или 16 бит? или надо указывать шорт?
или можно тупо везде писать инт и типа контроллер все равно же ворочает 32 битами?

сколько читал всяких уроков, а никто не уделил этому внимание

STM32F030F4
стоит по 7 баксов за 10 штук
там 4к озу и 16к пзу
при такой цене проще пучок взять и расковырять

[Леонид Иванович]

Длина int соответствует разрядности процессора, т.е. 32 бита. Но лучше всего подключить stdint.h и пользоваться определенными там типами int8_t, uint8_t, int16_t, uint16_t, int32_t, uint32_t и так далее. Тогда никакой путаницы с длиной и знаковостью переменных не будет. На этот счет даже есть рекомендация MISRA - использовать такие типы вместо базовых типов char, int, short, long и т.д. Подсветку синтаксиса для новых типов тоже обычно сделать несложно, для IAR, например, сделал список типов в текстовом файле CustomKeywords.txt и подключил его через Options->Editor->Setup Files->Use Custom Keyword File.

Ну а плата для корпусов с шагом 0.5 мм утюжится. Придется, возможно, немного ретушировать, иголкой процарапать кое-где зазоры после утюжки, но в общем - нормально. Главное, не перегреть тонер, иначе дорожки расширяются и зазоры становятся еще меньше. Вот как раз собираюсь утюжить плату на основе STM32F100C8T6B:

[menzoda]

1. Использование переменных меньше натурального размера слова для данного ядра: экономия памяти при уменьшении производительности.
2. Использование переменных больше натурального размера слова для данного ядра: ощутимое уменьшение производительности.
3. Использование переменных натурального размера: максимальная производительность при увеличенном расходе памяти (в случае, если нужно хранить небольшие значения).

Вывод: в общем случае для больших массивов данных используй минимально возможный размер переменной (в том случае, если имеются ограничения в размере RAM, а на сегодняшний день они пока еще имеются), во всех остальных случаях используй натуральный размер переменных.

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

[kalobyte]

Временные переменные, участвующие в рассчете контрольной суммы - натурального размера.

а обычные счетчики в циклах? мне больше пары байт считать пока ничего не приходилось
их делать 32?

1. Использование переменных меньше натурального размера слова для данного ядра: экономия памяти при уменьшении производительности.

ну вот, я и думал, что есть какая-то особенность

(в том случае, если имеются ограничения в размере RAM, а на сегодняшний день они пока еще имеются),

ну вот 4к рам это много или мало при 32 битной архитектуре? я просто не ощущаю это на интуитивном уровне
для 8 бит понятно, а тут непонятно

собираюсь утюжить плату на основе STM32F100C8T6B:

жуть просто
у меня она распаяна на заводской плате и такие дорожки даже фоторезистом трудно сделать

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

так ее и так нет
инт по умолчанию х86 компилятора это 4 байта
короткий -2, а длинный 8 байт
надо с минусом, то дописываеш signed
а эти новые типы какие-то кривые или это только мне так непривычно?

[КРАМ]

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

так ее и так нет
инт по умолчанию х86 компилятора это 4 байта
короткий -2, а длинный 8 байт
надо с минусом, то дописываеш signed
а эти новые типы какие-то кривые или это только мне так непривычно?

В чем там кривость?
По умолчанию они ЗНАКОВЫЕ. То есть писать signed не требуется.
А вот беззнаковые нужно указать как unsigned - uint

[kalobyte]

А вот беззнаковые нужно указать как unsigned - uint

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

[menzoda]

а обычные счетчики в циклах? мне больше пары байт считать пока ничего не приходилось, их делать 32?

Да, это ведь те же временные переменные.

ну вот 4к рам это много или мало при 32 битной архитектуре? я просто не ощущаю это на интуитивном уровне для 8 бит понятно, а тут непонятно

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

так ее и так нет
инт по умолчанию х86 компилятора это 4 байта
короткий -2, а длинный 8 байт
надо с минусом, то дописываеш signed
а эти новые типы какие-то кривые или это только мне так непривычно?

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

Например, в МК с ядром C28 от Texas Instruments:
char = short = int = 16 бит
long = 32 бита

В PIC16F876:
char = 8 бит
short = int =16 бит
long = 32

В ARMv4 и ARMv7-M:
char = 8 бит
short = 16 бит
int = 32 бита
long = 32 бита

Как видишь, везде свои тараканы, и если бы я использовал простые int и short вместо int32_t и int16_t, то замучался бы переносить код. Даже учитывая, что переносить код приходится довольно редко, использование типов с явным указанием размеров улучшает самодокументацию кода. Сразу ясно какой размер у переменной.

[kalobyte]

вот тут и возникает вопрос: зачем весь этот гимор с разными типами?
если уж придумали тип, то и делайте везде одинаковую длину
а то придумают одно, потом начинают костыли делать

[menzoda]

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

Например, битовый сдвиг влево знакового числа приводит к неопределенному поведению, а сдвиг вправо определяется реализацией. Сдвиг на большее количество бит чем размер переменной тоже приводит к неопределенному поведению. Переполнение знаковых целых неопределено или зависит от реализации, не помню уже. Максимальной размер непрерывно адресуемого участка памяти не должен превышать размерность особого типа size_t, который в общем случае не равен int. Размер указателя не обязательно должен совпадать с размером int (естественным размером), а равен особому типу ptr_t. При вычитании указателей получается значение типа ptrdiff_t. Стоит ли говорить, что оно не только как все другие может отличаться от int, но так же может не совпадать с ptr_t. Представление отрицательных чисел не определено, оно может быть как дополнением до единицы, так и до двойки, или вообще чем-нибудь экзотическим. Поэтому простое приведение положительного значения знакового типа к беззнаковому может привести к тому, что в беззнаковом будет что угодно, только не это положительное число. Я мог ошибиться где именно неопределенное поведение, а где оно зависит от реализации. Если что - поправьте.

Это все только верхушка айсберга. Там весь стандарт пестрит undefined behaviour и implementation defined. Это все плата за универсальность и простоту языка. Если подходить формально, то на Си в принципе невозможно написать переносимую программу. Хорошо, что современные архитектуры и компиляторы пришли к некому консенсусу и на большую часть темных мест можно закрыть глаза.

[HHIMERA]

"Спят усталые троллюшки, нубы спят!"(С)
Что-то такая тема... и подзатихла... нехорошо!!! Нужно срочно внести оживляш...
Кто там говорил... что 32-ух битки не оставляют простора для творчества???

Итак... Навеяло...
Этим...
viewtopic.php?p=2100572#p2100572

вот как всякие 7-сегментные индикации на ARM-е через DMA делать

и этим...
viewtopic.php?p=2097971#p2097971

Ну как же? На LCD пин "E"-то нужно после выставления каждого байта на 8-ми битную шину переводить из одного состояния в другое и обратно. То есть выдал байт, сделал строб, снова выдал байт и т.д. Так же нельзя забывать про RS (Или RW, не помню уже), чтобы показывать, что мы передаем, данные или команду.

Это... конечно не "всякие 7-сегментные индикации на ARM-е через DMA"... но тоже интересно...
Итак... WG12864 (типа KS0108) на ДМА + 2 таймера... шина 8 бит... Шина данных, Е, D/I и CS1, CS2 управляются хардварно... R/W на землю...

screenshot_2.png

(77.52 КБ) 317 скачиваний

Подробнее...

screenshot_1.png

(76.02 КБ) 196 скачиваний

Как видим... один таймер рулит ДМА и E... другой - D/I, CS1 и CS2... На отрицательном импульсе D/I засылаются команды управления 0xB8+x и 0x40... потом идут байты данных 0х00 очистки экрана... вуаля!!!

Честно говоря... это можно проделать и на STM8L... Правка кода, при этом, минимальная...
АТМЭЛы и ПИКи нервно курят... и бьются головой апстену в истерическом припадке ногодрыга...

Дальше... One-Wire... DS18B20...
viewtopic.php?p=2080462#p2080462

screenshot_3.png

(93.52 КБ) 300 скачиваний

Верхний канал - строб ДМА чтения состояния шины... нижний - сама шина One-Wire... всё хардварно...
Подробнее...

screenshot_4.png

(73.08 КБ) 331 скачивание

На STM8L... к сожалению... это не прокатит... у STM8L один полноценный канал ДМА...

Нус... будем и дальше... о вкусе 32-ух битовых устриц спорить???

[DX168B]

Странная полемика. МК выбирается исходя из потребностей задачи. Походу это правило все забыли.
Мой случай.
Недавно проводил дома обновление коммуникаций наряду с капитальным ремонтом дома.
В подвальной мастерской под шумок заменил всю проводку. А вот кинуть кабель с дому в подвал забыл.
После того, как все заделали, зашпатлевали и закрасили, портить вид кабелем уже не хотелось.
А ведь я хотел помимо интернета по оставшимся парам кинуть RS-485 для охранки и прочих нужд.
Пришлось идти другим путем. Купил PLC модемы (девайсы позволяют гонять данные по обычной квартирной проводке)
и решил так проблему с интернетом. Но ведь надо было решить проблему еще и с техническими коммуникациями.
Решение пришло само собой. STM32F407 с Ethernet PHY. Почему 407й? Запас на будущее. За то, у меня появилась
прорва интерфейсов. Два CAN, два RS-485 и голосовой интерком для связи с квартирой.
Я незнаю, как восьмибитка с этим бы справилась. Сколько гигагерц ей бы потребовалось, чтобы пропустить
через себя столько потоков данных одновременно? А ведь TCP/IP сам по себе сложен. Получи пакет, проверь,
тебе ли он предназначен, передай данные нужному интерфейсу, в зависимости от того, по какому номеру порта он пришел.
Сформируй пакет и т.д. и т.п. Плюс, самостоятельный опрос всех устройств на шинах и вывод на дисплей данных из них.

Следующая проблема. В мастерской нет нормального протока воздуха, в результате чего возникает сырость и
портятся детали, инструмент, приборы и прочее. В качестве решения пришла tiny2313 с релюхами для коммутации
вентиляторов и несколько датчиков температуры/влажности с шиной 1-wire. В качестве фичи, встроенный UART
был задействован для удаленного считывания значений со всех датчиков, состояний вентиляторов и добавилась
возможность удаленно задавать значения порогов срабатывания каждого вентилятора в отдельности.
Код, правда, пришлось тромбовать ногами ассемблером.
Простой тиньки тут хватило с лихвой.
Вот и пример двух задач, где применились слон и моська.

Да, кстати. HHIMERA. С предыдущим постом согласен.
Я тоже сторонник использовать периферию по максимуму. То есть, стараюсь возложить
максимум задач на аппаратный уровень. И подальше держусь от программных ногодрыгов.
При возрастании сложности программы, так-же возрастают и проблемы с ногодрыгами.
Как-то в одном проекте я даже отказался от программного ногодрыга 1-wire и поставил
дорогущую DS2482-100. Ибо были частые прерывания, портящие обмен по этой шине.
Знаю, можно было UARTом воспользоваться, но он был уже занят.

[HHIMERA]

МК выбирается исходя из потребностей задачи

В качестве решения пришла tiny2313

А я бы выбрал STM32F030F4... которая в полтора раза дешевле Тиньки... в розницу...

Код, правда, пришлось тромбовать ногами ассемблером.
Простой тиньки тут хватило с лихвой.

... чтобы АСМ-мазохизмом не заниматься... Да и... "тромбовать ногами ассемблером"... как-то не вяжется с "хватило с лихвой"...
Неувязочка...

[DX168B]

HHIMERA Тинька валялась без дела, вот и пихнул. На сях может быть и не хватило, но на АСМе хватило
и даже 0.5кБ флеша осталось свободными. Просто надо было хорошо подумать над фрагментацией
программы. В смысле, построить алгоритм так, чтобы можно было оптимально разбить код на процедуры,
чтобы не плодить множество одинаковых операций. Тогда все влезло. Ну и чтобы ассемблер не забыть и принципы построения
оптимальных алгоритмов подточить. А то я уже прочно сижу на Си.

Если буду апгрейдить в дальнейшем, то присмотрюсь к Cortex-M0.

[HHIMERA]

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

[DX168B]

Учитывая, что сейчас различных ARMов как грязи и к тому-же дешевых, то уже и не принципиально.
Естественно, в плане производительности лучше 32х-разрядные.

Вспомнил, как в одном проекте мудохался с PICом (PIC16F1825).
Задача сложная была и Cortex-M0\М3\М4 там было самое место, но были проблемы
сугубо технического характера. Во первых - спящий режим. Тот PIC в спячке кушает
сотни микроампер, что было важно. Во вторых - организация питания. Устройство
питалось от литиевой банки, напряжение которой варьируется от 2.8V до 4.2V.
Так как в девайсе активно использовался АЦП, который мерил эту-же банку,
то возникли проблемы с опорным напряжением в районе 2.9V на банке. (показания уплывали)
Ну и дешевых операционников, работающих в этом диапазоне напряжений не нашлось.
Пришлось ставить бустер, поднимающий питалово до 5V. Тогда все технические проблемы
пропали, но появилась проблема с камнем. Код пришлось пихать ногами и камень разгонять до 32МГц.