one_eight_seven

Нет. Это не так. Я тот сайт не читал, поэтому, зачем они, на том сайте, смешали два разных понятия, мне неизвестно: стандарт и без этого написан путано и непоследовательно, и не нуждается в дополнительном усложнении. В стандарте такого двойного использования термина "гаммирование"- нет.

Не совсем так. Это процесс зашифрования/расшифрования - XOR открытого/шифртекта с гаммой шифра. Сама же гамма шифра - это зашифрование счëтчика в режиме простой замены (ECB). Таким образом, гамма шифра будет всегда кратна размеру блока. А уже потом, в побитовом XOR, используйте столько бит, сколько нужно.

Не надо сворачивать на CI/CD. Вы что такое GIT - не знаете. Пуш в мастер - это, вообще-то слияние двух веток, по умолчанию - master и origin/master. Это не отличается от мерджа feature branch в мастер и ли мерджа двух любых других веток. Поэтому все те ужасы, которые вы описываете, полностью применимы и к вашим подходам. Я понимаю, что мнение - оно как дырка в заднице, есть у каждого, но если вы его высказываете к CI/CD, не надо вилять жёппкой и рассказывать, что у вас этого не может быть в принципе. Нет, прикладывайте свои мечтания и к своей системе точно таким же образом как к другой, и удивляйтесь результатам.

Я же выше написал, что CI/CD не для необучаемых идиотов. А ситуация, описанная вами - это типичный идиотский сценарий, т.е. сценарий, который никогда не случится, если хотя бы один из учатников окажется не идиотом. А тут - все, и участники описания, и их руководители, и руководитель руководителей, которые исключены из описания, но должны присутствовать. ист Но история хорошая, много о вас говорит. Почитайте, что сделает git, если несколько людей попробуют запушить изменения, тем более, такие, как у вас.

Пнятненько. Я далековато шагнул. Вообще, разговор про коммиты в мастер начал я и именно в контексте CI/CD. Если по каким-то квотам нужно держать необучаемых идиотов, и ни в коем случае их не увольнять - то им можно дать отдельный репозиторий, и они могут там хоть до второго пришествия решать конфликты. Нормальные же разработчики обучаемы, и, поскольку пушат они часто, то очень быстро тренируются делать это правильно.

Какое это имеет отношение к CI/CD?

И что здесь здравого? Это не может быть здравым, пока оно в отрыве от модели разработки и от задачи. Здравый случай модерации человеком при приёмке работ: Когда работает толпа, то сваливать это на одного - не получится. (поэтому, и изобрели pull request'ы между форками, когда вся работа ведётся в частном репозитории (условный origin, если говорим про git), а для апстримов - другой, уже публичный, репозиторий (условный upstream). На несколько апстримов назначается интегратор (лейтенант, мейнтейнер - куча ему названий), который мерджит код себе в частный репозиторий, там разбирается с конфликтами, и отправляет уже в свой upstream. Где над всем этим - диктатор, который, в итоге и предоставляет всем продукт. Так, например, разрабатывается ядро линукса. Тут нет CI/CD, и она невозможна. Здравый случай модерации человеком при назначении задач, и автоматической приёмки работ: Второй случай, когда тоже куча людей работает, но они под контролем большого брата, своей горячо любимой корпорации (например, Netflix), где огромная куча народу пушат прямо в мастер. Тут есть CI/CD.

Да нет такого критерия - по строкам кода. Коммитами в мастер пишут кое-что посложнее, чем firefox, и наличие бренчей в той же либре или линуксе - это производственная необходимость - их нельзя перевести на ci/cd, потому что нет контроля над разработчиками (да и не только - над всеми contributor'ами там нет контроля). Там, если построить CI/CD, то каждая уникальная снежинка свои хотелки в основной код будет отправлять, а запретить такой снежинке этим заниматься - нелья: нет рычагов влияния. Поэтому и нужна дополнительная модерация, и feature-branch, и системы лейтенантов, и т.п. CI/CD же, наоборот, перекладывает эту модерацию на менеджмент, который назначает задачи, а разработчики коммитят код, который эти задачи решает. Вместо модерации - проверка на собираемость и прохождение базовых тестов. А перед развёртыванием - автоматическое же прохождение регрессий. Поэтому внутри компании, где есть контроль над разработчиками, CI/CD построить можно, и люди знают, над чем кто работает, да и за метриками следят, ненужные фичи не должны попадать в итоговый код,. Понятно, что необычные люди-снежинки с руками из задницы найдут способ - но это не системная ошибка, а эксцесс. Они так же и в feature-branch найдут способ самовыражения. И, ещё раз, поскольку любой код должен попасть в мастер (как, кстати, и удаление кусков кода - тоже должно попасть в мастер), то какой смысл тянуть feature branch? Да, когда у себя локально работаешь над кучей задач, экспериментируешь - да хоть тремя слоями веток обмазывайся, никто не запретит. Но дальше - обновляешь мастер, мерджишь в него свои изменения, прогоняешь код через локальные тесты (опционально, но крайне полезно, особенно если локально тесты бегут быстрее, чем проходят через конвейер ci/cd), и пушишь в мастер. Т.е. я не призываю работать без веток, я говорю о том, что CI/CD не накладывает ограничений на СКВ, и работать будет одинаково и в GIT, и в HG, и в SVN. И да, коммит в мастер - это термин сам по себе, в отрыве от гита. В случае конкретно гита это будет "пуш в мастер"

Вы устарели. Это лучшая практика из имеющихся (для CI/CD) на сегодня. Вообще, если немного приложить логику, то это очевидно. Если ваша работа не должна попасть в мастер, то она не нужна. Значит, тянуть с решением возможных проблем мерджа не стоит - дальше их будет только больше. Да, а это кто? Дальнейшее словоблудие даже читать после такого не стоит. Чего я и не стал делать.

[alias] lg = !"git lg-specific --all" lg1 = !"git lg1-specific --all" lg2 = !"git lg2-specific --all" lg3 = !"git lg3-specific --all" lg-specific = log --graph --abbrev-commit --decorate --pretty=format:'%C(bold blue)%h%C(reset) %C(bold green)[%cd]%C(reset)%C(dim white): %an %C(reset)- %s %C(auto)%d%C(reset)' --date=format:%c lg1-specific = log --graph --abbrev-commit --decorate --format=format:'%C(bold blue)%h%C(reset) - %C(bold green)(%ar)%C(reset) %C(white)%s%C(reset) %C(dim white)- %an%C(reset)%C(auto)%d%C(reset)' lg2-specific = log --graph --abbrev-commit --decorate --format=format:'%C(bold blue)%h%C(reset) - %C(bold cyan)%aD%C(reset) %C(bold green)(%ar)%C(reset)%C(auto)%d%C(reset)%n'' %C(white)%s%C(reset) %C(dim white)- %an%C(reset)' lg3-specific = log --graph --abbrev-commit --decorate --format=format:'%C(bold blue)%h%C(reset) - %C(bold cyan)%aD%C(reset) %C(bold green)(%ar)%C(reset) %C(bold cyan)(committed: %cD)%C(reset) %C(auto)%d%C(reset)%n'' %C(white)%s%C(reset)%n'' %C(dim white)- %an <%ae> %C(reset) %C(dim white)(committer: %cn <%ce>)%C(reset)' Я себе вот это добавил в .gitconfig, и дерево коммитов тоже смотрю в коммандной строке. diff тоже смотрю vim'oм: [alias] ... d = difftool ... [diff] tool = vimdiff пользоваться ещё проще: git lg git d

так, собственно `git`

Для CI/CD не нужна никакая навороченность СКВ. Все коммитят в мастер.

Изменяются внешние соединения, не ядро. Но этот вопрос я даже не поднимал. Спасибо. Смысл не в том, чтобы костылить. А в том, чтобы сделать на C. Понятно, что после naked ничего кроме ассемблера не ожидается. И пока документация атрибута naked не поменялась, это спекуляция недокументированными возможностями.

Да, спасибо большое. Я недостаточно точно задал вопрос. Мне не для работы с уже готовым чипом, мне для его разработки, точнее, проверок. Где вектора и т.п. могут меняться. И невнимательность приводит к слишком долгому поиску ошибок. Поэтому, хотелось что-то вроде,: typedef void (*isr_f)(void); volatile isr_f vector_table[128] __attribute__((used, section(".vectors"))) = { [0] = default_exception_handler, [1] = default_vector_handler, [2] = default_vector_handler, [3] = software_handler, ... }; Т.е. чтобы код сам следил за их расположением. Понятно, что в ассемблерной вставке можно поставить метки, чтобы было удобно искать смещение, но за порядком всё-равно надо следить вручную. Без дополнительной проверки компилятором. Спасибо ещё раз. P.S. Есть ещё и такой вариант: __attribute__ ((section(".__vector_table"),naked,noreturn)) void isr_jumps(void) { default_exception_handler(); default_vector_handler(); default_vector_handler(); assoftware_handler(); }

Здравствуйте. Для RISC-V доступны несколько вариантов таблицы векторов. Одна из них - это Core Local Interrupter (CLINT) vected mode. Где в таблице не просто вектор, по которому нужно перейти, а инструкция перехода на адрес, по которому расположена ISR. На ассемблере это выглядит вот так: .global __vector_table __vector_table: IRQ_0: j default_exception_handler IRQ_1: j default_vector_handler IRQ_2: j default_vector_handler IRQ_3: j software_handler ... Буду очень благодарен, если кто-нибудь подскажет способ сделать эту таблицу на C.

С другой стороны, потом мучительно добавлять исключения по недостижимым состояниям. P. S. Это я исключительно про добавление default в код с и без того полным перечислением. Особенно, если код автогенерируется - таблицы подстановок, family, и т. п.

Это отсылка к довольно известному в индустрии анекдоту. Оно и видно.

Это немножко не то же самое, что произвести печатную плату. Например, они могут использовать макро флэш памяти именно TSMC'шные. И для перехода на другую фабрику - это переделка не только самого макро флэша, но и контроллера флэша, BIST, DFT, топологии, выпуск нового набора масок. Т.е. по сути - это уже другой микроконтроллер.

Нет. Мы имеем в виду, что в комбинаторном always должне быть определены все случаи, и в них переменной должно быть присвоено новое значение (возможно, оно будет тем же самым, но должно браться откуда-то снаружи, а не присвоение переменной самой себе). В противном случае, значение нужно запомнить, значит, будет latch, поскольку нет тактирования. Конкретно здесь - кейсы на 8 значений, а обрабатывается 4, и так - несколько раз. Тут не код менять надо, а ДНК, или хотя бы почитать что-то полезное. Поиграться в песочнице с кодом на 4 строки, потом на 16. А не тащить портянку, не понимая что это - и сразу на форум.

С того, что они ведут себя так, как должна вести комбинаторная логика. Можно сделать комбинаторику и с неблокирующими присваиваниями, но зачем? А вот то, что в приведённом примере всё-равно не будет комбинаторики - это да.

@Сергей Борщ, @cybersonner спасибо. Подключиться удалось - надо было переложить файл в другую директорию и ещё и переименовать, чтобы запустился установщик. Но после установки, как уже отметил @cybersonner, этого функционала не предусмотрено. Тему можно закрывать.

Да, тоже об этом слышал. Но нет. Не запускается. Спасибо, раз нет, то и чёрт с ним, что не запускается. Спасибо, но как обойти проблему я знаю. Мне её решить хотелось. Ну и вишенка на торте - это же FTDI - они не работают так, как написано, они не работают так, как логично. Они не работают так, как они должны были бы работать. Они работают через задницу. Если её включить как вход, то при питании 3,3 В она держит линию на уровне 2,5 В, и внешние 75 k способны утянуть это аж до 2,3 В, что ну никак не 0. Вот после того, как выводы попереключать в разные состояния - там да, там получается что-то как-то заколхозить: поведение вывода в состоянии входа изменяется на ожидаемое. Кстати, судя по поведению, там не близко к 75k, там ближе к 200 k, но вроде как их диапазон подтяжек - от 100k до 300k.

Приветствую Крайне хочется отключить Pull-Up на GPIO в режиме Asynchronous bit bang. Документация на этот чип такая, что лучше бы её не было вообще. Время потрачено, знаний не то, что не прибавилось, а даже убавилось. То, что они называют "библиотекой" d2xx, -не предоставляет подобных высокотехнологичных и инновационных функций. libftdi - того хуже. Вычитал, что может помочь FT_PROG, всё сделал как надо - купил винду, установил, скачал FT_PROG, чтобы узнать, что он не запускается. Внимание вопрос. Может быть кто-то находил/реверс инжинирил способы работы с настройками выводов этого поделия?

Daisy chain

Вот это как раз очень просто. Особенно, если карта регистров описана в ipxact - тогда симуляторы и вовсе сами создадут структуры данных и заявленные вами тесты. Можно пример? Да, дурацкие названия классов я встречал, например - Virtual Sequence и Virtual Sequencer, при том, что ни один из этих классов не virtual, а второй - ещё и не секвенсер, но с портами - не встречал. Непонятные правила и ограничения - тоже не встречал.