Ko4egap

Настоятельно рекомендую ext4. Она уже давно стабильна, и можно смело использовать. Работает значительно быстрее ext3

C msp430 будет тяжело. В свое время пытался, msp430gcc регулярно преподносит сюрпризы. Отладка по jtag становится практически невозможной (проблемы с закрытыми библиотеками от TI). Надеюсь что с тех пор были подвижки в лучшую сторону, в частности TI грозился выпустить еще к первому кварталу 2011 года CodeComposer для линукс.

Запахло новым холиваром window vs linux. А так же, в лучших традициях электроникс.ру, топикстартера начинают убеждать что ему совсем не надо то что он спросил.

Ubuntu на данном этапе своего развития вполне юзабельная операционка. Год живу не тужу с ней. Глубоких знаний совсем не требует, нужно только небольшое перестроение мышления после винды, потом все становится на свои места . Если есть желание более глубоко изучать, очень рекомендую видео лекции Михаила Браво (есть на рутрекере). Советую при просмотре тут же пробовать все что рассказывает Михаил в полноценной linux-консоле, и составлять для себя шпаргалку.

Нужный вам файл весит 375 МБ. Вам надо не "DVD image", а "Code Size limited (MSP430 and C28x)". Отличия первого в том что это 30-дневная версия полной студии, вообще для всего (и дсп и контроллеры). А второе - ограниченая по коду версия только для контроллеров. К сведению, после апрув на скачивание действителен в течении 72х часов.

Сам только сегодня утром заполнял форму на свежую фришную версию композера, только что получил мыл с апрувом.

Ну так а в чем проблемма? :) Регистрируетесь, заполняете форму, они ее в течении суток рассматривают, и дают (либо не дают) ссылку на скачивание.

Официальная документация - самая достойная литература

Пользуюсь TI-компилятором полтора года. Кроме неудобства их среды претензий нет. Компилятор в целом неплох. Неудобство среды решил переходом на vim, компилирую прямо из него с помощью scons-скрипта, прямо в нем правлю синтаксические ошибки (vim парсит вывод компилятора и делает переходы к месту ошибки), а в Code Composer занимаюсь только отладкой.

Ростут проффессиональные навыки - должны и рости навыки английского языка (я не беру в рассмотрении случаи когда инженер свободно говорит на языке). Чем выше квалификация, тем сложнее приходиться читать статьи. Нет английского -нет развития. С этим процентом я может быть и погорячился, но это что-то вроде точки входа. С опытом, конечно, это соотношение уменьшается, что больше связано с достижением некоторого уровня в языке, когда читается легко и без проблемм. Грубый пример: специалист вроде бы и хороший, а английским владеет на уровне "Ландон из зе кэпитол оф Грейт Британ", и переменные обзывает с ошибками, или транслитом.

Помнится в самом начале моей проф деятельности, мне было лень читать официальный Users Guide, и я работал с подобной книжкой. Но в один прекрасный момент, после дней 3-4х мучений в поисках почему же не работает железка, так, как мне надо, я посмотрел в оригинал, и заметил одну маленькую, но очень критическую неточность в переводе (давно было я уже не вспомню подробностей). С тех пор НИКОГДА не пользуюсь переводами, и никому не советую покупать такие книги. Во-первых дорого, во-вторых с ошибками. 60% навыков современного эмбеддера составлет английский язык. Если вы не знаете его на уровне, достаточном для чтения доккументации со словарем - грош вам цена.

Такие вещи делаются с помощью конечных автоматов (машина состояний). Выглядит примерно так: static int state = 0; switch(state) { case(0): if(state1_cond) { state=1; /* Kакие-либо действия, корторые необходимо выполнять при переходе * из нулевого состояния в первое */ } break; case(1): if(state0_cond) { state=0; } break; default: /* Что-то пошло не так, надо сбросить всю машину */ state=0; break; } И вообще нечего жалеть память. Чем меньше кода, тем меньше мест где могут появиться ошибки. Чем проще решение тем меньше вероятность ошибиться в его реализации, и меньше сил затрачивается на отладку и дальнейшее сопровождение, и стабильнее результирующий продукт. Машины состояний вообще мощный инструмент, рекомендую ознакомиться c этим

LaTeX давным давно стал стандартом для технической доккументации. В европах в научные журналы статьи принимаются только в LaTeX, или за дополнительную плату преводят из ворда, диссертация - тоже только в LaTeX. Только мы тормозим как всегда.

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