[haker_fox 60]

Модератор: повеселились, и право пора же заканчивать оффтоп.

[Oleg_IT 0]

14 hours ago, jcxz said:

Т.е. - сперва всё написать, отладить, а потом выкинуть весь отлаженный код, переписать заново по-другому и сдать заказчику, то что получилось, неотлаженным???   Странные у вас методы "отладки"...

Нет, это не так, это во так, забрав отлаженный свой код,

8 hours ago, tonyk_av said:

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

Но с Кубом, для меня, быстрее.

Спорить что проще, надёжнее Куб или не Куб смысла не вижу, каждый решает сам, тем более этот спор длится лет... много.

Вопрос к Forger. Есть сравнительные данные, какой код лучше, надёжнее, быстрее? Если есть поделитесь, может правда стоит перейти на альтернативу. 

 

[Forger 17]

2 hours ago, Oleg_IT said:

Есть сравнительные данные, какой код лучше, надёжнее, быстрее?

Таких сравнительных данных никто вам никогда не даст. 

А, если подобное обещает, то однозначно это - инфогане, жулики, продаваны и т.п.  😉 

 

2 hours ago, Oleg_IT said:

Если есть поделитесь, может правда стоит перейти на альтернативу. 

чаще всего использую MDK-Middleware (файловая система, сеть, USB) и MDK-Middleware_Graphics (графика, segger emwin). Пишу под Keil (тоже в основном).

Куб использовал иногда для наглядности назначения пинов, чисто чтобы визульано глянуть кто-где будет висеть (удобно при создании схемы), а так почти всегда хватает просто даташитов. Там все есть, что надо

[tonyk_av 31]

4 hours ago, Oleg_IT said:

Спорить что проще, надёжнее Куб или не Куб смысла не вижу, каждый решает сам, тем более этот спор длится лет... много.

По-моему, на easyelectronix как-то раз разговор зашёл об этом. Сравнили простейший обработчик приёма символа по UART. Без Куба на С он выполнялся 40 тактов, у меня на С++ немногим больше 60, обработчик, сгенерированный Кубом, 180 тактов. По размеру кода могу только сравнивать свои проекты и аналогичные с примерно одинаковым функционалом. Разница в 2-3 раза не в пользу Куба.

Я несколько раз прикручивал драйвер USB из HAL к своим программам, поэтому имел необходимость изучить устройство Куба. Это ужас.  Одно лишь использование Кубом задержек в обработчиках прерываний чего стОит. При этом удивляет то, что кодогенератор Куба имеет всю информацию, необходимую для построения хорошего кода, но почему-то строить жирную и тормозную кодохрень.

Где-то в Инете есть даже сайт, на котором энтузиасты-бедолаги ведут учёт ошибок в кодогенераторе Куба, которые СТМ почему-то не торопится исправлять, хотя эти энтузиасты тут же прикладывают заплатки-решения. Тот сайт я находил потому, что разбирался с драйвером USB из HAL, который регулярно намертво зависал. Причина оказалось простой: в драйвере не обрабатывались команды изменения скорости обмена по CDC после его инициализации, хотя есть все структуры и даже комментарии для дописывания кода, чтобы драйвер не вешался. И такой хрени там полно. Я такой падляны от СТМ не ожидал, думал, что чё-то не так понял, когда читал комменты в теле драйвера. Оказалось, что для Куба это норма. Дальше решайте сами, с кем хотите сексоваться, с кактусом в лице Куба или натуральной кожаной тётенькой.

Изменено 27 февраля, 2023 пользователем tonyk_av

[Oleg_IT 0]

Еще по поводу альтернативы. Когда вышел CubeIDE я с Keil перешёл а этот IDE. Зря перешёл, какое у кого мнение? это к тому если применять MDK-Middleware, MDK-Middleware_Graphics CubeIDE эти библиотеки переработает? (ну мало ли может кейловская специфика есть, компиляторы хоть и С, С++ но у каждого разработчика есть нюансы)

tonyk_av согласен что Кубовский код не рационален, кривой и ещё как там, но для начала проекта вполне сойдет и наглядность настроек тоже не мало.

Но буду думать:)

[Forger 17]

1 hour ago, Oleg_IT said:

Зря перешёл, какое у кого мнение?

А вот это только вам решать )))

Кейловские библиотеки "заточены" под ARM компилятор. Его можно пока спокойно пользовать бесплатно (читай поломать), если компилировать строго из-под кейла.

А как стэндэлон он уже ругается. Речь про свежий компилятор v6.x, старый v5 давно снят с поддержки, и для новых проектов его лучше не использовать.

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

Понятия не имею как это можно сделать руками в сторонней IDE, вот ни разу не пробовал (нет нужды).

 

[khlenar 5]

В 23.02.2023 в 12:46, Andrey190 сказал:

Жаль, что функции инициализации серого цвета не перемещаются.

[Forger 17]

35 minutes ago, khlenar said:

Жаль, что функции инициализации серого цвета не перемещаются.

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

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

[x893 35]

56 minutes ago, khlenar said:

Жаль, что функции инициализации серого цвета не перемещаются.

Жаль. Но если сильно хочется, то можно.

[khlenar 5]

18 минут назад, Forger сказал:

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

Да, согласен. И лень, когда нужно присвоить альтернативные функции пинам.

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

Жаль. Но если сильно хочется, то можно.

Хочется. Можно конечно и, что с верху находится переставить вниз.Но когда с верху остается одна функция для перестановки, то эта функция не хочет смещаться вниз)

[tonyk_av 31]

On 2/27/2023 at 7:32 PM, Forger said:

Таких сравнительных данных никто вам никогда не даст. 

Если мы о компиляторах, то, да, есть. Интересно- поищите сами, сравнений вагон. Коротко: бесплатный gcc строит вполне хороший код. Да, IAR и Keil его в некоторых специальных тестах заметно обходят, но, в целом, особой разницы нет.

[x893 35]

ARMCC
ARMCLANG

мой выбор