zhevak

А, простите, какой работодатель? Их OVER9000, кого конкретно Вы имеете ввиду? Не понимаю, причем здесь какой-то гипотетический усредненный работодатель-тоже-капусторуб? За тяп-ляп-быстро-сбацанными проектами как правило тянутся очень длинные шлейфы. И если не стоит цель всех быстро наобувать и раствориться, а стоит цель держаться на рынке долго, то как правило на спешку не ставят. Понято, что проекты нужно делать быстро. И не в ущерб качеству. Но обсуждаемая библиотека не позволяет ни существенно сократить сроки разработки, ни существенно повысить качество. Пока это есть "нечто". Невнятное и нестандартное. Может быть потом оно станет таким же явлением де-факто, как стандартная библиотека С. Но пока я (лично) не вижу преимуществ ее использования. Разве что поучиться как правильно инициализировать порты... Но разве для этого нужно было создавать целую библиотеку? Мне кажется можно было поступить более просто -- опубликовать несколько статей (а точнее -- документов (datasheet, pdf)) на тему, как правильно работать с тем или иным периферийным устройством. Плюс, несколько примеров кода. Это значительно менее затратно. -- Нет! Решили выкатить понты -- подсадить всех на библиотеку. Ну может и сканает. Вон -- огромная масса сидит на Венде и "программирует мышкой". И ничего, живут! И никакой Линух им нафиг не нужен! Потребителю не нужен качественный товар. Потребитель находится в состоянии перманентного шопинга. Ему постоянно нужно менять свой гардероб и мобильники. И если билиотека позволяет привлечь к разработке ПО домохозяек, то такая библиотека найдет спрос у новых-программистов, которые наводнят рынок своими быстро-созданными поделками. Не, нуачё? Копроэкономика же! Ага. Забавно. Но это и проявляется креативность природы человека -- обсуждать то, что интересно в данный момент, а не то что нужно по регламенту. Ну, не трамваи!

Да. Да. Да. В программировании это носит свой термин -- "синтаксический сахар". Библитека от ST -- это точно такой же тоже синтаксический сахар. При всем уважении к ST я рассматриваю коды этой библиотеки только в "учебном" плане. Применять их на практике... не думаю. По крайней мере, я испытываю от этоого какой-то дискомфорт. Такое чувство, что из под ног выбили табуретку, не на что опереться. Или чувствуешь себя в каком-то статусе недо-программиста. Что там (в библиотеке) происходит -- да хрен его знает! Начинаешь залазить, изучать. Теряешь время. А изучив и поняв, приходишь к мысли -- да нафига оно, это универсальное-на-все-случаи-жизни решение нужно! Получается что написать нужный функционал для проекта своими средствами (не прибегая к использованию библиотеки) получается ни чуть не хуже. Использование библиотеки -- это из области религии. Либо ты ей веришь (веруешь, доверяешь), либо нет. Если нет, то юзаешь свои наработки и опираешься на твердую _аппаратную_ почву, а не ватную библиотеку. Для чего создана библиотека? Первая мегацель библиотеки -- сэкономить время дорогого (по стоимости) программиста-разработчика. Библиотека создана для тех программистов, которые не любят углубляться в специфику камня. Библиотека так же создана для тех, кто непрограммисты вообще: сбацал проект - продал. Сбацал - продал. Сбацал - продал. Я не могу назвать их профи. Извините. Это скорее не программисты, это скорее капусторубы какие-то. Их кредо -- толщина "котлеты", а не глубокие знания камней. Ну есть еще один тип программистов, которым библиотека пойдет в пору. Это те, кто пишет очень большие проекты. Ну, о-о-очень большие! (с) Жванецкий. Таким проггерам, действительно, отвлекаться на регистры и биты -- мелко. Если они берут проц под свой проект, то как минимум с 256 килограммами флеша. Не мелочатся. Не когда. Ибо задачи у них реально -- космические. Но я как-то больше сталкиваюсь с программерами, которые пишут свои обычные проги, объем которых несколько единиц-десятков килобайт. И мне есть чему поучится у них. Вторая мегацель -- привлечь к программированию камней как можно больше людей. (Блин, стихами заговорил!) Библиотека снижает уровень вхождения в технологию. Это значит, что в ближайшее время следует ожидать наплыва домохозяек в розовых кофточках и прочих "программистов", которые "программируют мышкой".

Я точно не знаю, но мои предположения такие: Когда нарезаешь круги по пустыне и при этом водишь толпу людей за собой, то неважно куда и зачем прешься. Твоя задача -- израсходовать время чтобы люди забыли старые способы жить. Потом, через какое-то время, ты предложишь свои. Типа точно такие же, но с боку. Но люди уже не будут помнить кто они и откуда. И проблем у тебя не возникнет. Правь дальше! Правда, среди толпы порой находятся отдельные граждане, которым не дает покоя вопрос -- "а нафига это вообще надо?" Они, конечно, немного портят картину, но решающего значения их голос не имеет. Толпа пошумит и забудет. Зато в конечном счете у тебя будет библиотека-посредник, с помощью которой незаметно для потребителя ты сможешь рулить свое железо как тебе заблагорассудится. Типа развязать себе руки, а за одно торжественно объявить о какой-нибудь благородной цели -- например, об унификации. Многие программисты-от-Васика поймут твои цели и поддержат твои идеи. Мне кажется, что проталкиваемая библиотека-посредник, виртуально подменяющая одну суть другой, для настоящего спеца ничего полезного не дает. А для студента, которому влом что-то изучать, -- да, она будет в полный рост. Не, нуачо? -- Напихал в структуру значений, вызывал функцию -- и опа! И уже можно смело заявлять, что ты программист-разработчик. Без сомнений! Прога работает ведь.

Вопрос до конца не ясен. Вы слишком мало дали информации по проблеме. Тем не менее я попробую поддержать дискуссию. 1. Проверка данных может производится как: * по каждой переменной, например, переменная (параметр, установка, уставка и т.д.) укладывается в допустимые пределы. (Пример из электроники -- допустимый ток коллектора транзистора не может превышать 10А). * так и на предмет того, что переменные, находясь каждая в своем диапазоне допустимых значениях, в совокупности тоже не нарушают какие-то правила. (Пример из электроники, Ток коллектора транзистора не превышает 10А, напряжение на коллекторе -- тоже не превышает заданных 60В. Но в совокупности эти два параметра задают рассеиваемую на коллекторе мощность (10А * 60В = 600Вт), которая превышает допустимую мощность транзистора (100Вт)) 2. Опять же из радиотехники. Произвольный или непроизвольный выход параметра за допустимые пределы -- это, в некоторой степени можно считать, что параметр подвергся искажению какой-то помехой. Так вот, согласно радиотехническому правилу, бороться с помехами надо в местах их возникновения, а не по всему свету, где их можно принять. Так будет и легче и дешевле. В контексте вашей проблемы это следует понимать так -- проверять валидность параметров нужно там, где они могут измениться, а не размазывать их проверку по всей программе. 3. Определитесь с тем, откуда ожидаете "приход помехи". Я имею ввиду -- это будет человеческий фактор: 3.1. Оператор, конечный пользователь ввел не то значение 3.2. Программист-разработчик ошибся при инициализации переменной или написал бажный код, который вычисляет параметр не правильно. либо это будет аппартный сбой: 3.3. На вход поступили данные, которые явно не укладываются в заданные рамки. (Например, измеряем напряжение и ожидаем получить от 0 и максимум до +5.5 В, а придурок Вася сунул наш вольтметр в розетку. Ничего не сдохло, но на вход АЦП пришли та-а-акие данные, что непонятно что с ними дальше делать.) 3.4. Через МК прошла космическая частица с высокой энергией и изменила ячейку в памяти. Данные исказились. Рассмотрим по порядку: В первом случае, проверка нужна обязательно. Нужно производить проверки при каждом вводе пользователя. Во втором случае, нужно тоже производить всяческие проверки. Но когда отработка программы закончится, то в release-версии нужно удалить все проверки. Третий случай -- тут проверка нужна обязательно. Причем только в этом месте (бороться с помехой в месте ее возникновения). Четвертый случай особый. Тут одной проверкой не обойтись. Дело в том, что частица может прошить не только ячейку памяти с параметром, но она может пройти через ячейку памяти, где записаны границы допустимых значений параметра. Тогда получится, что при правильных данных, система будет работать не правильно. Значит нужно делать не просто проверку, а делать дублирующую систему. В своих изделиях я руководствуюсь изложенными выше принципами. Но это совсем необязательно, что я поступаю только так, а не иначе. Жизнь очень сложная, и заранее сказать что и как правильно следует делать -- очень сложно. Чтобы советовать что-то дельное, нужно "быть в теме". Форумными наскоками большую сложную проблему вряд-ли можно устранить. В любом случае -- удачи Вам!

Забудьте про 100 г. Вообще. Навсегда. Алкоголь -- это не пищевой продукт, а слабо действующий яд, который при даже небольших дозах все равно разрушает организм хоть и минимально. Зачем это Вам надо? У Вас в жизни проблем нет? Приходится придумывать, изобретать? Задавайте вопросы не тут на форуме, а самому себе. Разгадывать Ваши шарады наверно кому-то и будет интересно, но ядреные специалисты вряд ли будут вестись на Ваши "кроссворды", у них своих дел выше крыши. Они, конечно, помогут Вам, но при условии -- максимально предоставленная информация с Вашей стороны.А пока от Вас исходят одни только эмоции. Загадки угадывать -- не интересно. Интересно исследовать. Как самому бороться с проблемой? -- Копать. Копать глубже. Не происходит инициализация чего-то там к указанному сроку? Хорошо! Почему не происходит? Кто эту инициализацию осуществляет? Что является критерием правильно инициализации? Как проверить? Достаточно-ли просто для этого повесить на свободную гогу ЛЭД и зажечь его или нужно "вывести наружу" целый блок информации? Думайте, стройте предположения, проверяйте. Запаяйте два ЛЭДа. Выводите на них разные данный из разных частей программы. Откуда нам знать, что там у Вас твориться? Играть в угадайку -- неблагодарное занятие. Жизнь и без этих Что-Где-Куда быстро проходит. Уважайте тех, кто может Вам помочь. Не пытайтесь захомутать в свою игру. Либо мы работаем, и помогаем друг другу решать проблемы, либо мы балаганим. Я очень надеюсь, что Вы не обидитесь на мои нравоучения, а сделаете правильный вывод. Пожалуйста, добавьте серьезности и у Вас все начнет получаться. Итак. С чего начнем?

Я кажется знаю как нужно было топик стартеру задать вопрос. И я кажется знаю, что он хочет услышать. AVR имеют по нескольку выводов питания и по нескольку выводов земли. Сделано это не с целью -- "выберите любой удобный", а с целью "задействуйте все выводы" и на на каждой паре (соседние выводы земля-питание) установите конденсатор. Делая так, вы избавляетесь от потусторонних глюков. Это ж давно известно, что какой корпус ни возьми, всегда хочется иметь выводов портов побольше, а земли и питания -- желательно по одному. Однако, наши хотелки вступают в противоречие с реально большими проблемами, которые хоть как-то решаются большой кровью -- приходится жертвовать ногами и отдавать их под дополнительные выводы питания и земли.

Тоеретически это так. (Точнее было так, сейчас уже не так.) Но практически -- я сужу по себе и тем, кого я знаю, -- очень-очень редко проц используется на максимальной частоте. Там и энергопотребление, и тепло, и помехи, и прочий букет проблем имеют совсем другие цифры. Зачем так мучить скотину? Мне кажется, что когда в задаче нужна числодробилка по-мощнее следует брать АРМ9 или АРМ11. Не-е, конечно, можно сейчас придумать и натеоретизировать и оправдать необходимость большой скорости... но реально, пацаны, кто из вас РЕАЛЬНО и ПОСТОЯННО (из проекта в проект) использует проц на максимальной частоте? Только честно, да? Наверно этот показатель сегодня не очень актуален -- 72 или 100 МГц. Писькомеряние все это! Практической ценности в том, что проц бегает в полтора раза быстрее, нет никакого. Нужна скорость -- ну так возьми другой проц. Не гоняйся за 10% скорости, не наступай себе на горло. Как-то так мне кажется.

Я в теме не "глубоко". Но на протяжении последнего времени тоже занимался вопросом -- кому отдать предпочтение. В начале этого года сориентировался на LPC, так как он мне по совокупности параметров больше понравился. Да и работал я до этого с LPC2xxx, а STM для меня -- еще темная лошадка. А в Августе я уж сменил ориентацию на STM32F. Убеждающими факторами послужили: 1. Взрывной рост номенклатуры процов. Если сравнить с номенклатурой от NXP, то раза 3-5 больше всяких тварей. 2. Сравнил годовой доход (revenue): у STMicroelectronics он примерно в два раза больше, чем у NXP. 3. Где-то прочитал, что инвесторы, который вложили бабки в NXP, разочаровались в доходности этого бизнеса и потихоньку вынимают их обратно. Т.е. бизнес у NXP какбы оберечен "болеть и чахнуть". (Частично это прекликается с п.1 -- зоопарк процов не впечатляет. Выбор не очень.) 4. Пошерстил форумы и пришел к выводу, что STM32 -- это "народный" проц. Но него больше подсело народа и соответственно, он какбы больше изучен. Следовательно, при попадании на непонятки быстрее можно найти ответ. 5. Ну и не мало важный параметр -- реальная доступность. На бумаге можно хоть что написать. А ты приди в магазин и купи, если получится. В общем, советовать я ничего не буду. Решайте сам. Я честно сказал свою ситуацию. И отдавайте себе отчет в том, что через какое-то время для следующей поделки Вы возмете немного другой проц. Пересеть с одного STM32 на другой, или с одного LPC на другой -- легко, но с STM32 на LPC или наоборот -- сложнее. Поэтому нужно выбирать не сам проц, а скорее производителя процов. Учитывая то обстоятельство, что STM32 и LPC очень сильно пересекаются, то выбор не такой уж напряжный. К стати, согласно п.1 у ST выбор будет побогаче. Надеюсь, я помог увидеть некоторые моменты.

А это совсем не важно -- умеете Вы или нет. Важно -- хотите ли Вы научиться. Ваша жизнь не просто точка по пространстве. Ваша жизнь -- это движущаяся точка. Не важно, где Вы сейчас находитесь. Важно -- в каком направлении Вы двигаетесь. Все мы люди. И все разные. Кто-то делает на совесть, а кто-то абы-как. Кто-то пишет картины, а кто-то красит заборы. Э-э... стоп-стоп-стоп! Я немного не понял. Мы говорим о проблемах несанкционированного изменения данных в EEPROM. Это, как мы знаем, происходят в моменты включения/выключения питания. Мы так же предполагаем, что программа написана правильно и не выполняет неожиданных действий. Иначе говоря, мы абсолютно понимаем как работает наша программа. Но, если нас беспокоят проблемы включения/выключения питания, то тогда причем здесь RAM? При выключении питания информация в RAM полностью теряется. Да ну! Что за фигня? Если Вы не изменяете флешь, то это граничит с паранойей. Так никто не делает. Что за аппарат такой Вы изобретаете, где требуется такая сверх-надежность? Я лично с проблемами EEPROM не сталкивался. Может везло :( ... хз. 1. Создайте переменную в EEPROM, которую читаете. Ее значение не принимает участия в программе. Проследите, чтобы компилятор не "соптимизировал" код. 2. Тупо записывайте в регистр EEAR адрес неиспользуемой ячейки. Для этого дела как нельзя к стати подходит байт с адресом ноль.

Что-то мне не нравится это определение -- "порча". Возникают какие-то нездоровые ассоциации со сглазом, с гаданием на кофе, с П.Глобой, со звездами, со святой водой и т.д. Какой-то ненаучный термин -- "порча". Наверно лучше говорить о потере информации или искажении данных. Но это так, потрындеть... Вам, в общем-то, правильно сказали, что если питание МК выполнено правильно и программа работает без побочных эффектов (то есть вы умеете писать робастые программы -- стеки не переполняются, код одной функции не искажает данные другой), то ни нет никакой разницы, где вам хранить -- в RAM, EEPROM или во внешнем EEPROM. Если у вас питание выполнено по принципу "тяп-ляп", если вы начинающий программер и пишите корявый код, то нет никакой гарантии, что ваши данные не будут случайно изменены. По проблеме случайных изменений данных в EEPROM погуглите ради интереса, найдете много чего полезного. Несколько лет назад эта тема была очень обсуждаема в интернете. В спорах действительно было сломано много копий. Что же конкретно делать? В основном советы сводятся к тому, что в схему нужно добавлять супервизор, если у вас затянутые фронты питающего напряжения (Vcc при включении/выключении медленно нарастает/спадает), и после операции с EEPROM устанавливайте в регистре EEAR адрес ячейки, которая не используется.

Абсолютно с Вами согласен, но с одной оговоркой! Сам по себе язык С от архитектуры вообще не зависит. Однако, от нее зависит набор тех или иных библиотек. Стандартная библиотека С -- сильно зависит от архитектуры. (Я не захотел делать на этом акцент. Думал, что люди отличают сам язык от его библиотек. А зря наверно!) Как я уже говорил, эта библиотека разрабатывалась применительно к Фон-Неймановской архитектуре. По прошествию нескольких десятков лет с момента появления языка С и его стандартных библиотек (подчеркиваю!) в мире появилось очень много разных архитектур. В том числе и AVR архитектура. Поскольку стандартные библиотеки С не заточены для работы с Гарвардской архитектурой, то программистам (разработчикам компиляторов) пришлось писать библиотеки функций для работы с флеш-памятью. Теперь, я надеюсь, между нами нет недопонимания :) CodeVision изначально развивался по своему сценарию и всегда клал болт на стандарты С. Не берусь судить -- хорошо-ли это, плохо ли. Но одно могу сказать -- для новичков он подходит как нельзя лучше. А то, что люди работают с этим (не отвечающим стандартам) компилятором и потом, когда вырастают из этих "коротких штанишек", начинают воспринимать реальные стандарты как отклонение от своего "стандарта CV" -- это так, побочный эффект. Это как с утками -- что первое увидел, которое движется, -- то и мама.

Проблема в том, что Си изначально писался для Фон-Неймановских архитектур, у которых единое адресное пространство для данных и для команд процессора. AVR -же имеет Гарвардскую архитектуру с тремя разными пространствами (RAM, flash, EEPROM). Поэтому, когда Вы используете стандартную (из стандартной библиотеки Си) функцию, например sprintf, и передаете ей в качестве аргументов адреса строк, то функция предполагает, что работает с пространством RAM. Иначе говоря, Ваши строки "Socket type=%p", "TCP" и "UDP" должны располагаться в RAM. Туда они могут попасть только в двух случаях: 1. Автоматически. Такое имеет место быть, когда Вы понятия не имеет о предмете и тупо их прописываете в своей программе(то есть не указываете модификаторы __flash или PROGMEM, в зависимости от компилятора (IAR или gcc)). Так делают все начинающие. У каждого Си-шного проекта по умолчанию имеется файл начальной загрузки или startup-файл. Называется он по разному. Одной из множества его задач является как раз перенос вот таких строк из flash в RAM. Этот способ программирования удобен тем, что не надо думать вообще на эту тему. Недостаток способа -- повышенный расход RAM. Так можно делать, когда у вас проект небольшой, и строковых переменных немного. Перед тем как передать управление в вашу функцию main() загрузчик из всех разом перенесет в RAM. Понятно, что при этом придется отрезать для них нехилый кусок RAM и забыть про него. 2. Ручками. Каждый раз, когда Вам требуется строковая (или любая другая) переменная, которую вы прописали во flash, вы в функции, где она используется, ручками переносите ее в RAM. После того как функция отработает и переменная будет не нужна. Соответствующий объем RAM, временно занимаемый под эту переменную, снова станет доступен для размещения других переменных в других функциях. Иначе говоря, Вы используете RAM по мере необходимости. Вы контролируете процесс. Это и есть преимущество этого метода. Недостаток -- больше возни с исходным кодом, больше заботы, больше нужно уделить внимания техническим деталям -- как это сделать, а не бизнес-задаче, ради которой создавался проект, повышенный расход flash. Когда Вы пишите проект с LCD и меню на какой-нибудь Меге-16, у которой 16 кБ flash и всего 1 кБ RAM, то иногда выгоднее "помучатся", чем вешать дополнительный корпус внешней памяти или устанавливать другой проц, у которого оперативы побольше. Это кому что нравится -- есть профи и есть быдлокодеры. И те, и другие успешно зарабатывают себе на хлеб с икрой. Вот тут я написал, как работать "ручкам" -- http://forum.e-lug.ru/viewtopic.php?id=484 . Описание идет в контексте gcc, но IAR придерживается этих же принципов, поэтому Вы можете смело переносить рекомендации в свой IAR-вский проект. Конечно, Вам придется вместо PROGMEM писать __flash, и ставить модификатор не в конце определения, а в начале. Но принцип работы со строковыми переменными, которые находятся в flash одни и те же. Даже include-файл называется аналогично -- pgmspace.h Главное понять сам принцип, по ходу сориентируетесь сами. Если что -- форумы рулят. Удачи!

Ситуацию понял. Но по сути вопроса мне сказать ничего, поэтому прошу прощения за оффтоп. Перфекционизм -- это плохо. Иногда нужно просто решать задачу. Любым способом. Решить ее и двигаться дальше. Но когда насущная задача в подсознании подменяется задачей "красиво" решить, то имеется нехилая вероятность зависнуть на ней и потерять кучу времени. А потом, наверстывая упущенное, наговнокодить. Единственный совет наверно может быть такой -- не бойтесь написать говнокод. Вы ведь знаете, что это есть говонокод -- а это главное. Конечно, по возможности нужно избегать такой практики, но жизнь есть жизнь и не всегда получается срать красиво. (Простите и меня за мой хранцузский). Не надо бояться говокода там, где он не влияет на конечный результат. Что касается меня, то я обычно в таких случая ставлю в своих исходниках предупреждающие значки типа // TODO: Причеши бабушкин код или // TODO: Не забудь убрать за собой свои засранки или // TODO: Проблема решена с помощью тупого быдлокода. Потом, когда появляется свободное время можно будет и поупражняться в перфекционизме. Программисты -- они всё еще в душе художники. Но программирование -- уже давно не искусство, а ремесло. Соблюдайте баланс между искусством и ремеслом в своей работе и не позволяйте ситуации управлять вами!

Да. Все правильно. Либо закрываете от чтения извне и FLASH, и EEPROM, либо ничего. Иных вариантов нет. В Вашем случае Вам нужно будет "навесить" внешнюю EEPROM или предусмотреть в самой Меге серисный режим для передачи данных из внутренней EEPROM во внешний мир по какому-нибудь интерфейсу -- например, через RS232. Встречный вопрос: а зачем Вам нужно считывать из внутренней EEPROM информацию, охраняя при этом коды во FLASH? Кто будет выполнять эту операцию? Это человек будет извлекать МК из устройства и вставлять в программатор? Или подключать программатор к устройству? У этого человека есть программатор? Он умеет им пользоваться (Программатор + комповое ПО + знания МК и т.д.)? Может проще установить в Вашем устройстве EEPROM с интерфейсом SPI? Например, AT25256. И тогда ISP-программатором считывать сразу из микросхемы памяти?

alx2 -- спасибо за ссылки. Я их видел. Давненько правда, полгода-год назад, когда собирал тулчейн для АРМ-ов... Сейчас еще раз заглянул. Ну да, можно загрузить бинутилс, сконфигурировать его на MSP430, собрать и установить. Только этот путь мне кажется несколько более длинным, чем установка ассемблера Михаила Кона. Он, конечно, он более академический, чем самопальный ассемблер какого-то Мишки из Сент-Луиса... но... но... Мне надо-то -- всего-то отассемблировать файл в 200 строк, и получить на выходе HEX. Установить Мишкин ассемблер и откомпилировать, получилось быстрее и проще, чем продираться через gas. У меня всего несколько проектов на ассемблере MSP430. ("Проектов" -- в смысле, в контексте среды разработки.) Они отличаются друг от друга незначительно, так как предназначены для разных модификаций конечного изделия. Да и не развиваются они совсем. И перспективы, что замутим новое изделие снова на MSP430, как-то тоже нет. В общем, решил я задачу пока по-рабоче-крестьянски. Мне надо было слезть с Венды и IAR-а. Я слез -- а это главное! Теперь можно и академически подумать, ну в смысле поиграться с gas. Попробуйте нагуглить "msp430 assembler", и Вы увидите, что gnu assembler даже на первой странице. Наверно это меня и увело от gas для gnu. А за ссылки еще раз спасибо! Реально помогли. Просто почему-то глаз упорно за них не хотел цепляться.

Да мне, собственно, безразницы, что там в промежутке с кодом происходит. Я не смог найди, информацию по ассемблерным директивам для MSP430. Или хотя бы какой-нибудь проектик для примера. Промаялся я так пару дней, а потом вдруг наскочил на сайт Михайло Кона. Загрузил, собрал, установил, попробовал -- и все сразу же получилось. Делов-то -- всего на 15 минут! Может где-то дока есть какая? Что-нибудь бы почитать. Желание разобраться с gcc, как на нем писать чистые ассемблерные проекты, конечно, есть.

Потому что у них другой формат, потому что в них много "мусора", потому что они большие и длинные -- сложно сразу схватить что там понаписано и для чего. Да, много причин... msp430-gcc -- относительно большая сложная система, которая поддерживает много-много-многофайловые проекты. Такая мощь не нужна. Тем более, лично я не смог продраться через чисто ассемблерные проекты. Я не смог легко создать ассемблерный проект и получить код, как я это бы сделал в том же IAR-е. Мне нужно просто, на коленке, написать исходник из сотни-другой ассеблерных команд и откомпилировать его сразу в HEX, ни с чем больше не линкуя. Ну может я должен сказать так, чтобы точнее донести свою мысль -- мне не нужен квантовый молоток с регулируемой силой удара и лазерным наведением чтобы забить гвоздь в сельском сортире. Сколько людей, столько и мнений. Спасибо за Ваше мнение. Ответ подсказал Хабр: Вам должно нравиться то, что вы делаете, иначе вы зря тратите свое время. Не решение. IAR сам по себе тяжел. И если мне нужно работать с большими проектами, я использую msp430-gcc, который такой же тяжелый. Но мне нужен легкий и простой инструмент. В общем то, инструмент уже есть и работает. Его нужно только "насытить" заголовочными файлами. Мне не удалось это сделать легко и просто. С-шные проекты на нем стругать -- это, да. Без вопросов. Легко и просто. Как в IAR-е. Но проекты из одного файла и сразу в HEX -- у меня почему-то не получается. Спасибо за Ваше мнение!

По жизни часто бывает так, что нужно создать сверхмалопотребляющий девайсик с потреблением несколько единиц-десятков микроампер. (А не поднять средней тяжести проект с потреблением в несколько миллиампер и более.) В таких случаях я беру MSP430, а софт стугаю на асме. Си в таких микро-проектах явно избыточен. До этого момента я делал все в IAR-е под Вендой, так как он, в отличие от msp430-gcc, позволяет легко создавать небольшие асмовские проекты. Но это крайне неудобно. Мне хотелось бы пилить свои проекты под Линем. Поэтому, я присоседился к naken430asm-у. Он работает нормально. Точнее, там не работать нечему! Однако у naken-а есть небольшая проблемка. Состоит она в том, что он почти голый. В нем имеются описания всего лишь трех или четырех процов. (Как раз тех, которые мне не нужны!) Поэтому я сразу же написал файлик для своего проца. А пока писал, понял, что автор делает не совсем правильно. Нужно было систему .inc-файлов разбить на модули, а потом из этих модулей набирать конфигурацию для конкретных процов. Я переделал эту систему .inc-фалов на новый лад и получил положительный результат. Теперь надо ее продолжать развивать. Примерно половину работы по модулям я уже сделал. Надо описать еще недостающих 5-7 модулей типа ЦАП и АЦП. И надо написать .inc-файлы для других моделей MSP430, на основе этих модулей. Ну и желательно поиграться, проверить в на реальном железе. Нужна помощь сообщества в наборе этих файлов. Нужна помощь экспертов, хорошо знающих MSP430. Подскажите, что делать?

Да. Спасибо. Только мне кажется, что я это тоже видел и пробовал. Мне сейчас сложно сказать, что я тогда делал. Возможно, где-то и накосячил. Сейчас проверить нечем. Вполне может быть, что тогда меня не устроило, что прерывания возникают по любому перепаду -- нужно экономить питалово, а проц генерит два прерывания на один импульс. Не помню я. А за поправки -- огромное спасибо!

Я тоже так думал, пока не попробовал. Мне не удалось вывести МК из PowerDown (при отключенном тактировании портов CLK_io) по PCIx. Только через INT0 или INT1. В документации об этом явно не сказано. Поэтому создается ложное впечатление, что не смотря на отключение тактировниа, возможны прерывания INTx, следовательно, возможны и прерывания PCIx. Но это не так! У них разные механизмы. Попадалово для тех, кто не знает.

Ага, можно много чего сделать не так у ТС. Только это ТС определяет сам, что и как ему делать. Что непонятно, он задает вопросы. Нам-то какой резон делать все за ТС? Лезть к нему без спроса в огород и тыкать его носом, что у него грядки не перпендикулярны. Попросит помощь -- поможем. Нет, значит сам справляется. Получает свой личный ценный опыт.

В 2008 году я выбирал проц, на базе которого нужно было создать одно малопотребляющее устройство. На тот момент я уже много работал с AVR, а MSP430 почти не знал. Мне было бы проще, быстрее и дешевле создать девайс на базе AVR. Но я решил проверить и и тот, и другой проц. Я взял TINY48P и MSP430F2001. Немножко не эквивалент, но мне не нужно было много памяти. (Устройство крайне простое.) Сейчас уже точно не помню, но при напряжении 3.3 В AVR потреблял тока примерно на 20-50% больше, чем MSP430 при примерно одинаковых тактовых частотах (1 МГц и 1.1 МГц соответственно). Про снижении Vcc до 2 В микроконтроллеры потребляли примерно одинаковый ток. Но при дальнейшем снижении, MSP430 начинал проигрывать AVR-ке. Потребление измерялось в активном режиме МК, т.е. никакие режимы снижения мощности не включались. Казалось бы -- ага! Но следует заметить, что при напряжении даже 3.3 В у меня возникали проблемы с открытием полевых транзисторов (2N7002). А при питании 2 В, задача вообще не решалась -- транзисторы работали в активной области, что недопустимо для ключей. Мало того, при максимальном энергосбережении -- PowerDown для AVR и LPM4 для MSP430 -- AVR нельзя разбудить перепадом напряжения на ножке порта. Т.е. тактирование периферии отключать нельзя. С другой стороны, MSP430 просыпался по заданному перепаду на любой ноге. Поэтому, мне пришлось отказаться от AVR и принять решение в пользу MSP430. Спать можно по разному. Можно уснуть и не проснуться. Все зависит от задачи. В моем случае MSP430 по совокупности параметров выиграл. Хотя мне лично удобнее было бы работать с AVR. Просто я с ними работал несоизмеримо дольше и намного лучше их знаю. Если бы не жесткие требования энергопотребления, то выбор был бы однозначно за AVR.

Я имел ввиду не диодное переключение, а то, что процессор программно переключит свои режимы.

Да, уж... Схема хороша, когда нужно динамически в процессе работы изменять порог. А если порог задается в процессе разработки схемы (как это обычно бывает -- раз и навсегда), а во время работы девайса не меняется, то есть же пара внешних резисторов! Их все равно что так, что так устанавливать. Задали этими резисторами порог, и успокоились. Зачем "дергать" переключатель встроенной в МК колбасы из резисторов? Такое ощущение, что проблема, ради которой такое чудо-компараьор изобрели, надумана, высосана из пальца. Может быть она и встречается где-то в жизни, но крайне редко. Во всяком случае, это не наш случай. Коллеги, поправьте, если я ошибаюсь.

У Вас совершенно другой МК! Нельзя проводить эту аналогию! Переключение на батарейное питание займет несколько микросекунд. Это вообще капля в море! Вас поджидает еще одна проблема. Как Вы планируете узнавать, что питание восстановилось? Для этого МК у Вас должен периодически просыпаться. Если Вы его загоните в PowerDown (самый экономичный режим), то способов разбудить его у будет очень немного. А еще лучше взять напряжение до стабилизатора. И выбрать его уровень равный значению, когда напряжение питающей сети минимально, а потребление схемы максимально. Тогда, у Вас будет еще дополнительное время, после того, как пропадет сеть -- пока конденсаторы на входе стабилизатора разрядятся до напряжения, когда стабилизатор уже не сможет выдавать нужные 5В на своем выходе!