adnega

ТС уже все решил - мы тут для себя варианты выбираем ;)) "Мелкий контроллер" - каждый по-своему понимает. А обсуждается сейчас очень интересный вариант.

Есть

Насчет числа ядер. Там (RP2040) в PIO какой-то микрокод для ногодрыга что ли?

Доки есть на сайте

Тоже хотел сюда его вписать. Есть доки какие-нить? Где купить?

Вроде как, полноценный и даже какой-то стандартный. Может, какие правовые моменты не совсем корректные?

В чем различия: 0) vVal << V_VAL_POS 1) 0<<16 2) 0x00<<16 3) 0<<0x10 4)0x00<<0x10 ? По-моему, никаких различий нет. Но самый читабельный вариант 0. Причем тут система счисления и сдвиги?

Это я попросил вас привести пример asm-проекта. Ваш стиль программирования далек от идеала - одни "магические" числа. В крайнем случае хоть бы макросами обернули безобразие со сдвигами. Вместо вашего: LDR R1, =(ItemMenu_ManualMode3-ItemMenu_TestMode1)<<24|0x00<<16|0x00<<8|ItemMenu_ManualMode3; и четырех строк комментариев с рисунками из псевдографики написать через константы: LDR R1, =(ItemMenu_ManualMode3-ItemMenu_TestMode1)<<V_MENU_BUTTON_STEP|0<<V_MENU_ROLL_RIGHT_STEP|0<<V_MENU_ROLL_LEFT_STEP|ItemMenu_ManualMode3<<V_MENU_ITEM; в стиле самодокументирующегося кода. Или через макрос: LDR R1, =PARAM_MENU_STEP(ItemMenu_ManualMode3-ItemMenu_TestMode1, 0, 0, ItemMenu_ManualMode3); Или через макрос без лишних параметров: LDR R1, =PARAM_MENU(ItemMenu_ManualMode3-ItemMenu_TestMode1, ItemMenu_ManualMode3); И зачем писать 0x00, когда проще писать просто 0? Вот пример: .equ UP = PC1 .equ DOWN = PC3 .equ LEFT = PC2 .equ RIGHT = PC0 .equ BTN = PC5 .equ M_STOP = (0 << UP) | (0 << DOWN) | (0 << LEFT) | (0 << RIGHT) | (1 << BTN) .equ M_UP = (1 << UP) | (0 << DOWN) | (0 << LEFT) | (0 << RIGHT) | (1 << BTN) .equ M_DOWN = (0 << UP) | (1 << DOWN) | (0 << LEFT) | (0 << RIGHT) | (1 << BTN) .equ M_LEFT = (0 << UP) | (0 << DOWN) | (1 << LEFT) | (0 << RIGHT) | (1 << BTN) .equ M_RIGHT = (0 << UP) | (0 << DOWN) | (0 << LEFT) | (1 << RIGHT) | (1 << BTN) ldi temp, (1 << UP) | (1 << DOWN) | (1 << LEFT) | (1 << RIGHT) | (0 << BTN) out DDRC, temp ldi temp, M_STOP out PORTC, temp Документация есть, но в ней CAN полноценно не отражен.

В таком случае прошу соряна. Глянул цены на эти pic. Подтверждаю, если нужен минимальный BOM, то все верно с pic. Но мне (и многим другим) проще поставить M0 или AVR, т.к. с ценой МК вообще никаких проблем нет. Я порой подумываю ESP начать задействовать как МК общего назначения (без WiFi). Из-за размера ОЗУ в основном, но останавливает отсутствие защиты прошивки и дыры в документации по некоторым вопросам. Дал бы кто описание CAN в ESP32, я бы тут же начал его применять у себя масштабно. Есть, конечно, реверс-проекты на эту тему, но хочется более-менее официально.

Это вы про студентов? Если бы их архитектуру взяли в Intel, Microchip, ST, NXP или где-то еще, я бы приписывал к "avr" название этой фирмы. До сегодняшнего дня, я, честно, про этих студентов не слышал и был уверен, что это только Atmel. Ок. В дальнейшем буду использовать только "avr". Использовать в значении "печатать на форуме" Т.е. против новой тини10 с одним из вариантов этой системы команд вы ничего не имеете?

Решили: Atmel умер; AVR жив и жить будет. Все верно?

Хорошо. Прошу везде, где я упоминал и где буду упоминать "avr от Atmel" считать это "архитектура AVR, которую разработала Atmel". Кто именно производит МК в моих постах значения не имеет, либо я явно об этом буду оговаривать. Так понятно? Смотрите: можно же сказать МК от Microchip. Но сейчас это и avr, и pic всех семейств. Я добавляю Atmel, чтобы путаницы было меньше, но я не ожидал, что кто-то начнет к буквам придираться, а не смысл утверждений попытается понять. Да, архитектура AVR жива и умирать не планирует, хотя Atmel уже давно нет. Я готов обсудить цитату с сайта Microchip если в ней вы увидели хотя бы намек на смерть AVR.

Я не понимаю при чем тут Atmel, когда речь веду про архитектуру avr? Xmega и AVR32 я не использовал и ничего про них сказать не могу. Всю работу сейчас делаю исключительно на Cortex-M (всякие ESP32, ESP8266 и EAT от SIMCOM`а тоже есть, но ничтожно малы в сравнении с Cortex-M). Для мигалок светодиодом некоторые конторы используют avr (список привел, ни одного pic не видел, но допускаю, что может быть в домофоне). Я для мигалки сведиодом раньше использовал тини13, сейчас бы использовал тини10 в SOT23. И не забываем про ардуинщиков, где в основном avr, немного ESP, Cortex-M... а где же pic? Вот-ведь ирония - сделали программатор для pic на avr ;)

Неужели вы всерьез думаете, что "дураки" - это хоть сколько значимое в экономическом плане влияние?! У меня в плате управления газовым котлом (BAXI Main Four), стабилизаторе напряжения для котла (ST-555), в холодильнике (Samsung), увлажнителе (Boneco), даже в каком-то ноутбуке видел - везде avr от Atmel`a. А это точно не дураки. Какая продукция ликвидирована? AVR производятся, и никаких планов снимать с производства их нет. У ATmel были проблемы с поставками когда-то, надеюсь, Microchip такого не допустят, а это еще добавит очков в пользу avr.

Некоторые аппаратные вещи на логике/рассыпухе/реле/CPLD решаются кратно легче, чем на МК. Особенно там, где реакция на событие должна быть быстрой. Кста, я один раз разрабатывал сложную схему на реле для автомобильного КПП - спустя какое-то время в одном разговоре услышал эмоциональное, мол, "там ничего не работает". А как же "ручной" режим (тот что на реле)? Типа, только он и работает. От avr у меня только самые положительные ощущения. Начинал с 48-ядра, потом перебрался на 51-ядро (день и ночь). После появились avr. После чуть-чуть ARM7, но не понравилось и быстро убежал на Cortex-M. Совсем чуть-чуть программировал 1878ВЕ1 (ядро Тесей), а у pic`ов только исходники читал. Из всего что пробовал только к avr хорошее отношение (к Z80 тоже теплое отношение, но тогда это был не МК). Всякие там Cortex`ы, ESP - уже какая-то рутина, источник дохода... Насчет кривых ручек. Читаем ES, а этот документ должен быть у любого порядочного МК. Если есть бага - обходим, если нет - значит сам дурак и/или руки кривые. Катить бочку наМК или производителя из-за этого - как-то не по-взрослому.

Даже так... Тогда почему мы CPLD исключили из внимания?

Дык, 32-битный, типа, Cortex-M, где есть ART-ускоритель, отдельные шины для данных и кода, DMA и т.п. Питание должно быть комплексным: настаивать, что только яблоки можно употреблять в пищу - не разумно, когда есть наваристый борщик со сметаной и двумя кусочками черного хлеба (ЯВУ). Уже понятно, что многие любят яблочками побаловаться, но не на постоянку же ;)

Тот код, который вы привели во многом уступает аналогичному Си-коду. Инициализацию на Си гораздо проще описать. Я понимаю asm, например, для КИХ-фильтра применить. Тут реально можно выиграть в сравнении с Си: //--------------------------------------------- // fpu_iir //--------------------------------------------- .thumb .thumb_func .global fpu_iir .type fpu_iir, %function fpu_iir: .cfi_startproc cbnz r1, fpu_iir_load bx lr fpu_iir_load: push {r0-r4, lr} VPUSH {s0-s7} // load f VLDR.F32 s1, [r3, #0] // G VLDR.F32 s2, [r3, #4] // a1 VLDR.F32 s3, [r3, #8] // a2 VLDR.F32 s4, [r3, #12] // b VLDR.F32 s5, [r3, #16] // tn-1 VLDR.F32 s6, [r3, #20] // tn-2 fpu_iir_loop: // load ldr r4, [r0], #4 // s0 <- x VMOV.F32 s0, r4 // calc tn VMUL.F32 s7, s1, s0 // G * x VFMS.F32 s7, s2, s5 // -a1 * tn-1 VFMS.F32 s7, s3, s6 // -a2 * tn-2 // calc y VADD.F32 s0, s7, s6 // tn-2 VFMA.F32 s0, s4, s5 // b * tn-1 // save t VMOV.F32 s6, s5 // tn-2 VMOV.F32 s5, s7 // tn-1 // y -> r0 VMOV.F32 r4, s0 // store str r4, [r2], #4 subs r1, #1 bne fpu_iir_loop VSTR.F32 s5, [r3, #16] // tn-1 VSTR.F32 s6, [r3, #20] // tn-2 VPOP {s0-s7} pop {r0-r4, pc} .size fpu_iir, .-fpu_iir .cfi_endproc void fpu_iir(float *x, int size, float *y, sIIR *f); typedef struct sIIR { float g; float a1; float a2; float b; float t1; float t2; } sIIR;

А топовый Си-проект у меня сейчас более 32 тыс. строк кода, что на выходе дает 16кБ (загрузчик) + 122 кБ (приложение) бинарных данных, что примерно соотносится "1 Си-строка в 2 инструкции". Это примерно в 20 раз по строчкам жирнее самого топового моего asm-проекта, а по трудозатратам раз в 20 с меньшей трудоемкостью.

Хорошо. Но 4 кБ это порядка 2000 инструкций всего. Вряд ли там какой-то сложный функционал. У меня топовые проекты порядка 100 кБ - на asm я бы такое не осилил.

Ну, если вы такие богатые... ;)) то я советую современные AVR (ATtiny10-TSHR) или "монстров", типа, mega4808 - там даже программируемая логика есть!

Насчет asm vs C: у мну тьма коммерческих, сложных (от 10 тыс. строк кода) проектов на Си (местами с asm-вставками). Покажите мне проекты на asm... Я сам давным давно (с начала AVR до примерно 2010) много чего делал на avr на asm, но с Си разработкой ни в какое сравнение не идет. Самый сложный проект на avr-asm у меня был порядка 2500 строк.

Да, на asm разницы нет, я именно об этом ранее и говорил. Но на Си в avr, вроде, константы во flash нужно по особому обрамлять, держать две копии функций для работы со строками из ОЗУ и flash и т.п. В Cortex-M в этом плане более Си-оринтировано. Да, те же обработчики прерываний - обычные функции, а не специально оформленные конструкции. Итого, если ТС топит за Си, то Cortex-M не разочарует.

Допустим. Но использовать линейное адресное пространство на Си в Cortex-M намного приятнее AVR-овской модели памяти ;)

Я тоже когда с AVR на STM32 перебрался негодовал по этому поводу. А потом понял, что сам дурак, начал делать нормальную обвязку, и ни одного мертвого STM32 уже не видел. Кста, условия для STM32 у меня далеко не тепличные, изделия выпускаются более сотни штук ежемесячно. Две недели назад, правда, дочка мощной статикой убила сенсорный выключатель, но там полетел только один канал, там нет никакой защитной обвязки, контроллер проработал лет 5 при ежедневной эксплуатации (выключатель света в комнате в квартире). Итого, если есть возможность делать правильно, то STM довольно хорошее решение. А из Тини11 (когда они только на свет появились) у меня даже дым вышел какой-то, но он до сих пор работает