Хмм, оказалось под фаерфоксом плохо открывается сайт. Причём в приватных вкладках всё работает нормально. Да, после этого пробовал отключать все плагины - не помогает, видимо не в них дело.
maxlab писал(а): Чт июл 02, 2026 23:37:06Особенно интересно PIO с вспомогательным ядром. Это круче чем на PR2040
У PR2040/2350 PIO со всеми портами работает, можно за такт записать 32 бита, начиная с текущего пина, одновременно дергая еще 5 других пинов и все 12 PIO SM могут это делать одновременно. Полнейший детерминизм, поэтому там можно всякие HDMI реализовывать. A у U-1000 просто третьему ядру выделили быстрый 16-ти битный порт(у Pico они все быстрые). Понятно, что у RISC-V ядра инструкций намного больше и можно писать более гибкие программы, но что будет если параллельно с SoftDDS запустить на PIO что-то другое? Поэтому я бы очень осторожно высказывался касательно "круче чем на Pico" )
Adrift писал(а): Пт июл 03, 2026 08:21:54
я бы очень осторожно высказывался касательно "круче чем на Pico" )
Ну хорошо, вместо слова "круче" пока применим "гибче"
Но тут главная идея не запускать на этом ядре что то еще кроме SoftDDS. Для чего то другого есть еще 2 ядра с GPIO.
Как объяснили создатели U-1000 это вспомогательное ядро было введено как раз для узкоспециализированных целей в интерфейсо/протоколо строении.
Обещали выложить апноут как этим хозяйством грамотно пользоваться. Ждем-с
Отладка в модели ТСМА в виртуалке под виндой https://cloud.mail.ru/public/ix1N/6hPZGJ1jT
Есть полезная особенность. Не обязательно иметь внешний JTAG на FTDI. Одно ядро можно задействовать в качестве эмулятора JTAG через USB.
Почти как у ESP32C3 . Еще есть интересная фича... Можно предкомпилированный дамп грузить в специальную область памяти для Core_2 и осуществлять запуск.
Фактически все 3 ядра могут исполнять разнонаправленные задачи, при этом разделяя между собой отдельные банки памяти с независимым доступом. Память у них 2х портовая
Zapolyarny писал(а): Вс июл 05, 2026 13:49:27
а закинуть в это ядро, тоже (как у других) множество вариантов?
Выходит что можно по разному. Можно отладить задачу на нужном ядре и потом в рантайме подгрузить полученный дамп.
Но этот вопрос еще предстоит глубоко исследовать.
А смысл? Это практически ARM. По идее, лучше делать для разных серий разных производителей, так как, например, CH32V00x и этот BE U-1000 различаются настолько сильно, что то, что они оба RISC-V - уже как-то и не важно. Кроме того, недавно мне говорили, что только безграмотный любит лазить в отладках, читать ассемблерный листинг и т.д. Предположим, что это так (хотя это совершенно не так). Тогда вообще нет разницы, какая основная архитектура, остаются лишь различия в периферии и таких вот ядерных нюансов как у BE U-1000.
Zapolyarny писал(а): Пн июл 06, 2026 12:38:02
Кроме того, недавно мне говорили, что только безграмотный любит лазить в отладках, читать ассемблерный листинг и т.д.
Видимо я пещерный человек Кто такую глупость сказал? Я брошу в него камень!
На самом деле есть несколько подходов... мое субъективное мнение.
Разграничение ответственности между производителем чипов и конечным потребителем. Поясню на примере десктоп разработки .
Операционная система - Библиотечная абстракция - Приложение пользователя.
На каждом этапе своя ответственность. И не всегда нужен доступ к ОС на уровне WinAPI например, или к железу минуя syscall ОС.
То же самое можно отнести и к эмбедингу. Зачем разбираться с периферией на уровне регистров если есть вменяемый HALL (библиотечная абстракция), а вопрос архитектуры - это тулчейн.
Это разделение существенно сокращает время вывода приложения в эксплуатацию, т.к, в первом приближении, достаточно хорошо изучить библиотечную абстракцию.
Но если речь идет об выжимании из железа всего возможного - велком на нижестоящий уровень
