Перейти к содержанию
    

DmitriyX

Свой
  • Постов

    73
  • Зарегистрирован

  • Посещение

Репутация

0 Обычный

Информация о DmitriyX

  • Звание
    Участник
    Участник

Контакты

  • ICQ
    Array

Посетители профиля

908 просмотров профиля
  1. Интересно... а я *.out файл даже не заливал, просто стереть пытаюсь. Ну ладно, по прежнему принимаются любые идеи по решению проблемы.
  2. Precompaction делает функция библиотеки Flash_API, написанная TI. Я к ней отношения не имею, поэтому как вариант, можно обратиться в тех-поддержку, напишу им. Но если кто-то с такой проблемой сталкивался, то было бы интересно узнать, решаема ли она и как быть.
  3. Не больше 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.
  4. Раньше нормально удавалось перезаписывать программу во Flash контроллера. А теперь при стирании любого сектора возникает сообщение об ошибке: error #24, STATUS_FAIL_PRECOMPACT. Первый раз такое вижу, описания в интернете и в базе знаний TI не нашел. Может кто-то сталкивался?
  5. ой, прошу прощения, 0,03-0,04 секунды. А можно поподробнее про обратную связь по реальному воздействию? Что она дает?
  6. Структурная схема управления приводится ниже. Управление осуществляется в цифре. Информация о двигателе: 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
  7. Да, трехфазный двигатель. Две его обмотки висят в воздухе. На третью подается напряжение от -27В до +27В. Поскольку угол поворота двигателя требуется от -4 градусов до +4 градусов, то напряжение подается только на ценральную обмотку. Измеряю точный период между фронтами. На основе длительности расчитываю воздействие и подаю его на ШИМ. Пробовали без сглаживания - мотор начинает визжать и регулирование ужасное. Аппаратную схему на данном этапе менять не представляется возможным. Поэтому в данной теме интересует мнение с точки зрения теории, расчета воздействия при наличии описанного выше измерительного канала.
  8. Регулирую скорость. Про датчик совсем забыл написать. Датчик движения скорости - лазер. Система преобразования сигнала с лазера (в подробности системы не вдавался) на выходе выдает меандр, частота которого пропорциональна скорости движения двигателя. Требуемой скорости движения двигателя соответствует частота меандра 52.5 КГц. Т.е. чаще, чем с 52КГц не получится изменять воздействие. Воздействие на двигатель - ШИМ с последующим сглаживанием. Каким образом это можно учесть в модели?
  9. Не удается управлять на практике. А на модели я не знаю как смоделировать источник ошибок таким образом, чтобы после получения интегратора не удавалось регулирование. Траектория следующая: разгон за 0.05с, движение с постоянной скоростью 0.5с, торможение 0.05с. На участке движения с постоянной скоростью необходимо поддерживать постоянную скорость с точностью 0.1%.
  10. Требуется управлять двигателем переменного тока с тремя обмотками. Требуемый угол поворота двигателя от -4 градусов до +4 градусов. В связи с этим, для управления двигателем задействуется только ОДНА его обмотка, скорость движения двигателя будет пропорциональна току в этой одной обмотке. Требуется управлять двигателем, чтобы от разгона до торможения колебания его скорости составляли не более 0,1%, т.е. высокоточно регулировать. В документации на двигатель нашел значения электрической и механической постоянной времени. Простейшая модель двигателя, которая напрашивается после этого - два апериодических звена, соединенных последовательно. В модель также добавил белошумные источники помех измерений и помех воздействия. Рисунок модели прилагается. Изначально предполагалось управлять двигателем с помощью классического ПИД-регулирования, но требуемой точности достигнуть не удалось. Пытался синтезировать коэффициенты при теоретических расчетах следующим образом: получить такой ПИД-регулятор, который после перемножения на передаточную функцию двигателя дает интегратор 1/s. Но после расчета возникло затруднение точным образом оценить ошибку регулирования. В связи с этим следующие вопросы: 1. Каким образом усовершенствовать модель описанного выше двигателя? Может трение в осях добавить? (только плохо представляю как сделать это в операторной форме). Может как-то еще? 2. В связи с тем, что ПИД-регулирование не достигает нужной точности на практике, предполагается применить адаптивные алгоритмы регулирования, но изучением их я пока еще на начал заниматься. Каким образом и в каких моделях можно будет адеквадно оценить ошибку адаптивного регулирования? (в операторной форме адаптивные алгоритмы ведь не моделируются) 3. Если кто-то занимался работой с адаптивными алгоритмами регулирования, то буду очень благодарен за ссылку на материалы об этом. DvigModel.bmp
  11. Процессор 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
  12. Причина зависания стала понятна, найден способ прикрыть эту дыру, но не найден способ полного устранения источника проблемы. На 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 с использованием диспетчера или что-нибудь подобное.
  13. Есть проект, написанный на F2811 процессоре. Реализовано на базе DSPBIOS. Программой используется в процессоре: GPIO, CAPTURE, PWM, SPI. Работают прерывания от SPI и от CAPTURE, используется диспетчер DSPBIOS для обработки. Присутствует три таска. Когда работает таск, управляющий ШИМ на основе результатов вычисления в прерывании от CAPTURE, наблюдается хаотическое зависание, т.е. зависание через разные промежутки времени: может через 30 сек, может через 10 мин. После зависания не запускается даже PRD_func, а программный счетчик находится на функции FXN_f_self_loop, ассемблерная инструкция которой прыгает сама на себя бесконечно. Кто-нибудь сталкивался с проблемой, когда программа прыгает на FXN_f_self_loop? Кто-нибудь знает возможные причины попадания программы на эту функцию? Спасибо заранее
  14. Здесь возникли сложности: не нашел среди файлов, которые генерятся компилятором, что-нибудь похожее на 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 Следовательно, не знаю как загружать файл в контроллер. Но читать память для меня было гораздо нужнее, поэтому, спасибо огромное!
×
×
  • Создать...