Кокос капут? И где SPL для L и F4 ?

[ArtemKuchin]

Играюсь с кокосом. С версией 2 бета. 7 июня вышла новая бета. Стала стабильно виснуть на репозитарии и создании проекта. Др этого было иногда такое с версии от февраля. Толком ничего не поменялось. Пошел на их форум - там капец полный, все забито спамом, который никто не чистит. Хотел зарегится - псиьмо-подтверждение не пришло.
Пошел change log посмотрть - год не обновлялся.

Ощущение, что проект помирает.

Вообще все началось с того, что я хотел создать SPL проект для STM32L151 и не вижу в упор в репозитарии CooCox SPL для него. Вытащил в st.com
То же самое и с F4. Там SPL для этих серией реально нет и надо самому ставить с St.com или я туплю?

Начал посматривать в сторону system workbench...

[Serg1987]

Используйте версию CoIDE 1.7.8. И будет всё ОК. Давно всем известно, что бета 2 тормознутая. Всё что новое - не значит, что хорошее.!

[ArtemKuchin]

Это как-то неверно, как по мне.
1-я веря более не обновляется вообще. Там туча неподдерживаемых чипов. Суть не в том, что использовать одну или другую версию, а в том, что, похоже, инструмент умирает. И зачем пользовать умирающее? Ну банально, если форум не работает, чтобы что-то спросить или баг-репорт сделать, то о чем вообще говорить?

Вопрос с SPL для L и F4 открытый. Кстати, эти чипы в списке поддерживаемых в v1 отсутствуют.

[dosikus]

ArtemKuchin. вот из-за таких ляпов и стоит юзать вменяемый инструмент и не юзать г.либы . Что бы не зависить от блажи и тупости г.писателей...

[ArtemKuchin]

1) Можно перечень вменяемых инструментов
2) что такое г.либы? Примеры


Мое мнение по этому поводу такое. Надо использовать инструменты с минимумом ограничений и максимальной возможной жизнью. Под это подпадает все GNU - оно точно никуда не денется еще очень долго. Но так как хотелось бы иметь IDE и визуальный отладчик, то выбор не богат. Или кокос или eclips самому настраивать или systemworkbench (что тот же eclipse). С кокосом я проблемы описал. Эклипс как и гну будет жить очень долго, как и open ocd.

По либам, если под ними например имелась ввиду SPL. Я понял что ужасное делает кокос - они как то SPL переукаковывают, что вообще в корне неверно. В использовании библиотек от производителя я не вижу ничего плохого. Оособенно, если они не сильно мудреные, хорошо документированы, с примерами и популярны. Как SPL. Но уходить от исходников производителя не стоит тогда. В этом плате подход gcc+eclipse идеален. Если надо что-то супер быстро и оптимально никто не запрещает писать в регистры самому, но редко бывает, когда надо такое, а читабельность падает через N лет.

Но все-таки, конечно, с "фирМой" не сравнить все эти бесплатные тулзы.
Поставил воркбенч. Радует что он есть 64 бита.
Установилось. Не запускается. Идиотская ошибка какая-то. Погуглил, выяснилось, что у меня java 32бит толька (под firefox ставил), а 64бит нет. Поставил - запустилось.
Создал проект, хочу SPL под L151. Нажимаю кнопку скачать SPL, не работает. Да и не может, так как st.com требует регистрацию или подтверждение на email. Скачал сам, положил в папку fireware. Не цеплякт. Переименовал в то,ч то он хочет, зацепило. Проект создался.
Все скомильнулось без проблем. Залить не могу. Никак. Говорит что ресетить устройство не может. Гуглил, нашел,что надо .Cfg файл менять,е сли reset от stlink не прокинут. Поменял, залил.
Отладку запускаю - не запускается. Выяснилось,что stlink повик в каком-то левом состоянии, передернул, отладка запустилась.
Запускаю - нихрена не работает прошивка. Вывыаливается все в hard fault и крутится там в вечном цикле. Гуглил - ноль. Поставил точку остановку в обрпботчике прерывания таймера - а он говорит,что такой строки нет. Тут я смекнул, что дело в другом. startup на ассемблере из CMSIS не был в проект подтянут и так как-то пустой по-умолчанию для STM32 вообще. перекинул из архива SPL .S файл - все заработало как надо.
Но отладка/заливка периодически так и сбоит. Передернишь ST Link на USB - снова работает. Какая-то хрень. Ни в кокосе ни в утилитах ST такого не было.
Структура меню и терминология в эклипсе ушлепочная, но привыкнуть можно.

Видимо так и жить придется.

[dosikus]

1) Keil, Iar
1) SPL, калокуб

[ArtemKuchin]

1) ну нет, пиратские или с ограничениями не хочу, все пиратское потом обновлять тяжко и фигня выходит, согласен, что код они генерят лучше, но мне это не актуально


2) CUBE как-то тяжелый, я вообще не понял зачем сделали куб. Что HAL дает нового, чего не мог дать SPL? В чем там философия новая?

А SPL вполне себе скорописалка для своих побелок, если не программишь какждый день на производстве и нет миллиона строк своих наработок. Не вижу с ней проблем. И главное туча документации. Мне вот надо было побыстрому DAC запустить, а читать даташит так в лом. Бац бац и готово. Да, политически не верно,но ведь работает и сэкономлен час,а то и больше, времени.

[dosikus]

все пиратское потом обновлять тяжко и фигня выходит,

И главное туча документации.

Доводы высосаны из пальца...

Мне вот надо было побыстрому DAC запустить, а читать даташит так в лом. Бац бац и готово.

Ну а это уже диагноз...

[ArtemKuchin]

Это не диагноз, это жизнь такая. Есть работа, есть жена, дети и еще надо найти время на сон. Поэтому для хобби выбирается путь наименьшего сопротивления. Оптимизация.

[dosikus]

Это не диагноз, это жизнь такая.

Это путь в никуда, Или штудируем RM или скачем по граблям аурдуньи, Третьего не дано.

[ArtemKuchin]

Да вы того - радикал

Все или ничего!
RM или "жена, дети, работа, деньги и другие прелести жизнь". Третьего не дано!
IAR или играй в песочнице
Голый CMSIS (а может прямо по адресу хреначить) или иди на PHP сайт делай

[AVI-crak]

Все доступные ID различаются по сложности холодного старта. То-есть самое простое - моргнуть светиком.
После этого рубежа название id уже не так важно. У вас есть проект, который успешно собирается и исполняется - и его можно развивать любыми доступными средствами.
Для меня самая простая и надёжная id - EmBitz. Работает без сбоев, выдерживает переход компа в режим сна, собственно саму id можно неделями не закрывать.

Инсталлы для периферии - для каждого нового проекта уникальные. И это всего 0,1% от потраченного времени на весь проект. Посему можно и нужно обращаться к регистрам по CMSIS. Они в отличии от нового HAL или старого SPL - всегда работают корректно. Один раз написать нужный драйвер для серии, и юзать его до потери пульса.

А дальше идёт С или даже С++, с этим даже в блокноте ничего не случится. Будет пахать на любом чипе, даже в самых извращённых вариантах.

[ArtemKuchin]

Согласен с тем, что EmBitz хорош, легкий, быстрый, имеет тучу интересный функций для работы с исходниками, нормальный отладчик (у меня почему-то тоже подглючитвает, особенно в обработчиках прерываний).

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

[dosikus]

Для меня самая простая и надёжная id - EmBitz.

Уже год не могут добавить новые F0 в дебаг. Оно так и будет дальше - вечное допиливание...

[AVI-crak]

Серии STM32F746 вообще нет в упоминании.
Однако у меня прекрасно собирается проект и есть отладка.
F0 то-же работает, руками собирается стартовый проект - а дальше всё стандартно.

[dosikus]

Я о том, что для JLink нет выбора новых F0xx при отладке.
Да и сам дебагер по сравнению с Keil'овским - сплошная ересь...

[a5021]

Что HAL дает нового, чего не мог дать SPL?

А SPL мог кому-то чего-то дать? Как-то я не уверен. И вообще, вас, похоже, терзает дух противоречия. Одновременно вы говорите, что инструмент должен быть с перспективой на ближайшую тыщу лет, но при этом вцепились мертвой хваткой в успевший уже мумифицироваться SPL.

Мне вот надо было побыстрому DAC запустить, а читать даташит так в лом. Бац бац и готово. Да, политически не верно,но ведь работает и сэкономлен час,а то и больше, времени.

Не в курсе, есть ли код-снайпеты под L и F4, но если все-таки есть, то там все готово и работает даже без "бац-бац".

[ArtemKuchin]

SPL вообще не инструмент. Я его воспринимаю, как своего-рода примочку для быстрого прототипирования. Есть он - хорошо, нет его - никто плакать не будет.

[a5021]

SPL вообще не инструмент. Я его воспринимаю, как своего-рода примочку для быстрого прототипирования.

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

[ArtemKuchin]

Вариант для чего-то быстрого всегда один и тот же - взять чужой кож. Чем при это плох SPL мне не ясно. Его использует если не миллионы, то десятки тысяч, он проверен и перепроверен, если там и есть какие-то проблемы то они сразу находятся при поиске в гугл и не требуют суток копаний. Почти все туториалы и примеры написаны за десятилетие именно на SPL и это огромная база открытого кода. Ничего рядом по такому же объему я не вижу. По моему это смахивает на религиозный фанатизм. Мы за чистую религию и точка тут. Ну есть библиотечка, популярная и оточенная. Чем плоха, если мне не требуется забивать все по последний байт в МК и выжимает последний MIPS? НИЧЕМ, при этом читабельно высокая и если проект открытый и любительский, то и для остальных все будет более понятно.
В целом спор ни о чем и бессмысленный. Я уже написал, что писать свои либо хорошо, и вообще, единственный верный вариант при промышленной разработке, но для любителя вообще никаких ограничений нет. Не заморачивайтесь, пусть каждый пользует то, что пользует, лишь бы работало