Есть microlib и nanolib. Вообще, есть gcc для arm-none-eabi таргета, он вполне прилично компилирует. У проприетарных компиляторов получается немного лучше, но не на порядок.
Если исключить требование EEPROM (в stm его вроде бы нигде нет), то чипы вроде stm32f030k6, stm32f031k6 подходят по остальным требованиям и должны стоить в районе доллара за штуку. Есть в LQFP32.
ну вот я написал #include <util/atomic.h> — оно мне пожаловалось что «вы компилируете не в стандарте C++».
как в GUI это исправить — ХЗ. в Makefile-то я просто CFLAGS нужный добавил.
Ну только это не проблема языка, это убогая система сборки. Это да, никаких возражений.
дык они ценой же определяются. атмеге всего-то питание подать надо.
а ARM'ке одних конденсаторов обвязки килограмм надо повесить, ну и стоить плата будет куда дороже.
Но при этом сам чип армовый может быть и дешевле атмеги. Насчет платы и обвязки говорить не могу, не знаю.
Справедливости ради, никакого псевдоязыка в ардуино нет. Просто некоторые инклуды вставляются перед компиляцией автоматически (и прототипы функций генерируются), а дальше обычный avr-gcc.
Основная проблема Ардуины — убогая среда разработки, которая только подсвечивает синтаксис и загружает прошивку, но не умеет ни отладку делать, ни простейший рефакторинг. Я уже не говорю про нормальные многофайловые проекты.
Вторая проблема — убогая библиотека, которая прячет слишком много и вызывает привыкание.
Третья — убогие восьмибитные атмеги, с которых ардуина никак не может слезть.
В С++ самом по себе тоже ничего плохого нет, если уметь им пользоваться, код получается чище/проще/строже, чем на чистом С. Отстрелить себе ногу при этом, разумеется, тоже проще.
Внесу свои пять копеек. На мой взгляд, основные проблемы школьного обучения программированию (судя по моему опыту обучения студентов третьего курса на технической специальности) следующие:
— «информатика в ворде и экселе» вместо программирования
— скучнейшие задания и только консольные приложения, не заинтересованные и не умеющие программировать учителя
— в школе как правило не дают навыков отладки программ. Люди привыкают менять код случайным образом в надежде, что он заработает.
— отсутствие понимание алгоритма в принципе.
На мой взгляд, сваливать ООП, многопоточность и GUI в опросе было совершенно неправильно. Я с программированием впервые познакомился в третьем классе, в среде Роботландия, где надо было управлять кукарачей (тараканом).
Это GUI? GUI, не консоль ведь. Разумеется, никакого ООП при этом нет, вы просто пишете «таракан, иди вперед три шага».
Но для детей это гораздо нагляднее, и это дает самые базовые представления о построении алгоритма. Думаю, что сейчас подобных сред вполне достаточно и настаивать на какой-то определенной нет смысла.
В старших классах у меня был С. Честное слово, я не очень люблю С, но мне все же кажется, что учить на нем можно. Его синтаксис позаимствовали очень многие языки, на С все еще пишут продакшн, и в С вполне достаточно мест, где можно отстрелить себе ногу. Да, я считаю, что настоящий программист должен быть готов к этому с детства (но не с начальной школы, разумеется), а не расти в рафинированной виртуальной песочнице.
Я твердо уверен, что учить нужно компилируемым языкам, поэтому выбор между Паскалем и Питоном для меня выбор очень труден. Прямо как в анекдоте про бороду под одеялом или над одеялом.
Спасибо за пояснение. Просто из статьи мне показалось — «замена на настоящее содержимое каждого требуемого файла» — что импортируемый модуль просто копируется в итоговый файл.
И здесь появляется бандлер (bundler). Это инструмент для сборки модулей в единые пакеты, имеющий доступ к файловой системе. Получающиеся пакеты совместимы с браузером, которому не нужен доступ к файловой системе. В нашем случае бандлер нужен для поиска всех выражений require (имеющих ошибочный, с точки зрения браузера, JS-синтаксис) и замены на настоящее содержимое каждого требуемого файла. В финале мы получаем единый JS-файл без выражений require!
Я правильно понимаю, что в JS был, фактически, заново изобретен #include? А как разрешаются кольцевые зависимости?
Нельзя. По историческим причинам. Функции не описанные как constexpr компилятор, в большинстве случаев, в нужном контексте просто не видит (раздельная компиляция, всё такое).
Не могли бы вы объяснить по-подробнее? Почему прям нельзя?
Допустим, не видит компилятор тела функции из библиотеки — ну и ладно, в рантайме вызовем. В конце концов, constexpr не гарантирует выполнения на этапе компиляции.
Другое дело, что время компиляции от этого, скорее всего, сильно выросло бы.
На мой взгляд, минус constexpr в том, что он все равно не гарантирует выполнения на этапе компиляции. Вполне можно было вообще все функции считать constexpr по-умолчанию, а то даже в С++17 много функций из STL не constexpr (в смысле, просто перед ними не приписан constexpr), и их не получается использовать на этапе компиляции.
Преподаю по совместительству пятый год. В силу определенных обстоятельств не ощущаю на себе почти никакого бюрократического давления (помимо того, что расписание очень долго и мучительно согласовывают, но это скорее от пофигизма).
И недостатка студентов последние два года тоже не ощущаю, наоборот, группы стали слишком большими, 30-40 человек на третьем курсе!
Вот невозможность никого отчислить — вот это действительно проблема. Каждый год попадаются люди, которые непонятно как школу закончили, они иногда говорят-то связно с трудом! Но отчислить их практически невозможно, разве что они сами ходить перестают.
Несколько лет назад таких отсеивали еще на первой сессии, а теперь, видимо, перестали.
Зачастую, они еще и на целевом обучении, которое словно специально создано для того, чтобы протаскивать в ВУЗы неспособных к самостоятельному поступлению.
Странно, только что проверил gcc 6.3 — собирает.
Другое дело, что использовать нестандартные расширения языка, на мой взгляд, не лучшее решение. Я обычно просто запихивал такие инициализации в файлы.с.
Я предложил бы вам устроить голосование по поводу названия. Но вообще ему ведь необязательно быть осмысленным, достаточно быть просто красивым и благозвучным. Как «Оберон», например.
Только я было обрадовался выходу LL (учитывая, что SPL больше не поддерживается), как напоролся на баг в функции LL_GPIO_Init для F1. Т.е. даже светодиодом спокойно не помигать.
А багтрекера у STM так и не завелось.
Если от прототредов начинается вывих мозга, то можно использовать обычные конечные автоматы на свитчах. Все честно, понятно, никаких макросов и самообмана.
О цене аналогичных AVR судить не берусь.
Ну только это не проблема языка, это убогая система сборки. Это да, никаких возражений.
Но при этом сам чип армовый может быть и дешевле атмеги. Насчет платы и обвязки говорить не могу, не знаю.
Основная проблема Ардуины — убогая среда разработки, которая только подсвечивает синтаксис и загружает прошивку, но не умеет ни отладку делать, ни простейший рефакторинг. Я уже не говорю про нормальные многофайловые проекты.
Вторая проблема — убогая библиотека, которая прячет слишком много и вызывает привыкание.
Третья — убогие восьмибитные атмеги, с которых ардуина никак не может слезть.
В С++ самом по себе тоже ничего плохого нет, если уметь им пользоваться, код получается чище/проще/строже, чем на чистом С. Отстрелить себе ногу при этом, разумеется, тоже проще.
— «информатика в ворде и экселе» вместо программирования
— скучнейшие задания и только консольные приложения, не заинтересованные и не умеющие программировать учителя
— в школе как правило не дают навыков отладки программ. Люди привыкают менять код случайным образом в надежде, что он заработает.
— отсутствие понимание алгоритма в принципе.
На мой взгляд, сваливать ООП, многопоточность и GUI в опросе было совершенно неправильно. Я с программированием впервые познакомился в третьем классе, в среде Роботландия, где надо было управлять кукарачей (тараканом).
Это GUI? GUI, не консоль ведь. Разумеется, никакого ООП при этом нет, вы просто пишете «таракан, иди вперед три шага».
Но для детей это гораздо нагляднее, и это дает самые базовые представления о построении алгоритма. Думаю, что сейчас подобных сред вполне достаточно и настаивать на какой-то определенной нет смысла.
В старших классах у меня был С. Честное слово, я не очень люблю С, но мне все же кажется, что учить на нем можно. Его синтаксис позаимствовали очень многие языки, на С все еще пишут продакшн, и в С вполне достаточно мест, где можно отстрелить себе ногу. Да, я считаю, что настоящий программист должен быть готов к этому с детства (но не с начальной школы, разумеется), а не расти в рафинированной виртуальной песочнице.
Я твердо уверен, что учить нужно компилируемым языкам, поэтому выбор между Паскалем и Питоном для меня выбор очень труден. Прямо как в анекдоте про бороду под одеялом или над одеялом.
Я правильно понимаю, что в JS был, фактически, заново изобретен #include? А как разрешаются кольцевые зависимости?
Не могли бы вы объяснить по-подробнее? Почему прям нельзя?
Допустим, не видит компилятор тела функции из библиотеки — ну и ладно, в рантайме вызовем. В конце концов, constexpr не гарантирует выполнения на этапе компиляции.
Другое дело, что время компиляции от этого, скорее всего, сильно выросло бы.
И недостатка студентов последние два года тоже не ощущаю, наоборот, группы стали слишком большими, 30-40 человек на третьем курсе!
Вот невозможность никого отчислить — вот это действительно проблема. Каждый год попадаются люди, которые непонятно как школу закончили, они иногда говорят-то связно с трудом! Но отчислить их практически невозможно, разве что они сами ходить перестают.
Несколько лет назад таких отсеивали еще на первой сессии, а теперь, видимо, перестали.
Зачастую, они еще и на целевом обучении, которое словно специально создано для того, чтобы протаскивать в ВУЗы неспособных к самостоятельному поступлению.
Другое дело, что использовать нестандартные расширения языка, на мой взгляд, не лучшее решение. Я обычно просто запихивал такие инициализации в файлы.с.
Господи, дождались!
А багтрекера у STM так и не завелось.
Вот за утилитку спасибо, не знал!
Скажите, а как ваш язык называется-то?
И можно ли из него вызывать метафункции, которые уже написаны на С++?