mikki

Если скорость передачи сообщений не критичный параметр, есть способ подключить выход одного передатчика на вход другого приемника и так по кольцу. Все приееники ретранслируют передачу соседу, пока сообщение не прийдет к мастеру. Количество проводов такое же как и в конфигурации звезда. Основное достоинство- трансиверы-ресиверы можно сделать даже на рассыпухе, не заботясь о нагрузочной способности. Количество узлов ограничено только скоростью ретрансляции сообщений.

Примитивно все! ПИД-регулятор по простейшей формуле из учебника реализовали. Да и все остальное также. Тоска. Сравнить с Техасом вообще отстой.

Как то работал с ТМС320 была похожая ситуация.Оказалось, что маленькая функция тайм_делай(мкс) из примера оставалась скомпилированной для срама. И как только в нее заходило висло все. Переписал заново, как обычную функцию - все заработало

Вот нашел интересную подборку программного обеспечения для проектирование ПП. (ссылки) http://www.rcmgroup.ru/Programmnoe-obespec...pech.345.0.html Кому инетерсно по приведенным ссылкам можно найти свободно распространяемое программное обеспечение, демо-версии и бесплатные тестовые версии.

Что б тема не остыла. Кто не боится продукции микрочипа, все сюда http://www.microchip.com/stellent/idcplg?I...ocName=en542591. Digital 300 Watt AC/DC Power Supply with PFC - Так сказать хлестко и в тему. Далее поводу разницы между реализацией аналоговой и цифровой. Достоинства реализации на аналоговых микросхемах: - больший запас перегрузочной способности микросхемы по питанию (15В против 1,8Вядро у некоторых или 3-5В переферия. Очень проявляется при грязных сетях или вблизи источников помех, сварочники там всякие... - управление токовым контуром по методу ШИМ-2, а не ШИМ-1, когда время открытого ключа уже известно, что хорошо с точки зрения получения лучших динамических качеств источника, скорость отработки возмущений и т.п. Достоинства реализации на контроллерах: - как всегда, гибкость, перенастраиваемость - возможность реализации сложных, в т. ч. нелинейных законов управления.

Большая просьба к форумчанам, не использовать подобного рода штампы (скрытая пропаганда курения!!!), при описании интеллектуальной работы с документацией. :laughing:

Хотел задать вопрос, а чем, собственно, нравится? Почему выбрали именно АВР32, на какие какие преимущества перед АРМ системой прельстились? Если можно, по-конкретнее пожалуста. Как поклонник АВРа, тоже смотрю в эту сторону, но решиться выбрать в качестве семейства "на каждый день" и обзавестись соответствующим инструментарием (типа трассировщик AVRONE уж очень привлекателен - за 600 уе ) не решаюсь. Кстати, программите в чем, AVR32 Studia? ЗЫ. Может у кого-то есть опыт разочарования?

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

Не разделяю примитивизма некоторых участников в подходах к разработке техники. Полагаю, нельзя сравнивать по сложности терморегулятор и, например, манипулятор робота с 6-10 степенями свободы. Это разные вещи!!! Думаю применение специалистами-разработчиками Матлаба или подобных ему помощников (именно помощников, а не заменителей мозга, как некотоорые хотят это представить общественности) более ПРОДУКТИВНО и ЭЛЕГАНТНО с точки зрения решения задачи, дальнейшего совершенствования алгоритмов и поддержке конечного изделия в эксплуатации, чем грамотно написанный код для незаконченного, не поставленного на производство и в конечном счете заброшенного горе-изделия!!! Не надо бояться автоматизации труда embedder specialists, тем более говорить всем, что " - вертели мы мол таких на ..." ну и т.д. Смешно это. Может в задачах автоматизаци инкубатора "отмороженный гайковерт", знакомый с особенностями высиживания, будет эффективней кабинетного профессионала, а вот в других областях - сомневаюсь. Пора открыть новые горизонты в разработке встроенных систем. Сложные системы требуют соответствующих подходов и соответственно соответствующей элементной базы!!!

И так, ниша АВР уже определена! Малый контроллер для средней сложности задач, с прогнозируемым временем реакции, мощными ногами, хорошей надежностью ну и т.д. А может быть главное " - Я ЕГО ЗНАЮ!" Что касается АРМов, у них свой круг задач. И все давно поняли что за счет снижения цен на 32-х разрядные ядра, в том числе и не только АРМ но и других ядер, ниша 8-битных процессоров уменьшается. Поверхностно были затронуты проблемы конкуренции электронных изделий производимых Нашими компаниями с китайскими. Полагаю, что данному вопросу и тебуется уделить основное внимание в нашей дискусии!!! Уверен что практически всЁ, что можно реализовать на Мегах можно реализовать на Хольтеках которые будут дешевле, даже если их взять две штуки вместо одной!!! Отсюда следует несколько неожиданный для многих вывод, что речь должна идти в первую очередь о конкурентно способности специалистов- разработчиков!!! Идея проста - сокращение рабочего времени тех самых разработчиков пулучающих между прочим зарплату (думаю 3000$ в месяц -подойдет ) и как результат, за то же время реализации нескольки проектов. В даном контексте хочу рассказать про семинар MAtlab, где своим мастерством американцы просто упивались. Чувак взял стенд содержащий небольшой движок с двумя инерционными нагрузками соединенными пружинной связью. За полчаса он набросал в матлабе алгоритм управления (идентификация частотной характеристики всей этой приблуды, параметрический синтез регулятора), тут же, не парясь, загрузил автоматически сгенерированный код в борду на базе TMS320_28335, далее еще чуть чуть подогнал и все!!! При зарплате в месяц 10000$ дополнительные расходы составляют 25$ за полчаса!!! А теперь посчитайте сколько ему надо заплатить если все это он будет писать на Хольтек на ассемблере??? Ха-ха! А в это время его девайс работает, а я, будь я его работодателем, получаю прибыль!!! Вот вам в действии быстрый вывод изделия на рынок и возможность дальнейшего совершенствования в предполагаемый период. И вот основные преимущества которые обеспечивает использование мощных процессоров с возможностью, быстрой и по-возможности автоматизированной генерации кода (например средствами MAtlab или Labview), или епе минимум использованием предметно специализированных asm-оптимизированных библиотек. Поэтому, может этот посыл будет неоднозначно воспринят сообществом, но я скажу: - Не стоит ломать копья по поводу оптимизации кода для 8-битных процессоров, что точно также является хвастовством по использованию ассемблера вместо С. Ни кто не говорит что плохо написанная программа не хуже хорошо написанной. Конечно хуже. Но для того и существуют специалисты-программисты (не особо сильных, например, в электроприводах, что вполне естественно :laughing: , гигантов мысли в рассчет не берем), которые могут оптимизировать код, в то время пока электропривод уже продается и приносит ожидаемую прибыль. А основное внимание надо уделить возможностям сокращения времени реализации проекта. Если на МЕГЕ легче поднять проект пожалуйста, если на АРМ- пожалуйста.

Разговор как всегда уходит в сторону, о чем не забывают напоминать некоторые участники, особенно хорошо это получилось у Ксении, душевно так и логично. И так по-порядку. Самый первый пост от IGK навеян просто грустью по поводу прошедшей юности!!! Старые лохматые джинсы, в которых было так удобно тогда, а что сейчас...? - штанишки просто стали просто малы! Метания в рядах АВР-пользователей понятны, грустно прощаться с полюбившейся платформой. Да мы вырасли на AVR-ках и сейчас на фоне новых требований к продукции разные там интерфейсы, GUI и т.д мощности процессора, надо это признать не хватает. Конечно есть устройства в которых ничего этого не требуется и естественно AVR будет жить, хотя бы как AtX _Mega (думаю по новому техпроцессу устройства получаются конкурентнее классики, поэтому такой соотношение цен на старые и новые модели) и нас просто плавно пытаются перевести на новую микруху. Эх раньше бы все это и не было бы такого разговора сейчас переходить на что то или нет. Например в рядах ПИК-поклонников такого метания нет, там все спокойно, вовремя появился PIC24, dsPIC30, dsPIC33, а теперь и PIC32. Может быть нам (АВР-пользователям ) повезло меньше чем ПИК-пользователям? Попробую дать ответ в следующем посте. И так, куда движется мир?

Да, всегда нашим пацанам нехватает чуть чуть времени... Вобщем я разобрался сам. Задал в гугле запрос handler(void *baseaddr_p ) и получил много ссылок на примеры обработки прерываний.. Оказалось, что надо опросить флаг срабатываниЯ прерывания в регистре, например, для таймера CSR, о том что случилось прерывание и потом его же записать в тот же регистр CSR. Типа сгенерить acknowledge соответствующего прерывания. В этом случае запрос на прерывание сбрасывается и прерывание не автозапускается. Я попробывал это в случае использования ядра opb_intc. Как это будет в случае прямой генерации прерывания не пробовал, но думаю также. Спасибо отозвавшимся, надеюсть что мой опыт пригодится начинающим, типра меня.

Всем привет. Пытался завести прерывания по таймеру в собранной системе на Microblaze. Для чего использую opb_taimer и opb_intc. После некоторой заморочки с определением таймера и контроллера прерываний прерывания стали срабатывать. Проблема в том что после того как одно прерывание сработало остальные запускаются самостоятельно. И вот тут , что не делал ничего не помогает, просветите в какую сторону копать. Может что в обработчик прерывания вставить, типа программный сброс какого битика.

Может я и не втему , но неплохой контроллера сделал для ксилинкса некто D. Vanden Bout. Рекомендую глянуть.http://www.xess.com/ho03000.html А я тут благодаря ответам наших знатоков запустил конторллер на микроблэйзе. Разместил вектора данных там и вроде фурычит. Спаибо нашим пацанам.

если можно поясните какую схему можно исполтьзовать для этого, а то в инете есть на основе НС125 и на паралллельный порт и работает ли она с програамой xspi.exe. Я пользовался USB-JTAG, так вот на польском сайте встретил точно такую проблему, пользуясь утилитой xspi_usb через USB-JTAG не удавалось в режиме direct SPI увидеть , даже прочитать флэшку ST 25P40 (у меня 64), короче вывод такой, что ксилинкс нетого. Короче говоря я ищу путь как запрограммировать эту самую флэшку, и народ там советует использовать пикоблэйз, хотя в моей плате есть загрузчик который пользует файл формата srec, а вот его я как не старался не смого в 8.1.03 версии сделать. Буду пробовать сделать этот файл в версии 9.1. Буду признателен за комменты, отдельное спасибо "3.14" (пардон за назойливость жду примерчик) И если не внапряг, как указать компилеру что большой массив конкретно разместить во внешней памяти.