Xenia

Базовое знание - уметь вставлять в розетку паяльник! :) :) :)

Вот только изготовители программаторов в гробу видели этот стандарт! Например, Фитон (http://www.phyton.ru) рекомендует для внутрисхемого программирования МК типа ATtiny и ATmega адаптер собственного производства AE-ISP-U1, который по внешнему виду один в один похож на атмеловский (5x2), только все линии перепутаны совершенно в невообразимом порядке. Причем купив такой адаптер, вы остаетесь в неведении относительно его распайки. И даже если задаться целью найти эту распайку на сайте производителя, то сделать это не так-то просто. А если все-таки вам это удастся, то крайне удивитесь. А вот клевый документик - http://www.remkas.ru/files/tabl_sootv.pdf , позволяющий взглянуть на жуткую картину, царящую в стане изготовителей программаторов. Одно только название "ЖгуКаб" говорит само за себя :). Тут самая подходящая фраза - "кто во что горазд".

Переписывать вашу программу мне лениво, тем более отлаживать мне ее не на чем. Между тем причины, вызывающие у вас затруднения, мне непонятны. Ведь если вы уже умеете перезаписывать прошивку, начиная с нулевого адреса, то разве может возникнуть проблема загружать не нуля, а выше? Начинайте запись не с нулевой страницы, а с той, где у вас пустота начинается, - вот и вся разница. Пример самопрограмирования обычно приводится в даташите, в разделе про boot-загрузчик. Конкретнее ответить не могу, т.к. вы не называете ни типа вашего МК, ни компилятор, которым пользуетесь.

Попробуйте взять отсюда: http://www.4shared.com/file/95551839/60fe7...rified=22f04584 P.S. Если бы вы написали мне в личку, то я бы отреагировала на вашу просьбу сразу, а так я лишь спустя почти месяц совершенно случайно наткнулась на этот ваш пост.

Надо не резервную копию хранить, а начинать перепрошивку не раньше, чем убедишься в том, что новая прошивка скачалась целиком и без ошибок. Самый простой способ - взять МК с запасом собственной Flash. С таким расчетом, чтобы после прошивки оставалось не меньше половины свободного места. Тактика такая: новую прошивку прошиваем сначала на свободное место флэша - на верхние свободные адреса памяти. Тут мы ничем не рискуем, даже если связь по дороге оборвется или новая прошивка придет с ошибками. Когда загрузка новой прошивки будет завершена, приступаем к ее проверке - тут самое простое проверить по контрольной сумме. Убедившись, что новая прошивка хороша, переписываем новую провшику из верхних адресов флэш-памяти в нижние, чем и замещаем старую прошивку на новую. Код в верхних адресах стирать нет необходимости. Этот подход удобен еще и тем, что на время копирования из верхней памяти в нижную, можно заблокировать все прерывания, чтобы обезопасить процесс замещения. В то время как запись фрагментов новой прошивки в верхнюю память осуществляется в обычном режиме, т.к. работу МК повредить не может.

Помимо сигнатуры многие МК архитектуры AVR имеют уникальный серийный номер (Unique Serial Number). Хранится он рядом с сигнатурой, и достается похожими командами. Вот, например, выдержка из даташита на AT90USB647: Table 28-6. Signature Row Addressing Signature Byte Z-Pointer Address Device Signature Byte 1 0x0000 Device Signature Byte 2 0x0002 Device Signature Byte 3 0x0004 RC Oscillator Calibration Byte 0x0001 Unique Serial Number From 0x000E to 0x0018 Там много знаков - целых 10 байт!

IAR и PowerPack, скорее всего, тут не виноваты. Для PowerPack'а существует отдельный GUI (см. http://iar.com/website1/1.0.1.0/1763/1/ ), промимо USB и TCP/IP-стека, вот только его достать можно лишь за большую денежку, т.к. по WEB он не распространяется. Проблема видимо в том, что данный GUI оказался "чужеродным" (взятым из другой системы) и поэтому конфликтует с RTOS. Где это происходит, сказать трудно, но проблема тут того же рода, когда ругают Микрософт Виндоус за то, что запущенная под ней программа глючит. В большинстве таких случаев виновата бывает сама программа, а не операционная система.

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

Скажите пожалуйста, частота вращения ваших ШД определяется частотой меандра или его скважностью? Если скажностью, то такая задача может быть решена, т.к. на одном таймере можно приготовить несколько меандров с различной скважностью. А если частотой, то дело гиблое - на одном том же таймере две частоты не создашь.

Это означает, что нужно еще поделить на корень из 2. Корень их двух как раз равен 1.41421356237309505, что, с учетом погрешности вычислений, дает все цифры вашего числа. А когда поделите, то получите точно 1000, как и должно быть. Для полной уверенности поверьте на другом N.

Полагаю, что нужно разбираться с конкретным алгоритмом FFT, а не рассматривать вопрос о масштабном множителе в отрыве от этой информации. В зависимости от применяемой модифицикации алгоритма масштабный множитель действительно может отличаться в два раза. Дело тут в том, что FFT-преобразование по своей природе комплексное, однако чаще всего наши исходные данные являются строго действительными и не содержат в себе мнимой части (например, данные от АЦП). Из-за этого могут существовать "тупой" и "умный" алгоритмы FFT, отличающиеся между собой возможностью учета того, что исходные данные действительные. "Тупой алгоритм" попросту приписывает к массиву данных еще массив такой же длины, заполненный нулями, который будет выполнять роль нулевой мнимой части. После чего на этих двух массивах запускается алгоритм комплексного FFT. В результате его получаем "бабочку": в действительной части результата (cos-части) имеем строго зеркальную картину - в первой половине (до N/2) расположены cos-коэффициенты, а во второй половине они же в обратном порядке; во мнимой части результата (sin-части) таже самая история, только зеркальные коэффициенты имеют противоположный знак. Когда таким результатом пользуются, то используют коэффициенты до N/2, а на остальное внимания не обращают, считая это мусором. "Умный алгоритм" экономит память, но более трудоемок в реализации. В отличие от "тупого" алгоритма он не заводит дополнительный массив под мнимую часть, а также не оставляет после себя зеркальный мусор. Поэтому его чаще используют в МК, где память в дефиците. "Умный алгоритм" поступает иначе. Он не создает отсутствующую мнимую часть, а просто использует первую половину исходных данных, как действительную часть, а вторую половину - как мнимую. Первичный результат такого FFT-преобразования получается, конечно же, неправильным, но из него можно извлечь правильный результат хитрым способом. В этом случае половинки получаются уже не зеркальными, а правильный результат из них можно выделить, если вычислять полусуммы и полуразности между отражениями. На двойку тут обычно не делят для скорости, из-за чего получают масштаб вдвое больший, чем при использовании "тупого алгоритма". Чтобы не заниматься анализом алгоритма (тем более, если не вы сами его составляли), проще всего заполнить массив исходных данных тестовой кривой - например чистой синусоидой с амплитудой 1000: for( int i=0; i < N; i++) data = 1000 * sin(2*M_PI/N*i); А потом применить к этому массиву данных ваш алгорим FFT и посмотреть, какую амплитуду он выдаст для 1-ой гармоники. Отсюда и вопрос о масштабе сразу прояснится.

Удвоенному опорному! При Vref=2.5V в униполярном режиме полная шкала 5V. Однако так не для всех АЦП - те, что встроены в МК, действительно требуют опору, равную величине шкалы. Прошу вас соблюдать на форуме правила приличия и не опускаться до унижения собеседников.

В этом случае, после перемещения данных в переменную типа в long достаточно вычесть из нее 0x800000, чтобы получить стандартное представление, где нуль находится на нуле, а не на 0x800000. Полная шкала для этого АЦП, кажется, равна удвоенному опорному (без учета Gain). Но в даташите это должно быть написано точно. Страница 11 даташита (ревизия C):

Получите - не получите, но все эти 24 бита они выдают, как бы ни шумели младшие биты. Поэтому поднятый в теме вопрос о том, как преобразовать эти 24 бита в число, с которым можно работать, остается правомерным. А шум при желании можно фильтровать, если измерения поступают часто, а изменяемая величина малоподвижная, типа термопары.

Это обычное число в двоичном формате. Обычно бывает достаточно приписать спереди еще один (старший) байт, содержащий нули, чтобы получилось типичное число типа unsigned long (32-битное беззнаковое целое). В тех случаях, когда АЦП работает в дифференциальном режиме, то выдаваемое им число может оказаться со знаком. Тогда приписываемый спереди байт заполнятеся нулями только в том случае, если старший бит данных является нулем, или заполняется полностью двоичными единичками, если старший бит является единичкой. Этот метод носит название "расширения знака", т.к. здесь старший бит данных распростаняется на всю приписываемую спереди часть. Последнее не есть какая-то специфика АЦП, а представляет собой типичный метод, которым более короткое знаковое число копируется в более длинное. Короче говоря, берете число типа long, зануляете его, запихиваете 24-битные данные от АЦП в его младшие 3 байта, а потом разбираетесь с тем, что получилось. Оно окажется либо пригодно сразу, либо потребует минимальную коррекцию: if (xlong >= 0x800000) xlong |= 0xFF000000;

Это всё новички, которые доступа к ftp не имеют. Поскольку регистрация на форуме свободная, любой желающий может на нем зарегистрироваться и тут же выложить свой пароль на всеобщее обозрение. А вот участника с интересным ником "HyuVam!" и не менее интересным паролем "Pizda!" :) вообще в списках участников нет. Что ж теперь каждый день всем пароли менять из-за той чепухи, что пишут в интернете?

Вообще-то за 0.7 сек можно спокойно передать эти 400 точек даже по самому медленному из существующих каналов. И не мучить АВРку.

На платформе AVR, как и на любой другой, можно запрограммировать любые вычисления, если ... хватит места под данные. Особеность тут только та, что МК этой платформы не имеют аппаратного умножения чисел с плавающей точкой, а с использованием эмуляции сложный расчет может занять порядочное время. Полином 11-ой степени уже не подарок, т.к. расчет в лоб потребует инвертирования матрицы, которая к тому же очень плохо определена (близка к матрице Гильберта). Поэтому такой расчет на AVR лучше не делать, а если и посылать в него данные, то не коэффициенты полинома, а уже готовую обращенную матрицу, чтобы тот только множил на нее вектор данных и больше ни о чем не заботился. А ту матрицу пусть хоть писюк посчитает. Только при этом нужно учесть, что такая матрица-сомножитель для вашего случая будет иметь размерность 400x11=4400 элементов, а если каждый по 4 байта (тип float), то выйдет 17.6 килобайт. Уже многонько, не каждая AVR-ка потянет. А с точностью double потребуется еще вдвое больше памяти. Да и само умножение получится не быстрым при такой большой матрице и медленной реализации умножения. А если говорить об алгоритмах, то тут, полагаю, надо попытать расчет коэффициентов через полиномы Чебышева. Кажется где-то есть такой способ, отличающийся устойчивостью. Однако в любом случае AVR придется делать одну и ту же операцию умножения вектора длиной 400 на матрицу размером 400х12. А алгоритмы будут различаться между собой только тем, как такая матрица вычисляется. В любом случае вычислять ее надо будет не на AVR, а засылать ему уже готовую.

С чего бы это вдруг, если оба выставляют или снимают маски с прерываний? CLI это вроде рубильника, отключающего электричество во всем доме, а TIMSK - для отдельной квартиры. И с точки зрения отдельной квартиры, все равно как в ней свет отключили - главным домовым рубильном (CLI) или тем, что стоит на лестничной клетке рядом со счетчиком (TIMSK). Никаких дополнительных задержек не возникнет ни в том, ни в другом случае. А вы собрались пред тем, как отключить от сети свой телевизор, предварительно обесточить всех жильцов в доме :). И расчитывете, что так ваш телевизор отключится быстрее.

Тогда, следуя вашей логике, надо и после CLI ставить нопы :), поскольку CLI точно так же стирает маску, как и TIMSK=0 (только в другом регистре масок - в SREG). И по своей аппаратной реализации ничем не отличается.

Не поняла вопрос. Если вы успели установить TIMSK=0 (т.е. когда обнуление этого регистра состоялось), то никакого прерывания от таймера больше не будет, как не будет и никакой "подготовки к прерыванию". Зачем вообще нопы ставить? В архитектуре AVR, по моему мнению, не бывает никаких "подготовок", а вопрос быть прерыванию или не быть, решается в промежутках между инструкциями. Вот тогда-то и будет решен вопрос о том, переходить ли к следующей по порядку инструкции или вылететь на прерывание. Проверка на совпадение флага прерывания и его маски производится, несомненно, аппаратно. Так что если некая инструкция обнуляет маску прерывания, то следом за ней прерывание уже не последует, даже в том случае, если бит прерывания оказался к этому моменту уже взведен. Точно так же прерывание не может случиться во время выполнения какой-либо инструкции. Отсюда следует, что ставить нопы не нужно.

Умные советы вроде иссякли, поэтому дам совет дурацкий, а точнее иррациональный: запитать XTAL1 на +5V через резистор 5 ком. Типа для проверки. Ведь то, что генератор все-таки запускается при кратковременном снятии питания, наводит на мысль, что при включенном питании на какой-то пин натекает плюс, что способствует запуску. А при холодном старте такого натекания нет. Скорее всего, этот пин XTAL1, другому вроде бы некому.

Есть резон заглянуть в софт, поставляемый к демонстрационной плате EVK1100 с установленном на ней AT32UC3A0512. Речь идет об архиве AVR32-SoftwareFramework-AT32UC3A-1.4.0.zip или -1.5.0.rc1.zip. См. http://www.atmel.com/dyn/products/tools_ca...sp?tool_id=4192 Там в этом архиве среди всякой всячины встречаются определения (через #define) следующих функций: Is_usb_endpoint_dma_interrupt(epdma) Is_usb_endpoint_dma_interrupt_enabled(epdma) Is_usb_endpoint_int_dis_hdma_req_enabled(ep) Usb_disable_endpoint_dma_interrupt(epdma) Usb_disable_endpoint_int_dis_hdma_req(ep) Usb_enable_endpoint_dma_interrupt(epdma) Usb_enable_endpoint_int_dis_hdma_req(ep) Usb_get_dma_buffer_size() Usb_get_dma_channel_nbr() Usb_get_dma_fifo_word_depth() Usb_raise_endpoint_dma_interrupt(epdma) Судя по их названиям, есть вероятность, что USB с участием DMA там реализован. Архив слишком большой - 66 Мб исходников и текстовых материалов, поэтому я глубоко в нем не копалась. Если того, что вам надо, там нет, то извиняйте.

А откуда вы взяли, что там должен быть параметр? Просто "FUNCTION test" не проходит? У меня впечатление, что FUNCTION является заменой PUBLIC. Попробуйте "FUNCTION test" раскомментировать, а PIBLIC закоментировать. P.S. Прошу прощения, но у меня IAR компилятор для AVR, а не для PIC18, поэтому могут быть расхождения в синтакисе языка.

Скорее всего в ассемблерной части вы забыли объявить сегмент. Например так: RSEG CODE:CODE:NOROOT(1) PUBLIC Wr_Reg Wr_Reg: nop nop ret Как называется по умолчанию мой сегмент кода, а как называется ваш - узнаете, если взглянете на листинг C-шного кода.