DmitriyX

Интересно... а я *.out файл даже не заливал, просто стереть пытаюсь. Ну ладно, по прежнему принимаются любые идеи по решению проблемы.

Precompaction делает функция библиотеки Flash_API, написанная TI. Я к ней отношения не имею, поэтому как вариант, можно обратиться в тех-поддержку, напишу им. Но если кто-то с такой проблемой сталкивался, то было бы интересно узнать, решаема ли она и как быть.

Не больше 5 раз я ее перезаписывал. Экспериментировал с записью в сектора I и J, но не стирал их. Для этого вызывал функции Flash_API в программе процессора. Когда начал стирать - началась эта ошибка. Попробовал через FlashProg диалог - то же самое. Единственное, место где про ошибку написано - документ на Flash API. Цитирую: This error code is new as of V2.10 of the API. Erase operation failed because the pre-compaction portion failed. The pre-compaction is applied to all sectors on the device. The FLASH_ST structure will return a fail address corresponding to the first sector fails this step. Что тут написано, я не понимаю. Вариант, что я мог случайно записать что-то в биты защиты, исключаю, т.к. точно наблюдал по каким адресам вызываю функции записи. Иногда еще наблюдается другой симптом: нажимаю в диалоге программирования "Erase Only". Появляется сообщение "Erase operation in progress..." и так и остается бесконечно долго (минут 10 ждал). Процессор в это время в RunMode.

Раньше нормально удавалось перезаписывать программу во Flash контроллера. А теперь при стирании любого сектора возникает сообщение об ошибке: error #24, STATUS_FAIL_PRECOMPACT. Первый раз такое вижу, описания в интернете и в базе знаний TI не нашел. Может кто-то сталкивался?

ой, прошу прощения, 0,03-0,04 секунды. А можно поподробнее про обратную связь по реальному воздействию? Что она дает?

Структурная схема управления приводится ниже. Управление осуществляется в цифре. Информация о двигателе: http://mashap.maverick.ru/rus/eeng.html Модель двигателя: ДБМ40-0,01-5-3 1. Период измеряю таймером с частотой 150 МГц, получается чуть больше 6 наносекунд. 2. Честно говоря не знаю, пропорционален ли момент квадрату тока. Мне почему-то казалось, что скорость двигателя прямопропорциональна току в обмотке. 3. Разрядность ШИМа 10 бит. Двигатель удается разогнать, но не быстро. Подав максимальное воздействие, он разгоняется до номинальной скорости где-то за 0.3-0.4с минимум, должно укладываться в 0.5с. Но увеличение момента инерции это идея хорошая. Хотелось бы эту систему промоделировать и теоретически проверить различные методы эффективного управления. Только учитывая все приведенные выше особенности системы затрудняюсь составить ее модель сходу. Но в любом случае буду благодарен за советы, какие алгоритмы управления подойдут в этом случае лучше. Struct.bmp

Да, трехфазный двигатель. Две его обмотки висят в воздухе. На третью подается напряжение от -27В до +27В. Поскольку угол поворота двигателя требуется от -4 градусов до +4 градусов, то напряжение подается только на ценральную обмотку. Измеряю точный период между фронтами. На основе длительности расчитываю воздействие и подаю его на ШИМ. Пробовали без сглаживания - мотор начинает визжать и регулирование ужасное. Аппаратную схему на данном этапе менять не представляется возможным. Поэтому в данной теме интересует мнение с точки зрения теории, расчета воздействия при наличии описанного выше измерительного канала.

Регулирую скорость. Про датчик совсем забыл написать. Датчик движения скорости - лазер. Система преобразования сигнала с лазера (в подробности системы не вдавался) на выходе выдает меандр, частота которого пропорциональна скорости движения двигателя. Требуемой скорости движения двигателя соответствует частота меандра 52.5 КГц. Т.е. чаще, чем с 52КГц не получится изменять воздействие. Воздействие на двигатель - ШИМ с последующим сглаживанием. Каким образом это можно учесть в модели?

Не удается управлять на практике. А на модели я не знаю как смоделировать источник ошибок таким образом, чтобы после получения интегратора не удавалось регулирование. Траектория следующая: разгон за 0.05с, движение с постоянной скоростью 0.5с, торможение 0.05с. На участке движения с постоянной скоростью необходимо поддерживать постоянную скорость с точностью 0.1%.

Требуется управлять двигателем переменного тока с тремя обмотками. Требуемый угол поворота двигателя от -4 градусов до +4 градусов. В связи с этим, для управления двигателем задействуется только ОДНА его обмотка, скорость движения двигателя будет пропорциональна току в этой одной обмотке. Требуется управлять двигателем, чтобы от разгона до торможения колебания его скорости составляли не более 0,1%, т.е. высокоточно регулировать. В документации на двигатель нашел значения электрической и механической постоянной времени. Простейшая модель двигателя, которая напрашивается после этого - два апериодических звена, соединенных последовательно. В модель также добавил белошумные источники помех измерений и помех воздействия. Рисунок модели прилагается. Изначально предполагалось управлять двигателем с помощью классического ПИД-регулирования, но требуемой точности достигнуть не удалось. Пытался синтезировать коэффициенты при теоретических расчетах следующим образом: получить такой ПИД-регулятор, который после перемножения на передаточную функцию двигателя дает интегратор 1/s. Но после расчета возникло затруднение точным образом оценить ошибку регулирования. В связи с этим следующие вопросы: 1. Каким образом усовершенствовать модель описанного выше двигателя? Может трение в осях добавить? (только плохо представляю как сделать это в операторной форме). Может как-то еще? 2. В связи с тем, что ПИД-регулирование не достигает нужной точности на практике, предполагается применить адаптивные алгоритмы регулирования, но изучением их я пока еще на начал заниматься. Каким образом и в каких моделях можно будет адеквадно оценить ошибку адаптивного регулирования? (в операторной форме адаптивные алгоритмы ведь не моделируются) 3. Если кто-то занимался работой с адаптивными алгоритмами регулирования, то буду очень благодарен за ссылку на материалы об этом. DvigModel.bmp

Процессор TMS320DM642. Имеется буфер, состоящий из 64 ячеек по 256 Кб. Размещается в некэшируемой внешней памяти. Регулярно идет помещение объектов в буфер и доставание их оттуда. Приблизительно через час после начала работы в какой-то момент времени функция BUF_alloc возвращает неадеквадное значение (не 0 и не адрес свободного буфера). Через watch смотрел состояние буфера, вроде бы значения там адеквадные. Каким образом и что могло привести к подобному поведению? Подробности: Фрагмент кода: QUE_Elem *p= (QUE_Elem *) BUF_alloc( m_phBUF ); в какой-то момент возвращает значение 0x0033525B или 0x0035525B (зависание поймано два раза). такого адреса в конфигурации dspbios нет. Он находится между внутренней и внешней памятью. Конфигурация DSPBIOS: bios.MEM.create("MONRAM"); bios.MEM.instance("MONRAM").base = 0x00030000; bios.MEM.instance("MONRAM").len = 0x00010000; bios.MEM.instance("IRAM").len = 0x00030000; bios.MEM.instance("IRAM").createHeap = 1; bios.MEM.instance("IRAM").heapSize = 0x00004000; bios.MEM.create("CEXTDRAM"); bios.MEM.instance("CEXTDRAM").base = 0x80000000; bios.MEM.instance("CEXTDRAM").len = 0x01000000; bios.MEM.instance("CEXTDRAM").createHeap = 0; bios.MEM.instance("CEXTDRAM").space = "data"; bios.MEM.instance("CEXTDRAM").comment = "кэшируемая внешняя память"; bios.MEM.create("UEXTDRAM"); bios.MEM.instance("UEXTDRAM").base = bios.MEM.instance("CEXTDRAM").base + bios.MEM.instance("CEXTDRAM").len; bios.MEM.instance("UEXTDRAM").len = 0x06800000; bios.MEM.instance("UEXTDRAM").createHeap = 0; bios.MEM.instance("UEXTDRAM").space = "code/data"; bios.MEM.instance("UEXTDRAM").comment = "некэшируемая внешняя память"; bios.BUF.create("BUF_SendResults"); bios.BUF.instance("BUF_SendResults").size = 65536*4 + 16; bios.BUF.instance("BUF_SendResults").bufCount = 64; bios.BUF.instance("BUF_SendResults").align = 4; bios.BUF.instance("BUF_SendResults").comment = "IFG Send Results"; bios.BUF.instance("BUF_SendResults").bufSeg = prog.get("UEXTDRAM"); Map-файл: name origin length used unused attr fill ---------------------- -------- --------- -------- -------- ---- -------- IRAM 00000000 00030000 0002f4e8 00000b18 RWIX MONRAM 00030000 00010000 00008000 00008000 RWIX CEXTDRAM 80000000 01000000 004fccf0 00b03310 RWIX UEXTDRAM 81000000 06800000 06000800 007ff800 RWIX .BUF_SendResults$data * 0 86000000 01000400 UNINITIALIZED 0002f284 _BUF_Registrar 0002f25c _BUF_SendResults 00022680 _BUF_alloc 81000000 _g_aRegDataLarge 86000000 BUF_SendResults$databeg 87000400 TSK_myLoop$stack

Причина зависания стала понятна, найден способ прикрыть эту дыру, но не найден способ полного устранения источника проблемы. На FXN_f_selfLoop программа прыгала у меня в случае когда возникало прерывание, для которого не был назначен обработчик в DSPBIOSe, стояло по умолчанию HWI_unused. Возникало прерывание PIE_INT_5_1, согласно документации, это прерывание при периоде таймера GPT4 в Event Manager B. Самое интересное, что я это прерывание никак не разрешаю. Прерывание возникает даже если таймер GPT4 заблокирован и его значение не изменяется. Проблема решилась установкой обработчика прерывания вместо HWI_unused на пустую функцию возврата, содержащую лишь PieCtrlRegs.PIEACK.bit.ACK5 = 1 (работает без диспетчера). Не ясно, откуда возникает прерывание от таймера, который во-первых стоит, а во-вторых прерывания от него запрещены. Прерывание от GPT4 возникает в среднем раз в 10 минут. Все это происходит при частоте прерываний модуля Capture 52 КГц. Если понизить частоту до 3 КГц, то ни одного ложного прерывания не наблюдалось. Тоже интересный факт. Не исключено, что время от времени и другие ложные прерывания могут возникать. Поэтому для неиспользуемых прерываний вместо HWI_unused буду ставить FXN_f_nop с использованием диспетчера или что-нибудь подобное.

Есть проект, написанный на F2811 процессоре. Реализовано на базе DSPBIOS. Программой используется в процессоре: GPIO, CAPTURE, PWM, SPI. Работают прерывания от SPI и от CAPTURE, используется диспетчер DSPBIOS для обработки. Присутствует три таска. Когда работает таск, управляющий ШИМ на основе результатов вычисления в прерывании от CAPTURE, наблюдается хаотическое зависание, т.е. зависание через разные промежутки времени: может через 30 сек, может через 10 мин. После зависания не запускается даже PRD_func, а программный счетчик находится на функции FXN_f_self_loop, ассемблерная инструкция которой прыгает сама на себя бесконечно. Кто-нибудь сталкивался с проблемой, когда программа прыгает на FXN_f_self_loop? Кто-нибудь знает возможные причины попадания программы на эту функцию? Спасибо заранее

Нашел, спасибо!

Здесь возникли сложности: не нашел среди файлов, которые генерятся компилятором, что-нибудь похожее на hex-формат, в котором происходит сохранение содержимого памяти командой "Memory Upload". Нашел только файл вида: @1100 30 40 F8 13 31 40 00 0A 3C 40 02 02 3E 40 A3 00 B0 12 DA 13 3C 40 00 02 3E 40 FA 13 30 12 01 00 B0 12 EC 13 21 53 B0 12 7C 13 B0 12 C0 13 03 43 Но он отличается от hex-формата: :FF1100003040A41C3140000A3C4002023E408602B012E41C3C4000023E40021D30120200B012F61 C2153B0 Следовательно, не знаю как загружать файл в контроллер. Но читать память для меня было гораздо нужнее, поэтому, спасибо огромное!

Каким софтом можно писать/читать Flash MSP430F149 из/в файл при подключении FET? В IAR пытался найти эту функцию - не нашел. Там увидел только как можно читать флэш после запуска отладчика. А хотелось бы иметь возможность загрузить программу из любого файла и сохранить программу в файл для последующего анализа "машинного кода".

Пытаюсь настроить в F2811 блок SPI (!Отдельный SPI, а не MCBSP) в режиме Slave, хочу его заставить адеквадно принять хотя бы один байт. В качестве мастера используется DM642, его работа отлажена хорошо и проверена на другом SPI Slave (MSP430). Наблюдаются следующие симптомы: на осциллографе отчетливо видны SCK и MOSI, а в отладчике на эмуляторе не видно никаких изменений: ни флагов окончания приема, ни генерации прерываний. Сигналы однозначно доходят до процессора. Досягаемость сигналов проверена простым чтением GPIOF в цикле и анализом интервалов между перепадами, изменений ровно столько же, сколько и должно быть перепадов => на GPIOF сигнал виден процессору. Корректная настройка прерываний проверена следующим способом: перевод SPI на F2811 в режим Mastera с Digital Loopback. В этом случае адеквадно срабатывают оба прерывания и в полученном массиве наблюдается точно такая же информация, как и была отправлена. SPI работает в режиме с FIFO. После проверки в режиме мастера с Loopback-ом просто перевожу SPI в режим Slave обнулением бита Master/Slave и обнуляю бит loopback-a. Далее с мастера DM642 подаю сигнал, SCK и MOSI видны на осциллографе. Прерывания не срабатывают, флаги тоже не ставятся. В чем может быть проблема? Частота SCK от DM642 примерно 400 КГц. Нужно ли как-нибудь по-особому настроить делитель частоты SPI на F2812, или для Slave это значение никак не влияет? Замечено, что при частотах SCK 5 МГц, процессор F2811 начинает генерить прерывания приема, но принимает мусор, не похожий на исходные данные. На частоте 400 КГц ни одного срабывания о приеме данных замечено не было. (В обработчиках прерываний добавлена строка CLRC DBGM, тобы на брекпойнтах останавливался в прерывании) Спасибо заранее за любые идеи

Пытаюсь промоделировать работу сторожевого таймера для процессора TMS320C2812 в симуляторе CodeComposera v 3.1. Вроде бы выставил все настройки как надо, только почему-то контроллер не сбрасывается, необходимое количество циклов проходит. Поддерживает ли симулятор моделирование сторожего таймера или я что-то неправильно делаю? Спасибо заранее Фрагмент инициализации такой: /*** Disable the Watchdog Timer ***/ SysCtrlRegs.WDCR = ((0 << 7) | (0 << 6) | (0 << 0)); /* bit 15-8 0's: reserved bit 7 ?: WDFLAG, write 1 to clear bit 6 ?: WDDIS, 1=disable WD, 0=enable WD bit 5-3 ???: WDCHK, WD check bits, always write as 101b bit 2-0 ???: WDPS, WD prescale bits, 000: WDCLK=OSCCLK/512/1 */ /* System and Control Register */ SysCtrlRegs.SCSR = 0x0003; /* bit 15-3 0's: reserved bit 2 ?: WDINTS, WD interrupt status bit (read-only) bit 1 ?: WDENINT, 0=WD causes reset, 1=WD causes WDINT bit 0 ?: WDOVERRIDE, write 1 to disable disabling of the WD (clear-only) */

Спасибо огромное, особено за картинки, это именно то, что нужно было.

Всем спасибо огромное! Столько сразу новой информации... пойду переваривать постепенно...

Можно в двух словах о том, что это такое и каким образом это поможет выделить узкую полосу? Задача понять, есть ли импульсы на этой частоте или отсутствуют. Да, было бы очень здорово. Ящик следующий: Dmitriy далее [email protected], вместо " далее " нет ничего, всего 8 букв до собаки. (чтобы спамеры не нашли)

В интернете статьи журнала Радио я не нашел, а дома у меня этих журналов нет, и не знаю, где вообще их можно взять. Если не сложно, то запостите, пожалуйста схему для полосового фильтра на одном ОУ с такой узкой полосой. Что-то плохо представляю ее. А в связи с чем на такие частоты пассивных фильтров не делают? Имеется ввиду что на частоты порядка 5-10 КГц? или имеется ввиду, что с такой узкой полосой невозможно получить фильтр на пассивных элементах?

Есть некоторая несущая частота, например 5 КГц или 10 КГц. С такой частотой мигает светодиод. Эти импульсы либо есть, либо их нет. Сигнал со светодиода поступает на фотодиод. Хотелось бы с выхода фотодиода выделить именно несущую частоту. Первое, что пришло в голову: это сначала CR (дифференцирующая цепь), а за ней интегрирующая RC. Причем RC у дифференцирующей в 100 раз меньше, чем RC у интегрирующей. Моделирование показало АЧХ, которая имеет максимум на несущей частоте и при удалении от нее убывает. Но когда начал подавать смесь несущей и импульсов в 10 раз большей частоты, сильного подавления лишних импульсов не произошло, они всеравно остаются. Можно ли как-нибудь с помощью RC или RLC цепочек добиться узкой полосы пропускания и сильного затухания частот в десять раз меньших и в десять раз больших? Или требуется ОУ или какие-нибудь другие активные компоненты? Где можно почитать про активные и пассивные фильтры НЧ, ВЧ и полосовые? Спасибо заранее

Под первичным источником питания подразумевается источник, которым планируется питать заряжающий блок? Это пока еще окончательно не решено, но предполагается, что либо у устройства будет вход для подачи постоянного напряжения 12В, либо будет вход для ~220В, с которого сигнал будет преобразовываться АСDC преобразователем в 12В. А какое это имеет значение? Специализированые зарядники посмотрел, но это не то, что мне нужно. У меня нет цели собрать один экземпляр. Цель разработать и выпускать портативное устройство, которое содержит аккумуляторный отсек и блок, позволяющий заряжать аккумуляторы при подключении внешнего адаптера, поэтому готовые зарядные устройства мало интересуют, если нельзя посмотреть их принципиальную схему. По поводу основного критерия: скорей всего, будет предполагаться два режима: быстрый заряд (1-2ч), либо стандартный заряд (10-20ч). Если не получится сделать два режима, выбираемых пользователем, то остановлюсь на режиме быстрого заряда. А еще прочитал PDF на одну микросхему, которую многие хвалят: MAX712/MAX713. И не смог в документации найти упоминание о том, что микросхема разряжает аккумуляторы перед тем, как их заряжать. Читал, что у NiMH аккумуляторов эффект памяти меньше, чем у NiCd, но количественной оценки не видел нигде. Как вы считаете, насколько "плохо" будет NiMH аккумуляторам, если их не разряжать перед зарядом? Можно, конечно, написать в инструкции к прибору, чтобы пользователь не начинал заряжать аккумуляторы, пока они не разрядяться, но это ведь дополнительные для него неудобства.

Необходимо собрать модуль питания, содержащий в себе 5 аккумляторов NiMH 1.2В 4000мАч (С-тип). Модуль питания должен работать либо автономно (если не подключен внешний адаптер), либо в режиме заряда аккумуляторов (если внешний адаптер подключен). Во время работы блока необходимо оценивать текущий заряд аккумуляторов и передавать этот заряд в соседний блок устройства. Необходимо также оценивать время, оставшееся до разряда аккумулятора и время, оставшееся до заряда (в зависимости от режима). Поискал специализированные микросхемы для заряда аккумуляторов. В качестве кандидатов оставил BQ2004 и MAX712/713, в документации написано, что микросхемы самостоятельно определяют как заряжать и когда останавливать заряд аккумулятора, поэтому по поводу управления зарядом вопросов пока нет. Интересует следующее: 1. Каким образом лучше определять текущий заряд батареи? В BQ2004 не нашел вывода, по которому передается текущее состояние батареи. Напрашивается вариант поставить АЦП или использовать внутренее АЦП микроконтроллера, которое будет измерять сигнал "BAT" на входе микросхемы BQ2004(это поделенный сигнал суммарного напряжения аккумуляторов). Но в таком случае не совсем понимаю, как на основе текущего напряжения определить % заряда. Зависимость, наверно, сложная? А для всех NiMH аккумуляторов 1.2В она одинаковую форму имеет или есть сильные разбросы? Устроит точность определения заряда 1-5%. Насколько я понимаю, ток, которым заряжаются аккумуляторы может меняться, поэтому пока не вижу простых решений оценки оставшегося времени заряда аккумулятора. 2. Есть ли специализированные микросхемы для заряда NiMH аккумуляторов, которые бы передавали полную информацию о состоянии аккумулятора (% заряда и оставшееся время). 3. Какое минимальное напряжение питания необходимо подать на микросхему заряда, если необходимо зарядить 1.2В х 5 аккумуляторов? В BQ2004 написано, что максимальное допустимое напряжение питания 7В. Но ведь по идее напряжение заряда должно быть больше 6В, правильно? Очень буду благодарен, спасибо заранее