скажем точнее FGPA может обеспечить гарантированную пиковую производительность при должном распаралеливании процессов.Nick писал(а):FGPA обладают гарантированной производительностью но меньшими возможностями по гибкости, размерам программ, многозадачности.....
ИМХО, драйверы лучше отдельно паять, так конструкция будет модульной, а значит легко расширяемой и заменяемой, если вылетит один драйвер не придется менять всю плату. Но для всего выше перечисленного уже есть mesa. Она как раз на FGPA и умеет выполнять функции генератора шагов и пид регулятора. Кстати можешь посмотреть на прошивки hostmot2 - в них все это зашито.АБу писал(а):1. N КАНАЛЬНЫЙ ДРАЙВЕР ШД реализация микрошагового управления шаговыми двигателями в подчиненном режиме. Управление PC/lpt emc2, mach3. step/dir. выходные драйверы ШИМ и(или) линейные, питание выходных мостов 12-100В, регулируемая токовая защита выходов драйверов 1-10А. тепловая защита двигателей и драйверов. поддержка терминала для вывода состояния драйвера на хост машину.
2. N КАНАЛЬНЫЙ ДРАЙВЕР КОЛЛЕКТОРНОГО СЕРВОПРИВОДА Управление PC/lpt emc2, mach3. step/dir?. выходной драйвер из П.1. энкодеры. пид регуляторы. настройка параметров пид через терминал П.1.
А так ли это надо, сейчас есть не дорогие и миниатюрных microATX, на которых отлично идет EMC2, вот посмотри на размер: http://cnc-club.ru/forum/viewtopic.php? ... t=20#p4892АБу писал(а):4. запуск Linux на Microblaze интерфейс Microblaze (emc2/Linux) к П.1 - 3
5. минимализация размеровlinux/emc2 до достаточного для пульта чпу
. Чтобы на нем была возможность управлять n шаговыми или серво (что сложнее) двигателями согласно программе (причем наверняка заранее подготовленной, для упрощения контроллера), управлять ими же в ручном режиме и возможность обрабатывать датчики и выставлять нули.Вполе реально.АБу писал(а):Есть мысль создания (полу)автономного пульта с драйвером для чпу
база fpga + adc + силовая исполнительная часть
наполнение fpga
цифровой автомат реализующий микрошаг для ШД и(или) сервопривод на базе (без)коллекторных движков.
цифровой автомат для управления шпинделем (vfd)
А вот это нереально.и на закуску + sdram + flash + софтоверный процессор для запуска линуха, например microblaze http://ru.wikipedia.org/wiki/MicroBlaze
и запуска в нем emc2
Настоятельно рекомендую их осваивать отдельно друг от друга.для меня цель этой задумки глубже освоить fpga, линукс + польза себе и людям
Дешёвые - с малым количеством ячеек. На них толковый процессор не сделаешь.зы плат с fpga на ebay есть по вполне бюджетным ценам
Вроде как самое навороченное ядро микроблаза 3157 LUTs для спартана6 http://www.xilinx.com/tools/microblaze.htmPetka писал(а): 1. fpga в которое поместится ядро процессора вместе с MMU стОит несколько тысяч долларов.
Petka писал(а): 2. Производительность получившегося процессора получится очень низкой ~200Мгц.
Petka писал(а): 3. Энергопотребление fpga будет зашкаливать. Придётся ставить очень мощные источники вторичного электропитания.
Petka писал(а): 4. Для запуска линукса придётся эмулировать кроме самого ядра ещё и периферию (минимум uart).
Petka писал(а):
Это только хардварные моменты. СтОит упомянуть о том, что вам придётся для своего процессора собирать и патчить весь софт самому. Это (gcc + binutils + bootloader + linux kernel + root filesystem + драйвера для своей периферии + поддержка ваших устройств в существующем ПО верхнего уровня).
Если процессор справится с декодером то мне не важно мизерная производительность у него или нетPetka писал(а):
И что в результате этой громадной работы получится? Процессор сомнительного качества и мизерной производительности при большИх габаритах, большом энергопотреблении, низкой надёжности, отсутствии какой-либо поддержки, никаких обновлений, никакой универсальности, огромная стоимость. Что вы с этого получите? Опыт портирования софта? Да, но его можно получить и не используя никаких fpga. Опыт соединения нескольких закрытых IP ядер для fpga? Тогда лучше сделать на FPGA то, чего действительно в железе ещё нет. Может какую очень хитрую периферию к готовому дешёвому производительному покупному процессору/микроконтроллеру.
ключевое слово "ГЛУБЖЕ".Petka писал(а):
Настоятельно рекомендую их осваивать отдельно друг от друга.
АБу писал(а):Вроде как самое навороченное ядро микроблаза 3157 LUTs для спартана6 http://www.xilinx.com/tools/microblaze.htm
129мГц не знаю хватит оно или нет
люди запускали декодер G кода если не ошибаюсь на арме7 вроде как с циклом 1мС он справляется cnczone.ru
а тут еще FPU на борту есть так что шансы есть.
не будет зашкаливать. пластмассовый корпус фпга как бы намекает, что проблем с тепловыделением быть не должно. технология 45нм все таки.
Что за декодер?
Если процессор справится с декодером то мне не важно мизерная производительность у него или нет
итого меньше габариты , потребление.
Хе. Если всё заработает сразу, то считайте что очень сильно повезло. А если не заработает? Как искать ошибку? Как отлаживаться? Как бороться с "гонками" сигналов, "иголками"? Всё в принципе решаемо, но какое время придётся потратить что бы получить посредственный аналог уже готового и отлаженного микроконтроллера? Посмотрите хотя-бы на http://starterkit.ru/html/index.php?nam ... view&id=41надежность должна быть в разы лучше чем то что сейчас, полностью вся цифра практически на 1 кристалле (снаружи только ОЗУ). как оно может быть еще надежнее?
на счет универсальности: имхо более универсального чем фпга цифрового полупроводника (общающегося с реальным миром) еще нет в свободной продаже и альтернатив вроде не намечается..
1. Мне не важно сколько стоит кортекс, важно что фпга можно сконфигурировать как паралельную машину у которой есть шанс справится с задачей.Petka писал(а):Да, спартан дешёвый, но медленный. См. ниже.
Сейчас копеечные кортексы работают на той же частоте.
люди запускали декодер G кода если не ошибаюсь на арме7 вроде как с циклом 1мС он справляется cnczone.ru
а тут еще FPU на борту есть так что шансы есть.
Да, но там никаким линуксом и не пахло. Это огромный плюс. Сначала надо определиться: писать свой собственный узкозаточенный софт, без использования функций операционной системы или воспользоваться наработками под linux?
Речь была про производительные FPGA, которые хоть как-то можно сопоставить с ПК.
декодер Г кодаPetka писал(а): Что за декодер?
Petka писал(а): Хе. Если всё заработает сразу, то считайте что очень сильно повезло. А если не заработает? Как искать ошибку? Как отлаживаться? Как бороться с "гонками" сигналов, "иголками"? Всё в принципе решаемо, но какое время придётся потратить что бы получить посредственный аналог уже готового и отлаженного микроконтроллера? Посмотрите хотя-бы на http://starterkit.ru/html/index.php?nam ... view&id=41
Или если есть желание повозиться и с fpga, то сюда: http://starterkit.ru/html/index.php?nam ... view&id=50
Ты смотрел в сторону MESA? Чем тебе она не подходит?АБу писал(а):1. Мне не важно сколько стоит кортекс, важно что фпга можно сконфигурировать как паралельную машину у которой есть шанс справится с задачей
Для emc2 и риалтайма не так важен проц, как сама система. Попробуй взять мать с хорошей latency и загрузить тот же емс из консоли, без "свистелок и перделок", я думаю, что 10мкс получится запросто. Другой вопрос, что все это можно сделать на MESA с лучшим результатом и без особого гимора.АБу писал(а):у меня Q6600 2ГГц под емс2 не справляется с циклом 10мкС
начал изучать.Nick писал(а):Ты смотрел в сторону MESA? Чем тебе она не подходит?
Mesa открытый продукт?Nick писал(а):Для emc2 и риалтайма не так важен проц, как сама система. Попробуй взять мать с хорошей latency и загрузить тот же емс из консоли, без "свистелок и перделок", я думаю, что 10мкс получится запросто. Другой вопрос, что все это можно сделать на MESA с лучшим результатом и без особого гимора.
-- Copyright (C) 2007, Peter C. Wallace, Mesa Electronics
-- http://www.mesanet.com
--
-- This program is is licensed under a disjunctive dual license giving you
-- the choice of one of the two following sets of free software/open source
-- licensing terms:
--
-- * GNU General Public License (GPL), version 2.0 or later
-- * 3-clause BSD License
Вы думаете что закрытое ядро микроблаза будет каким-то волшебным путём что-то как-то распараллеливать? Оно ничем не отличается от другого ядра. Как будет алгоритм линейный, так и останется линейным. В чём глубинный смысл fpga? Изобретать свой велосипед?АБу писал(а): 1. Мне не важно сколько стоит кортекс, важно что фпга можно сконфигурировать как паралельную машину у которой есть шанс справится с задачей.
Вполне возможно. Но только микроблайз это и есть тот самый "голый процессор", да ещё и медленный.имхо сейчас на любом голом процессоре не решить задачу управления железякой с микросекундными интервалами .
Проблема есть, но для её решения надо сначала определиться, что является "бутылочным горлышком". А уже потом пытаться решить.у меня Q6600 2ГГц под емс2 не справляется с циклом 10мкС, чипсеты и операционки не поддерживают реальное время, так сложилось и никому это не исправить, можно выжать из системы все на что она способна (пример мач3) но чтобы вылизать систему нужно глубоко в ней разобратся а на это нужно годы.
Аппаратная поддержка чего? Сначала надо определиться, что должна делать "аппаратная поддержка", по какому интерфейсу она будет взаимодействовать с "программной поддержкой". Как на сегодняшний день решается данная задача, какие есть минусы у существующих решений, как принципиально их можно решить и уже потом решать проблему.мое имхо должна быть аппаратная поддержка.
Насколько я понимаю с МЕСОй всё так и есть. Проц говорит что надо делать железке. (Ник, поправь если я не прав)проц должен говорить что и когда делать железяке.
Формально линукс не является real-time ядром. Есть набор патчей, которые позволяют приблизить linux к реалтайму. Но полностью реалтаймовым линукс не станет никогда. Есть туева куча различных сервисов, которые тоже требуют процессорного времени. Да эти сервисы от общего процессорного времени отбирают доли процента ЦПУ. Но если перевести эти доли в микросекунды получим десятки миллисекунд или десятки тысяч микросекунд отсюда и берётся джиттер.Линуксом не пахло... огромный плюс... в чем тут дело? линукс отъедает 90% производительности?
Двойные стандарты налицо =) Процессор готовый брать не будем (тут реюз не рулит). А вот линукс будем брать готовый (реюз рулит)Пользовать наработки Линукс однозначно. реюз рулит.
Сам декодер дело плёвое. G-code разрабатывался для тупеньких железяк. А вот для шагания движком надо очень шустро шевелить ножками это либо аппаратно, либо программно. Для программного шевеления и нужна большая частота.декодер Г кода
Начните лучше с АРМа. Симуляторы и эмуляторы это всё игрушки. Иногда соответствуют действительности а иногда....Использовать внешний арм соблазнительно на хочу сначала в симуляторе попробовать с микроблазом, если не срастется будем пробовать внешний.
В прошивках МЕСА есть генераторы шагов, обработчики энкодеров, пид регуляторы и pwm генераторы. EMC2 говорит им что делать и они это делают. В основном команды идут на заданное положение или заданную скорость. При этом эти команды даются раз в Servo period, который обычно гораздо более медленнее (1 миллисекунда) base perioda вместо 10-20 микросекунд.Petka писал(а):Насколько я понимаю с МЕСОй всё так и есть. Проц говорит что надо делать железке. (Ник, поправь если я не прав)
Декодер дело не такое плевое. Может само по себе это дело не ресурсоемкое, но блин с реализацией запаришься. Если не брать в расчет тупой Gкод из одних прямых и наворочек. В спецификации Gкода есть столько всякого:Petka писал(а):Сам декодер дело плёвое. G-code разрабатывался для тупеньких железяк. А вот для шагания движком надо очень шустро шевелить ножками это либо аппаратно, либо программно. Для программного шевеления и нужна большая частота.
оно не будет ничего распаралеливать.Petka писал(а):Вы думаете что закрытое ядро микроблаза будет каким-то волшебным путём что-то как-то распараллеливать?
для данной задачи мне не нужно линуксовое real-time ядро.Petka писал(а):Формально линукс не является real-time ядром.
в данной задаче Я не собираюсь программно шевелить ногами которые управляют железом.Petka писал(а):Для программного шевеления и нужна большая частота.
тьфу тьфу не могу вспомнить чтобы симуляторы и эмуляторы меня подводили.Petka писал(а):Начните лучше с АРМа. Симуляторы и эмуляторы это всё игрушки. Иногда соответствуют действительности а иногда....
для фпга это тоже есть. опыт использования софтовых процессоров (других правда) тоже есть.Petka писал(а):Порог вхождения в АРМ гораздо ниже. Есть уже готовый, собранный до вас компилятор и не один, есть копеечные JTAG-дебагеры (и их тоже много), Есть куча открытых библиотек, примеров, FAQ, Документаций, Errata. Не могу сказать что у меня с ними большой опыт, но в чём-то могу и помочь.
Что, и линукс на софтпроцессорах запускали? Если запускали то какие преимущества получили? Насколько устройство получилось дешевле, производительнее, компактнее, экономичнее, проще, чем аналогичное на готовом процессоре? И насколько быстрее устройство было выпущено по сравнению с устройством, основанном на готовом камне?АБу писал(а): для фпга это тоже есть. опыт использования софтовых процессоров (других правда) тоже есть.
нет не запускали. применяли picoblaze. на нем сильно не забалуеш.Petka писал(а):Что, и линукс на софтпроцессорах запускали?
Хм. Как планируешь использовать USB на плате (а)?АБу писал(а):Корректируем ТЗ:
1. Выбор платформы для отладки.
Варианты:
а. http://www.ztex.de/usb-fpga-1/usb-fpga-1.11.e.html
б. http://www.starterkit.ru/html/index.php ... view&id=50
2.5. Сборка linux-rt, emc2 под отладку.2. запуск Linux на отладке
3. запуск emc2 на отладке.
4. портирование прошивки хостмота с 7i43 ? на отладку.
5....
С усб сейчас связыватся не хочу.Petka писал(а):Хм. Как планируешь использовать USB на плате (а)?
Лучше брать отладку (б). К ней можно подключить стартеркитовскую-же LCD-панель. Ethernet, батарейка для RTC, USB - довольно полезные дополнения к Линуксу.
