adnega

В действительности, сейчас и с G0 на складе не так густо, а F051 есть >3000 штук, просто нам в TQFP32 нужно. Можно было плату под LQFP48 развести, и софт никакой не переделывать (тем более, что G0 по пинам не совместим %)), но мы ребята легкие на подъем - воспользовались ситуацией и перепрыгнули на другой камень - значительно функциональнее.

МК выбирается под задачу, а не наоборот. Никогда раньше бы не подумал, что такое возможно, но сейчас разрабатываю управление автофорсункой чисто на МК (STM32F3). С поцикловым ограничением тока, с форсированием и удерживанием, с накачкой высоковольтной емкости, расширенной диагностикой и т.п. АЦП, компаратор, ЦАП, таймеры - все внутри МК %)) - и замечательно работает. Я за STM не агитирую, просто, на AVR я бы такого не смог сделать.

Там сроки поставки для нас не приемлемые, просто. Может, в других корпусах ситуация лучше - у нас TQFP32 используются.

Критические по быстродействию участки кода загружаются в ОЗУ. Медленное - хранится по внешней flash в малоногом корпусе. Я зам с QSPI не работал, но - это вообще круто, т.к. можно не только ПЗУ внешнего навесить, но и ОЗУ (PSRAM тот же). А если еще и МК аппаратно поддерживает и в общую память ремапит, дык, это просто сказка. Куда хуже у тех же STM32F - внешняя память начинается более-менее со 100/144-ногих "монстров".

Мы экстренно с F051 на G070 перепрыгнули в этом месяце, просто потому, что F051 сейчас нет на складе. МК новый, есть особенности, в документации ошибки, но осваивать нужно :)) Я вот очень рад сложивмися обстоятельствам, иначе так бы и сидели на F051. Макетки с G4 уже полгода на столе пылятся, кста.

Уважаемые коллеги! Давайте будем добрее. Я желаю всем счастья от осознания того, что у вас есть любимое дело, которое приносит достаток. Не нужно ко всему относится негативно, попробуйте понять другое мнение, даже если вы с ним не согласны. Просто приведите свои доводы - мне, например, это очень интересно знать. Я никому не навязываю свою точку зрения, а в споре сначала пытаюсь найти общую систему координат, понятные критерии оценки, и если это получается, то можно вывести оппонента на противоречие. Но в большинстве случаев в этом процессе рождается истина. Я смотрю многие так же себя ведут, но есть люди, у которых только их точка зрения правильная - ничего страшного, я призываю уважать их мнение, но тратить силы на их переубеждение не рекомендую.

Все верно - задачи бывают разные. Например, меня попросили сделать 8 канальный DDS на arduino. Сделал с asm-вставками софтовую реализацию. А был бы 16 канальный шим... Но меня больше привлекает объем ОЗУ Насчет прайса - $4 за плату или за МК? За МК, вроде, $2.5

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

Есть

Насчет числа ядер. Там (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;