Comments 9
Вопрос такого подхода в цене разработке, качестве результата и времени.
Вряд ли кому-либо удастся быстро и качественно повторить функционал LinuxCNC.
В проекте MachineKit эта задача решается за счет real time ядра linux и программ для сопроцессоров Programmable Real-time Unit (PRU) на чипе AM335x.
И есть задачи, которые стоит решать уже на уровне ПЛИС, так как никакого микроконтроллера может не хватить для грамотного параллельного управления разной высокочастотной электроникой, например, драйверами шаговых приводов с обработкой данных энкодеров и регуляторами скоростей. В таких задачах процессор бывает просто лишним.
Вряд ли кому-либо удастся быстро и качественно повторить функционал LinuxCNC.
В проекте MachineKit эта задача решается за счет real time ядра linux и программ для сопроцессоров Programmable Real-time Unit (PRU) на чипе AM335x.
Не совсем понятна необходимость в NIOS-процессоре в середине цепочки. HPS может взаимодействовать с FPGA напрямую и программу в нём можно дебажить без проблем.
Аналогичный вопрос нафига юзать ущербный NIOS, если вы используете SoC систему, где целых 2 900 МГц АРМа на которых вполне можно запустить Linux с GUI, если вам АРМ не нужен нафига было брать систему с SoC она как бы не бюджетная)
Подскажите, пожалуйста, откуда информация по частоте?
Насколько мне известно в DE0-Nano-SoC 925MHz (Насколько помню в настройках Qsys можно выбрать между 800 и 925)
Насколько мне известно в DE0-Nano-SoC 925MHz (Насколько помню в настройках Qsys можно выбрать между 800 и 925)
А из линукса с плисой можно как-нибудь проще общаться?
Поднять какой-нибудь spi с двух сторон и общаться через него хоть через скрипты на питоне и чтобы готовые драйверы использовать?
Поднять какой-нибудь spi с двух сторон и общаться через него хоть через скрипты на питоне и чтобы готовые драйверы использовать?
Все зависит от конкретной задачи.
Например, идея использовать Mailbox появилась неспроста. Нужно было найти способ связать два готовых набора ПО, написанных ранее для микроконтроллера и PC. Там связка была реализована вообще через UART. При использовании SPI пришлось бы вручную добавлять какой-то механизм контроля получения данных. Mailbox не дает записать новое слово, если старое не было прочитано.
Конечно, общаться с ПЛИС можно еще проще. Если всю скоростную логику реализовать на Verilog, то каждое устройство можно просто сделать модулем со своим набором регистров в памяти HPS, видимых напрямую ядром Linux. Тогда можно обойтись и без NIOS и без транспортного уровня вообще. Но в этом случае придется написать еще и свои драйвера для каждого из устройств.
Например, идея использовать Mailbox появилась неспроста. Нужно было найти способ связать два готовых набора ПО, написанных ранее для микроконтроллера и PC. Там связка была реализована вообще через UART. При использовании SPI пришлось бы вручную добавлять какой-то механизм контроля получения данных. Mailbox не дает записать новое слово, если старое не было прочитано.
Конечно, общаться с ПЛИС можно еще проще. Если всю скоростную логику реализовать на Verilog, то каждое устройство можно просто сделать модулем со своим набором регистров в памяти HPS, видимых напрямую ядром Linux. Тогда можно обойтись и без NIOS и без транспортного уровня вообще. Но в этом случае придется написать еще и свои драйвера для каждого из устройств.
Я понимаю, что цель статьи показать методы, но хардварный uart без NIOSов был бы конечно проще…
Контроль получения это проверка контрольной суммы и выставление флага?
Контроль получения это проверка контрольной суммы и выставление флага?
Sign up to leave a comment.
Распределённая система управления на базе SoC FPGA