zhevak

Вы можете поставть две точки останова: одну до цикла, вторую после цикла? 1. И когда, по вашему представлению, программа зависнет на выполнении цикла, остановть ее (нажать "паузу" или что-то там в Кайле нажимают) и посмотреть на переменную цикла и на сумму. 2. Попрбуйте поиграть с количество итераций цикла. Задайте в цикле просумировать один элент. Два элемента. Пять элементов... Просто попробуйте набрать статистику зависаний. 3. Кроме этого цикла, программа какие еще действия делает? Особенно интересуют какие прерывания Вы используете. Я к чему это говорю -- к тому, что возможно во время работы (конкретно -- во время выполнения этого злополучного цикла) возникает прерывание и оно как-нибудь не правильно обрабатывается. например, тупо не снимается флаг прерывания, который должен сниаться программно. Я не знаю, никто не знает что там у Вас происходит. Но наиболее вероятные версии нужно отработать -- проверить. Всё равно что-то делать надо. 4. Что еще могу предложить -- если есть осциллограф, то предлагаю вписать в тело цикла команду дергания какой-нибудь свободной ножки проца. и осциллографом попробовать уловить сколько итераций совершает цикл. Может быть он лупит бесконечность, а модет слелает пару-тройку и процесс уходит в обработку какого-нибудь прерывания.

Ты в ответе за тех кого приручил (с) Блин! 1. К сожалению, не могу подсказать. Я с эклипсом не работаю. Для моего компа он слишком "тяжелый", поэтому я его не использую. 2. На сколько я помню, mspdebug по Си-шному исходнику вроде бы не "бегает". Что-то не припомню чтобы я отлаживал в нём Си-шные проги. я уж года два наверно с MSP не работаю, забывается всё быстро. 3. Что бы я сделал, если бы коснулось меня проблема отлаживать Си-шные проги в mspdebug. Я бы вывел из elf-файла дизассемблированный листинг, в нем будут физические адреса команд и данных, перемежающиеся с исходным кодом на Си. отлаживаживать. Имея под руками такой листинг, я думаю, не составит больших проблем установить с помощью mspdebug точки останова, а так же проверять значения ячеек памяти с данными. Ну, как-то так, наверно. Вывод листинга из elf-а можно существить командой: $ msp430-objdump -dSt myproga.elf > myproga.lst Вместо myproga.elf, разумеется, Вы должны подставить имя своего файла. 4. MSP430 можно отляживать с помощью gdb-сервера. gdb-сервер -- это такая программа, которая с одной стороны общается через отладчик с вашим МК, а с другой стороны -- принимает запросы (команды) от клиентской программы и отдает ей результаты. К gdb-серверу обычно подключаются через сокеты (сетевой IP-адрес + TCP/IP-порт). Таким образом, можно отлаживать устройства на разных компах. Если отладка производится на том же компе, где расположена программа клинета, то вместо сетевого адреса либо ничего не указывается, либо указывается localhost. (Имя localhost траслируется в IP-адрес 127.0.0.1, что означает, что это тот же самый комп.) Вот пример работы с gdb-сервером для msp430: После того как залили код в МК, запускаем прокси-сервак на порту 2000 (можно взять любой другой ещё не занятый): msp430-gdbproxy --debug --port=2000 msp430 Далее создаем в рабочем директории скрытый файл .gdbinit и записываем в него следующие строки: set remoteaddresssize 64 set remotetimeout 999999 target remote localhost:2000 После чего запучкаем отладчик: msp430-gdb myproga.elf Это в кратце. Ну а для получения более детальных знаний, нужно гуглить. У меня нет возможности для более глубоких консультаций. Для этого лучше нужно написать книгу или что-то в этом духе. Мне кажется, что за меня это наверняка уже кто-то сделал, нужно просто поискать. 5. Ну, грубый ответ такой -- сначала погуглить, и если гугл ничего полезного не даст, то написать самому. Сложного в crt0.S ничего нет. Этот файл предназначен для начальной (я бы сказал -- аппаратной) настройки процессора переде тем как будет вызвана Си-шная функция main. К этим настройкам следует отнести, например, (временно) отключить вотчдог, установить указателя стека, настроить систему тактирования ядра и периферии, настроить периферийные устройства. Возможно вам понадобиться очистить память, проинициализировать какие-нибудь данные. Ну и в конце этого файла нужно вызвать main. Некоторые компиляторы (с языка Си) не требуют наличия такого файла (crt0.S). На сколько я помню, так делал AVR CodeVision v.1.24. А вот про msp430-gcc -- я ничего не могу сказать. Не помню, что там 6. Лежать crt0.S может как в рабочем директории наравне с другими исходными файлами, так и в тандартном пути (там где располагаются файлы библиотек статической линковки). Всё зависит от задач и потребностей программиста. Не важно, где находится этот файл. Важно только иметь к нему правидльный прописанный путь. А для чего он нуже, я уже ответил в передыдущем пункте. 7. Да хрен его знает! А Вы случаем не смотрели -- там файл реально есть или он находится где-то в другом месте? Попробуйте поискать его. На всякий случай команда для поиска: $ find ~/pf -name crt0.S запомнить ее формат просто: find <где искать> <что искать> <что делать, когда найдем> Последний пунктдля нашегослучая можно опусть, тогда команда просто распечатает полный путь к найденному файлу. Опция что искать может быть не одна. Это скорее целий набор критериев для поиска. Мы можеи искать по имени (-name), по типу (-type), по размеру, по дате создания, по владельцу, по правам доступа и т.д. Если это сложно (извините, я не знаю какой у Вас уровнь знания Линукса ), то можно поступить по другому. Линукс поддерживает базу данных (условно) по всем файлам, которые у него есть. Перед тем как произвести поиске по этой базе, нужно сначала её подновить. Сама БД не подновляется, только по команде пользователя. Поэтому, если на разделах файловой системы производились какие-то изменения (удалялись файлы, записывались новые), то БД не будет соответствовать файловой системе. Подновить БД можно командой # updatedb или $ sudo updatedb После того как БД будет актуализирована, можно в неё искать файл. Команда поиска очень простая (шаблон команды -- locate <имя файла>): $ locate crt0.S В этом случае поиск будет знчительно быстрее, но гибкости в нём будет -- никакой. 8. Не могу сказать. Не работаю с Эклипсом. Уф-ф!

[grumbling_mode] А почему "хИдер", а не "хЭдер"? Где вы изучали язык? [/grumbling_mode] Я просто оставлю это здесь: http://ru.forvo.com/search-en/header/

Присоединяюсь. Интерес определяется так же и ценой и сроком поставки, ибо многие сами умеют делать утюгом платы. Могу про себя сказать -- вообще плата интересная, да. Возможно, я бы и прикупил штук пяток для моделирования. Но если цена голой платы (без проца и др. элементов) будет более 25-50 рублей, то в этом случае макетные платы для своих поделок я лучше сделаю сам. Причем сделаю так, как мне надо, согласно схеме, по назначению, по месту, по габаритам и т.д. А не универсально, то есть в полном соответствии с вашей платой. Я рассматриваю назначение Вашей платы, сродни назначению транзистора КТ315, 2N3904 или BC547. Они всегда должны быть под рукой в некотором количестве. Должны быть дешевыми. Не должно быть жалко их случайно сжечь. А заказывать относительно дорогую плату -- это как заказывать какой-нибудь уникальный транзистор -- наверно можно. Возможно кому-то это и надо. Но лично я не вижу в этом жуткой необходимости. Приспичит -- сделаю сам. Никто умирать не собирается из-за отсутствия вашей платы (простите за резкую фразу. Не смог найти слова, чтобы смягчить ее.) Она хороша, но абсолютно не необходима. И в этом трагедия. Мне кажется, что чтобы Вам продать свою плату, ее нужно растиражировать в нескольких тысячах экземпляров. Она тогда будет очень недорогой. теоретически можно также вылезти на рынок за счет созданной вокруг изделия экосистемы. Но пока Вы создаёте свою экосистему (общество потребителей, набор инструментов и программ, список применений, оширный и качественнй FAQ и так далее) мир неизбежно изменится. И Ваша плата, не достигнув вершины продаж, станет уже неактуальна. А в мире всё может быть. К примеру, США перекроют поставки процов в возрождающийся СССР, и мы будем вынуждены переключиться на изделия Миландра. Или через пару лет выйдет еще более совершеннй проц с еще более низкой ценой. Кто его знает, что там нас ждет впереди! Кусок фольгированного текстолита -- он тем и хорош, что пока он не вытравлен под нечто конкретное, он обладает очень большой универсальностью и гибкостью. Дело за малым -- включить утюг и развести FeCl. И с этим особых проблем у людей нет. Проблемы с тем, как убедить людей купить то, что они и сам могут худо-бедно сделать.

Ваша проблема в том, что Вы не знаете команд Cortex. Вы их неправильно понимаете. Команда LDR r0,[pc,#32] ; @0x08000210; загружает в регистр R0 4-байтное значение (число), которое находится рядом с кодом программы. Доступ к этому значению осуществляется относительно программного счетчика. В комментариях к листингу указан адрес -- 0х08000210. Видимо, в исходном тексте программы Вы описывали переменную (точнее -- константу). А это ничто иное, как данные. Данные бывают разные -- константы, переменные. Переменные бывают инициализированными и неинициализированными. Кроме данных, в программах присутствует код. В общем, программа состоит из разного рода кирпичиков. Более того, проекты, как правило, представляют представляют собой (или состоят из) нескольких исходных файлов. Каждый исходный файл проекта может иметь и программный код, и константы, и инициализированные данные и так далее. Так вот, задача ликовщика заключается в том, чтобы пройтись по всем объектным (откомпилированным) файлам и сгруппировать "корпичики" в кучки. Кучка кирпичиков типа "программный код", кучка кирпичиков типа "инициализированные данные", кучка кирпичиков типа "неинициализированные данные" и так далее. Эти кучки называются секциями. Вы наверно уже встречались с их названиями -- .text, .bss, .data и так далее. Названия секций у разных компиляторов (линковщиков) могут отличаться. Я сижу в Линуксе и использую gcc, Вы сидите под Виндовсом и используете Кайл. У нас секции скорее всего будут называться по-разному. Но назначение секций, как правило, соблюдается. Итак, возвращаемся к Вашей программе. У вас в коде, было какое-то определение данных. Эти данные после линковки попали на адрес, который находится рядом с секцией кода. Чтобы переместить эти данные (значение) из памяти в регистр, понятно, нужно как-то адресовать эту ячейку памяти. Для данного случая оказалось удобнее адресовать ее относительно программного счетчика, что и было сделано приведеной выше командой. Следующая команда MOV r1,#0xE000E000; запиысывает в регистр R1 базовый адрес Системного Таймера. Системный Таймер -- это группа регистров. Точно так же следует думать и про другие устройства. Например, порт ввода-вывода -- это тоже группа регистров с каким-то базовым адресом. USART, DMA, ADC и так далее -- все эти устройства имеют по нескольку (иногда даже десятков) регистров. С одной стороны, в микроконтроллерах многие устройства зачастую присутствуют в нескольких экземплярах. А с другой, адресное пространство для регистров практически не ограничено (как антипример, микроконтроллеры ATMEL AVR -- там куда-только не пихают регистры и биты!) Поэтому оказывается, что более удобно выделить для конкретного устройства базовый адрес в этом адресном пространстве и более не париться с размещением битов и байтов. Но так как, допустим, портов ввода-вывода в микроконтроллере может быть несколько экземпляров, а они все одинаковые, то было бы разумно для каждого порта назначить какой-то базоавый адрес для группы его регистров. А доступ к конкретному регистру осуществлять относительно этого базоаого адреса. Таким образом, всё становится унифицировано и удобно Следующая команда STR r0,[r1,#0x14]; сохраняет содержимое регистра R0 по базовому адресу (который находится в регистре R1) плюс смещение 0х14. (Простите за то, что опять написал много. Был в ударе.)

Я -- "за"!

Серега, ты что?

Я понимаю, что ни к месту... но в качестве версии. Просто хочу помочь с проблемой. У меня такое же было несколько раз, разница только в том, что я работал не с STM32, а с MSP430. По какой-то неведомой мне причине IAR-собака несколько раз заливал прошивку вместо таргет-проца в программатор. Происходило это не регулярно, и без какой-либо видимой причины. Приходилось с воплями и проклятиями возвращать прошивку обратно. После чего IAR продолжал заливать код нормально. А через какое-то время опять история опять повторялась. Причину я таки не нашел. Просто к тому времени меня Венда уже порядком достала, и я пересел на Линух. В Линухе, конечно, свои тараканы, но работая с теми же программаторами и с теми же микросхемами, я за столько лет ни разу не уган-шил программатор. (Простите за рекламу, просто я на своей шкуре почувствовал что значит работать не вздрагивая.) Может быть у Вас те же грабли. Попробуйте залить прошивку в программатор. Кто его знает -- возьмет, да и поднимется.

Честно говоря, я не думал про какой-то конкретный компилятор. Я под Линем сижу, могу притащить сюда листин от gcc. (Если кто-нибудь меня не опередит к этому времени, гы-гы!) Давайте какой-нибудь простенький код обуликуем, откомпилируем и сравним. Внимание нужно будет уделить именно арифметическим командам проца, которые как раз занимаются вычислением деления int на size_t. Ну что, попробуем сделать?

Да. Было бы любопытно посмотреть на распечатку ассеблерного кода в том и другом случае.

... и еще вот тут есть интересные рассуждения про size_t http://www.embedded.com/electronics-blogs/...-size-t-matters Переведу-ка я ее на русский, да опубликую не сегодня-завтра в своем блоге. Полезное ведь дело, однако, да.

здесь у Вас unsigned char (8 бит), а t имеет тип int (16 бит). И надо учитывать, что sizeof возвращает не unsigned char, и даже не unsigned int, а size_t. Думаю, Вам надо посмотреть как конкретно на вашем компиляторе реализуется тип size_t.

А Вы знаете, уважаемый коллега Golikov, Вы натолкнули меня вот еще на какую мысль. Начну немного издалека. Допустим, у нас имеется некая емкость, которая заряжается от какого-то источника напряжения через сопротивление. Теоретически, заряд емкости будет длится во времени бесконечно долго. Но мы с Вами не математики и физики, а инженеры. Наши пределы погрешностей составляют 1, 2, 5 и иногда даже 10%. Грубо говоря, те измерения, с которыми мы обычно имеем дело имеют вот эти названные погрешности. Теперь, если считать, что с нашей (инженерной) точки зрения процессы останавливаются тогда, когда они попадают в диапазон "наших" погрешностей, то мы сможем продвинуться дальше в наших рассуждениях. Допустим, при некоторых известных параметрах (напряжение источника, сопротивление, емкость) переходной процесс заканчивается за 100 нс. При этом тратится какая-то энергия, которую косвенно мы можем оценить путем измерения тока заряда. Теперь давайте увеличим сопротивление в два раза. Что мы можем сказать в целом про переходной процесс? Ну, то, что время заряда будет больше в два раза, это понятно. Но что станет с потребляемым током? По идее оно тоже уменьшиться. А что можно сказать про затраченную от источника питания энергию? -- Она не измениться. Идем дальше. Допустим мы должны выполнить 1000 циклов заряд-разряд емкости. Пусть один цикл составляет 1 мкс, а циклы следуют пачками через каждые 10 мс. (Я специально так подобрал времена, чтобы было понятно, что пачка будет длиться 1 мс, а инерционность стрелочных приборов не позволит увидеть период этих пачек.) Вопрос -- что покажет амперметр в первом и во втором случае, когда мы увеличили сопротивление в два раза? Ответ состоит в том, что в обоих случаях потребление энергии (а значит и показания амперметра) будет одинаковым. Хорошо. Идем дальше. Как вы думаете, по какой причине у микроконтроллеров (да и вообще -- у любого процессора) существует некая граничная частота, начиная с которой он уже не в состоянии выполнять программу детерминировано? Видимо, в следствие того, что на высоких частотах начинаются сказываться задержки распространения фронтов импульсов. Эти задержки связаны с тем, что существующие паразитные емкости не могут заряжаться мгновенно. Поэтому, на выходе вентилей мы имеем задержанные по времени выходные сигналы. Более того, эти сигналы не очень-то похожи на прямоугольники. Точнее так -- мысленно отрежьте от хорошего прямоугольника его вершину, а нарастающий и спадающий фронт соедините вместе. Получится нечто напоминающее зубчик пилы. Давайте ещё немного мысленно поиграемся с "отрезанием" средней части импульса. Вырезанием средней части импульса, мы как бы увеличиваем тактовую частоту. Мы можем видеть, что продолжая увеличивать частоту, форма пилы мало меняется, но зато амплитуда пилы резко начнет уменьшаться. Наверняка вы такое видели не раз в своей практике. Уменьшение времени заряда-разряда конденсатора говорит о том, что он не заряжается до конца. А это значит, что количество забранной у источника питания энергии будет меньше на единицу события (фронта импульса). Если мы считаем, что независимо от тактовой частоты, количество команд в программе одно и тоже, значит при низких частотах, когда паразитные емкости успевают полностью, заряжаться суммарное потребление тока будет примерно одинаковым. И только тогда, когда емкости не заряжаются полностью, но процессор еще не сбоит, мы можем ожидать незначительное снижение потребляемого тока. Мне наверно следует предупредить холливар -- я не говорю о режимах работы, когда проц "молотит" постоянно. Я говорю о режимах, когда проц 90 и более процентов спит и потребляет доли микроампер, а только в 10 (и менее) процентов времени проц работает, потребляя десяток-другой миллиампер. Но поскольку в моменты бодрствования проц выполняет одно и тоже количество команд, условно совершая 1000 переходов состояния внутри ядра, то можно утверждать, что он в этот момент потребляет одно и тоже количество энергии. Но ситуация начинает немного меняться, когда проц, пробуждаясь, работает на предельных частотах. Когда его паразитные емкости не полностью заряжаются. Кто-нибудь понял, что я тут сказал?

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

Какая у Вас тактовая частота? Я с системой тактирования у LPC не очень знаком. Но скажу по аналогии с MSP430. Там тоже несколько генераторв. Когда проц отправляете в спячку, нужно выключать "быстрый" тактовый генератор (в процах он обычно где-то на 1 МГц) и перходить на тактирование от медленного генератора. В MSP430 это внутренний RC генератор на 12 кГц. От этого геренратора тактируется таймер, по которому должен проснуться проц, или какая-нибудь другая периферия. Как только возникает событие, которое пробуждает проц, нужно в обработчике этого события включить быстрый тактовый генератор, дождаться установки режима колебаний (а Кортексах это установка флага, в MSP -- можно сразу) и переключить тактирование ядра на этот генератор. Наверняка Вам это уже известно, но я все же скажу -- КМОП-структуры потребляют тогда, когда происходит у них переключение из "0" в "1" или обратно. И вот тут не все так просто, как кажется на первый взгляд! Потребление происходит в момент перехода. Ожидается, что чем выше тактовая частота, тем должны быть круче фронты у сигналов внутри МК. Незначительно, но круче. Иначе говоря, время перехода из "0" в "1" на более высокой частоте чуть-чуть должно быть меньше, чем на низкой тактовой частоте. Теоретически, на очень маленькой частоте, когда, допустим, что фронт мы формируем в ручную с помощью переменного резистора, при напряжении около половины питания, через комплиментарные структуры потечет ток. Об этом я уже писал выше. Таким образом, время перехода определяет сколько времени будет протекать этот ток. Это значит, что при одном и том же количестве переходов (допустим 10000), общее (интегральное) для одного и того же участка программы, время протекания тока будет больше если этот участок программы будет выполняться на более низкой частоте. Вообще-то тут лучше рисовать, но я не очень расположен сейчас к рисункам. Поэтому предлагаю вот такой ход. Допустим, прога должна совершить те же самые 10000 переходов и снова уснуть до слудующей побудки. Пусть побудки будут происходить один раз в секунду. Так вот, допустим на тактовой частоте 12 кГц, время протекания сквозного тока составляет 25 нс, а на тактовой частоте 1 МГц -- 10 нс. Точных значений я не знаю, да и скорее всего вряд ли кто их знает. Но для примера сгодится. Допустим так же, что суммарный сквозной ток этих коротких импульсов составляет 1 мкА. Допустим, мы работаем на 12 кГц. Таким образом перемножаим 1 мкА х 25 нс х 10000 переходв и получаем 250 мкА. Это интегральное значение нужно рстянуть на одну секунду. Теперь допустим, что мы заставили ядро работать на 1 МГц. Снова перемножаем 1 х 10 х 10000 = 100 мкА. И это значение мы снова должны растянуть на односекундный период. С одной стороны, на частоте в 1 МГц будет большой и короткий бросок тока, когда процессор работает, а на 12 кГц -- небольшой ппо амплитуде, но растянутый по времени. В остальное время, когда ядро вообще спит и, считается, что тока не потребляет. Практика подтверждает, что если проц, который все время спит, но раз в секунду просыпается чтобы выполнить какую-то работу, и если проц для этой работы запускать на максимальной частоте, то общее потребление будет ниже, чем если бы проц запускался на более низкой частоте. Бли-ин! Кто это всё читать!? Наверно действительно надо было рисовать. С картинками все процессы намного понятнее. ЗЫ. Для ориентации и как пределный случай. Я недавно делал один девайс на MSP430 с батарейным питанием. Вопросы экономии стояли очень жестко. Проц просыпался каждую секнудны, проверял сигналы и снова засыпал. Прога написана на Си. Итоговое потребление схемы составило 12-14 мкА. Причем проц жрал примерно половину. В момент пробуждения я его его тактировани на частоте в 20 МГц. В режиме спячки -- 12 кГц. Не расценивайте это как хваствовство, просто оценивайте каких результатов можно вообще добиться. В принципе, можно было участок проги вообще написать на ассемблере, тогда примерно еще можно было бы на половину уменьшить потребление проца. Но зачем? Сама схема устройства потребляет, да и саморазряд источника тоже имеется. Так что дальнейшее снижение энергопотребления проца не имел особого смысла.

Сделать наоборот -- неиспользуемые выводы МК разверните на выход, а резисторы подтяжек поотключайте. Выходные CMOS-структуры в статическом режиме ток не потребляют. Входные цепи из-за наводимых на них помех часто могут находятся не в "цифровом" режиме. Цифровой ркежим -- это когда на затворах транзисторов присутствует только высокий уроевнь или только низкий. В результате воздействия помех на вхлдах могут быть любые напряжения. Такаим образом, когда входное напряжение ("медленной" помехи) будет примерно равно половине напряжения питания, то входные транзисторы не будут четко закрыты. Они будут находится в "аналоговом" режиме. (Не в режиме отсечки или насыщения, а в активном режиме.) То есть через них будет протекает небольшой сквозной ток. Хоть этот ток и не большой, но в режимах сохранения энергии, он будет заметен. Тем более, что этот ток не одного вывода, а нескольких.

Я Ваш код скачал, но еще не смотрел. Элементарно нет времени. Вот некоторые приёмы, который помогут Вам понять, где и что в программе не работает. 1. Если в изделии есть каике-то светодиоды, которые подключены к ножкам МК, то начало борьбы с снеизвестностью будет вам облегчено. Поробуйте дописать в проект свой код, который бы тупо заставил их моргать при каком-либо наступающем условии или событии. Событие или условие должны наступать однозначно (точно), Вы должны быть в этом уверены. Например -- ежесекундные циклические обращения к какой-нибудь периферии. Сделайте так, что бы светик каждый раз менял свое состояние. 2. У Вас в изделии имеется UART. Подключите его к компу через RS232 или прокиньте его через USB. В консоли тупо задайте команду печати получаемой информации на экран. Это будет Ваш монитор. А в изделии напишите короткий код, который отправлял бы какой-нибудь байт (символ) на комп. Очень важно наладить сам канал передачи информации. Судя по вашим отзывам, Ваша проблема большая как слон. В подобных случаях я всегда задаю вопрос -- "Как съесть слона?" Правильный ответ -- "по кусочкам". Вот и Вам нужно делать так же!

Что значит -- "не корректно"? Уточняйте -- что КОНКРЕТНО выполняется не так, как ожидалось. За эту ничточку и вытягивайте различия между процами. Начните с самого простого. Коды программы кто писал -- Вы? Дописывайте кусочки кода для тестирования и проверяйте на железе. И не беспокойтесь, что расходуется ресурс проца по записи/странию. Он реально -- неисчерпаемый! Потратив личное время на решение своего вопроса, Вы получите коллосальный опыт, которий ни из книжек, ни из интернета не получить. Я не смогу за вас научиться плавать и кататься на велосипеде. Но я могу по ходу дела подсказать, какие движени вам нужно выполнять.

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

Задирать цену == плодить конкурентов. Не хочу говорить, что жадность наказуема, в конце концов на извлечении прибыли держится вся коммерция. Скорее всего, производитель ошибся в своих оценках потребительского рынка, за что и был наказан. Не правильно был определена потребность изделия (грубо -- вместо 100000 экземпляров заложили 1000). Это отразилось на конечной цене изделия. Возможно, решили извлечь сверхприбыль. Часть бабла ушла так же на создание защиты или еще какой-нибудь ненужной конечному потребителю хрени. Иначе говоря, пример еще раз доказывает, что не зная законов бизнеса можно с размаха влететь в стену.

Хорошо, попробую объяснить. Если Вы производите серийную продукцию, то Ваш бизнес уже защищен как минимум двумя преградами: 1. Вы поставляете продукцию на рынок и рынок знает Вас как поставщика этой продукции. Поэтому сначала будут обращаться к Вам, а уж потом к no-name поставщикам. Почему так дорого стоят изделия Sony и Toyota, и почему так мало просят за изделия неизвестных фирм? Пробиться на рынок со своим именем (со своей маркой) очень сложно. Не зря ведь существует такое явление франчайзинг. Иначе говоря, что бы продать свое изделие укравшему Вашу программу придется на каждой продаже терять. Если Вы на рынке будете продавать по себестоимости, то ему придется работать вообще в убыток. Понятно, что долго он не протянет. 2. Чтобы резко переориентировать массовое производство, а тем более создать новое направление, нужно сделать очень много затрат. Для этого нужны (понятно!) -- деньги, и нужно время. Таким образом, укравший Вашу прогу выйдет на рынок с опозданием и ослабленный. Ему бы сейчас самое время начать продавать и отбить свои затраты, но не тут-то было -- продать он может только по себестоимости или еще ниже. Я еще раз подчеркну, что нормальный лютый бизнесмен, который просчитывает свои ходы, никогда не опустится до воровства чужого, простите, говно-кода. Не льстите себе! А мелкая шпана, которая украдет Ваш код -- ну что они могут вам сделать! Ну изготовят пару десятков устройств, ну продадут пять штук. И сдохнут. Конечно, можно рассматривать эти пять устройств, как недополученную прибыль. А можно и рассматривать их как неизбежные потери, связанные с защитой Вашего рынка. Вы защищаете свой код, а я защищаю свой рынок -- ну и кто из нас в конечном счете выиграет? Врагов, на самом деле, -- нет. Есть проблемы личной амбициозности и неумения договариваться с соседями. А если Вы производите штучный товар, то тут еще сложнее продать копию. Заказчиков (потребителей) можно перечесть по пальцам. Все друг друга знают в лицо и величают по имени-отчеству. И если заказчик работает с Вами, и между Вами установились честные (партнерские отношения), то какой ему смысл менять поставщика? Даже если тот предложит на 10% дешевле? Хороший пример был лет пять назад, когда ATMEL перестраивала свой бизнес. Цены на AVR-ки выросли в разы. На рынке появились STM8. Какой процент разработчиков перекинулись в другой лагерь? Конечно, Ваше изделие и скопированное с Вашего наверняка будут больше похожи друг на друга, чем AVR и STM8. Но Вы постарайтесь уловить суть: менять партнеров -- затратно! А что касается очень больших денег, большого капитала, то с ним бороться бесполезно. Большой капитал либо вообще не заметит Вашего присутствия, и Вы просто будете оттеснены в сторону, либо "дружественно поглотит" Ваш бизнес. А будете сопротивляться, то произойдет что-нибудь типа рейдерского захвата. В любом случае, по соседству с очень большим бизнесом Вам не выжить. Просто отдавайте себе отчет в этом. А с соизмерим бизнесом нужно просто уметь договариваться и делить сферы влияния. И все будет нормально. Мир -- не коммунальная квартира. Мир, на самом деле, бесконечен, научитесь смотреть не только себе под ноги, а -- шире и дальше.

Пустые слова ни о чем. Вы путаете теплое с мягким. Украсть что-то из машины (или угнать ее) и украсть программу -- это разные вещи. Разные по _сути_. Да, оба действия противозаконны, оба квалифицируются как кражи -- то есть присвоение чужого. Но на этом их общие черты, в общем-то, заканчиваются. Поэтому говорить о них, как об одном и том же явлении -- это по меньшей мере демонстрировать свою необразованность в данном вопросе. Ну, не отличает человек одно от другого, ну и ладно!

Мои извинения!. Перед публикацией ссылок я не удостоверился в их валидности. (Тупо переписал со своих бумажных распечаток.) Ну, я не знаю, наберите что ли в строке поиска "Редактор связей gnu ld" и выберите из полученного списка то, что Вам нравится. Там полно всего.

Вообще описаний не очень много, но есть. Предлагаю начать с классики -- с UNIX-way. В Unux/Linux всё открыто и очень даже дружелюбно. Даже если Вы работаете в Виндовсе, то всё равно принципы линковки объектных модулей остаются одними и теми же. Классика -- она и есть классика. 1. Редактор связей gnu ld (описание на русском) http://linuxland.itam.nsc.ru/gnu/ld/dnuld.html 2. Книжка "Using ld", авторы Стив Чемберлен и Иан Лэнс Тэйлор http://www.arl.wustl.edu/~fredk/Courses/Docs/ld.pdf 3. Еще одна мощная книга "Linkers & Loaders" Джона Ливайна http://www.amazon.com/Linkers-Kaufmann-Sof...g/dp/1558604960 И не забывайте про Гугл!

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