Easyelectronics.ru

[Дружеские встречи с Алгоритм-билдером]
[Изготовление и ремонт деталей машин]
[Тема: русский софт]
[Графическая среда разработки программ]
Алгоритм билдер - это новый программный продукт (моложе на 2 - 3 десятка лет, соотносительно с си), по которому очень многие желают высказаться. Продукт позволяет создавать программы на ассемблерном уровне в 3 - 5 раз быстрее, чем на обычном ассемблере (сохраняя при этом качество ассемблера - не спускаясь до качества программ, созданных на языках более высокого уровня).

Подниматель, вам одной темы не хватает для этого вашего билдера? Зачем плодить? Еды не хватает что ли?

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

Пожалуйста! Приведите пожалуйста примеры гибкого ассемблерного кода (специально для "сторонников" Cи подхода), чтобы бы это продемонстрировать.

Две дополнительные темы (кроме основной) были засраны "Вашими" сообщениями и были удалены с форума. (остались, наверное, только в сервисе Web архива)

P.S. Не нравится тема и если проходите мимо, то и проходите мимо!

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

Расскажите лучше что у АБ с системами контроля версий и командной работой.

Можно ли его привязать к меркуриалу или гитхабу какому? Как организовать работу с ветками разработки? Контролировать и протоколировать внесенные изменения? Мерджить ветки?

Ну и главный, животрепещущий, вопрос. Что будет с АБ если его создатель завтра попадет под трамвай?

Не считаю нужным, все это есть в инете. А горбатого только могила исправит (может быть?) ...

Это вторично.
Первично (@"Законы песка") нет достаточного спроса, значит и нет предложения! (надеюсь, автор мог и дальше развивать продукт при наличии спроса)

P.S. "Форки" АБ тоже могут появится при "попадания автора под трамвай" и наличия интереса к данному направлению.
Пример HiAsm среды разработки, когда автор забросил разработку базовой ветки. В HiAsm "блок-схема" описывается в текстовом формате, но как это учесть при контроле версий - отдельный вопрос.

Разве здесь нужны комментарии?

Нет это не вторично.

Отсутствие подобных систем резко ограничивает уровень разработок одним человеком и "будильником на AVR". Т.е. это изначально тупиковый путь для разработчика который хочет вырасти в профессионала выполняющего серьезные коммерческие задачи.


Т.е. о чем я и говорил. Уровень проектов АБ - будильник на avr и средняя квалификация пользователей примерно такая же. Т.е. им это не нужно, т.к. их проекты слишком просты.
Либо автор хочет, но ввиду изначальной концепции ни одну из готовых CVS не прикрутить, а свою написать это обосраться сколько работы надо. Это задача не для одного человека.


Оно разве опенсорц?

У меня есть одна прохладная история с коммерческим применением АБ. Есть такая вещь как Пеллетный котел Roteks, его делают в Челябинске. Я лично знаю его разработчика (он же директор этого предприятия). Вот он изначально все делал на AVR и АБ, пока хотелки клиентов и возможности конкурентов банально не превысили возможности AVR.

В результате, вместо простой миграции на какой нибудь жирный STM32 ему пришлось забрасывать свои прошлые наработки и радикально менять всю систему управления. Думаю не надо объяснять сколько это дало головняков и потеряного времени.

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

Хотелось бы для тупых все таки объяснить почему пришлось забрасывать и радикально менять.

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

А так бы прокатил копипаст логики/физики с правками только аппаратно зависимых вещей.

Я же когда пишу на Си стараюсь делать так, чтобы можно было буквально изменив несколько строк в конфигах перетащить все на совершенно любой контроллер. Т.е. есть логика, а есть HAL зависящий от конкретного МК. Так что без проблем бросить код с AVR на STM32 или LPC, PIC или MSP какой-нибудь. Да куда угодно. Все МК в принципе одинаковые концептуально.

Ну тогда, если бы программа была написана на обычном ассемблере, были бы такие же трудности переноса на Си, АБ тут не причем. На тот момент, когда писалась программа для AVR наверное не планировался графический интерфейс и прочее. А то что появились конкуренты с новыми возможностями это, имхо, недоработка директора предприятия. Появились они (конкуренты) наверное не сразу - было время изучить Си, новые микроконтроллеры или нанять работника для этого. Разработчик, считаю, должен постоянно изучать новые технологии.
Занимался я переносом своего быдлокода с АБ на Си, правда простые проектики - да это дольше, но вполне осуществимо, главное это, что есть уже готовый алгоритм.

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

А какие то готовые решения брать для системы ещё лучше :)
Пример для пеллетного котла GSM-реле
или это уже идёт отдельной опцией для разной комплектации? (как принято у авто производителей)

P.S. 160 т.р. не такая уж и предельно низкая цена для котла обогрева жилища :)

тут и устаревшие AVR в эту концепцию не вписываются, остаются только у дел 6-ногие типа Tiny10, для них на Си писать нет смысла, тут нужны ассемблеры всяческие.

НУ в итоге к готовому решению и пришли. Стали ставить какие то готовые панели от мицубиши. Все круто, стоит фигню, программируются прям со своего же экрана (там подобие мини скада системы и типо ПЛК небольшого). Но опять уперлись в ограничения этой панели. Не хватает ее мозгов для всех фич. А более мощной у них нет и делать они их не планируют. Аналоги тоже не нашли. И вот опять что то свое колхозят.

Как правило, при переносе с ассемблера - трудностей не возникает. Во-первых, перенос асм-асм - как подтвердил выше Ди, достаточно прост, особенно на "старшие" контроллеры.
во-вторых, да, изначально была выбрана неверная тактика - вместо написания софта на си (или, хотя бы, на стандартном асме) был использован негодный инструмент. Что привело к выбрасыванию изрядного задела.
третье - "было время изучить си" - так си, в общем, не сложнее ассемблеров. спускаться на уровень ассемблеров, владея ЯВУ, гораздо проще логически (хотя неприятнее психологически - нужно рожать в разы больший объем в строках). поэтому и говорят - начинайте _программировать_ с ЯВУ. А научитесь программировать - кодировать потом можно хоть на чем.

не могу себе представить перенос асм-асм с AVR на STM32. На PIC24 с AVR, да проще. На микроконтроллерах с более навороченной периферией USB, Ethernet, Chrom-ART Accelerator, наверное проще использовать готовые библиотеки, тут без Си не обойдешься, да и вообще на микроконтроллерах с ядром Cortex на ассемблере пишут лишь энтузиасты.

каким образом поможет при переносе на Си программа на стандартном асме? Тут уж все равно что АБ что асм, главное алгоритм. А тактика неверная может уходить корнями в те времена, когда еще Си для микроконтроллеров не существовало.

текст на нормальном асме - это текстовый документ.
текст на любом ЯВУ - это текстовый документ. человеку психологически проще работать с одинаковыми представлениями (меньше ошибок), хотя легче (за счет участия разных участков мозга) - с двумя различными представлениями (но это уже различия психотипов) , но возникает больше ошибок.
Да, кстати, "си для микроконтроллеров" существовал гораздо раньше, чем появился АД. и будес существовать еще долго после смерти АД.
Т.е. основная тактическая ошибка в том, что выбрали "красивость", и "низкий порог вхождения" вместо функциональности и правильности.

Ад наверное все таки раньше появился чем Си :) :

асм для микроконтроллеров все таки был раньше чем Си, может и ошибаюсь

спасибо, посмеялся - напомнило (было популярно в 80-х):

насчет корней - неправильное понимание, у меня, например как было:
начало -> асм для 580ИК80 -> асм для 51 -> асм для PIC -> Си для PIC -> асм для AVR -> АБ+Си для AVR -> Си для STM32/STM8
"красивость", и "низкий порог вхождения" совершенно не мешают, а иногда помогают в решении задач

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

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