Dir

Добавьте PHY и цены сравняются ;) А даже если и есть небольшая разница, то не о вагонных же нормах речь. Цены в общем-то одного порядка. А на LPC17xx и LM3S9Bxx, реализованных по одним нормам (0x13мкм) и по одной архитектуре сравнение будет еще более наглядным.

Не понял. Вы непосредственно в Luminary заказывали? У посредников цены вполне вменяемые. Вот, например: http://search.digikey.com/scripts/DkSearch...ame=726-1078-ND http://www.eltis.ua/russian/shop/search/in...%EF%EE%E8%F1%EA У Элтиса, правда, сейчас из-за нестабильнорсти курса гривни on-line цены убрали. Но были уровня Digi-Key. На розницу даже меньше.

А сколько вам ОЗУ нужно? Luminary на днях анонсировало 100МГц Cortex-M3 (R2P0) с 256К Flash и 96К SRAM с 10/100 MAC+PHY в LQFP-100. Называется это чудо LM3S9B95 и содержит кроме того USB Dev/OTG/Host, 2xCAN, 3xUART, 2xI2C, 2xSSI (синхронный последовательный порт), I2S, внешнюю конфигурируемую (x8, x16, x32) шину с поддержкой SDRAM-SRAM-Flash. Поддерживается 32 канала DMA. На борту дополнительно есть ROM с которой работает бутлоадер, содержится библиотека для работы периферии и зашиты криптографические таблицы AES и CRC32. Весь цифровой и аналоговый фарш (встроенный LDO, 1% 16МГц внутренний генератор, 2xADC, 3 компаратора, 2 квадратурных енкодера, 2xWDT, таймеры, PWM, RTC...) тоже на борту. Если учесть, что MAC поддерживает IEEE1588 и все это по 0,13мкм технологии, т.е. потребление будет на уровне, то можно считать, что рай уже наступил http://www.luminarymicro.com/products/lm3s9b95.html PS. Кроме этого МК они еще много чего по 0,13мкм технологии анонсировали, но LM3S9B95 - квинтессенция.

Абисняю ;) В прошлом году кнопочки были новенькие, а в этом - уже замусоленные пальцами, заслюнявленные чихами и кашлями. Статический заряд через новенькие кнопочки не хочет сбегать на вход проца по поверхности кнопки, а через замусоленные делает это с удовольствием и чем ниже температура, тем меньше влажность и заряда на студентах накапливается больше. А поскольку кнопки 4-х выводные и через защитный ободок и 5 ножку заряд не стекает на землю, то он делает свое черное дело с входом проца. Тем более, как оказалось, вы его даже резистором и диодами не защитили.

Хм, так может вас армированные ADuC-и (ADuC7xxx) устроят? Корпуса там такие, как вам нужны (+64-выводные BGA 6x6). И практически всю цифровую периферию через PLA можно ремапить в очень широких пределах. И вдобавок кое-что (типа синхронизации и т.п.) свое лепить. Правда, ARM7TDMI в THUMB-режиме до 41МГц тактовой. Зато очень качественная аналоговая часть. Точная калиброваная опора, суперовые АЦП (12, 16, 24 бита), ЦАПы, даже DDS есть. Относительно недорого. С цифровой периферией, однако, напряженка в отличие от той же STM32. Особенно с навороченной комуникационной.

Э..., простите, вам для Ethernet корпус LQFP64 12x12 мм слишком большой? Так ведь все равно еще как минимум PHY + кварц + трансформатор с разъемом (можно комбо) нужен. Т.е. корпус МК тут не самая главная часть. Если сэкономить размеры на PHY, то можно использовать МК от Люминари. Правда корпуса 100-пиновые 16x16мм. Что тоже по сравнению c RJ-45 не так много. Вижу смысл вообще отказаться от Ethernet - тогда полный кайф с корпусами VQFPN36 размером 6x6мм у STM32 :laughing:

Вообще то выходы проца, соединенные с кнопкой, убиваются статикой на ура. Особенно в зимнее время при низких температурах и малой влажности. Чтобы этого не происходило даже специальные тактовые кнопки изобрели: с металлической оправкой пластмассового штифта кнопки и 5 закороченным на землю выводом. Если у вас тактовая кнопка с 4 выводами и вы живете в Сибири, то в январе-феврале такое событие как умирание входа проца у вас почти со 100-процентной вероятностью должно было произойти. Решение очевидное: использовать кнопки с 5 заземляющим электродом + специальная защита входа от статики: последовательный резистор на кнопку, с другой стороны стабилитрон или BAV99 c одним выводом на землю, а вторым на +питания.

Максимальная частота осталась 72МГц, так что NXP LPC17xx с Ethernet и с тактовой 100МГц все еще потенциальные лидеры. Но зато STM32F107R, например, упакован в LQFP64. 12-битные АЦП и ЦАПы, USB Device/Host/OTG это, похоже, уже стандарт. http://www.st.com/mcu/modules.php?name=mcu...ocs&FAM=110 Образцы первого LPC17 с Ethernet (LPC1766FBD100), вроде, обещают в 1 квартале. Остальные (LPC1758FBD80, LPC1768FBD100) - во втором. Вообще-то 100МГц для Ethernet - явное преимущество. Как и совместимость по ногам с LPC23. Интересно, кто кого опередит по срокам начала производства: NXP или STM.

Так уже ж даташиты официально висят и семплы в 1 кв. 2009г вроде заказывать можно http://www.nxp.com/#/homepage/cb=[t=p,p=/50809/56890]|pp=[t=pfp,i=56890]

Ну это вы зря. У ADI встроенные АЦП ничуть не хуже, чем отдельностоящие. Например у ARMированных ADUCов (ADUC7xxx) шумы и нелинейности - младший разряд. Также очень точно калиброванная опора. Хорошие встроенные АЦП и у Силабза. Его C8051F06x с 16-разрядым SAR АЦП - прекрасная штука.

Вообще-то для ADuCов гораздо удобнее как раз бутлоадер использовать в производственном программировании. Меньше ножек, чем у JTAG надо. Но можно и JFlashARM от Сеггера использоватью (в пакете JLinkARM идет) http://www.segger.com/pub/jlink/Setup_JLinkARM_V396d.zip Или ее урезаный, но вроде легальній ADIшный аналог miDASLink там же на сайте Segger-а или ftp://ftp.analog.com/pub/MicroConverter/ Нужен, конечно, JLink или что-то совместимое: MT-Link, Jet-Link... Будет-будет, не путайте человека ;) Там с помощью коэффициентов, PLL и какой-то матери получается почти то, что надо ;)

LM339 не ОУ, это компаратор с открытым коллектором, LM358 - ОУ с нормальным выходом. На схеме ошибка. Нет +5В сверху для запитки.

Навскидку: 1. Смысла в супервизоре не вижу. Проще включить фьюзы BODEN и WDTON в M8 2. При этом на /RESET желателен резистор 4,7к к +5V и кондер 10нФ на GND 3. Выходы MISO, MOSI через 4,7к к +5В, SCK через 4,7к к GND. Иначе в будущем возможны недоуменные вопросы типа: "А почему у меня флэш слетает?". 4. Как уже говорились, выходы енкодкодера лучше подтянуьть резисторами 1...4,7к к +5В. Они как правило ОК, а надежды на внутренний pull-up мало. На пины, идущие за пределы платы, неплохо бы и какую-то защиту поставить. Сгореть ведь может, а вы на программу грешить будете. 5. Не вижу питания +5В на на элементах вблизи компаратора LM339

Ну, если любые, то NVidea Tegra - ARM11 ;) http://www.3dnews.ru/news/novost_dnya_nvid...ipe_ofitsialno/ http://www.nvidia.ru/page/handheld.html http://www.nvidia.ru/object/mobile_games_demos_ru.html

Не самые доставаемые на сегодняшний момент, но, наверное, самыми дешевыми будут недавно выпущенные Low-desity access line STM32F101x4/6 и Low-desity USB access line STM32F102x4/6 c флешем 16 и 32кб. Похоже, что с их выпуском 32-битники будут использовать где попало.

Особой методики нет. Просто экспериментальным путем подбираю эти макс. и мин. значения ШИМ, чтобы регулируемая величина достаточно быстро доходила до минимума и максимума и при возврате назад в регулируемую область ощутимой задержки не было. Обычно 2...4 итераций хватает. Занимает времени меньше, чем подбор коэффициентов ПИД. А потом, как правило, пересчитываю параметры регулятора так, чтобы диапазон регулировки ШИМ был от 5 до 95% для всего диапазона выходных величин. PS. Пересчитывать или нет, переделывать или нет определяется чаще всего причинами, напрямую к регулированию касательства не имеющими.

Вообще то это я говорил, что делал регулятор для стабилизации потока и, наверное, должен ответить. Приведите пример бесконечно отрицательной и бесконечно положительной нагрузки, тогда я вам может и поверю. А так нагрузка либо есть, либо ее нет. Соответственно нельзя приложить бесконечное регулирующее воздействие любого знака, чтобы компенсировать возмущение. И, в конце концов, пояснит ли кто-нибуть чем конкретно не нравится простая и логичная операция из одной команды, которая не позволяет неограниченно расти интегральному терму, которое я привел в начале темы (топик 12): ... fError = fSetPoint - fProcessValue; ... fsError = pid->fSumError + fError; fIterm = pid->fKi * fsError; ... fRet = fPterm + fDterm + fIterm + pid->fMinPID; // if (fRet > pid->fMaxPID) return (WORD)(pid->fMaxPID); else if (fRet < pid->fMinPID) return (WORD)(pid->fMinPID); pid->fSumError = fsError; return (WORD)fRet; Т.е. сравнимаем полученное регулирующее воздействие (fRet) с границами регулирования (pid->fMinPID, pid->fMaxPID) и если оно выходит за эти границы, то интегральный терм (pid->fSumError) замораживается, т.к. просто программа не доходит до его обновления. Мы, фактически, выбором этих границ и регулируем наш I-терм. О каком пристальном внимании речь? И просьба пояснить чем плохо именно данное решение, а не приводить примеры, вводящие дополнительные ограничения I-терма. А насчет того, зачем тут плавучка я уже говорил: сравните текст программы в AVR221 в целочисленном виде и приведенный в топике 12 данной темы ее плавучий аналог и все станет ясно. Программа скукоживается в несколько раз, все внимание разработчика к процессу, а не к особенностям реализации в целых числах. Запасов производительности у ARMа, как правило, хватает. PS. Для профи это, конечно, не аргумент. Они оперируют понятиями "робастности" и т.п. У них свои критерии и свои объекты регулирования: атомные станции, ракетоносители, авиатехника... А что делать простым программистам и электронщикам у которых такая задача как, например, управление потоком CO2 или его температурой стоит раз в 3 года и занимает 0,01%. Утром поставили задачу и до обеда ждут решения в железе. Отлаживать целочисленку ни времени, ни аргументов не хватает.

??? А мое имя всуе без указания причин почему было произнесено? Я с вами не спорил и даже не знаю на какую тему спор. :( :(

Чето я вас не понимаю. Ну нет у моего процесса ограничения и насыщения как сверху так и снизу. Регулирование осуществляется в диапазоне значений. Поэтому и искусственно ограничивать интегральный терм смысла нет. Я же согласился с вами, что в "ваших" случаях при наличии ограничений это обязательно :beer: Чего же вы пытаетесь найти несуществующую ошибку у меня. Просто вынимательнее рассмотрите программу и найдете то, чего так настойчиво не хотите видеть :) Ну не работала бы она с ошибкой так долго

Интересно услышать почему. Если речь про "мой" вариант, то буду. Нижняя и верхняя граница пределов задания управляющих воздействий (fMinPID, fMaxPID) выбирается с некоторым запасом меньше (больше) тех, что нужно для регулирования fProcessValue к уставкам fSetValue(min) и fSetValue(max). Это автоматом не позволяет интегральному терму бесконечно расти да еще и в направлении компенсации ошибки регулирования :)

Дневная жара спала и наконец-то возратилась способность хоть как то соображать :) Не оставляет ощущение, что мы говорим о разных регуляторах. Или совсем не понимаем друг друга. На эту мысль наводят слова: Недаром pid->fMaxPID восприняты как регулируемая величина. А на самом деле это регулирующее воздействие. Причем вместо выхода сумматора сравнение ведется с регулируемой величиной (хотя не возражаю, иногда работают и с выходом). Поэтому приведу расшифровку принятых обозначений. Структура PID_DATA: fKp, fKi, fKd - коэффициенты регулятора fLastProcessValue - последнее значение регулируемой величины fSumError - понятно fMinPID...fMaxPID - допустимый диапазон задания регулирующих воздействий Переменные функции ContrPID: fSetPoint - желаемое значение регулируемой величины fProcessValue - текущее значение регулируемой величины PID-регулятор классический. Т.е. все термы работают одновременно, а не так, что I-терм нужен только в режиме насыщения. Отсюда понятна формула, что регулирующее воздействие fRet равно сумме всех термов, которые считаем от 0, плюс pid->fMinPID - начальное регулирующее воздействие. fRet = fPterm + fDterm + fIterm + pid->fMinPID В случае достижения регулирующего воздействия максимальной величины fMaxPID или минимальной величины fMinPID происходит его ограничение на этом уровне. Поэтому ошибка регулирования в дальнейшем в случае приближения регулируемой величины к желаемому значению должна уменьшаться. ... И вот теперь, когда расставлены дефиниции, можно поговорить и о предмете :) Жду замечаний и возражений :1111493779:

// Ну пусть ошибка. Но почему она должна изменить знак? Вопрос снимается. Туплю после пляжа и на такую жару. Да и в теме не был уже несколько лет. Но тем не менее фрагмент проги рабочий и фокусов за ней не замечено. Если жара отпустит, возможно на досуге вспомню прошлое ;)

Пока не рабирал, т.к. воскресенье и думать совсем лень, но вот это не понял сразу Т.е. почему сумма изменит свой знак?

Какая деталь проскочила? Есть там в алгоритме ограничение интегрального терма (нижние и верхние границы регулировки)! Смотри хотя бы текст программы.

Не иллюзию создаст, а будет нормально работать. Вопрос в том стоит ли корпеть и вылизывать целочисленный алгоритм на AVR со множественными побочными явлениями и эффектами или за 5 минут наваять то же самое на ARM с плавучкой.