Xenia

Я-то думала, что в нем фильтр встроенный, а так хороших операционников полным-полно. У меня лично стоит AD8552, он сдвоенный симметричный для + и - входа АЦП сразу (у меня используется дифференциальный режим). У меня нет необходимости прибегать к изолирующим входным усилителям, поскольку моя конструкция уже гальваноразвязана (АЦП питается через DC/DC, связь с МК развязана индуктивно - ADUM1401). Без гальваноразвязки работать было совсем невозможно. На счет этого я начитана :). Только всё это скорее для выравнивания потенциала, чтобы его уровень не гулял далеко от середины шкалы АЦП, а вовсе не для подавления сетевой наводки. Напоминаю :), что сетевая наводка - это гармоническая составляющая с нулевым средним, которая появляется из-за того, что тело человека либо служит антенной, либо имеет ёмкостную связь со внутренней поводкой помещения или электрическими приборами. Схватитесь пальцами за вход осциллографа - сами это наглядно увидите. Откуда этого так много берется, аж странно. Когда измерение ведется в дифференциальном режиме между двумя точками на поверхности тела, то сетевая наводка тут многократно меньше. Однако как только вы повысите усиление, намереваясь разглядеть милливольты, то сетевая наводка снова начнет вам досаждать, т.к. на этом уровне входного сигнала она весьма значительна. По ряду причин я не могу проводить подобные эксперименты в комнате, полностью изолированной от сети заземленным экраном на стенах, полу и потолке. С усилителем нет никаких проблем, проблема в том, как можно (если это все-таки можно) зарезать наводку от промышленной сети переменного тока (50 Гц) на входе усилителя. Поскольку при коэффициенте усиления 500-1000 она начинает зашкаливать за пределы шкалы АЦП, а мне хотелось бы разглядеть на ее фоне сигналы 1-10 милливольтовой амплитуды. Коэффициент усиления я хотела бы 500-1000. Чтобы при шкале АЦП ±2.5 В иметь возможность наблюдать сигналы с амплитудой 1 мВ. При усилении 1000 работать невозможно, т.к. сетевая гармоника начинает зашкаливать либо снизу, либо сверху шкалы. Я, конечно, центрируюсь, старясь удержаться на середине шкалы, то при таком размахе этого трудно гарантированно достичь. Вот и приходится работать на коэффициенте усиления 50-100. Увеличить его мне мешает проклятая наводка. Оттого и мой интерес к тому, чтобы ее на порядок (в 10 раз) понизить, чтобы иметь возможность в это же число раз увеличить усиление. А тут тема как раз подходящая открылась, вот я и рискнула задать вопрос, когда конденсаторы уже обсосали со всех сторон. Все эти математические премудрости хороши тогда, когда удается получить незашкаленную оцифрованную запись. Вот представьте ситуацию: АЦП зашкален вниз, непрерывно показывает -2.5 В (у него 5-вольтовая шкала с центром в середине диапазона), потом резко угодит в верхний зашкал, где непрерывно показывает +2.5 В, и так далее с периодом 50 Гц. Если усиление зарубить, то видишь синусоиду сетевой наводки, которая вызывала эти зашкалы то снизу, то сверху, поскольку не помещалась внутри шкалы АЦП. Неправда, кабель (даже с разомкнутым входом!) не дает такой сильной сетевой наводки, какая появляется в тот момент когда цапнешь за его жилы руками. Что толку пыжиться, экранируя эти несчастные проводки, если к ним присоединяется огромная туша тела :), без всякого экрана? Впрочем, входной провод у меня экранирован, только когда он присоединен к телу, это становится без разницы. Всё равно что взвешиваться вместе с блохой и без нее :). Да-да, всё это очень важно, но не будем отвлекаться от означенной темы. Вопрос поставлен относительно возможности сделать узкополосный завал на частоте 50 Гц во входном каскаде предусилителя АЦП. Очевидно, что ни вибрации, ни температурные изменения, ни пот пациента не влияют на величину сетевых наводок. Если бы в жилице человека электроэнергия подавалась в виде постоянного тока, то моих проблем попросту не существовало. Проблема в том, что мы фактически живем между обкладками конденсатора, к которому приложены 220 вольт переменного напряжения с частотой 50 Гц. И тут хоть стирай с себя пот или не стирай, добиться существенных изменений в ситуации не удается.

А вы мне посоветуйте чего-нибудь конкретное, а то я впервые слышу о существовании инструментальных усилителей для медицинских применений.

Ага, пронеслась. С децибелами мне редко приходится иметь дело - не по той формуле вычислила. За ответ спасибо!

Я когда задавала вопрос ничего конкретного в виду не имела. Ссылку эту посмотрела и задумалась... 50 Гц он, конечно, режет хорошо (-40 db), но на 100 Гц он давит полезный сигнал на -15 db (соглаcно графику Figure 2), т.е. в 32 раза. Это много. Кроме того, он резко изменит соотношение амплитуд составляющих внутри интересующего меня диапазона частот, т.к. правый край - 400 гц он практически не режет. Нужно думать. Хотелось все же, чтобы фильтр был еще более острым. Я не спец в фильтрах. Что касается самого АЦП (сигма-дельта ADS1255), то его фильтрующие способности, по-видимому, сильно завязаны на частоту дискретизации. Если установить частоту сбора данных 50 Гц, то сетевую наводку он рубит замечательно. Но мне, как понимаете, такая частота для оцифровки данных мала, т.к. мой диапазон 100-400 Гц. Таким образом, мне приходится работать на частоте дискретизации 1000-2000 Гц, чтобы хотя бы различать биения на 400 герцах. Поведение АЦП при этом таково, что при частоте оцифровки 5, 10 или 50 Гц сетевой помехи не видно, но она появляется во всей своей красе уже при 100 Гц. Все отлично до тех пор, пока полный период сетевой помехи целиком укладывается в период преобразования. Т.е. тут не столько АЦП своим фильтром ее фильтрует, сколько она сама самовычитается по причине своего нулевого среднего за этот период. Уже на частоте пребразования 100 Гц видно разительное отличие между четными и нечетными точками. А на частоте 1000 Гц я отчетливо вижу четкую гармонику 50 Гц, повторяющуюся через каждые 20 точек. В даташите на мой АЦП есть куча информации про эти фильтры, но я не вижу никаких средств управлять ими иначе, чем изменяя рабочую частоту оцифровки (data rate). Но такой возможности я лишена, т.к. фактически привязана к частоте 1000 Гц и снизить ее не могу.

Кондёры это спасение от высоких частот. А вот кто бы подсказал входной (относительно АЦП) фильтр для глушения сетевой наводки 50 Гц. Проблема в следующем - измеряются биопотенциалы человеческого тела, из-за чего полезный сигнал слабый, а сетевые наводки относительно велики (т.е. амплитуда полезного сигнала на порядок меньше частоты 50 гц, которая туда проникает). Частота наводки легко отфильтровывается цифровыми методами, но только в том случае, если ... она не зашкаливает за пределы шкалы АЦП. Вот и получается, как между Сциллой и Харбидой - при малом коэффициенте входного усиления наводку удается устойчиво держать в рамках, однако полезный сигнал при этом слишком мал и грубо оцифровывается, а если прибавить усиление, то сигнал становится достаточно интенсивным, но тогда сетевая наводка слепит АЦП, т.к. в местах зашкалов пропадает вклад полезного сигнала. Вот если бы можно было еще до входа АЦП пусть не полностью отфильтровать 50 Гц, а хотя бы понизить ее амплитуду на порядок, то был бы полный ажур. Кондёрами, как понимаете, эта проблема не решается. Нужен какой-то узкополостный фильтр низких частот. Кто-нибудь встречал нечто подобное перед входом на АЦП? P.S. Область частот полезного сигнал 100-400 гц, это, к сожалению, слишком близко к 50 гц, чтобы давить низкую частоту грубо (типа того, чтобы поставить разделительный конденсатор на проходе) - вместе с 50 герцами такой фильтр завалит мне и полезный сигнал.

Тут всё предельно просто. У такого АЦП имеется 8 входов. AINP1 - 1-ый вход, положительный AINN1 - 1-ый вход, отрицательный AINP2 - 2-ый вход, положительный AINN2 - 2-ый вход, отрицательный ... AINP4 - 4-ый вход, положительный AINN4 - 4-ый вход, отрицательный Присоединяете по термопаре к каждому входу, следя за тем, чтобы полярность ее ЭДС совпадала с названием выводов (+ к P, - к N). Если перепутаете, ничего страшного не случится, просто измеряемое значение окажется отрицательным. Такой режим называется дифференциальным, т.к. АЦП при этом измеряет разность между AINP и AINN. Но некоторые АЦП могут работать в униполярном режиме, когда все его входы измеряют напряжение относительно земли. Тогда каналов получается вдвое больше, но при этом будут иметь место недостатки, о которых я за недостатком времени распространяться не стану. Очень часто дифференциальный или униполярный режим позволяется задать программно. Тут тоже нет ничего сложного. После того, как АЦП получит число, его придется как-то передавать дальше. Тут существует два варианта - параллельный и последовательный. В параллельном режиме все биты числа выводятся на отдельные ножки, помимо которых выводится один дополнительный сигнал (строб) готовности. Т.е. в момент высокого уровня строба готовности с ножек АЦП можно считывать число. Так обычно работают принтеры на интерфейсе LPT или винчестеры на интерфейсе IDE/ATA - тянут шлейф с отдельным проводом под каждый бит числа + сигнал готовности. Такой способ обычно применяется на низкоразрядных АЦП (не более 8-ми байт). Однако представьте, что в нашем случае выходное число 24-битное! Представляете сколько нужно ног и проводов? Аж целых 25. А если в чипе 4 или 8 АЦП то тогда бы число проводов возрастет до 100 или 200, соответственно! За такую конструкцию по головке не погладят, а еще и пинка дадут :). И вот тогда переходят на последовательную передачу данных по одному проводу на канал. Т.е. передают не все биты числа сразу, а по порядку друг за дружкой. Для этого добавляют сигнал CLK (клок), который синхронизирует выдачу данных. Чаще клоком дергает тот, кто данные получает. После каждого подъема клока АЦП выдает на свой вывод (ножку DO - data out) очередной бит. Иногда приходится сколько-то подождать после подъема клока, прежде чем АЦР выплюнет свой бит. Величина такой задержки оговаривается в даташите на АЦП. Одновременно по другому проводу (DI - data input) этот же АЦП может принимать информацию (последнее бывает нужно при программировании режима его работы). Как видите здесь обходятся всего 3-ми проводами: выхода, входа и клока. Такой тип интерфейса связи называется SPI. Им можно передавать число любой разрядности за счет замедления передачи (тут она получается многотактовой). В настоящее время разработчики АЦП очень охотно идут на этот способ цифрового обмена, поскольку разрядности у современных АЦП прибавилось, а многоногих чипов люди не любят. Кроме того, время расходуемое на передачу не имеет значения, т.к. АЦП отдает/принимает цифровую информацию не прерывая свою преобразовательскую деятельность. Т.е. пока АЦП накапливает следующий отсчет, вы имеете возможность прочесть предыдущий. Но горе вам, если не успеете - отчет будет потерян или испорчен, т.к. данные о предыдущей цифре хранится лишь до формирования новой. Поэтому крепко подумайте, нужна ли вам частота 100 КГц. Представьте какой будет геморрой :) ловить от него биты с частотой выше 10 Мгц. На такие жертвы люди идут в области скоростных телекоммуникаций, но никак не при ... измерении температуры :). Я бы на вашем месте честно призналась преподавателю, что задание измерять температуру с частотой 100 кГц кажется вам полнейшим абсурдом. И договорилась бы с ним о снижении этой частоты хотя бы в 100 раз, а лучше в 1000. Если преподаватель не дурак, то ваши резоны он должен принять. А вам бы был тот профит, что ваше задание перешло из разряда экстраординарных в типичные. Вы бы могли тогда взять типовую схему подключения термопар к АЦП (ее частенько приводят в даташитах на АЦП) и этим без особого труда выполнить задание. P.S. Любопытства ради взгляните на даташит счетверенного/свосьмеренного АЦП Quad/Octal, Simultaneous Sampling, 24-Bit Analog-to-Digital Converters ADS1274/ADS1278 http://focus.ti.com/lit/ds/symlink/ads1274.pdf и описания демо-платы с его использованием: ADS1274 Evaluation Module (EVM) http://focus.ti.com/lit/ug/sbau134a/sbau134a.pdf АЦП от Texas Instrement удобно выбирать здесь: http://focus.ti.com/paramsearch/docs/param...NODE_STRY_PGE_T

В последнюю неделю IAR выпускает патчи под все свои компиляторы с dll-библиотекой ...jtagicemkII.dll Как с ней работать в приложении к AVR-компилятору написано невразумительно (дается ссылка на отсутствующий файл readme.txt), но в приложении для AVR32 (avr32jtagicemkII.dll) можно прочесть следующее: Новая библиотека avrjtagice-mkii.dll поставляется к последней версии компилятора в виде патча (5.30.5._0186.zip), модифицирующего его до версии 5.30.5. Это предпоследний патч, последний - 5.30.6._0191.zip.

Скажите, откуда взялись такие странные требования? Не только сама температура, но и ее датчики достаточно инерционны для того, чтобы повторять измерения с такой головокружительной скоростью. 100 КГц это же всего 10 микросекунд. У всех веществ есть теплоемкость, и она не маленькая. Заметно изменить температуру тела за 10 миллисекунд и то проблематично, не то что 10 микросекунд. И что вы с таким потоком данных потом делать будете? Обычно температуру измеряют не чаще 50 раз в секунду, подстраиваясь под частоту сети, чтобы наводки от последней не досаждали. Чтобы мерить, чаще нужны веские причины. Из вашего сообщения неясно, каков у вас датчик температуры. Термопара это, терморезистор или еще что-то. Если первые два, то они достаточно инерционны для того, чтобы к частотам выше 50 Гц не обращаться. Иначе есть опасность, что шум от сетевых наводок погубит вам точность измерений. Сигма-дельта АЦП действительно вещь хорошая. Но хороши они в основном тем, что выдают не мгновенное значение напряжения, а как бы среднее за время всего периода преобразования. Т.е. они, в буквальном смысле слова, накапливают значение за время периода. А отдавая одно оцифрованное значение, продолжают накопление следующего. Благодаря этому у них потрясающая точность измерения, поскольку гармонические наводки частотой, более высокой чем частота оцифровки, окажутся подавленными за счет того, что при накоплении их положительные полупериоды окажется сложены с отрицательными полупериодами, давая в результате ноль или близко к нему. Выбирая частоту преобразования 50 Гц, вы тем самым эффективно подавляете сетевую наводку, т.к. в этом случае в период оцифровки укладывается целый период частоты сети. Столько же хороши окажутся и кратные им частоты: 10 Гц (5 периодов), 5 Гц (10 периодов), 1 Гц (50 периодов) и др. Поэтому, если время терпит, то проводить измерения чаще, чем 50 Гц не рекомендуется. И, наконец, есть определенное затруднение с тем, что вы собираетесь использовать входной мультиплексор на 4 канала. Сигма-дельта АЦП не любят переключений на другой канал (т.е. на другое измеряемое напряжение). А это значит, что после такого переключения первые измерения на новом канале могут оказаться испорченными. Испорченными в том смысле, что это окажутся промежуточные величины между тем, что было на старом канале и тем, что имеется на новом. И в практических случаях приходится первые 3-5 измерений после переключения на другой канал выбрасывать. Т.е. работать приходится так: переключаемся на интересующий нас канал, снимаем 5 измерений на одном канале, забираем последнее 5-ое измерение, а про первые 4 забываем, дальше переходим к следующему каналу. Конечно, самый лучший способ, когда на каждом канале стоит свой АЦП, которые находятся в режиме непрерывного периодического преобразования, а следящий за ними микропроцессор оттаскивает данные по мере их готовности. То это решение слишком дорогое, хотя и бывают 4 (а то и 8) сигма-дельта АЦП в одном чипе, работающие синхронно. Все-таки это скорее экзотика. Я же склоняюсь к тому, что высокая скорость в этом деле не нужна, и для дела сгодится любой АЦП со входным мультиплексом. А если вам температуру в комнате мерить, в печке или под мышкой :), то тут высокая точность не нужна (из-за ограниченной точности самих датчиков) и можно было бы пойти на самое дешевое решение - использовать АЦП, встроенный в микропроцессор. Он хоть и не сигма-дельта, и разрядов у него, как правило, 10, но сотую градуса с трудом вытянет. А если надо хай-класс, то я бы использовала что-то типа ADS1256 от Texas Instrument. Но это исключительно мои личные предпочтения, основанные на практических результатах работы с этим АЦП. Там как раз 4 дифференциальных входа (при желании можно их использовать как 8 одинарных) при разрешении 24 бита! Это очень высокая точность, позволяющая точно определить, в каких границах гуляет шум, а где граница достоверных измерений. С этим инструментом можно вытянуть из датчика всю ту точность, которую он способен давать, не внося собственных искажений.

А что сможет сделать ПК с такой прорвой данных? Да он просто захлебнется в них! 200 МБайт/сек даже на диск не успеешь писать. И памяти ПК хватит лишь на несколько секунд, прежде чем она будут исчерпана. Хотелось бы узнать, какую участь вы уготовили ПК. Какова его задача в отношении лавинопоступающих извне данных?

Была 15-го числа на семинаре в Москве "АЦП/ЦАП Texas Instruments. Свойства, особенности, примеры применения". Так там очень настойчиво советовали не ставить конденсатор между входами АЦП сигма-дельта типа. А у вас какого типа АЦП?

Обращаю внимание присутствующих (и особливо суперпривередливого супермодератора), что этот топик не так прост, как можно заключить из его названия. Дело тут не в примитивном ногодрыганьи, а в том, что код, нормально работающий в нижних адресах памяти, не работает в верхних. На новичка Slev мало похож, новички xor-ом не моргают :). Данный пример программы, несомненно тестовый. И будь на месте человека, столкнувшегося с проблемой верхних адресов, профессионал, то он точно так же попытался бы запустить в этих адресах что-то моргающее светодиодиком. Я, к сожалению, не могу ответить на вопрос автора топика, т.к. сама не работала на mega с объемом flash выше 64К и EWB не использую. Однако подозреваю, что здесь что-то не ладно с фузами. Что-то типа того, что стоит защита, запрещающая обращаться к верхним адресам памяти. Такое бывает сплошь и рядом из-за требований обезопасить загрузчик (верхнюю часть памяти от попыток его протестировать через нижную загружаемую часть). Возможно и то, что таблица векторов прерываний оказалась по недосмотру поднята вверх, а старт остался снизу. Тогда тоже может случиться, что main() не получает управления. А вот заниматься поиском ляпов в программе не стоит, поскольку на нижних адресах памяти она работает. В любом случае, заданный вопрос достаточно серьезен, чтобы не вызывать раздражение модератора. Куда большие сомнения в отсутствии профессионализма следовало бы отнести к авторам реплик, не знающих механизма постинкрементации. Программа написана свершенно верно. Проблема же только в том, отчего она не работает в верхних 4К адресного пространства.

Так и я о том, что как только в голове появляются мысли про такты, следует обращаться к ассемблеру, чтобы эти вопросы урегулировать. Он для того и сделан, чтобы программить в тактах. Но если мысли о тактах вас не посещают, то и думать о них не надо - используйте C. Последннее дело - думать про такты, но програмировать на С :).

У вас "лишняя" проверка cmd & 0x80, т.к. тестировать быстрее при сдвиге cmd <<= 1, поскольку этот бит выпадающий. К другим недостаткам вашего кода можно отнести отсутствие однотактной задержки между установкой MOSI и подачей клока SCK. Здесь желательно тоже пропустить один такт, чтобы MOSI успел достичь своего максимального или минимального значения. И вообще, потуги вроде ваших :), возникают исключительно вследствии того, что вы знаете, какой должна быть данная процедура в кодах МК, но пыжитесь достигнуть этого, укрощая С. В таких случаях было бы более эффективно, если бы вы воплощали свое знание сразу на том языке (в данном случае ассемблере), который плозволяет учитывать все необходимые нюансы. А так вы вместо этого боретесь с языком С, пытаясь подогнать его под требуемую ассемлерную кодировку. Язык должен быть помощником, не противником. Не стоит мучить С, чтобы он выдавал тот код, который без напряга можно было бы написать на ассеблере. А на языке С пишут обычно то, в отношении чего у вас не будет в дальнейшем притензий к компилятору.

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

Поправила. Да-да! Это очень важно! И вовсе не для эстетов. В ассеблерную процедеру есть возможноть натолкать столько nop (пустых операций), чтобы сделать любую дополнительную задержку. Это очень даже может понадобится тогда, когда МК работает на более высокой частоте кварца, чем необходимо, чтобы соблюсти требования ведомого устройства. И тут дело не только в частоте его кварца, сколько в технических требованиях к обмену. Это весьма типичная задача при работе с АЦП, в даташите которых расписаны тайминги на SPI обмен. Ассемблер очень хорош как раз для соблюдения всех этих таймингов и латентного времени между передачей команды и приемом данных. Однако смысл имеет писать на ассемблере только такую интерфейсную часть программы. Полностью переходить на ассемлер не советую - ошибки на нем совершаются гораздо чаще, чем на C, и программировать на нем медленнее.

SPI куда элегантнее программировать на ассемблере, если аппаратно этого сделать по каким-то причинам нельзя. Элегантность заключена в том, что так можно эффективно использовать флаг переноса при сдвигах, строго выдержать меандр по времени (хотя последнее, обычно, не требуется) и сделать правильные задержки. На чистом С такое написать нельзя. Здесь приведены сочиненные мной процедуры: void Wr_Reg( char byte); // запись по SPI в регистр АЦП char Rd_Reg( void); // чтение по SPI регистра АЦП Вся остальная программа у меня на С, откуда я и вызываю функции Wr_Reg(byte) и Rd_Reg(). Их описание в хидере я только что привела, их тела на ассемблере выглядят так: RSEG CODE:CODE:NOROOT(1) PUBLIC Wr_Reg Wr_Reg: ldi R17, 8 LoopWrReg: sbi PORTD, SCLK; установим SCLK в 1 rol R16; сдвигаем регистр brcs SetSDI cbi PORTD, SDI; SDI = 0 rjmp CliSCLK; 2 clocks SetSDI: sbi PORTD, SDI; SDI = 1 nop; 1+1 clocks nop CliSCLK: cbi PORTD, SCLK; установим SCLK в 0 dec R17 brne LoopWrReg; если не 0 ret PUBLIC Rd_Reg Rd_Reg: ldi R17, 8 clr R16; обнуляем регистр LoopRdReg: sbi PORTD, SCLK; установим SCLK в 1 nop cbi PORTD, SCLK; установим SCLK в 0 lsl R16; сдвигаем регистр sbic PIND, SDO; SDO ? ori R16, 1; устанавливаем мл.бит dec R17 brne LoopRdReg; если не 0 ret Связь осуществляется через порт D, который можно заменить на любой другой. SDI, SDO и SCLK по назначению соответствуют MOSI, MISO и СLK. Суть не меняется, если вместо АЦП будет какое-то другое устройство. P.S. Проект на IAR EWAVR, в котором имеется один ассемблерный файл (этот), а остальные на C. Микроконтроллер ATtiny2313.

Хуже, чем описание работы USB, ничего на свете нету :). Купила обе книги Агурова - "Интерфейс USB" и "Практика программирования USB", пыталась это читать. Но разве это читать можно? :) Жуть сплошная. Чем дальше читаешь, тем непонятнее становиться :). А когда дошла до описания протоколов и форматов структур, мне и вовсе поплохело :). Поэтому я пошла другим путем, близким к тому, что рекомендовал здесь aaarrr - взяла документацию на свой "родной" AT90USB647 (это МК архитектуры AVR со встроенным USB) и принялась разбираться в демонстрационной программе USB-COM конвертора, попутно разбираясь в назначениях USB-регистров по даташиту. Через некоторое время я сократила эту программу от всего того, что мне не было нужно (например от HOST-режима, обслуживания других задач и пр.), оставив три функции: 1) инициализацию USB, т.е. те действия, которые необходимо провести всего однажды, чтобы USB заработало. 2) функцию отправления байта по USB (тут на самом деле они сначала кладутся в буфер, а отправляются группой) и 3) функцию, которая вызывается по прерыванию, когда по USB приходит передача. Вообще-то ничего кроме этого мне не было нужно. Помимо этих необходимых мне функций пришлось оставить механизм обработки USB-прерываний, в котором приходится отвечать на всякие каверзные запросы хоста, т.к. без этого с моим USB-устройством никто бы не захотел разговаривать. В процессе такого разбирательства мне неоднократно приходилось обращаться к книге Агурова "Практика программирования USB", но лишь затем, чтобы выяснить назначения тех или иных констант, записанных в структурах, которые передаются в ответ на запросы. Т.е. тут я уже дошла до того, что некоторые поля подправила под себя - увеличила длину буфера на передачу, убрала "лишнюю" endpoint, запросила больше тока питания, придумала своему устройству красивое имя и т.п. После всего этого сотворила двойную (или уже тройную?) буферизацию, организовав кольцевой буфер размером 256 байт в памяти, откуда данные отсылаются по USB-прерываниям. Тут дело в том, что USB мне нужно, чтобы отсылать данные от "говорливых" АЦП. И здесь у меня нет времени, чтобы ждать, когда USB отправит данные. А я просто кидаю байты в свой буфер, не заботясь об их отправке, а "голодные" прерывания от USB сами черпают из буфера, если там еще что-то неотправленное осталось. После этого моя программа перестала быть понятной другим :), зато оставалась понятна мне. И вот, странное дело! - Открываю я снова книги Агурова, читаю и вдруг обнаруживаю, что всё (или почти всё) мне в ней стало понятно :). Такова участь большинства инструкций, которые обладают хитрой особенностью сохранять непонятность тогда, когда мы остро нуждаемся в понимании, и быть абсолютно ясными, когда понимание уже за плечами.

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

Да. Я вам в личку написала. Таймер очень уж быстро считает, отражать состояние его счетчика в реальном времени отладчику компилятора не по силам - он так быстро не сможет обновлять картинку. Кроме того, отладчики обычно работают пошагово - сделают шаг, а затем распечатывают состояние регистров. А за "бегущим" состоянием регистра им не уследить, ведь время шага не соответствует реальному такту МК, значит и понятия времени здесь нет.

Александр77, не окажете ли вы мне ответную услугу - поделиться своим компилятором? Он представляет для меня теоретический интерес. По роду добровольно взятой на себя общественной работы я "заведую" IAR-компиляторами на здешнем FTP. Уже 4-ый год коллеционирую оные, хотя сама лично работаю только с AVR. У меня очень большая коллекция (выкладывать ее полностью на FTP не имеет смысла из-за отсутствия спроса на старые версии), но такой версии, чтобы писала EW78KOR, у меня нет. Очень хотелось бы заполучить ваш экземпляр, чтобы разобраться, что он собой представляет и чем отличается от EW78K. Можно ли это как-нибудь устроить?

У вас на картинке точка на Other не стоит! Format надо выбирать Other, чтобы intel-standart не было засерено. И на Override default нет галочки. Прочтите, что я вам написала раньше!

Э, нет! Сначала надо приступать к опытам, а по мере набивания шишек станет интересно читать матчасть :).

По этому поводу у меня ответа нет. Я вообще никогда не видела, чтобы компилятор когда-либо вис. Может у вас триал-версия, а срок использования уже истек? Что-то меня смущает этот K0R, а у меня представляется как "IAR for NEC 78K 4.40A".

Project => Project Option => Category: Linker => закладка Output Галочка перед "Override default" - вписываете имя прошивки, например, "proshivka.hex" но лучше назвать по имени проекта. Точечка перед "Other", выбираете: Output format: intel-standart Format variant: None Mode-local symbol: include all OK После этого на дереве проекта в желтой папочке Output должен появиться "proshivka.hex". В нем и будет получаться эта прошивка после компиляции. А сам этот файл будет лежать в \Debug\Exe\proshivka.hex P.S. IDE, на мой взгляд, гораздо удобнее, чем вызывать компилятор и линкер из командной строки. Но некоторые ("Юниксоиды") приемлют только последний вариант. А на zitigo внимания не обращайте - у него тяжелый характер :) :) :).

Обычно в меню Project жмешь "Build All" или "Make" (F7), а после компиляции ловишь в поддиректории Debug\Exe\ , которая создается сама относительно того места, лежит лежит исходник. Про отладку я вам не отвечу, а вопросик задам: какой версии компилятор от IAR вы используете? Для вашего процессора вроде бы последний EW78K-4621. Это так?