zhevak

Программы, в отличие от автомобилей, не гниют и не бьются на дорогах. Восстановить порушенную программу намного легче, чем железного друга. Современный автомобиль -- это уже не столько средство свободного перемещения в пространстве, сколько средство самовыражения владельца. По мощности движка складывается мнение о чуваке. Да, автомобиль нужен как средство для повышения своего рейтинга в обществе. Поэтому, марка автомобиля очень важна. Поэтому вы уже не сядете за руль какой-нибудь ТАЗ-2105, вам обязательно нужен X-Lancer. "Скажи мне какой у тебя мустанг, и я скажу кто ты". Мы приняли эти правила игры, продиктованные автомобильными концернами. Мы подвержены влиянию моды. Но как я уже говорил, автомобили не только стареют морально, но и изнашиваются физически. Поэтому авто-гиганты не особенно утруждают себя проталкиванием своей продукции. Не-е, конечно, они ее проталкивают. Но это скорее конкурентная борьба между собой за кошельки потребителей. Однако, вернемся к программному обеспечению. Что принципиально изменилось в специфике разработки программ для микроконтроллеров за последние 5-10 лет? Практически -- ничего! Объемы программ как были от нескольких сотен байт и до нескольких десятков килобайт, так и остались! Вот это и вызывает удивление -- чтобы создать и отладить программу на 1-2 килобайта требуется установить на комп ПО размером под гигабайт. Я подчеркну это -- требуется установить ПО, размер которого превышает создаваемый продукт ни много, ни мало в миллиард раз! Вдумайтесь в цифру -- миллиард! Если 10-15 лет для назад для разработки программы для МК с лихвой хватало компа с объемом 64 или 256 МБ и быстродействием 500-700 МГц, то сегодня примерно для тех же МК требуется во много раз большие ресурсы компа. Дак кто кому мозги пудрит и с какой целью? Ответ очевиден -- программы не "гниют". Чтобы продавать очередную версию, нужно искусственно состарить предыдущую. Что бы продать Висту или Семерку, нужно искусственно состарить ХРюшку. Что-нибудь принципиально изменилось в Висте-Семерке-Восьмерке по отношению к ХП? О-о, да, изменилось! Изменилась система драйверов и политика учетных записей. Теперь над учетной записью "администратор" (которой, по сути, является пользователь компа) появилась учетная запись с демократическим названием -- "установка и подновление". Правами этой учетной записи исключительно принадлежат только одной компании из Рэмонда, которая, в общем-то, управляет вашим компом через интернет. Кому принадлежит комп? -- А тому, у кого максимальные права. Всё -- комп уже не ваш, ребята! Железо -- ваше. Можете делать с ним, что хотите. А комп в целом -- как весь комплекс ПО работающего на железе и приносящего вполне ощутимую пользу -- комп уже не ваш. Вы можете делать на нем только то,все, что вам позволит одна довольно-таки известная зарубежная фабрика. Да, нам продают каждый раз новую версию "автомобиля", оборудованного такими прибамбасами, которые выглядят очень круто. Но на способность "автомобиля" доставить нас в заданную точку планеты, они никакого влияния не оказывают. Печальнее всего осознавать то, что эти прибамбасы каждый раз делают "автомобиль" все тяжелее и тяжелее. Не пора ли задуматься, а так ли уж необходимы в автомобиле кофеварка, набор сковородок, тазик для мытья ног и прочие елочные украшения? А что бы ответить на это вопрос, нужно задуматься о назначении автомобиля (компа) -- для чего он нужен? Одно дело -- решать конкретные задачи (доставлять нас и наши грузы на место), и другое -- красиво тусоваться в обществе (у меня все в аужре! Я программирую мышкой! Думать вообще ни о чем не надо!) Так, вам нужно доехать до места, или вам нужно произвести впечатление на окружающих, сидя на богатом диване. Может быть ложа Большого Театра будет более разумным ходом для достижения вашей цели? Тем более, ни у кого нет ни времени, ни желания закапываться в детали и изучать что-то. Ведь хочется получать результат быстро и с минимальными затратами собственных усилий. Хочется программировать мышкой, а не тупить в консоли. to Серокой: Конечно, это не нормально. Я не знаю, что там у Вас на компе установлено. Возможно Вы установили очень тяжелую среду разработки типа Eclipse. Попробуйте работать без нее. По большому счету для успешной работы вам нужно только 1) обычный текстовый редактор (например, я использую gedit) 2) компилятор gcc и тулчейн к нему 3) обычное ПО программатора (я пользуюсь avrdude) Вне зависимости от размера проекта я Вам советую в директории проекта иметь Makefile, в котором Вы можете делать специфические пометки для себя (по другому -- комментарии) и который поможет автоматизировать Вашу работу. Не бойтесь начать. Пусть он будет у Вас по началу очень аскетичный. Но по мере Ваше деятельности, он будет у Вас "путешествовать" от проекта к проекту, улучшаясь и обрастая сервисами. В конце концов Вы создадите идеальный для себя любимого инструмент. И второй момент. Когда Ваш проект будет достаточно большим и Вам понадобится отладка, то не пожалейте своего времени на изучение avr-gdb. Я не знаю Вашей специфики, но я искренне желаю Вам правильного выбора инструмента для работы! Ссылок на свои публикации не даю (здесь за это наказывают), но если что гуглите по слову zhevak и gcc или avr.

Идея понятна. Публикуйте схему, уточняйте детали. Желающих написать софт будет много. Особенно за оплату. Я в этом более чем уверен. Модераторам: наверно нужно перенести тему, например, в раздел "Работа" или "Ищу исполнителя"?

Вы не правильно поняли. То, что Вы написали #define LED 0x01 // P1.0 #define Led_1 0x02 // P1.1 #define TXD 0x20 // TXD on P1.5 это всего лишь определение названий битов _без_привязки_к_портам. Допустим, у меня висят два ЛЭД-а разного цвета на разных портах, и оба на последнем -- седьмом бите: один на P1.7, другой на -- P2.7. Тогда я пишу: // Биты определения порта P1 #define LED_R 0x80 ... // Биты определения порта P2 #define LED_G 0x80 Как можно видеть, коды совпадают. Но я-то знаю, что красный ЛЭД подключен к первому порту, по этому я буду писать (1): P1OUT |= LED_R; Но компилятор скушает и даже не поперхнется и такой код (2): P1OUT |= LED_G; и такой (3): P2OUT |= LED_R; Разница только в том, что в первом случае (1) логически будет правильный. Во втором случае, исходный код будет неправильный, но откомпилированный будет точно такой же, как и в случае (1). В третьем случае, мы не замечаем, что у нас перепутан порт, и хотим зажечь красный ЛЭД. Только на реальном железе можно обнаружить такую путаницу. Но я думаю, что Вы достаточно внимательны при написании кодов чтобы видеть такие описки. Но если Вам нужно знать коды других битов, то это просто: бит_0 -- это 0x01 бит_1 -- это 0x02 бит_2 -- это 0x04 бит_3 -- это 0x08 бит_4 -- это 0x10 бит_5 -- это 0x20 бит_6 -- это 0x40 бит_7 -- это 0x80 Возможно я неправильно ответил на ваш вопрос, но тогда уточняйте, что Вы хотели спросить в отличие от того, что спросили.

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

Я знаю, что это наглый офф-топ. Просто наболело. К несчастью, это так. Самое поганое то, что они даже не понимают, что тут не так. Хомячки ставят себе не комп Линукс и хотят от него точно такого же поведения как это было у них в Виндовсе. Ну, разве что только название ОСи и копирайт будут другие. А так им нужно чтобы все было один-в-один, иначе Линукс -- УГ. Потом они ставят про-вендовый софт и начинаю требовать от него возможности тонкой настройки под себя. Да, как бы Виндовс и не предназначен для глубокого копания в нем. Юзай, что купил. Виндовс предназначен для офисных работников, не отягощенных желанием разбираться "что там под капотом". Метяфора Виндовс состоит в том, что оно (Виндовс) -- это как автомобиль для розовых кофточек -- вот дырка для бензина, вот руль, а вот две педальки. А там за углом сервичсная служба. Вот телефон, звоните, если что. С вас 1000 рэ и счастливого пути! Если хотите контролировать комп -- меняйте платформу. Там тоже есть жизнь. Если претит религия или нет желания изучать другой мир, то наверно стоит смириться с тем, что дают (чем "кормят"). Смириться с положением, что за вас уже подумали и никуда не надо лезьть ручками. На вас работает целая индустрия, задача которой -- отрубить вас от знаний двигателя, оставить вам только -- крутить руль, жать на педальки, да вовремя заезжать на СТО. Не ваше это все -- тонкая настройка двигла и IDE. Вы платите деньги, чтобы не знать как это делать. Хотя, если ты украл... Все равно, как-то все не разумно.

1. Вы в каком городе живете? Может быстрее получится встретиться и порешать Вашу проблему живьем, а через тырнет? 2. Надумаете портить 2313 -- делайте по шагам. Начните с того, что попытайтесь читать пустой МК (флешь, еепром). Считайте фьюзы. Запишите. Потом попробуйте просто стереть флешь. Еще раз считайте. Убедитесь, что МК не захлопнулся. Ну и т.д. Думаю, идею Вы уловили. И, наверно, самое главное -- не переживайте, что Вы возможно приобрели дохлый программатор или Вам попались некондиционные МК. Во первых, это еще ничего не доказано. А, во вторых, что бы Вы сейчас ни делали, Вы получаете опыт работы с МК. Вы ради этого (ради получения опыта) и занялись этой работой? Чудес не бывает. Рано или поздно, Вы добьете эту проблему и получите колоссальный опыт, какого может не оказаться у тех, у кого все прошло гладко. И в следующий раз Вы уже будет знать эти грабли, а они (те, у кого все тип-топ) будут терять время на борьбу с проблемой. Так что все ОК. Главное -- не сдаваться! Все так. Только установите еще конденсатор на 0.1 мкФ параллельно питанию (ножки 10-я и 20-я). Можно еще попробовать подтянуть сброс (ножка 1) к питанию резистором в 100 кОм и установить конденсатор 10-47 пФ с нее на общий провод. Он замкнет возможные ВЧ "иголки". Питание обязательно проверьте. Вы нам про него ничего не сказали -- откуда берете? Не знаю чем, я бы сунулся осциллографом. На худой конец тестером. Можно воткнуть параллельно питанию маленький электролитический конденсатор 10-47 мкФ. (Большой не надо.) У "магазинских" АВР-ок (то есть с заводскими установками) ядро получает тактовую частоту с внутреннего RC-генератора. Поэтому жесткой необходимости сразу подключать кварц -- нет. Это уж если Вы переустановите фьюзы на внешний кварцевый резонатор, то тогда -- да, надо будет его подключить.

Очень походит на несоответствие форматов файлов с кодами для заливки. Я не знаю SianaProg. Я использую avrdude и тот из-под Линуха. Компиляцию выполняю с помощью avr-gcc, на выходе получаю файл в формате elf. Затем перегоняю из него машинные коды для заливки с помощью avr-objcopy и сохраняю их в файле hex-формата. И наконец, полученный hex-файл скармливаю avrdude-у. Но, на сколько я помню, в CodeVision (ver.1.25.8) был встроенный модуль, который позволял прошивать МК не выходя из среды программирования. Почему Вы не пользуетесь этой возможностью? Я не помню, какой выходной формат файлов у CodeVision. Вполне может оказаться так, что он будет несовместим с форматом-по-умолчанию, принятым в avrdude. Может здесь собака зарыта? updete Сейчас посмотрел на Ваши hex-файлы... Не. Похоже, чушь сморозил. Заархивируйте и выложите весь проект.

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

:) Блин! Вы заставили меня найти MSP430G2231 и воткнуть в Launchpad. У меня все работает. Вот мой исходник button.asm: .include "MSP430G2231.inc" .org CODE Reset: mov #STACK, SP mov #(WDTPW + WDTHOLD), &WDTCTL mov.b #0x41, &P1DIR ; as output mov.b #0x00, &P1OUT ; ЛЭДы выкл mov.b #0x08, &P1IE mov.b #0x08, &P1IES eint Loop: bis.b #LPM3, SR jmp Loop ISR_Button: bic.b #0x08, &P1IFG xor.b #0x40, &P1OUT reti .org 0xFFE4 DW ISR_Button .org 0xFFFE DW Reset .end Вот строка запуска компиляции $ naken430asm button.asm naken430asm - by Michael Kohn Web: http://www.mikekohn.net/ Email: [email protected] Version: September 21, 2011 Input file: button.asm Output file: out.hex Pass 1... Pass 2... Program Info: Include Paths: . /opt/msp430-naken/share/naken430asm/include Instructions: 12 Code Bytes: 48 Data Bytes: 4 Low Address: f800 (63488) High Address: ffff (65535) Вот файл out.hex, который получился в результате: :10F8000031408002B240805A2001F2404100220083 :10F81000C2432100F2422500F242240032D272D0CB :10F82000D000FD3FF2C22300F2E0400021000013AF :02FFE40024F8FF :02FFFE0000F809 :00000001FF Вот команда для его заливки в камень: $ mspdebug --fet-force-id MSP430G2231 rf2500 "prog out.hex" MSPDebug version 0.16 - debugging tool for MSP430 MCUs Copyright © 2009-2011 Daniel Beer <[email protected]> This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Trying to open interface 1 on 002 rf2500: warning: can't detach kernel driver: No data available Initializing FET... FET protocol version is 30066536 Configured for Spy-Bi-Wire Set Vcc: 3000 mV fet: FET returned error code 4 (Could not find device (or device not supported)) fet: command C_IDENT1 failed fet: identify failed Trying again... Initializing FET... FET protocol version is 30066536 Configured for Spy-Bi-Wire Sending reset... Set Vcc: 3000 mV Device ID: 0xf201 Device: MSP430G2231 Code memory starts at 0xf800 Number of breakpoints: 1 Erasing... Programming... Writing 48 bytes to f800... Writing 2 bytes to ffe4... Writing 2 bytes to fffe... Сделайте следующее: 1. Откомпилируйте свой исходник и сравните полученный секс-файл с моим. 2. Если они отличаются, попробуйте дизассемблировать и сравнить с исходниками -- все ли правильно ассемблировалось? 3. Попробуйте залить мой hex-файл в МК. Удалось его запустить? 3. Если не получилось, запустите mspdebug в интерактивном режиме и посмотрите, что у Вас реально находится в памяти $ mspdebug rf2500 MSPDebug version 0.16 - debugging tool for MSP430 MCUs Copyright © 2009-2011 Daniel Beer <[email protected]> This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Trying to open interface 1 on 002 rf2500: warning: can't detach kernel driver: No data available Initializing FET... FET protocol version is 30066536 Configured for Spy-Bi-Wire Set Vcc: 3000 mV fet: FET returned error code 4 (Could not find device (or device not supported)) fet: command C_IDENT1 failed fet: identify failed Trying again... Initializing FET... FET protocol version is 30066536 Configured for Spy-Bi-Wire Sending reset... Set Vcc: 3000 mV Device ID: 0xf201 Device: MSP430G2231 Code memory starts at 0xf800 Number of breakpoints: 1 Available commands: = delbreak gdb load opt reset simio alias dis help locka prog run step break erase hexout md read set sym cgraph exit isearch mw regs setbreak Available options: color gdb_loop iradix fet_block_size gdbc_xfer_size quiet Type "help <topic>" for more information. Press Ctrl+D to quit. (mspdebug) Команда для просмотра содержимого памяти: (mspdebug) md 0xf800 0f800: 31 40 80 02 b2 40 80 5a 20 01 f2 40 41 00 22 00 |1@[email protected] ..@A.".| 0f810: c2 43 21 00 f2 42 25 00 f2 42 24 00 32 d2 72 d0 |.C!..B%..B$.2.r.| 0f820: d0 00 fd 3f f2 c2 23 00 f2 e0 40 00 21 00 00 13 |...?..#...@.!...| 0f830: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................| (mspdebug) md 0xffe0 0ffe0: ff ff ff ff 24 f8 ff ff ff ff ff ff ff ff ff ff |....$...........| 0fff0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff 00 f8 |................| (mspdebug) А теперь ищите отличия своего от моего. И да! Выход из mspdebug осуществляется командой exit или нажатием на Ctrl-D. Если вообще ничего не получается, то разделите задачу на две -- вывод (моргание ЛЭД-ом) и ввод (получение данных с кнопки). Напишите сначала тупую прогу моргания ЛЭД-ом. Убедитеь, что у Вас хоть это работает. А потом наращивайте функциональность.

боюсь задать вопрос -- а формат файла прошивки Вы правильный указываете? Может тут проблема?

Даже не надейтесь! Современные МК очень сложно убить. (Хотя дурость безгранична...) Если Вы делали все так, как описывали, то Вы свои МК __не_убили__. В самом худшем случае Вы их просто запрограммировали (сконфигурировали) в какой-то такой режим, где они не откликаются. Но они у Вас __живые__. Самое тяжелое, что может Вам потребоваться -- это воспользоваться программатором, который позволяет обращаться к МК в так называемом "высоковольтном режиме". "Высоковольтный" -- это всего лишь +12В на ножке сброса. Пример такого программатора STK500. Программатор нужен Вам только для того, чтобы восстановить обычную (старую) конфигурацию у АВР-ок. Если Вы подойдете к менеджерам в магазине, и объясните ситуацию, то он наверняка Вас сведет с инженером по применению. Если Вам удастся расположить к себе инженера, то, я уверен, что он Вам не откажет в "восстановлении" конфигурации на своем STK500. Про консультацию я уже просто молчу. В каждом уважающем себя большом магазине всегда есть такой инженер. Спрашивайте. Вы можете значительно облегчить работу консультантов, если покажете фотки, что Вы там сделали. Было бы хорошо, если приведете схему, Расскажите об источнике питания. Я так понимаю, осциллографа у вас нет, чтобы проверить генерацию колебаний на кварце? Тогда попробуйте посмотреть через конденсатор 10нФ-0.1мкФ, что там у Вас делается на выводе XOUT вольтметром, включенным на переменный напряжение. Если есть генерация, то вольтметр хоть что-нибудь покажет. Если нет, то, понятно, -- покажет ноль. И еще совет, постарайтесь найти кого-нибудь из своего окружения. Повесьте объявление на местном форуме, что Вам требуется помощь. Я уверен, что из 10-20 тысяч людей, проживающих рядом, найдется не менее 3-5 человек, кто умеет обращаться с АВР-ками. А у тех, кто знает таких людей (но сам не работает с МК), таких будет десятками. Вам нужно преодолеть только первую ступеньку. Она -- самая трудная. Порой кажется, что она высотой со стену. Поэтому не стесняйтесь обращаться за помощью. Все проходили через это. Нормальный человек поймет и постарается помочь.

dxp говорит дело. Использование тяжелых библиотек на слабых вычислительных единицах -- это проявление непрофессионализма. Применение на Кортексах и АРМ-ах -- еще куда ни шло, хотя и там лучше все-таки как-нибудь обходится без ООП. Но на АВР-ах... не-е, лучше не надо! Поиграться для получения опыта, конечно, можно. Но для изделий, которые предполагается использовать на блага себя или общества, код лучше писать на чистом Си. А Си++ -- это все-таки для компов или более мощных МК. Хотя, опять же! На форуме всегда найдутся спорщики, и начнут доказывать, что это не исключение, а правило. Основной аргумент -- типа принципиально же запускается, работает. А чем это достигается, чем при этом приходится жертвовать -- для них это вопрос второстепенной важности. Если хочешь растолкать локтями конкурентов на рынке, делай лучше, чем они. Не игнорируй второстепенных вопросов. Конечному пользователю все равно -- на каком языке написан софт. Хоть на Васике! Ему важна надежность оборудования и цена. Если ваш девайс будет периодически сваливаться в синий экран из-за фрагментации памяти, нанося мне убытки, то я приду к вам и... угадайте с одного раза, куда я вам засуну ваше изделие. Более того, я еще всем расскажу, какой есть глюкавый и тормознутый (при такой тактовой частоте на что тратит он свои такты) ваш недо-девайс. А теперь попробуйте сделать свой бизнес и продержаться долго на рынке!

Если у схемы "свое" питание, то смысла брать питалово из программатора -- нет. -- А хрен его знает, товарищ майор! (с) Когда у меня тетки Венду валили я приходил и задавал им вопрос: -- Чего делали? Они на голубом глазу отвечали. Честно-так, искренне: -- Ничего. Оно само раз и все перестало... Ну, во первых, Вы могли запрограммировать фьюз SPIEN. А во вторых, если фьюзы не трогали, то попытайтесь понизить тактовую частоту обращения программатора к Тайни2313. Делается это путем вставки дополнительных "пропусков" (вставка команд NOP, то есть пауз) при формировании тактовых сигналов программатором с помощью указания ему опции -B n avrdude-у. Вы же его пользуете? n -- это количество NOP-ов. Код будет заливаться несколько медленнее, но устойчивость связи станет 100%-ой.

Да, теоретически такое тоже может быть. Но, практически... 1. Дребезг контактов -- это времена миллисекундные. Даже короткую миллисекундную вспышку можно заметить. 2. Я не думаю, что ТС нажал на кнопку только один раз. И в этот раз произошло четное касание контактов. Скорее всего, ТС нажимал много раз. Таким образом в какой-то из них могло произойти нечетное касание контактов. 3. На плате Launchpad дребезг давится с помощью конденсатора, который подключен параллельно контактам кнопки. Уж легче предположить, что либо светодиод не подключен джампером, либо кнопка сломана, либо ТС что-то делает не то. Там блудить-то -- совсем негде. Ждем-с его появления -- какие факты он еще вынесет на обсуждение. А так гадать ... может он после программирования питание с платы отключает. Кто его знает, что к него там!

Сложно сказать. Код вполне рабочий, должен работать. (Мелкая придирка только к повторному разрешению прерываний -- eint это и есть команда bis.b #GIE, SR) На сколько я понял, это у Вас Launchpad? Джамперы на ЛЭД-ы установлены? А если Вы свою схему собирали, то может быть не обратили внимания, что на плате Launchpad кнопочка подтянута внешним резистором к питанию. А если у вас этого резистора нет, и при включении питяния на лапке будет нуль, то хоть зазамыкайся кнопкой эту лапку на землю -- единице-то неоткуда взяться. Должен быть резистор либо внешний, либо внутренний. Я немного переписал Вашу прогу, проверил. У меня на Launchpad-е все работает. Может это Вам как-то поможет. .include "MSP430F2001.inc" .org CODE Reset: mov #STACK, SP mov #(WDTPW + WDTHOLD), &WDTCTL mov.b #0x41, &P1DIR ; as output mov.b #0x00, &P1OUT ; ЛЭДы выкл mov.b #0x08, &P1IE mov.b #0x08, &P1IES eint Loop: bis.b #LPM3, SR jmp Loop: ISR_Button: bic.b #0x08, &P1IFG xor.b #0x40, &P1OUT reti .org 0xFFE4 DW ISR_Button .org 0xFFFE DW Reset .end Я использую naken430asm (Линуксовый), поэтому синтаксис немного отличается. И еще незначительное отличие, у меня воткнута MSP430F2001. Ссылку на свой блог, где я расписываю как начать работу с MSP430 я кину Вам в Личку. Update: Нифига не получилось -- у Вас ящик отключен. За публикации ссылок тут наказывают, поэтому придется Вам самому погулить по словам zhevak и msp430.

Ура-а-а-а!!! На часах половина пятого утра. Сестра, запишите -- родился эмбеддер! Счастливые родственники пожимают друг другу руки. На лицах слезы умиления... И еще пять копеек от simpleavr: http://www.simpleavr.com/avr/vusbtiny

Уже хорошо. Молодец! А вот тут, на сколько я понимаю, собака зарыта в том, что Винда не дает пользовать напрямую порты. К сожалению, по Венде я Вам не смогу подсказать. За прошествии многих лет уже забыл, как-там запрет на работу с портами "обходили". Вроде как запуском какой-то утилиты. Название уже не помню. (Надумаете работать из-под Линукса -- милости просим! Расскажу и покажу. Там всё намного ... Ну, не буду дергать котов за усы. В общем, кто просек фишку, как там __правильно__ работать, обратно уже не возвращаются.)

Да, пофигу все это! Вы уж начните что-нибудь делать, а там разберетесь что-к-чему. А то температуру воды помериете, и плотность, и соленость. И прозрачность... И глубину, уклон... И а все никак войти в воду не можете. Не бойтесь потерять 100-500 рублей, ошибившись с программатором. В крайнем случае это будут не потери. Это будет "запаска" на черный день, когда тьфу-тьфу-тьфу издохнет рабочий программатор. У меня был и 5-ти проыодковый, и AVR910-ый, и Китайский Драгон, и фирменный AVR MK-II -- не суть, все одно и то же. Все позволяют заливать код в МК. Ну один льет за секунду, другой за 10 -- где разница, а третий будет минуту цедить килобайт кода? У Вас что, крупносерийное производство, когда каждая секунда дорога? Пока у Вас ничего такого нет, то скорость для Вас -- одни понты. Берите, что есть и двигайтесь вперед. И еще. Вы ведь не живете где-нибудь на другой планете. Наверняка в вашем городе найдутся люди, которые имеется программатор. Попробуйте поискать их, а когда найдете, попросите прошить _ваш_первый_программатор_. Я уверен, что Вам не откажут. -- Желаете умереть сразу. Или хотите помучиться? (с) (перевод: желаете как можно скорее начать работать с МК, или хотите сначала намучиться?) Со стороны, это как-то немного странно выглядит. Может я чего не замечаю. Вы реально хотите достичь цели (начать заниматься с МК) или для Вас принципиально _поднять_своими_силами_все_с_нуля_? Второе -- очень глупо. Человек -- прежде всего, существо социальное. То есть его деятельность очень сильно опирается на окружающих его людей. Ну так и пользуйтесь тем, что Вы не одиноки, а среди других таких же. К стати, я до сих пор пользуюсь параллельным программатором (5 проводков + 74РС244). За пять лет подыхал уже раз пять если не больше. И каждый раз чинился. А что там чинить-то? Скорость нормальная. Да и скорость больше, чем на AVR910. А то, что JTAG позволяет проходить программу по шагам и видеть живьем переменные и регистры -- ну это конечно плюс. Не плохой плюс. Но это не есть принципиальное ограничение для работы с МК. Начните с простого. А когда понравится процесс (работа с МК). вот тогда и разживетесь на любимую игрушку. Дал бы свой программатор на недельку поиграться, да не знаю в каком городе Вы живете. Проблемы-то нет. Уже прыгайте в воду!

К стати, да. Похоже АТМЕЛ "одумалась". Цены возвращаются на прежний уровень. Из бесед с представителями ЭФО -- Россия в числе самых последних стран по удовлетворению запросов. Из-за перестроения специфики производства (продажа заводов) образовался дефицит МК и запасенных на кануне перестройки производства запасов не хватило. Большинство людей не умеют ничего делать руками и головой. Это порок они умело компенсируют элементарной спекуляцией на нуждах людей. Пререпродавцы всех мастей. Вспомните недавнее затопление фабрик по производству жестких дисков. Цены взлетели вверх в разы. АТМЕЛ сначала удовлетворяет потребности Пендосии, потом Европии и только потом уж России. Ну вот, теперь и до нас дошла очередь. Радуйтесь. Но пользуясь сложившейся ситуацией на рынке STM все-таки успела отхватить кусманчик от мирового пирога. Я уважаю STM. Я уважаю ATMEL. Но на STM8 я лично переводить свой бизнес не собираюсь. Если хорошо знаешь AVR, менять шило на мыло нет никакого смысла. Если c AVR не знаком, то тут еще можно подумать. К сожалению, у них мелкие корпуса. А это явно не "плюс" для макетирования, особенно на этапе освоения МК. Ну и начинающим радиолюбителям тоже дополнительные сложности. Даже NXP изгаольнулась выпустить младшую модель Cortex-ов в достаточно большом "кузове". Что же касается gcc для STM8 -- тут вообще не чего комментировать. Засада по полной программе. "Избушка-избушка, повернись к людям передом..." (с) и процесс пойдет. Я понимаю, что меня никто не просил афишировать мою точку зрения, но не я первый "бросил камень", не я начал агитацию за процы. Я никого не призываю следовать за мной. Я не знаю правильного пути. Я могу ошибаться. Идите своей дорогой и собирайте свои шишки. Update Не сразу, но все же нашел-таки! Катька чисто по-женски рассказывает о природе собственной правоты у людей. http://www.ted.com/talks/lang/ru/kathryn_s...eing_wrong.html (У кого с английским неважно, включите русские субтитры.)

К сожалению есть один здоровенный минуссище -- всё под Вендой. Костыли и клизьмы не предлагать!

Лет пять назад, на старой работе, мы так устанавливали AVR-ки (MEGA8) -- запрограммированные и залоченные запаивали на плату. Было изготовлено несколько тысяч изделий. Слетания прошивки что-то не припомню. Несколько лет назад таким же макаром паяли MSP430 -- уже запрограммированные и залоченные. Разница только в том, что здесь серия уже исчисляются десятками тысяч, и пайка происходит не руками, а в специальных печах. Тут уж точно -- ни одного отказа у меня не было.

Ну вот сходу могу предложить пару вариантов. 1. Например, можно сделать с помощью штатной утилиты, которая входит в состав binutils: $ msp430-objdump -dSt myfile.elf > myfile.lst По ключам (-dtS) смотрите встроенный хелп. Там все достаточно прозрачно. Разумеется, нужно сначала установить этот пакет. Где найти и как установить пакет, это тема отдельного разговора. Извините, я привести ссылку на сайт, где я описываю, как это сделать. http://forum.e-lug.ru/viewtopic.php?id=666 2. Если тяжело, то можно пойти по более простому пути, воспользуйтесь доморощенным пакетом Михаила Кона: http://www.mikekohn.net/micro/naken430asm_...0_assembler.php Ну тут всё по-домашнему просто и без лишнего бряцания знаниями. Закачиваете исходники, компилируете и устанавливаете. Если что, задавайте опросы. А вообще проблем по дизассемблированию MSP430 уже давным давно нет.

Рискну предложить еще один способ для обычных оперов -- не Rail-to-Rail. Схему детекторного приемника помните? Схема в прикрепленном файле. (Как вставить изображение в пост я не понял. Ни разу не пользовался.) Если у МК есть свободная нога, то выведите на нее меандр и подайте его на этот "детектор". Я, правда, не знаю на сколько хорошо этот способ подойдет для вашей схемы, но ВЧ-помехи по -Vcc можно загасить или RC-цепью, или поставить маленький дроссель. Вариантов масса. Опер жрет совсем чуть чуть, поэтому тут нагрузка вообще никакая. Пробуйте, может что и получится. Я так иногда делаю. Реально помогает! Главное -- не лениться искать решения. И да, извините, за качество схемы. Рисовал тем, что было под руками, хотелось по-быстрее ответить.

Ну, почему же! Я об этом упомянул косвенно. Я сказал что потребители (в т.ч. и потребители кристаллов) находятся в состоянии перманентного шопинга. Код коду рознь! Я про себя скажу. Я никогда тупо не переносил исходники с одного проца на другой. Мои задачи не подразумевают высокого программирования уровня Васика. мои задачи низкоуровневые -- в основном сбор и частичная обработка данных, отсылка их в комп, работа c кнопочками и LCD-экранчиком. Пишу я в основном на С. Очень-очень редко опускаюсь до ассемблера. И тем не менее при переносе проекта с одного проца (ставшего , допустим, по мере роста проекта слабым) на другой проц, я обычно вношу изменения в код. Может быть где-нибудь на очень больших проектах, где флеши расходуется больше чем 32 кило, имеет смысл закрывать глаза и довериться библиотекам, но у меня не было таких больших проектов. Не знаю. Не знаю. Кому-то нравится писать проги на Бейсике, а кому-то на асме. У людей разные требования. А почему Вы считаете, что библиотеки будут жить дольше, чем кристаллы? У кристалла меняется индекс (номер), а у библиотек меняется версия. И то и другое не постоянно. Есть несколько уже много лет существующих библиотек, так сказать -- составляющих основной костяк, их ведь никто не отменяет. Появится новый Кортекс, у которого совершенно другая периферия, другая архитектура (например, чем отличаются Атмеловские процы Мега и Х-Мега), и тогда все структуры инициализации периферии "поплывут". Если библиотека не поднимает уровень абстракции, а заменяет одну сущность на другую, то особого смысла в этом не много. Типа давайте изучать библиотеку, чтобы не изучать железо. Ну, наверно, где-то это и сканает... А изучать и то и другое, мне кажется не очень разумно. Знания железа делают знания библиотеки ненужными. Зачем изучать какую-то библиотеку, если нормально можешь работать с периферией проца? А вот знания библиотеки все равно потребуют погружения в железо. Хотя, опять же, много людей программирует на Васикие и ничего, программируют же! Но Васик дает другой уровень абстракции (по сравнению с С/С++), а библиотека ST только подменяет аппаратные сущности камня программными вызовами и структурами. Т.е. уровень-то остается примерно тот же. Так в чем тайный смысл библиотеки? Про полезность библиотеки можно говорить только через какое-то время. Может она будет новым мощным стандартом , а может канет шуме других многочисленных библиотек. Как знать!

Ну, а я о чем говорю -- уменьшает порог вхождения в ST-технологии. А это значит, что STM32 -- минируется на роль народного МК. Ждем наплыва новых программистов.