VladimirYU

Это не бред, а просто массив указателей. Но задача все равно не понятна. А первая строчка :(

Посмотрите в сторону AD у них есть МК на базе 51 ядра со встроенными 16-24 битными сигма-дельта ADC и с другой переферией, UART в том числе.

Например DS32C35 имеет встроенные генератор и термодатчик, взависимости от которого переключаются корректирующие емкости генератора, обеспечивается та самая термокомпенсация плюс еще 4к FRAM (все по I2C). Конечно по цене не 1307, зато очень функциональное устройство, для батарейки отдельный вход, никакие праздники даже бразильский карнавал не страшен.

А ничего не получится, упомянутый вами проект для мега88, так и работайте средствами для семейства АВР, а уж никак не АРМ. Если задача же перенести проект на другую платформу, то так и формулируйте вопрос.

Конечно нужно, пока Атмел будет сохнуть, нам не хотелось бы сдохнуть. Это лучший программатор, как только заставил производственников им пользоваться, забыли про неправильно зашитые фузы, про перепутанные хексы т.д. Мне по барабану какая эмблемка будет на чипах, пока они меня устраивают.

Мы то друг друга поняли, главное, чтобы коллега не пытался ничего изобретать, все уже изобретено для его случая.

Это вопрос не к IAR, а ответ K&R, на форуме ссылок достаточно.

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

Пример, который Вам приводили, с локомотивом достаточно наглядно показывает суть вашей проблемы. У вас нет возможности управлять охлаждением, о чем ранее тоже говорилось. В рамках линейных методов регулирования также достаточно было рекомендаций, необходимо только их пробовать и сравнивать результаты. Все последние рекомендации Вас, осознано или неосознано авторами, толкают на применение методов нечеткой логики. ИМХО в вашем случае можно обойтись и без них. Процессы все у Вас медленные и нет НИКАКОЙ необходимости знать +10 или +30 в помещении, где стоит ваша печь, только разве, что какую одежду одеть работнику. Оцените динамику разогрева пустой печи и ее остывания при полной загрузке, т.е. самые "худшие" случаи. Определите постоянные времени. Далее по Бесекерскому с учетом особенностей цифровой реализации.

Как вариант, посмотрите в сторону UNION, в купе с вашим вариантом, может быть поможет.

Есть такой глюк у студии с WDT, с m128 тоже, думаю это их косяк. Не знаю как в последних версиях, но в 589 релизе он есть. Я с этим смирился и при отладке инициализацию WDT просто комментирую. ИМХО с этим бессмысленно бороться и "ломать копья", просто знать, принять и учитывать при построении программы, чтобы на "железе" уже с WDT все нормально было.

Практически реализована Ваша идея. См. пост выше от IJAR: ..... один термодатчик ставили на нагреватель (прямо на проволоку) и по нему работал ПИД регулятор а второй ставился непосредственно в рабочий объем - контрольный датчик. При настройуе системы подавлся скачок мощности и по контрольному датчику определялось термосопотивление объекта и далее подбирались коэфициенты ПИД регулятора.

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

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

Это только предположение. У меня была вот какая заморочка, правда с AT90PWM3. После установки фуза разрешающего отладку под JTAG кристалл не откликается на программатор, пока JTAG-ом не сбросишь этот фуз. Сообщение программатора бало один в один как и у Вас.

Цитирую: .....а шлейф взял 70 см кусок плоского сетевого кабеля...... ....... Из 3.3 В до платы доходило 2.5........ 1) Пусть плата потребляет 100mA, (3,3-2,5)/100*10^-3=80 Om, т.е. 1Oм/cм - опять не верю. 2) Если девайс потребляет больше, то питают не девайс от программатора, а программатор от девайса или от отдельных источников, поэтому - опять не верю. 3) В процессе записи флэш ошибки могут быть только при записи лог. 0, что при верификации сразу проявилось бы, т.к. если программатор ошибочно считывает лог. 0, то он прочитал бы практически все ячейки как 0хff, при ошибках записи аналогично - прочитал бы эти биты как лог.1. Поэтому - опять не верю. Видимо, проблема либо не полностью изложена, либо не до конца исследована.

и схемка выделения положительного или отрицательного полупериода сети.

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

Не верю.

Шлейф конечно хилый, попробуйте его посто перевернуть. Дело в том, что по одной стороне идут сигнальные линии, а по другой только "земляные", которые запараллелены. Меня в свое время это спасло. Самопальный шлейф творить рисковано, можно просто не вытянуть требуемые скорости обмена.

Имеется: мега128, проект состоящий из двух частей. Первая - лоадер, вторая- приложение. После старта лоадер, если нет сверху обращений, передает управление приложению. Приложение, если есть обращение сверху возвращает управление лоадеру. Все работает проблем нет. Задача: в область флэш между лоадером и приложением с определенного адреса разместить программу, которую бы лоадер при определенных условиях загружал и вызывал , а приложение о ней бы ничео не знало. Как делаю: Пишу программу, перенастраиваю файл lnkm128.xcl, т.е. меняю адрес начала области CODE, INTVEC, TINY, NEAR собираю проект, смтрю HEX. Все хорошо. Легло все по нужным адресам, как надо и все работает. Далее: требуется усложнить данный код с подключением уже отлаженоой и проверенной не один раз библиотеки, работающей с объектами С++. И тут при компановке начинает выскакивать ошибка. Error[e18]: Range error, Number out of range. Valid range is -128 (-0x80) to 255 (0xFF). File: D:\IAR Systems\EW4_12A\avr\Work\Ðàçíîå\Buses_app.h, Line: 72 Source: LDI R17, (??__vtbl) >> 8 Where $ = TBusKmspi::TBusKmspi(unsigned char) + 0x12 [0x102FA] in module "main" (D:\IAR Systems\EW4_12A\avr\Work\Ðàçíîå\Release\Obj\main.r90), offset 0x12 in segment part 17, segment CODE What: 8 ? (TBusKmspi::__vtbl >> 1 & 0x7FFFFFFF) >> 8 - 1 : TBusKmspi::__vtbl [0x102] Allowed range: 0xFFFFFF01 - 0xFF Operand: TBusKmspi::__vtbl [0x10200] in module Buses_app (D:\IAR Systems\EW4_12A\avr\Work\Ðàçíîå\test_lib.r90), Offset 0x0 in segment part 31, segment NEAR_F Ставлю галку - всегда сосздавать выходной файл, загружаю - не работает. Пересобираю код с перемещением его в сторону меньших адресов - с определенного момента ошибка пропадает - программа работает. В область лоадера не попадаю одназначно. Шаманство вокруг попыток настройками линкера подавить ошибку или сделать ее предупреждением само собой ничего не дает. Можно было бы плюнуть на это и опустить вниз данный код, но не хочется загонять себя в ограничения по объну приложения. Но не получается :-(

Весьма спорное утверждение. Читаем в описании на компилятор: __delay_cycles(unsigned long int); Makes the compiler generate code that takes the given amount of cycles to perform, that is it inserts a time delay that lasts the specified number of cycles. Note: The specified value must be a constant integer expression and not an expression that is evaluated at runtime. ИМХО весь топик придуман на ровном месте.

Апериодическое звено 1-го порядка.