RISC-V К1921ВГ015 - новая забава, 32-разрядный МК

[linux_rulezz]

Ну как же не нужно в стартап лезть? А когда нужно новый МК добавить? Скажем, есть у меня стартап под CH32V003, а я хочу добавить для CH32V203... Ну и т.д., и т.п.
Да и вообще, некошерно это, когда ты пишешь код на С, стартап асмовый использовать. Плюс, я вообще асм не знаю и знать не хочу!

[maxlab]

linux_rulezz, Вообще то так не делают
У каждого чипа есть свой стартап предоставляемый производителем вместе с SDK
Не надо ничего добавлять... Бери готовый и используй.
Лезть в стартап можно лишь по нескольким причинам. Радикально упростить начальную инициализацию камня
или, наоборот, добавить инициализацию периферии которую делают обычно в user space.
Ну... или векторами побаловаться
У каждого стартапа, по завершению его работы, есть вызов функции main().

[linux_rulezz]

[uquote="maxlab",url="/forum/viewtopic.php?p=4788253#p4788253"]У каждого чипа есть свой стартап предоставляемый производителем вместе с SDK[/uquote]
Я еще ни одного микроконтроллера не встречал, чтобы производитель предоставлял вменяемый стартап, и уж тем более — вменяемую SDK!
Максимум полезного, что можно оттуда вытянуть — header-файлы с описанием регистров. А под STM8 вообще самому писать пришлось (т.к. под него нет порта gcc, а убогий sdcc не умеет нормально оптимизировать)…

[maxlab]

linux_rulezz, вменяемый/не вменяемый...это уже вопрос религии и личных предпочтений/заблуждений/предрассудков. К теме этого топика не относится

[maxlab]

Не спеша пилим Arduino_Core для ВГ015. Может из этого что то получится

[maxlab]

Всем привет!
Разобрался с системным таймером ядра riscV. Кому интересно, он всегда молотит и тактируется по шине SYSCLK
Используя эту фишку реализовал ардуиновские функции millis(), micros() и добавил расширение seconds(),timestamp(). Ну и delay() и delayMicroseconds() тоже есть.
От таймера можно прерываться. У меня получился минимальный период прерывания в 2мкс. 1 мкс не взлетела, задал вопрос на форуме НИИЭТ. Посмотрим что скажут


Теперь можно заняться pinMode, digitalWrite,digitalRead и attachInterrupt
Как устроена обработка прерываний в riscV мне еще не до конца понятна

[maxlab]

Оказывается, у этого контроллера есть очень полезная фича на GPIO. Входные фильтра...

Прощай борьба с дребезгом контактов

[AlexS4]

оу этож почти точная реализация алгоритма групповой борьбы с дребезгом, который я обычно использую и который содержит менее 2..4 десятков инструкций на разных архитектурах. я его здесь в ветке про дребезг показывал.

забавненько, ~тысяча транзисторов против 20 байт кода.
думаю логическим апофиозом такого подхода будет микрофонный вход, в который "программист" на русском языке будет расскзывать чево бы он хотел от mcu. при первом включении или по фразе "Воронеж! концепция изменилась, теперрь давай ... " .

[maxlab]

[uquote="AlexS4",url="/forum/viewtopic.php?p=4789217#p4789217"]забавненько, ~тысяча транзисторов против 20 байт кода.[/uquote]

ИМХО аппаратные решения всегда лучше софтовой обработки. Помню, древние клавы на триггерах делали пока не появились специализированные контроллеры.
В роботроновских клавах вообще каждая кнопка - это юнит с герконом и бескорпусным триггером, с питанием 5в и выходом

[jcxz]

[uquote="maxlab",url="/forum/viewtopic.php?p=4789230#p4789230"]ИМХО аппаратные решения всегда лучше софтовой обработки. Помню, древние клавы на триггерах делали пока не появились специализированные контроллеры.[/uquote]Далеко не всегда.
Аппаратное решение - это трата транзисторов и места на кристалле. И тратятся они всегда - даже если не нужны. В то время как "софтовая обработка", если не нужна - просто её нет и ничего не тратится.
Так что - можно налепить на кристалле кучу мало кому нужных "аппаратных фич". В ущерб например размеру ОЗУ. Или другим полезным вещам. А можно не тратить транзисторы на эти "аппаратные фичи", потратив транзисторы на доп. ОЗУ.

Тратить транзисторы на такие простые вещи, как подавление дребезга клавы - весьма сомнительное решение. Во-первых: так как оно легко реализуется программно; во-вторых: "подавление дребезга клавы" - очень редко когда нужно в реальных проектах (сужу по своим проектам). А ОЗУ никогда много не бывает.

Добавлено after 6 minutes 22 seconds:
[uquote="maxlab",url="/forum/viewtopic.php?p=4788253#p4788253"]linux_rulezz, Вообще то так не делают
У каждого чипа есть свой стартап предоставляемый производителем вместе с SDK
Не надо ничего добавлять... Бери готовый и используй.[/uquote]Вообще-то не надо говорить за всех. Делали и делаем. Стартап - это такой же код, как и прочий. Почему я не могу его писать сам? Только потому, что кто-то этого не умеет и поэтому запрещает делать другим.

[Zikon]

сейчас фильтры на входах GPIO очень часто есть в китайских Cortex-M
и даже больше там функционал - вот например

Код: Выделить всё

Когда каждый GPIO переведен в режим цифрового ввода, его можно использовать в качестве внешнего источника сигнала прерывания, причем
источник сигнала прерывания может быть настроен на четыре типа: высокий уровень, низкий уровень, нарастающий фронт и спадающий фронт. 
Методы запуска прерывания могут использоваться в комбинации, но имеют один и тот же бит флага прерывания.
После срабатывания прерывания аппаратным обеспечением будет установлен соответствующий бит регистра флага прерывания
GPIOx_ISR, и программа может определить, какой порт сгенерировал прерывание, запросив GPIOx_ISR.
С помощью регистра очистки флага прерывания GPIOx_ICR[y] можно очистить соответствующий бит флага прерывания.
Внутренний цифровой фильтр прерываний может выполнять цифровую фильтрацию входного сигнала на выводе, предоставляя 7 вариантов синхронизации фильтра HCLK/2,HCLK/4,HCLK/8,BTIM1 ovf,RC150K,LSI(32k),RC10K

[maxlab]

jcxz, А Вы всегда разводите флейм вокруг фраз вырванных из контекста?
Пресловутый "дребезг" - это то что сразу пришло в голову. Цифровой фильтр на входе GPIO это борьба за помехоустойчивость в широком смысле. И аппаратное решение всегда лучше софтового.
А как насчет аппаратной обработки квадратурных сигналов с энкодеров? Или наличие на борту аппаратных NCO? Это же все решается элементарно программными средствами, но ,тем не менее,
производители чипов предлагают такие решения. Наверное они о чем то догадываются.
А по поводу стартапов... я Вам не запрещал изобретать свой велосипед

[muravei_]

[uquote="maxlab",url="/forum/viewtopic.php?p=4789390#p4789390"]И аппаратное решение всегда лучше софтового.[/uquote]
Ну не всегда, всегда лучше аппаратно-программное !
Вот как на RP2040 , например. Там некоторые пины могут быть подключены к нано пико "контролерам" с возможным программированием до 32 шагов. Это более универсально.
В примерах есть блинк , где 3 светодиода мигают с разной частотой , во время исполнения пустого цикла .

[uquote="jcxz",url="/forum/viewtopic.php?p=4789339#p4789339"]Аппаратное решение - это трата транзисторов и места на кристалле. И тратятся они всегда - даже если не нужны.[/uquote]
Так может у них этих транзисторов завались , вот и ставят куда ни попадя.
Вот в RP2350 2 двух ядерных запихали , причем, в одно время, может использоваться только один.
Конечно, большое ОЗУ было бы лучше.

[AlexS4]

во скока разгорелось
hw-sw
с - asm
win - linux
vendor-diy


а мне кажется что все хорошо что дает преимущество,
например поднять максимальный ток gpio программно не очень получится. или на порядки повысить скорость семплирования adc тож неочень
а сделать антидребезг и фазировку энкодера и прочие супермедленные задачи - проще софтом и тут я тоже за то чтоб куча транзисторов перекочевала в ram
а производители - им чего, им нужно фишечки продавать, они чоугодно наляпать могут если это дешево в производстве и выглядит дорого.
вот по 6 транзисторов на 1 бит sram они жмут, многоненаляпать а мало - несолидно, а ненужного всякого нагородить - это прогресс

[jcxz]

[uquote="Zikon",url="/forum/viewtopic.php?p=4789377#p4789377"]сейчас фильтры на входах GPIO очень часто есть в китайских Cortex-M
и даже больше там функционал - вот например

Код: Выделить всё

Когда каждый GPIO переведен в режим цифрового ввода
...
Внутренний цифровой фильтр прерываний может выполнять цифровую фильтрацию входного сигнала на выводе, предоставляя 7 вариантов синхронизации фильтра HCLK/2,HCLK/4,HCLK/8,BTIM1 ovf,RC150K,LSI(32k),RC10K

[/uquote]И каким образом это может быть полезно для "подавления дребезга клавы"?

Такие фильтры давным-давно есть в разных МК на Cortex-M. А не только "в китайских". Например - у Infineon-а. Но для "подавления дребезга клавы" они бесполезны.

Добавлено after 4 minutes 55 seconds:
[uquote="maxlab",url="/forum/viewtopic.php?p=4789390#p4789390"]jcxz, А Вы всегда разводите флейм вокруг фраз вырванных из контекста?
Пресловутый "дребезг" - это то что сразу пришло в голову. Цифровой фильтр на входе GPIO это борьба за помехоустойчивость в широком смысле.[/uquote]Вы сморозили глупость. Теперь же пытаетесь переобуться в воздухе и переходите на личности, вместо того чтобы это признать.

Добавлено after 6 minutes 26 seconds:
[uquote="maxlab",url="/forum/viewtopic.php?p=4789390#p4789390"]И аппаратное решение всегда лучше софтового.[/uquote]Ещё раз - НЕТ.
От того, что вы несколько раз повторили эту глупость, она не перестала ею быть.

PS: Отучайтесь от обобщающих понятий "всегда", "все так делают" и т.п. И отучайтесь говорить за всех. Вы не знаете обо всех возможных случаях применения и всех возможных ситуациях. Также на знаете что и как делают все разработчики в мире.
Всё обо всех знают только дураки. Имейте это в виду. Говорите только за себя.

Добавлено after 5 minutes 37 seconds:
[uquote="AlexS4",url="/forum/viewtopic.php?p=4789466#p4789466"]вот по 6 транзисторов на 1 бит sram они жмут, многоненаляпать а мало - несолидно, а ненужного всякого нагородить - это прогресс [/uquote]Однозначно!
Скажем - самое минимальное FIFO в UART или SPI будет в 100500 раз полезнее "антидребезга контактов" доступного даже на всех ногах сразу. Лучше транзисторы потратить на RAM такого FIFO.

[maxlab]

jcxz, Остапа понесло? Топик про конкретный контроллер. Там есть фильтр на GPIO. С его помощью можно повысить помехоустойчивость без написания кода.
"Дребезг" первое что в голову пришло.Аппаратное решение всегда лучше софтового.
Логическая нить понятна? Если это глупость - аргументировано докажите. Не сможете - не засоряйте эфир.
И про "никто так не делает" я не говорил. Я говорил что "Обычно так не делают". За 40 лет работы в отрасли я не видел желающих переписывать, или писать с чистого листа,
bios или startup без особой необходимости. Про "необходимость" этого действия я тоже упоминал. Вы по диагонали читаете?

muravei_, Топик не про RP2040, а про наш православный ВГ015.

[uquote="AlexS4",url="/forum/viewtopic.php?p=4789466#p4789466"]а сделать антидребезг и фазировку энкодера и прочие супермедленные задачи - проще софтом и тут я тоже за то чтоб куча транзисторов перекочевала в ram
а производители - им чего, им нужно фишечки продавать, они чоугодно наляпать могут если это дешево в производстве и выглядит дорого.[/uquote]

А Вы пробовали обработать оптический энкодер с 600 импульсов на оборот который на валу у двигателя и который может раскручиваться до 1500-3000 об.мин.
И как чувствует себя контроллер и софтовая обработка если нет аппаратного декодера на борту но с кучей оперативной памяти?

Еще раз повторю "глупость"... Если на борту контроллера есть аппаратное решение - оно будет лучше чем софтовое.

[electroget]

А RISC-V архитектура это всё ещё актуально?

[maxlab]

[uquote="electroget",url="/forum/viewtopic.php?p=4789705#p4789705"]А RISC-V архитектура это всё ещё актуально?[/uquote]
Говорят что это не только актуально, это будущее

[AlexS4]

RISC-V это единственная достаточно развитая открытая архитектура на сейчас, которая воплощена в чипах-процессоров (не только как конфиг fpga), пока ее не сменит в чипах другая успешная и именно _открытая_ архитектура, она будет актуальна.
все разговоры что например arm-круть а RISC-V-кака - такой же холивар как и прочее вроде cat vs dog
imho.

[electroget]

Дело конечно не в архитектуре, согласен.