makc

Проверьте соответствие порядка подачи питания требованиям документации. Желательно не просто по схеме и описаниям проверить, но и убедиться с помощью осциллографа на дурящих платах, что с этим всё в порядке.

При том, что АЦП будет регистрировать суперпозицию шумов и нужно гарантировать, что правильный шум (имеющий равномерное или подобное ему распределение) будет доминировать. В противном случае получится регистратор наводок от какого-нибудь ШИМ DC/DC. Случайность и независимость этого шума от процессов в системе вы можете обосновать? Я - нет. Посмотрите, как люди бьются с генерацией случайных чисел на кольцевых генераторах... Казалось бы всё просто, но это совсем не так как кажется. 😞 Это не добавляет энтропии в получаемое случайное число, но выравнивает распределение случайных величин. Т.е. в сумме это всё равно будет не качественное случайное число. А, главное, есть вероятность его повторения, которой по словам ТС быть не должно в принципе.

Если ТС нужен GUID/UUID, то как раз наоборот хорошо. Согласен, но про ключи у ТС речи не шло. В любом случае решать ТС, т.к. мы не знаем сути прикладной задачи, которую он пытается решить с помощью этого механизма.

Есть два варианта: ноль и всё остальное. 😉 В данном случае будет не ноль, хотя и очень малое число, но не ноль.

Ваш, @jcxz, вариант на АЦП, к сожалению, не отвечает этому требованию. Вообще у ТС задача очень похожа на задачу получения GUID/UUID и по-моему поэтому не стоит мудрить. Это пока, к сожалению, только умозрительная оценка. Я, например, наблюдал на выходе аппаратного генератора случайных чисел МК от Миландра К1986ВК025 далеко не случайные последовательности типа 0xDEADBEEF и т.п. Сильно удивлялись вместе с коллегами и смеялись, а потом оказалось, что количество энтропии там мало, поэтому получались всякие смешные комбинации. Если энтропию копить и правильно обрабатывать (размешивать и т.п.), то результат получается сильно лучше. В предлагаемом вами варианте нет никаких гарантий отсутствия повторений, т.к. если основным источником шума в АЦП будет помеха от работы какого-либо узла платы или от самого МК, то увы, повторения будут, вопрос размера выборки. Да, и именно это обеспечивает гарантию отсутствия повторений за заданное время.

Псевдослучайная последовательность всё же случайная для внешнего наблюдателя, не знающего закон её формирования. К тому же в изначальном вопросе ни слова про истинно-случайную последовательность (непредсказуемую априори) не написано. Ваш вариант, кстати, тоже псевдослучаен, пока не будут доказаны его свойства и не будет дано теоретико-вероятностное обоснование, в том числе пока не будет построена и доказна математическая модель случайного процесса. Увы.

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

Не у всех STM32 он есть аппаратный. Пока ТС не уточнит, какие именно STM32 он рассматривает, то что-то определённое предложить сложно.

Главное не забывайте, что с точки зрения логики энумерации PCIe это тот же PCI с дополнениями. Поэтому можно смело начинать читать, как это делалось/делается для PCI.

Всё это описано в стандарте, но в разных его частях. Поэтому могу предложить вам почитать книгу, которая есть на местном FTP в /pub/DOC/STANDARDS/PCI/Whitepapers/Budruk R., Anderson D., Shanley T., PCI Express System Architecture(2003).pdf Начните с главы 21. Такой опыт есть, правда не на Zynq, а на Artix. Но в целом разницы нет, и там, и там Root Complex. Вы управляете ресетом, даёте ресет, IP поднимает линк, далее вы сами должны сформировать конфигурационные транзакции для поиска устройств (endpoint) на шине, записывает параметры в их регистры (назначает адреса, разрешает работу MEM/IO) и выполняет транзакции чтения/записи. В целом там нет ничего сложного, звучит это страшнее, чем есть на самом деле.

Опишите вашу задачу, что именно и для чего должен делать ваш хост. В общем случае порядок действий такой: ресет, подъём линка, энумерация, назначение базовых адресов, разрешение работы (настройка управляющих регистров в пространстве конфигурации), обмен данными (чтение/запись по адресам BAR и/или обмен в режиме DMA).

https://github.com/tdrozdovskiy/i2c_eeprom_blk - не пробовали?

Да, точно, это немного другой интерфейс с таковым сигналом (синхронный UART), которого у FTDI нет. Поэтому единственное на мой взгляд решение для FTDI это программно воспроизвести этот протокол с использованием режима BitBang или MPSSE. Точно так же сделан драйвер для протокола SWD. Но готовых реализаций для этого варианта нашел только одну - https://github.com/DiUS/xmega-pdi-pi2 Если в ней заменить работу с GPIO-пинами на работу с пинами FTDI, то вы получите искомое решение.

https://github.com/mraardvark/pyupdi Avrdude использует ту же схему.

Раздел вполне соответствует уровню и характеру вопроса. Устное предупреждение: исходники и логи (длинный текст) прикрепляйте к сообщениям в виде файлов (аттачей), а не вставляйте в текст без тега код и спойлеров. В противном случае вы получите предупреждение и посты будут удалены.