ST прикупает Atollic и...

STM32

Новость надеюсь приятная — теперь Atollic TRUE Studio V9.0 для STM32 PRO версия бесплатна!

blog.atollic.com/truestudio-for-stm32-9-released
И очень похоже что я нашел себе новую IDE- по первым впечатлениям она напоминает CooCox, но менюшек и фенечек полезных и хз дофига всяких, по сравнению с CooCox 1.78. Есть Atollic Store — где можно скачать примеры, скачал один и он даже скомпилировался :)

ps надеюсь не боян
  • +3
  • 27 января 2018, 00:50
  • GYUR22

Комментарии (96)

RSS свернуть / развернуть
Скачал еще вчера утром, но не ставил, пока не до того было. Теперь наверное придется поставить, заманили ))
0
Интересно, коммерческую версию для других чипов они продолжат пилить? И еще интересно, насколько оно залочено под STM32.
0
  • avatar
  • Vga
  • 27 января 2018, 03:00
  • ↓
Вот что написано в их Q/A документе:
Q4: Will there be a new TrueSTUDIO release in the future?
Yes, ST is working to deliver a new TrueSTUDIO version exclusively for STM32 developers that will provide the advanced features of TrueSTUDIO-Pro free.
Q6: What is the recommended migration path when Atollic TrueSTUDIO for ARM will no longer be updated? Do you recommend another tool?
For users of ST target devices: ST is working to deliver a new TrueSTUDIO version exclusively for STM32 developers that will provide the advanced features of TrueSTUDIO-Pro free of charge.
Users of non-ST target devices: Please contact your distributor. The available migration solutions are target device specific.
короче — вас кинули, расходимся.
0
Я за последний месяц перелопатил сред для stm32 (любимый code:blocks не подходит для текущей задачи) в поисках той самой подходящей… Видимо, придётся глянуть и на этот вариант)
0
У С::B божественный интерфейс отладчика. Но код писать всё-таки удобнее писать в QtCreator'е. Очень удобные автодополнения и снипиты.
Я, конечно, говорю только про нативные IDE. В IDE, работающие в JVM или .NET между нажатием комбинации автокомплишена и разворачиванием меню проходит полсекунды работать становится очень мерзко. Чувствуешь себя как в ведре с маслом. Вязко и неторопливо.
А кто-то пишет в браузере…
0
А кто-то пишет в emacs и vi ;-)

Но вообще, в IDE от JetBrains хоть они и на Java нет никаких полусекундных пауз когда индексация проекта закончена. Но под микроконтроллеры да на C у них ничего нет, конечно. Может CLion допилят, они думают в эту сторону. Но он не будет бесплатным.

В общем, дело не в JVM, а в руках программистов, как всегда. Эклипс я сам не могу вообще.
0
Я тоже с эклипсом не дружен. На физическом и психо-эмоциональном уровнях.
0
На счёт тормознутости приложений на JVM и .NET… это ж всё интерпретаторы, размещающие реальный код процессора в оперативной памяти… если вызвать повторно операцию, уже ранее интерпретированную и незатёртую в памяти, то ранее интерпретивный код сразу выполняется… поэтому Сименс в рекомендациях RAM пишет: 16 GB (min. 8 GB, 32 GB for large projects)
Объективная плата пользователей за огромадные зарплаты заграничных программистов, которые за взятки от производителей процессоров и памяти с каждым днём нагромождают всё более тупой и жрущий ресурсы элитный код интерпретаторов для интерпретаторов.
-1
Нет ты не прав. Это плата не за взятки а за сокращение времени разработки. Менеджеры требуют чтобы рабочий код появился именно в то время когда его можно продать а не на 2 месяца позже. Это заставляет программистов использовать универсальные СДК. что сказывается на производительности, ведь за универсальность надо чем-то платить. По этому разработчик ставит или или и менеджер выбирает тот способ что позволяет переложить затраты на конечного пользователя. ТЕ увеличение системных требований. С другой стороны если софт покупать, а его цена завышена и неадекватна тому сколько на него готовы потратить, то покупка самого дорого компа это капля в море по сравнению с ценой софта. Например автокад стоил около 200К мак под него только 80К. Ну или официальная винда 6К а по жизни 100р за диск, при зарплате пусть даже в 30К (это в 2 раза выше среднего по области) ясно что человек выберет.
0
это ж всё интерпретаторы, размещающие реальный код процессора в оперативной памяти…
Во первых, не интерпретаторы, а во вторых — и это главное — нативный код тоже полностью размещается в оперативной памяти.
поэтому Сименс в рекомендациях RAM пишет: 16 GB (min. 8 GB, 32 GB for large projects)
Это заслуги сименса, а не дотнета или на чем они там пишут.
0
Во первых, не интерпретаторы, а во вторых — ...
смысл так опрометчиво подставляться?
[url=http://5cm.ru/view/i7/hmPs.jpg][img]http://i7.5cm.ru/t/hmPs.jpg[/img][/url]
поэтому все суждения в сообщении имеют ложный смысл :(
-1
Смысл так ярко демонстрировать, что ты ничего не понял?
Во первых, .net и JVM — не интерпретаторы. Это JIT-компиляторы (ну, за исключением .net CF и J2ME, предназначенных для эмбеда). О чем, впрочем, ты и сам пишешь — код компилируется и исполняется, скомпилированный код хранится в памяти.
«Во-вторых» относится к программам на нативном коде, типа С++. Они также целиком загружаются в память и исполняются оттуда, так что в этом плане разницы нет.

Ну и в-третьих, засрать оперативку исполнимым кодом проблематично. Просто потому, что несколько гигабайт исполнимого кода — это пиздец как много. Память засирается рабочими данными программы. Не знаю уж, что TIA хранит в таких количествах, но это определенно заслуга ее авторов.
+1

«Интерпретатор компилирующего типа» в оперативную память?
Ну тогда как называется загрузка традиционной программы *.com (или *.ехе) в машинных кодах в память? Компиляция?
А если область памяти кода находится в масочном ПЗУ?
Кто то потерял гендерную память и не может отличить кончиту от нормальных людей.
я не воспринимаю серьёзно набивающих на клаве браные слова
-1
«Интерпретатор компилирующего типа» в оперативную память?
JIT-компилятор, а не интерпретатор.
Ну тогда как называется загрузка традиционной программы *.com (или *.ехе) в машинных кодах в память? Компиляция?
Так и называется — загрузка. Впрочем, бывает и компиляция. JIT-компилятору, по большому счету, пофигу, какой там код на входе — JBC, MSIL, ARM, x86…
А если область памяти кода находится в масочном ПЗУ?
В чем-либо крупнее микроконтроллера в масочном (да и вообще любом, втыкающемся прямо в шину процессора) ПЗУ редко бывает что-то кроме IBL. На ПК даже BIOS не выполняется прямо из флешки.
я не воспринимаю серьёзно набивающих на клаве браные слова
И это говорит человек, сводящий вопросы информатики к кончитам. Прямо в стиле «нет, Вовочка, так ты мне всю науку в хуям сведешь!».
+1
какие то вымыслы из школьных рефератов по информатике


не стоит за некрасивыми словами скрывать своё бессилие
-2
какие то вымыслы из школьных рефератов по информатике
То есть ничего осмысленного ты возразить не можешь. ОК, слив защитан.
не стоит за некрасивыми словами скрывать своё бессилие
Не стоит скрывать за бессмысленным ханжеством неспособность что-либо сказать по делу.
+1
На счёт БИОСа — если б я сам был школьником и никогда сам не писал(изменял) и не отлаживал БИОС ПК, то может быть на слово поверил бы в лапшу о том, что Процессор не выполняет кол, читая команды на выполнения прямо из БИОС… начало 198*..2018
На счёт «микроконтроллеров» — Intel386EX и ему подобные микропроцессор или микроконтроллер? а Н7 сравним по вычислительным мощностям с ПК IBM AT 386?

Конкретно кто откуда код и с какими задержками на шине выполняет надо смотреть на конкретную модель — но всегда первая команда выполняется из «постоянной» памяти, так как в оперативной без батарейки пусто… как в башке пустобреха.

Об интерпретаторах и компиляторах.
Интерпретатор Васьки/MS.NET/Java по ходу дела читает исходный текст программы на человеческом «Васькином» языке и превращает их в памяти в набор команд процессора Интел = интерпретирует.
Каждый раз при запуске программы происходит трата времени на превращение исходника в команды процессора = интерпретация.

Компилятор Паскаля/С читает исходный текст программы на человеческом языке Паскаль/С и превращает их в памяти в набор команд процессора Интел и результат записывает на диск в виде готового к исполнению файла ЕХЕ/DLL = компилирует.
При запуске программы или функции она сразу выполняется процессором, так как является готовым изделием.

MS.NET и JAVA задумывались как интерпретаторы… коими они и являются.
Некоторые пытаются представить MS.NET как «Интерпретатор компилирующего типа»… то есть мол он исходный текст превращается в какой то полуфабрикат ЕХЕ/DLL файл и это мол признак «компиляции»… ну а то, что содержимое полуфабриката потом ещё и интерпретируется в код процессора… ну так его ж назвали «Интерпретатор компилирующего типа» :)
По идее это должен знать каждый Программист :)
-2
может быть на слово поверил бы в лапшу о том, что Процессор не выполняет кол, читая команды на выполнения прямо из БИОС…
Вот только одна мааааленькая проблемка — ковыряя BIOS нельзя выяснить, откуда оно исполняется. Потому что это зависит от чипсета. А так биос выглядит ровно так же, как COM-файл — блоб, загружающийся по определенному адресу. Отличается только адрес и способ загрузки.
На счёт «микроконтроллеров» — Intel386EX и ему подобные микропроцессор или микроконтроллер? а Н7 сравним по вычислительным мощностям с ПК IBM AT 386?
Обрати внимание — «не исполняется прямо из ROM» относилось только к ПК, причем более-менее современным. Ко всему остальном относится «обычно в ПЗУ только IBL». Про девайс на фото сказать сложно, но, насколько я вижу, там присутствует мелкая ROM 29хх/39хх с IBL и NAND со всем остальным.
но всегда первая команда выполняется из «постоянной» памяти, так как в оперативной без батарейки пусто… как в башке пустобреха
А вот здесь глянем на такие забавные девайсы, как ARM-микроконтроллеры GD32. И что мы видим? Кучу RAM специально под код, которая железом загружается из флешки 25хх. Из самой флешки код, разумеется, никогда не исполняется.
Об интерпретаторах и компиляторах.
К сожалению, изложенное тобою дальше было актуально разве что во времена, когда писались советские учебники по информатике. В современном мире грани сильно размазаны. Достаточно сказать, что x86 процессоры уже давно именно что интерпретируют «нативный» х86 код. А жаба и дотнет — нет, в полноценной пекашной версии это именно что компиляторы. Они всего лишь выносят часть фазы компиляции (именно часть, самое накладное по времени выполняет компилятор байткода) на момент запуска программы. Это несколько замедляет запуск программы, зато повышает ее производительность по сравнению со статически скомпилированным кодом.

Стоит заметить, что автор Паскаля, Никлаус Вирт, подобный подход предлагал еще как бы не в 70-х, как средство, позволяющее одновременно отвязаться от архитектуры машины и повысить производительность кода. Реализовали это только сейчас, и то не полностью — Вирт предлагал хоранить AST вместо байткода, который дает значительно больше возможностей для оптимизации при JIT-компиляции.
Также стоит отметить тот забавный факт, что именно Паскаль является одним из первых представителей «компилирующих интерпретаторов».

И вот это должен знать каждый программист, не застрявший в прошлом веке.
0
«Мать» у меня этого века — выше на картинке представлен её БИОС, при включении компьютера команды которого исполняются из него.
У меня есть прошловековой чистый Атмел АРМ без памяти и в доке на него указано какие задержки можно устанавливать для памяти с разным быстродействием — код будет выполняться из внешней постоянной памяти

Как понял с традиционными технологиями и терминологией «прошлого века» ты не знаком :(
и тебя легко обвести — если с бытовой точки зрения смотреть на компиляторы и интерпретаторы
Компиляторы готовят продукты готовые к употреблению без дополнительной обработки = ну типа «Блинчик с повидлом»… взял и съел…
Интерпретаторы — могут по требованию выпечь блинчик из полуфабриката (заранее подготовленного теста в случае MS.NET)… при наличии технической возможности в виде горячей сковороды определённого типа (Framework'a не ниже vN.M)… если сковорода не та = нет блинчиков.
А все эти выдумки про «компиляцию в память по требованию» это лукавый рекламный обман, когда явление «интерпретация по требованию» называют «компиляцией по требованию»… в итоге официально явление обзывают «интерпретирование компилированного по требованию» со всеми вытекающими сложностями и задержками во время подготовки к выполнению программы.

Отсылка к Вирту и его изысканиям — это для другой темы о потерянной Модуле
0
при включении компьютера команды которого исполняются из него.
Пруф?
Компиляторы готовят продукты готовые к употреблению без дополнительной обработки = ну типа «Блинчик с повидлом»… взял и съел…
Я не нуждаюсь в поверхностных аналогиях.
Компиляторы транслируют исходный код в машинный. Интерпретаторы выполняют непосредственно исходный код. Эти понятия не являются строго полярными, так что помимо целого спектра промежуточных вариантов есть варианты, являющиеся одновременно и тем, и другим.
Дотнет и жаба не интерпретаторы. Они не интерпретируют ни исходный код, ни байткод. Они компилируют исходный код в байткод, а байткод в нативный код и потому можно считать их двухступенчатыми компиляторами.
Также есть пара забавных моментов:
1) JBC — нативный машинный код. На процессорах ARM с технологией Jazelle DBX.
2) Дотнет можно скомпилировать в нативный код целевой машины статически. Собственно, многие программы при установке так и делают.
при наличии технической возможности в виде горячей сковороды определённого типа (Framework'a не ниже vN.M)… если сковорода не та = нет блинчиков.
С нативным кодом все куда хуже. Не тот процессор — упс. Не та операционка — упс. Нет необходимого рантайма — упс.
Как понял с традиционными технологиями и терминологией «прошлого века» ты не знаком :(
Знаком, отчего же. И потому понимаю, что солидная их часть устарела.
0
Как понял с традиционными технологиями и терминологией «прошлого века» ты не знаком :(
Знаком, отчего же. И потому понимаю, что солидная их часть устарела.
я делаю готовые к исполнению самодостаточные программы — кликнул и она выполнила свою задачу напрямую,
мой коллега делает программы для запуска которых требуется наличие на компе интерпретатора MS.NET определённой версии…
видимо мой подход устарел, а подход коллеги современно-инновационный :)
Дотнет и жаба не интерпретаторы.
то есть без установленного Дотнет и жаба программа запустится? или нет? :)
вот в этом и есть реальная разница между интерпретаторами и компиляторами.
-1
Как понял с традиционными технологиями и терминологией «прошлого века» ты не знаком :(
Повторение не сделает бездоказательное заявление ни на йоту более веским.
то есть без установленного Дотнет и жаба программа запустится? или нет? :)
А твоя «самодостаточная» программа без винды запустится? А с виндой, но на ARM'е? На MIPS'е?
видимо мой подход устарел, а подход коллеги современно-инновационный :)
Вот опять, передергивание. Мы о терминологии касательно компилятор/интерпретатор говорим, а не о подходах.
0
А твоя «самодостаточная» программа без винды запустится?
Впрочем, достаточно отсутствия требуемой версии Visual C++ Redist, чтобы нативная программа на винде не запустилась. Вывод: С — интерпретатор!
+1
Если ты использовал не встраиваемые в исполнительный код внешние компоненты, то программа в машинных кодах дойдя до их вызова заявит, что их просто нет и вылетит по ошибке «Отсутствует вызываемая внешняя программа»…
это как бы не относится никоим образом к «интерпретации»… а относится к целостности комплекта программы

А потом нэт-профи удивляются почему Embadcadero компилирует как бы простые программы размером в несколько мегабайт… там всё нужное уже в одном ЕХЕ файле (если иное не задумано автором в виде внешних DLL)
-1
программа в машинных кодах дойдя до их вызова заявит, что их просто нет и вылетит по ошибке «Отсутствует вызываемая внешняя программа»…
Лолчто? Нет, она вылетит еще до запуска, с сообщением лоадера винды об отсутствии нужных библиотек (очередной забавный момент: лоадер винды выполняет функции линкера, то есть часть компиляции выполняется в момент запуска даже при компиляции в нативный код!). На твоем скрине, кстати, ровно этот случай, и ты даже его не можешь правильно объяснить.
это как бы не относится никоим образом к «интерпретации»… а относится к целостности комплекта программы
Вот именно! Другими словами, тут
то есть без установленного Дотнет и жаба программа запустится? или нет? :)
вот в этом и есть реальная разница между интерпретаторами и компиляторами.
ты сморозил ерунду.
там всё нужное уже в одном ЕХЕ файле (если иное не задумано автором в виде внешних DLL)
Да нифига. Там не «все нужное», там несколько мегабайт оберток на винапи. Без которого, собственно, работать ничего и не будет. Конечно, найти винду без Win32 API в 2018 году сложно (последняя таковая называлась Windows 3.11) — но в 2018 году немногим менее сложно найти и винду без дотнета.
+1
программа в машинных кодах дойдя до их вызова внешних функций заявит, что их просто нет и вылетит по ошибке «Отсутствует вызываемая внешняя программа»…
Лолчто? Нет, она вылетит еще до запуска
получается ты не понимаешь как работает программа :(
В данном случае загрузка DLL повешена на момент создания формы (для удобства), но даже в этом приложении загрузку разных DLL можно повесил на кнопку и вызывал для сравнения их функционала и различия по необходимости
0
На твоем скрине системное сообщение виндового лоадера. Оно означает, что DLL слинкована статически. Ну или что ты его старательно имитируешь, обнаружив что из LoadLibrary прилетел нулл.
Покажи-ка код, как ты там длл грузишь и сообщения выдаешь.
0
У тебя странная аргументация — машинный код Интел х86 не обязан запускаться на Арме и МИПСе… но может запуститься на Эльбрусе :)
Скомпилированный машинный код можно запустить и без Винды… пример ниже

или же любой пример для Atollic TRUE Studio V9.0 для STM32 будет на нём работать без Винды на ней :)
0
У тебя странная аргументация — машинный код Интел х86 не обязан запускаться на Арме и МИПСе… но может запуститься на Эльбрусе :)
Зато машинный код дотнета (ака MSIL) запустится на всем перечисленном.
Скомпилированный машинный код можно запустить и без Винды… пример ниже
Не проблема. Машинный код дотнета там тоже можно запустить.
0
То есть ты утверждаешь, что залитый через ST-Link машинный код VS.NEt 2017 запустится на STM32? Акции Кейла рухнули…
Маленькая оговорка тянет за собой маленькую ложь, которая последовательно превращается в огромадную ложищу, если лгущий не может остановиться :(
0
То есть ты утверждаешь, что залитый через ST-Link машинный код VS.NEt 2017 запустится на STM32?
Разумеется. Естественно, нужно удовлетворить его зависимости в виде .net VM — благо она есть и называется .net MF.
Правда, вот на сей раз дотнет действительно станет интерпретатором.
0
Правда, вот на сей раз дотнет действительно станет интерпретатором.
Впрочем, учитывая с какой скоростью STM выкатывает новые чипы — недолго осталось и до JIT.
0
Маленькая оговорка тянет за собой маленькую ложь, которая последовательно превращается в огромадную ложищу, если лгущий не может остановиться :(
-2
Так зачем же ты продолжаешь лгать?
0
представлен её БИОС, при включении компьютера команды которого исполняются из него.
Бред.
При инициализации теневого ПЗУ (Shadow ROM) содержимое затеняемой области копируется в ОЗУ, и при дальнейшем чтении по этим адресам подставляется ОЗУ, а запись в эту область блокируется.
Теневая память появилась на развитых моделях АТ-286, где она была реализована аппаратно. Процессоры класса 386+ позволяют ее реализовать программно, с помощью страничной переадресации.
+1
Я сын материнской платы… у нас со чтением БИОСа не всё так однозначно
:)
0
Какой няшный раритет. Аж на 8088. В отличие от более современных — этот, полагаю, действительно запускается прямо с ПЗУ.
0
извиняюсь за нетот формат ссылки
0
Скажите, куда мне зайти за взяткой? А то даже обидно, уже 7 лет пишу исключительно на Java, в том числе код, который работает заметно быстрее написанного на C кода наших конкурентов, а взяток производители процессоров не платят :-(
+2
Или взятки платят только плохим программистам, которые не умеют писать быстрый код? Это многое объясняет!
0
У меня в заначке ещё лежит 200 баксов 2002-го года от Сименса за заказ на 10000 баксов (евро тогда ещё только вставал на ноги) :)
не вымогал… предложили взять для дальнейшего сотрудничества 500…
Могу сфоткать…
и не надо сравнивать мелкие утилитки на 300 килобайт, запакованные сомнительными архиваторами, которые антивирусные программы воспринимают как вирусы
с глобальными творениями, которые уже тянут на пол сотни гигабайт… а ещё не всё вышло…
0
с глобальными творениями, которые уже тянут на пол сотни гигабайт… а ещё не всё вышло…
Вопрос еще, образец это глобального творения или глобальной кучи дерьма. Слыхал, что народ плюется на софт от сименса вообще и на TIA в особенности.
0
Все возможно иначе немного :)
как правило те кто принимают решения наверху — страшно далеки они от народных нужд им как правило нужно выполнить план который приходит еще свыше (а там полный уже отрыв...), а потом начинается тестирование на кошечках… на нас
И на вопрос, а почему так — per design :)
Короче просто каждый решает проблемы своего уровня.
0
И на вопрос, а почему так — per design :)
Говно by design — суровая реальность некоторых отраслей, увы. Но лучше-то оно от того не становится.
0
-2
Нипонятна…
0
эта картинка не к тебе, а к любителям набивать неприличные слова
-2
Своих мыслей у тебя нет, ОК.
0
Наконец-то эту богадельню, паразитирующую на open_source, купила взяла на довольствие сурьезная фирмА! А какая радость всем neo-MCU-говнокодерам новым членам stm32 сообщества!

Кокос сдулся года 2-3 назад окончательно, бисплатные клоуны из SW4STM32 (System Workbench for STM32) шо-то не потянули, не внушили доверия ST Micro. Наконец-то этот
быдло
народный чип получил сурьезную, коммерчески поддерживаемую, open_source IDE, да еще за бисплатно.
0
народный чип
Похоже, уже миф. Чипы от NXP с их IDE MCUXpresso не сильно затратнее.
0
На базе Eclipse можно собрать свою среду. Подробная статья на эту тему.
0
И на базе кодеблокса можно среду собрать. В принципе, можно писать код в любом редакторе, а компилить используя скрипт или make. На эклипсе (читай java) все что я видел — жуткое тормозилово. Хотя на вкус и цвет…
0
На эклипсе (читай java) все что я видел — жуткое тормозилово.
Не порите чушь, ей больно.И жаба и эклипс — инструменты. На них можно сделать хорошо, а можно плохо. Но сами они от этого не становятся плохими или тормозными. Особенно смешно читать слова «жуткое тормозилово» о жабе, которая в худшем случае уступает нативному коду несколько процентов.
0
Известный специалист и тоже гуру из Индии Rajalpragram Najave полностью с Вами согласен!
0
и тоже гуру
Мне до ваших коллег дела нету.
0
«На базе Eclipse можно собрать свою среду» — ага собирал еще на базе Eclipse Indigo (в 2011) среду для AVR, года два назад, когда переходил на ARM, пересмотрел все что было из бесплатных/доступных. В итоге просто обновил эклипс до последней версии и настроил его сразу на ARV и ARM.
Довольно удобно получилось одна среда на 2 системы. Редактор хороший, дебаггер есть, заливка прошивок из IDE.
Кстати, СиЛабс тоже на базе эклипса делает свой Simplicity Studio — у меня он под 8051 камни от силабса.

Кто-знает чем сильно этот атоллик будет отличаться от просто эклипса (ядро-то одинаковое)?
+1
чем сильно этот атоллик будет отличаться
Как они сами себя хвалят — оптимизированный компилятор.
0
Не на базе gcc и не на базе clang? Серьёзно?
0
Так в спаме от st было написано. Типа оптимизирован под st… Жаль письмо уже грлхнул.
0
Ну, это может означать то, что там правильные хедеры и, что важно, линкер-скрипты лежат из коробки :-)
0
Поставил, посмотрел.
Но компиллер GCC, имя файла как-бы намекает:
C:\Devel\Eclipse_Based\Atollic\TrueSTUDIO for STM32 9.0.0\ARMTools\bin\arm-atollic-eabi-gcc.exe
Ну или подправленный GCC (не могу пока точно судить)
0
Ну, по лицензии они обязаны поставить все свои поправления, если они там есть :-)
0
И еще один момент эклипс-базированных сред от производителей — там стоят относительно старые ядра самого эклипса. Что в Simplicity Studio, что а Atollic.
Последний Atollic на Eclipse-Neon-1a (4.6.1), а текущая актуальная версия Eclipse-Oxygen.2 (4.7.2) — это почти 30 версий разницы (судя по списку релизов www.eclipse.org/downloads/packages/all)
0
4.7.2 и 4.6.1 отличаются на одну младшую версию а не на 30 так вроде.

Ну для моих проектов стм32 пока жирно. вот стану пенсионером будет много свободного времени может тогда :)
0
Может к тому времени 32-битные процессоры будут считать устаревшими, как сегодня 8-битники :0
Будете сразу stm64 или stm128 осваивать :)
0
Да у меня так с 8 битными. пока я научился худо бедно использовать из они устарели.
0
не знаю что у вас за проекты, но например даже в мелких stm32f042c6t6 есть встроенный usb bootloader, что дико удобно — не надо ничего писать и всегда есть возможность легко обновиться ну и ценник тоже не велик+ возможности
0
Это круто конечно. Но всё дело в том что очень часто эта крутая периферия мне просто не нужна. И обновление прошивки после окончания испытаний прототипа в реальном железе и на реальном объекте просто не предусмотрено. Да и толку от прямого ЮСБ если там всё равно надо ставить изоляцию чтоб комп не пристукнуть.
0
обычно питается проц от usb остальное обесточено и что то пристукнуть трудно — особенно от ноута на батарейке
0
Если оборудование стоит где-нибудь в производственном цеху, изоляция точно не помешает. Как вариант, для обновления софта можно использовать ноутбук, который работает на батарее. Но ведь не все об этом помнят. Поэтому — изоляция.
0
Аналогично надо изолировать и RS232/RS485.
Как то на РЕN подали очень много сильного электричества (монтажник в обед просверлил шурупом крышку кабельного короба и жёстко врезался в кабель частотника на 100 КВТ) — при включении частотник свистнул (я по свисту определяю коротун)… сгорел варистор в блоке питания нотебука… и 2 светильника… а всё остальное выжило… частотник быстро почуял коротун и пострадали только ближние объекты от первого электромагнитного импульса ;) Единственный за пару десятков лет случай проблем с нотебуком, подключенным к сети на объекте.
0
Жесть!
0
Гальваническая развязка для сети это RS-485 ее нормальная работа независимо окружения, а не защита от перфоратора :)
Если подключить ноут даже к галванически неразвязанному оборудованию (особенно на батарейке) — ничего не должно произойти иначе бы всех бы раньше по ТБ поушибали бы
0
и?
зачем нужен искалеченный эклипс, когда есть расовый Ac6 aka System Workbench, кристально чистый Eclips Luna с надстройкой STM32

Новость о чем, непонятно.
0
Почему то никак не могу запустить на отладку, проект созданный в STM32CubeMX для TrueSTUDIO.

0
  • avatar
  • Aneg
  • 12 февраля 2018, 17:04
  • ↓
А эльф-то по указанному пути есть? Может оно не собралось или собралось не туда?
0
Эльф-файла, по указанному пути, нет. Его вообще почему-то нет на диске.
0
Смотри лог сборки, вероятно она зафейлилась. Либо собирает не в ELF, смотри скрипт сборки.
0
Где это нужно смотреть?
0
Понятия не имею, с атолликом не работал. Обычно снизу вылазит окошко с сообщениями о процессе сборки.
0
Ааааа, ну так там пишет, что все ок!
0
Так ты бы хоть показал, чего оно пишет.
0
Пишет «Launching tri.elf» и застревает на 63%
0
Полный лог дай.
0
Маленькая оговорка тянет за собой маленькую ложь, которая последовательно превращается в огромадную ложищу, если лгущий не может остановиться :(
VGA: Понятия не имею, с атолликом не работал
вот такая честность мне нравится :)

Windows 7 x64
всё работает с HAL из Куба :)
0
Мне, однако, интересно, как очередное хвастливое фото изображение дискавери поможет Aneg'у решить проблему.
0
ты в очередной раз показываешь свою полную некомпетентность :( — это Nucleo!!! :)
На изображении копии экрана ИАР и Атолика с HAL после STM32Cube… если это работает у меня = значит и Aneg сможет создать условия для нормальной работы у себя.
Меня не удивляют подобные теоретики, которые боятся Хала и Куба :), но треплющиеся с глупым видом о том, чего сами не знают и не пробовали.
0
ты в очередной раз показываешь свою полную некомпетентность :( — это Nucleo!!! :)
О, так компетентность — это способность различать платки, отличающиеся только названием.
На изображении копии экрана ИАР и Атолика с HAL после STM32Cube…
Сбегал за лупой и таки нашел на коллаже скрины! Правда, так и не нашел в них никакой полезной информации, помогающей в решении проблемы.
0
Гавно ваш атолик. Как и все недоподелки на эклипсе.
0
Аргументы будут или как всегда?
0
Например, у меня так и не получилось запустить на отладку, проект созданный в STM32CubeMX для TrueSTUDIO.
Об этом я писал здесь выше.
+1
То есть один ваш личный неудачный опыт вы обобщили не только на атоллик, но и вообще на всю эклипсовскую экосистему. Ну-ну. Верной дорогой в «илиту» идете.
0
Долго мучился с TrueSTUDIO под WinXP, ни как не удавалось откомпилировать и запустить на отладку, проект созданный в STM32CubeMX. Под Win7 x86 все получилось!
0
У меня под линухом ничего подобного не наблюдалось. Из чего следует логичный вывод, что проблема не в атоллике, а в винде.
-1
Пример из аппнота атмела на атмеге заработал, а на стм32 — нет. Логичный вывод: проблема не в днк, а в стм32.
+1
В общем-то кто-то чего-то не умеет готовить. Тут вот почему-то проекты компилируются и в кейле, и в атоллике (под виндой, ага). Но так было не всегда.
0
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.