Ну они для этого Ramtron купили, который эту технологию разработал лет 10 назад. Только фича эта достаточно дорогая. Хотя с возможностями TI глядишь допилят до больших серий и мелких техпроцессов.
У меня подобные глюки вылезали в IAR'e. Там нужно было поставить галочку Use flash loader и, соответственно, подсунуть ему загрузчик. Вот тут я рассказывал, как настраивать discovery под IAR.
Рискну написать небольшое замечание. Немного напрягает, если зайти в запись (топик) — её название пишется жирным шрифтом, а на главной странице — обычным. Создается впечатление, что название «скачет»
Спасибо :) Правда, с сервером приходится админом становиться. Вот сейчас — почту пытаюсь запустить. Красноглазым уже стал, осталось только бороду отрастить.
От C++ остается объекты, строгая типизация, перегрузка, namespace (очень люблю их, они хорошо структурируют программу). Полиморфизм совсем мало кушает, особенно на современных процессорах, которые под него заточены.
Я тоже очень не люблю шаблоны в С++ варианте хотябы потому, что они сложны для понимания. Особенно, когда начинаются какие-то фокусы в стиле Александреску.
Вообщем, мы с тобой очень похоже мыслим, эт хорошо :)
Использовать все возможности C++ — это сродни самоубийству
При проектировании я либо опираюсь на каноны ООП либо пишу чисто структурный код. Многие возможности С++ я не использую даже при программировании для ПК (здесь, я разделяю твой поход и придерживаюсь «Google C++ Style Guide»).
Просто, ИМХО, от С++ на МК остается слишком мало. Даже динамический полиморфизм требует накладных расходов (да, не таких уж значительных, но иногда это критично). Да, есть инкапсуляция и наследование – но особого проффита только от них я не вижу без применения ООП в комплексе. Нет иерархии объектов, нет уровней абстракции. ИМХО, действительно получается «суржик». Хотя, безусловно, есть шаблоны. С их помощью можно много чего наворотить. Но я не любитель обобщённого программирования.
Все вышесказанное – это исключительно мое субъективное мнение.
Про споры на ЕЕ не в курсе, но я умею программировать и на Cи и на C++. Как раз, из-за специфики МК я беру лучшее из двух миров и использую стиль «Си с классами» (компилятор, естественно, C++).
Использовать все возможности C++ — это сродни самоубийству. Это очень сложный и неоднозначный язык (хотя, так и не кажется с первого взгляда), именно поэтому софт для Curiosity пишут на Си.
Хм, я так понял, ты в курсе недавних споров не ЕЕ?
Я, честно говоря, редко пишу под МК на «Си с классами». Я привык либо проектировать программу под С++ (со всеми его возможностями), либо проектировать под С. Я, для себя, не вижу особого смысла а применении С++ для МК (это исключительно мое ИМХО). С++ очень мощный инструмент, но специфика МК очень ограничивает его использование. Это что-то типа «вот тебе пряник со вкусной начинкой, но начинку кушать нельзя» :)
Я пользовался встроенным в IAR MIRSA. Круто конечно, но писать очень сложно, он сильно замедляет написание кода. В итоге, отказался. Кроме того я, в основном, пишу на «Си с классами» (то есть на C++, не придерживаясь ОО подхода). Анализаторов, которые глотают такой «суржик» нет, насколько я знаю.
Интересно было узнать о методологии написания кода с таким высоким уровнем надежности. Хотя «штрафы» и «доска почета», ИМХО, смотрятся как-то по-детски :)
А кто-то пробовал использовать статические анализаторы в embedded проектах?
Я как-то попытался прогнать код через статический анализатор (какой-то из open source, точное название уже не вспомню). Он «сходил с ума» от записи и чтения регистров периферии МК замапленных на память. Например, с его точки зрения (и понять его логику можно), запись/чтение в память по произвольному адресу (типа PORTA = 0xFF) – это баг.
Можно, конечно прогонять через анализатор только код «высокого уровня», но это как-то не интересно.
tqfp
...разрабатываем электронику вместе
но при просмотре видео все же ждал когда стример кому нить в голову ударит )))
а так интересно
Я тоже очень не люблю шаблоны в С++ варианте хотябы потому, что они сложны для понимания. Особенно, когда начинаются какие-то фокусы в стиле Александреску.
Вообщем, мы с тобой очень похоже мыслим, эт хорошо :)
Показалось.
При проектировании я либо опираюсь на каноны ООП либо пишу чисто структурный код. Многие возможности С++ я не использую даже при программировании для ПК (здесь, я разделяю твой поход и придерживаюсь «Google C++ Style Guide»).
Просто, ИМХО, от С++ на МК остается слишком мало. Даже динамический полиморфизм требует накладных расходов (да, не таких уж значительных, но иногда это критично). Да, есть инкапсуляция и наследование – но особого проффита только от них я не вижу без применения ООП в комплексе. Нет иерархии объектов, нет уровней абстракции. ИМХО, действительно получается «суржик». Хотя, безусловно, есть шаблоны. С их помощью можно много чего наворотить. Но я не любитель обобщённого программирования.
Все вышесказанное – это исключительно мое субъективное мнение.
Использовать все возможности C++ — это сродни самоубийству. Это очень сложный и неоднозначный язык (хотя, так и не кажется с первого взгляда), именно поэтому софт для Curiosity пишут на Си.
Я, честно говоря, редко пишу под МК на «Си с классами». Я привык либо проектировать программу под С++ (со всеми его возможностями), либо проектировать под С. Я, для себя, не вижу особого смысла а применении С++ для МК (это исключительно мое ИМХО). С++ очень мощный инструмент, но специфика МК очень ограничивает его использование. Это что-то типа «вот тебе пряник со вкусной начинкой, но начинку кушать нельзя» :)
А кто-то пробовал использовать статические анализаторы в embedded проектах?
Я как-то попытался прогнать код через статический анализатор (какой-то из open source, точное название уже не вспомню). Он «сходил с ума» от записи и чтения регистров периферии МК замапленных на память. Например, с его точки зрения (и понять его логику можно), запись/чтение в память по произвольному адресу (типа PORTA = 0xFF) – это баг.
Можно, конечно прогонять через анализатор только код «высокого уровня», но это как-то не интересно.