Comments 62
Would you like to create the new run directories for the synthesis of all labs in the package, based on your FPGA board selection? We recommend to do this if you plan to work with Quartus GUI rather than with the synthesis scripts.
то нужно ответить Y.
На такой вопрос нужно отвечать не "Y", а "YES I DO create run directories rather than with the synthesis scripts". Еще бы стихи Пушкина в вопрос вставили.
C hardware сложнее, если бы не доступ к апаратуре - упаковка в Docker и все воспроизводимо у всех кто запускает контейнеры, как и виртуальные машины (если бы не досуп к аппаратным ресурсам)
Помню, сталкивался где-то у себя с разным поведением, если в скрипте #!/bin/sh или !#/bin/bash . Но как-то сильно на это внимание не обратил, исправил в проблемном скрипте на bash и все...
То есть криво написаный скрипт, с использованием относительных путей, без проверок на то, что за оболочка используется, но удар в спину почему то от Ubuntu?
Пути используются корректно - когда надо realpath, когда надо относительный.
Если хотите покритиковать - покажите конкретные некорректные места вот здесь - https://github.com/yuri-panchul/basics-graphics-music/tree/main/scripts/steps
Что касается проверок - я никогда не видел и не слышал, чтобы скрипт, в котором есть shebang bash, как-то проверялся что его кто-то пытается выполнять как "sh скрипт". Как это вообще проверять? При этом shebang игнорируется.
А удар в спину заключается в том, что еще в 1990-х куча материалов говорила, что bash - оболочка по умолчанию в линукс, и sh привязан к ней через symbolic link, а вдруг оказалось что они втихую подменили bash на dash и теперь надо проверять против еще одного кривого сценария использования.
Всё же вы не правы на счёт удара в спину. В 90-х, да и в 00-х, в куче статей говорилось что bash в линуксе используется по умолчанию, а в другой куче говорилось только о том что он в линуксе есть по умолчанию. Те статьи ведь писали обычные люди, которые установили себе какой-то конкретный дистрибутив и работали, в основном, только с ним.
Применение же bash в качестве sh как раз и породило массу проблем с башизмами: человек честно указывает в шебанге «/bin/sh», а на самом деле система использует bash. При этом он эти самые башизмы использует, просто об этом не подозревая — работает же. И, в результате, этот скрипт прекрасно работает на компе пользователя, но при запуске в каком-нибудь hp-ux валится. Почему? От чего? Мы же явно указали «/bin/sh»! А вот фигвам, вы указали, а у ОС своё прочтение.
Собственно, использование в качестве sh чего-то, реализующего только POSIX SHELL и есть стандарт.
Ну, badstyle кнш, но проблема не в этом же. По команде sh вместо bash вызывается dash. Не знаю, кстати, что это такое, пошел гуглить
Dash для sh вместо bash в debian/ubuntu используется очень давно. Проверять это в скрипте достаточно просто: если в переменной BASH_VERSION что-то есть — скрипт выполняется башем.
Куда на самом деле указывают sh и bash:
$ readlink -f $(which sh)
/usr/bin/dash
$ readlink -f $(which bash)
/usr/bin/bash
В сеансе bash переменная есть:
$ echo $BASH_VERSION
5.1.16(1)-release
А в dash — нет:
$ sh -i
$ echo $BASH_VERSION
$ set | grep ^BASH
$
Простая проверка.
В начале скрипта добавляем:
$ cat test_bash.sh
#!/bin/bash
[ -n "$BASH_VERSION" ] || { echo "please run this script with bash"; exit 1; }
echo "начинаем начинать"
И запускаем:
$ ./test_bash.sh
начинаем начинать
$ bash test_bash.sh
начинаем начинать
$ sh test_bash.sh
please run this script with bash
О, спасибо!
Когда в 2021 ставил Ubuntu 20.04LTS, то там sh была симлинком на dash. Возможно кто- то из причастных скучает по Korn shell или ему там что-то недодали, не знаю.
А не решило бы проблему на месте, в качестве "временной меры" , добавление команды, bash перед скриптом? То есть:
$ bash ./some_path/ some_script.sh
Тестировать свои скрипты на работоспособность на разных ОС?
Явно указывать, на каких ОС они протестированы?
Заорачивать в docker?
Не использовать bash?
Использовать python?
Да нет, сложно как-то… @#$-@#$ и в production наше все.
Я протестировал скрипты этой и предыдущей инкарнации в Ubuntu, Lubuntu, CentOS, ALT, Simply Linux, Astra Linux и других. Докер в решении всех проблем не поможет - там проблемы с USB Blaster и его драйверами.
Почему не использовать bash, если он везде есть и нормально работает кроме вот таких кривых сценариев использования.
Питон... Да у питона куча проблем с совместимостью с библиотеками.
Питон… Да у питона куча проблем с совместимостью с библиотеками.
Питон… Да у питона куча проблем с совместимостью с библиотеками.
Какие библиотеки нужно использовать в обертке над zip, чтобы словить несовместимость?
По части docker, есть флаги privileged и device, не знаю, пробовали или нет. Я работаю с Xilinx программатором, там вообще все удобно по сети без заморочек с USB.
А по поводу dash в Ubuntu это давно известный факт, а не удар в спину, особенно для тех кто Petalinux от Xilinx использует если говорить об FPGA, куча одинаковых вопросов на форуме. У того же digilent например прям в инструкции об этом написано, dpkg-reconfigure dash или ln -fs /bin/bash /bin/shрекомендуют обычно, лучше в docker конечно.
На Perl надо было писать. Вот уж кто закостенел, но при этом достаточно гибкий...
писать негативные комментарии в интернете — yees,
помочь школе, протестировать всё во всех предложенных случаях, открыть Pull Request на GitHub со своими идеями и предложениями по улучшению — noo
Вопрос немного не по теме: у меня древний офисный ноут 2012 года с целероном и 2 гигагми оперативки(2 ядра, 2 гига, игровой, классика). ОС Linux Mint. Необходимое ПО у меня запуститься хотя бы?
Запустится, но на пределе. У меня есть ноут с такими параметрами (2012 год, 2GB, Lubuntu), на нем Intel FPGA Quartus работает. Нужно swap не забыть сделать в несколько гигов.
Откопал свой старый комментарий. У меня такой старикан:
Laptop System: Acer product: Aspire 5030 v: V1.40
BIOS: Phoenix v: 1.40 date: 03/02/2006
AMD Turion 64 Mobile ML-32 bits: 64 type: UP
RAM:2 GiB ID-1: /dev/sda vendor: Hitachi model: HTS421280H9AT00 size: 74.53 GiBМного перепробовал дистрибов и остановился на Debian GNU/Linux 11 (bullseye) - LXDE(Openbox 3.6.1). Ставил в начале этого года.
Сейчас актуален Debian 12 Bookworm.
https://cdimage.debian.org/debian-cd/current-live/amd64/iso-hybrid/debian-live-12.1.0-amd64-lxde.iso
Если есть время и навык - неплохо зайдет Arch Linux
https://wiki.archlinux.org/title/LXDE_(Русский)
Старый скрин: Старичок без томозов воспроизводит ролики yutube в Chromium(480p). Загрузка CPU в среднем 80% Используется родной HDD IDE.
Купил HDD кредл в отсек CD/DVD IDE(PATA), добавил SSD и развернул Debian на него.
От части пользователей был запрос к организаторам не валять дурака и показать как работать по нормальному, то бишь в Windows GUI и без скриптов.
facepalm.jpg
Может, ребята просто ошиблись профилем? ИМХО, если они изначально неспособны осилить консоль и скрипты, это уже вполне себе маркер для первичного отсеивания.
нет, они просто изуродованы неправильным нормированием. Их надо не фильтровать и отсеивать, а объяснить и занести другие знания в голову.
К чему такой скепсис? И в Quartus, и в ISE Xilinx / Vivado отличные графические приложения. И это как раз те программные комплексы, где писать скрипты - себе дороже и проще использовать GUI. Особенно забавно смотрится про "долгое возюканье мышью", когда обычно нужно ткнуть что-то типа "Implement" и потом "Programming" / "Simulation". Скрипты имеют там смысл, если нужно писать свою какую-то хитрую обертку, например, для сетевого подключения, прошивки. И, кстати, обычно большая часть времени уходит на ожидание синтеза / оптимизации.
И это как раз те программные комплексы, где писать скрипты - себе дороже и проще использовать GUI.
Без скриптов не получится CI. Не сможете погонять регрессионные тесты. Со скриптами какой-нибудь Jenkins раз в сутки будет собирать ваш проект и гонять полсотни тестбенчей в автоматическом режиме, а затем рисовать какую-то красивую статистику по этому поводу.
Это очень круто, вы делаете очень важные дела!
Пишем фигню - получаем фигню.
Внезапно? Нееет! Виноват убунту! И билл гейтс. Не ну а шо система работает не так как мы себе придумали?
#!/usr/bin/env bash
#!/usr/bin/bash
или, что правильней
#!/bin/bash
И всегда будет запускаться именно bash.
Ubuntu наносит ответный удар:
/usr/bin/bash
bash: /usr/bin/bash: No such file or directory
В том случае, который описан в статье, пользователи явно указывают в командной строке, какой они хотят использовать командный интерпретатор:
$ sh 03_synthesize_for_fpga.bash
От этого никакие декларации не помогут. Но таким пользователям можно предложить попробовать ещё много неработающих вариантов:
$ perl 03_synthesize_for_fpga.bash
$ python 03_synthesize_for_fpga.bash
$ ...
И каждый раз будут выдаваться новые ошибки, которым можно удивляться.
Описанная в статье претензия претензия относится к разряду "Компьютер (операционная система) работает не так, как я хочу!". Ну, ок.
Работать с GUI просто неэффективно, в Quartus нужно долго водить мышкой, нажимать на кнопки и открывать разные диалоги просто чтобы запустить прошивку платы.
Потоково работать может и неудобно, но обучаться-то - вполне. Чего может быть проще окошек? Тем более есть вещи, где графика нагляднее, например подсветка линий с невыполненными временными ограничениями, модульный дизайн проще мышкой нарисовать... А скрипты - это дело наживное и кто пойдёт по стезе сам себе велосипедов нужных напишет там где потребуется.
Потоково работать может и неудобно, но обучаться-то - вполне. Чего может быть проще окошек?
Проще окошек может быть только командная строка, согласен. Никогда не программировал и не программирую в окошках и своих студентов обучал этому же подходу.
Когда у вас тысячи модулей, их рисовать мышкой неудобно. Хотя рассматривать мышкой иерархию в waveform viewer - это OK.
За Русь Верилогу обучусь!
?
мы не смогли победить Windows Subsystem for Linux ...
Это как ? Хотите совет ? wsl2+docker - 99% повторяемость. А вот как раз git bash врагу не посоветую.
Как раз так и запускал под убунтой! И у меня была эта проблема. Спасибо за разъяснение. Потом перезагрузил компьютер в виндовс, а там gowin eda была установлена в не стандартый путь, пока не перенес все в стандартые катологи. Почему-то переменная среды GOWIN_HOME ге подхватывалась скриптом и он не мог найти установленную ide. Спасибо за ваш труд!
Господа! У меня Quartus 15.0. Ubuntu. В нем потихонечку изучал, как мог, fpga. А вот теперь появилась возможность, благодаря этому курсу, изучить системно. Но в старом Quartus нет intelFPGA_lite, а новую версию интел не дает. Ну и скрипт basics-graphics-music-main завершается ошибкой. Как быть? Что делать?
Какая у вас плата? Где установлен дистрибутив? ~/Altera ? В принципе скрипты поддерживают версии начиная с 9 (13.0 ... 22.1) так что наверняка у вас запустится после пары пинков.
Например вы можете сделать чтобы скрипт искал версию в ~/Altera если поменяете строчки здесь (также можно просто самому поставить PATH и QUARTUS_ROOTDIR до запуска скрипта):
Первое занятие Школы Синтеза и удар в спину от Ubuntu