Просто суть в том, что все говорят о Web-программистах, пишущих на Python и прочих новых языках и зарабатывающих сотни тысяч, но о разработчиках электроники, пишущих на C на низком уровне и зарабатывающих много денег почему-то никто не упоминает.
Ну, вполне логично; веб-разработчиков существенно больше, соответственно, зарабатывающих выше среднего среди них тоже больше (в абсолютных числах) — поэтому и упоминаний больше.
На мой взгляд, основная проблема — высокий порог вхождения. Для веба вам нужен ноутбук… ну и все, в принципе.
А чтобы делать электронику (более-менее профессионально), придется обложиться осциллографами, вольтметрами, рассыпухой, паяльными станциями. Отладка плат дело не быстрое, цена ошибки очень велика, как и время исправления.
А если вы еще и корпуса для своих девайсов хотите, то… ну вы поняли.
Еще немаловажный факт, кстати, это сообщество и доступность мануалов и учебников. Python — очень популярный язык, на stackoverflow можно быстро получить ответ на любой вопрос (или скорее найти уже готовый ответ).
Подозреваю, что у предложенных вами языков с этим похуже.
Не холивара ради, а исключительно из любопытства — чем все-таки автору не угодил Python как первый язык?
Мне всегда казалось, что самый первый язык должен быть простым, умеренно-лаконичным, не стрелять программисту в ноги и самое главное — чтобы на нем можно было сделать что-то клевое. На мой взгляд только так человек может заинтересоваться программированием.
В идеале это должно происходить еще в школе, но и в университете полно людей, которые только издали видели Паскаль и ничего не поняли.
Клевое — это, конечно, очень субъективное понятие, но, например, какая-то примитивная графика обычно заходит на ура — летающие по экрану кружочки, крестики-нолики, исполнитель-черепашка. Веб тоже хорошо идет.
Ардуино, где можно легко помигать светодиодом или покрутить моторчиком.
Еще крайне желательно, чтобы рабочая среда была дружелюбной и настраивалась легко и быстро.
Python этим требованиям вроде бы вполне удовлетворяет. А вот как с этим у Scheme и Smalltalk — я вообще не в курсе, к сожалению.
Вот после того, как человек «подсядет» на программирование, когда почувствует свою власть над кодом, уже можно более осознано выбирать язык, цели и т.д.
Я так подозреваю — но только подозреваю, разумеется, что М1 они не покупали официально (поэтому и не могут написать, что это Cortex вообще), а либо где-то эмм скопировали, либо от М3 отрезали с мясом все подряд, в том числе то, что можно было бы и оставить.
Они даже SysTick слегка поломать умудрились, какая уж там отладка.
Отладку, кстати, тоже сломали; во время выполнения нельзя отладчиком в память смотреть, иначе рандомные HardFault'ы сыпятся.
Хороший, короче, микроконтроллер, прям всем советую :)
Да, эти главы я уже проштудировал, но в чем я не прав — пока не понял. Прерывание DebugMon явно настроено (__BKPT без отладчика его триггерит), сам watchpoint отладчик останавливает. А вот без отладчика — ничего.
Официально 1986ВЕ1Т имеет некое RISC-совместимое ядро, которое исключительно случайно очень напоминает Cortex-M0 :) В тех поддержке мне предложили его считать «функциональным аналогом».
И DWT там вполне может не быть, раз уж ITM они выкинули. Хотя проверить не помешает, конечно.
Возможно вы не заметили, но я в статье привел «просто посчитать» как один из возможных способов (-fstack-usage) и сам же отмел потому что этот способ работает не всегда.
Т.е. ваш ответ никакой новой информации для меня не содержал, этот способ мне известен, спасибо.
На мой взгляд ваша ошибка в том, что вы начали эмоционально реагировать. И вместо аргументации «чтобы не было переполнения стека, надо делать так-то и так-то» была «вы все вокруг дураки и не лечитесь». Если считаете себя взрослым в детском саду, то ведите себя соответственно.
Я искал более-менее универсальное решение для конкретной проблемы — я его нашел. Что вас не устраивает?
И таки да
Я знаю, что реалтайм — это не про скорость, а про гарантированный срок исполнения.
Опять-таки, все зависит от задач. Реалтайм реалтайму рознь, сами понимаете.
Насчет стека — тоже неоднозначно. Я видел, как на -О3 распухает стек для main'a, потому что в него вся инициализация заинлайнилась. А потом этот стек так и остается съеденным, потому что main никогда не завершается, а компилятору это невдомек.
Даа, мощно!
У меня как-то с задачами все сильно проще; чаще приходится по размеру оптимизировать, чтобы втиснуться на случайно поставленный в серию слишком дохлый МК. А вот чтоб код чего-то не успевал сделать — даже и не припомню.
Окей, пример слишком простой. Представьте, что пользователь полностью вводит адрес функции, которую нужно вызвать.
Судя по всему, с точки зрения Кейловского компилятора, любые манипуляции с указателями на функции — слишком сложные. Поэтому он их вообще с точки зрения потребления стека не оценивает.
А не появился ли случайно хороший аналог PuntoSwitcher'a? Собственно, интересует не автопереключение раскладки, а только возможность сменить раскладку последнего набранного слова.
Лично мне такая фича очень много времени экономит при наборе текста.
Резонно. Поскольку я рекурсией стараюсь не пользоваться, а оптимизацию почти никогда не включаю, то не могу утверждать, что компилятор вообще никогда так не делает.
Насколько я понимаю, компилятор просто выделяет максимум стека однократно, а если у какого-то локального объекта заканчивается время жизни, то новый объект просто записывается поверх.
Но это вроде как ничем не гарантируется, просто это более-менее логично — можно сэкономить на инструкциях. А выделять-освобождать память в стеке несколько раз — зачем?
По идее, какая-нибудь alloca или VLA могут хапать еще стека уже после первоначального выделения стекового кадра.
Но alloca я не использую (потому что Кейловская реализация использует кучу), а VLA Кейл просто в куче выделяет.
Ну, вполне логично; веб-разработчиков существенно больше, соответственно, зарабатывающих выше среднего среди них тоже больше (в абсолютных числах) — поэтому и упоминаний больше.
А чтобы делать электронику (более-менее профессионально), придется обложиться осциллографами, вольтметрами, рассыпухой, паяльными станциями. Отладка плат дело не быстрое, цена ошибки очень велика, как и время исправления.
А если вы еще и корпуса для своих девайсов хотите, то… ну вы поняли.
Но если вы ко всему этому готовы, то почему нет?
(меня больше про гештальт интересует)
Подозреваю, что у предложенных вами языков с этим похуже.
Мне всегда казалось, что самый первый язык должен быть простым, умеренно-лаконичным, не стрелять программисту в ноги и самое главное — чтобы на нем можно было сделать что-то клевое. На мой взгляд только так человек может заинтересоваться программированием.
В идеале это должно происходить еще в школе, но и в университете полно людей, которые только издали видели Паскаль и ничего не поняли.
Клевое — это, конечно, очень субъективное понятие, но, например, какая-то примитивная графика обычно заходит на ура — летающие по экрану кружочки, крестики-нолики, исполнитель-черепашка. Веб тоже хорошо идет.
Ардуино, где можно легко помигать светодиодом или покрутить моторчиком.
Еще крайне желательно, чтобы рабочая среда была дружелюбной и настраивалась легко и быстро.
Python этим требованиям вроде бы вполне удовлетворяет. А вот как с этим у Scheme и Smalltalk — я вообще не в курсе, к сожалению.
Вот после того, как человек «подсядет» на программирование, когда почувствует свою власть над кодом, уже можно более осознано выбирать язык, цели и т.д.
Они даже SysTick слегка поломать умудрились, какая уж там отладка.
Отладку, кстати, тоже сломали; во время выполнения нельзя отладчиком в память смотреть, иначе рандомные HardFault'ы сыпятся.
Хороший, короче, микроконтроллер, прям всем советую :)
Официально 1986ВЕ1Т имеет некое RISC-совместимое ядро, которое исключительно случайно очень напоминает Cortex-M0 :) В тех поддержке мне предложили его считать «функциональным аналогом».
И DWT там вполне может не быть, раз уж ITM они выкинули. Хотя проверить не помешает, конечно.
Т.е. ваш ответ никакой новой информации для меня не содержал, этот способ мне известен, спасибо.
Я искал более-менее универсальное решение для конкретной проблемы — я его нашел. Что вас не устраивает?
Насчет стека — тоже неоднозначно. Я видел, как на -О3 распухает стек для main'a, потому что в него вся инициализация заинлайнилась. А потом этот стек так и остается съеденным, потому что main никогда не завершается, а компилятору это невдомек.
У меня как-то с задачами все сильно проще; чаще приходится по размеру оптимизировать, чтобы втиснуться на случайно поставленный в серию слишком дохлый МК. А вот чтоб код чего-то не успевал сделать — даже и не припомню.
Судя по всему, с точки зрения Кейловского компилятора, любые манипуляции с указателями на функции — слишком сложные. Поэтому он их вообще с точки зрения потребления стека не оценивает.
Если программа и на -О0 укладывается в рамки по размеру/времени работы, то зачем ее оптимизировать?
А вот Миландр 1986ВЕ1, зараза, на другом ядре, в нем этой функциональности вообще нет.
Лично мне такая фича очень много времени экономит при наборе текста.
Но это вроде как ничем не гарантируется, просто это более-менее логично — можно сэкономить на инструкциях. А выделять-освобождать память в стеке несколько раз — зачем?
По идее, какая-нибудь alloca или VLA могут хапать еще стека уже после первоначального выделения стекового кадра.
Но alloca я не использую (потому что Кейловская реализация использует кучу), а VLA Кейл просто в куче выделяет.