Мигать светодиодом. ARM или не-ARM?

[oleg110592]

The ADSP-CM408F Mixed-Signal Control Processor integrates dual high precision 16 bit ADCs and an ARM® Cortex-M4TM processor core with floating-point unit operating at 240 MHz core clock frequency and integrating 384KB of SRAM memory, 2M byte of flash memory, and accelerators and peripherals optimized for motor control, photo-voltaic (PV) inverter control and other embedded control applications.

24x24 176 lead LQFP package
http://www.analog.com/en/processors-dsp ... oduct.html
есть и 120 ногий:
http://www.analog.com/en/processors-dsp ... index.html

[slavokhire5]

АЦП там очень злой, как для МК. Но цена наверное....

[oleg110592]

Цена за 1000 вполне гуманная

в розницу, наверное надо на два умножить

[oleg110592]

Freescale тоже радует
FRDM-KL26Z: Freescale Freedom Development Platform for Kinetis KL16 and KL26 MCUs (up to 128 KB Flash) US$12.95

The FRDM-KL26Z is an ultra-low-cost development platform for Kinetis L Series KL16 and KL26 MCUs (up to 128 KB Flash and up to 64-pin packages) built on ARM® Cortex™-M0+ processor. Features include easy access to MCU I/O, battery-ready, low-power operation, a standard-based form factor with expansion board options and a built-in debug interface for flash programming and run-control. The FRDM-KL26Z is supported by a range of Freescale and third-party development software.

*MKL26Z128VLH4 MCU – 48 MHz, 128 KB flash, 16 KB SRAM, USB OTG (FS), 64 LQFP
*Capacitive touch "slider," FXOS8700CQ magnetometer and accelerometer, tri-color LED
*Easy access to MCU I/O
*Sophisticated OpenSDA debug interface
*Mass storage device flash programming interface (default) – no tool installation required to evaluate demo apps
*P&E Multilink interface provides run-control debugging and compatibility with IDE tools
*Open-source data logging application provides an example for customer, partner and enthusiast development on the OpenSDA circuit

из обсуждений:

Сейчас в плане софта лидирует Freescale с их семейством Kinetis.
Буквально на днях они выпустили новую версию SDK для Kinetis куда входят готовые адаптации со всеми драйверами для RTOS: uCOS-II, uCOS-III, FreeRTOS и MQX. Также туда входят все те же LwIP, FatFS.
Продолжается развитие их библитек для управления двигателями, подключения к облакам, медицинские библиотеки, библиотеки для радиопротоколов и ZigBee, визуальные eGUI, интерактивный рекордер-осциллограф FreeMASTER и проч.
Также для Kinetis есть самая работоспособная адаптированная версия ucLinux.

недилер

[shodan]

Решил попробовать откомпилировать предыдущую программу с помощью бесплатного компилятора GCC, а то скажут на ворованном каждый сможет, хотя Keil бесплатно 32K позволяет. Лекарством в предыдущих случаях не пользовался - как говорил известный программист-милиардер 32K "должно быть достаточно для каждого"

Да вот с этим реально проблема, когда проект развитой и функциональный
Program Size: Code=39432 RO-data=796 RW-data=2280 ZI-data=11072 (-O3 -Otime)
GCC кстати тоже неплохо компилит, но это не IDE

Как только появляется USB, куча математики, солидное меню... все алес... появляется жесткая невлезаемость в 32к, хотя на меге8-128 кода было-бы явно меньше.
32-х битность дает о себе знать в полной мере. Поэтому я для себя грубо размер флеша делю на 4+1 при работе с STM32.
Хотя не буду спорить тут еще сильно влияет принципиально другой стиль написания кода "не зажимаясь в размерности переменных". Если на мегах почти всегда выбиралась максимальная размерность 8-16 бит, и последующие пляски с бубном в заталкивании-вытаскивании в них нужным данных, то тут все проще, МК легко щелкает операции с высокой размерностью переменной. Поэтому они используются нативно. Это конечно влияет и на флеш.

К тому-же когда ресурсов тьма, появляется и другая существенная проблема, все больше и больше хочется добавлять всякий "расширенный" функционал, о котором раньше даже не задумывался, ну скажем бутлоадеры и логирование чего-либо неделями и перекачка на ПК.
Вот и получается, что "Medium Density" не такой уж и безграничный как это кажется сначала

[oleg110592]

Поэтому я для себя грубо размер флеша делю на 4+1 при работе с STM32

SPL используете?
Переношу, как раз сейчас, постепенно свои проектики с mega48 и pic16f684 на stm8 и некоторые на stm32f0. Ранее mega48 была выбрана из-за доступности, дешевизны (можно при желании купить по 0.7$) и более менее хорошего функционала. Т.е. 4 Кб флэша мне хватало иногда с трудом. Сейчас наблюдаю объем такой же программы на stm8 (самом дешевом) занимает практически столько же как и на меге. На stm32f0 тот же код занимает меньший размер флэша (SPL не использую), правда провожу небольшую "модернизацию" кода - типа были 8 разрядные переменные, стали 32 разрядные и использую возможности новой периферии - типа АЦП теперь складывает данные по ПДП. Объем флэша у стм8 и стм32, у самых дешевых, больше (в 2 и 4 раза соответственно), поэтому уже делаю модернизацию по расширению функционала.
Сейчас есть одноразовый заказик - управление 2 частотниками по 485 интерфейсу, 4 клапанами, вывод на индикатор 128х64, поддержание 3 температур, связь по 485 с пк и пр.. Купил под это дело отладочную плату NUCLEO-F302R8, там STM32F302R8T6 Cortex M4 64KB Flash. К этой платке закажу на нашем местном заводе плату шилд на которой будет все остальное. Раньше подобное было сделано на меге64, 64К флэша, думаю, мне хватит с избытком.

[Kavka]

Если в проекте есть целочисленная арифметика в размере больше 8 бит, то на АРМах флэша понадобиться меньше из-за поддержки таких операций в ядре. Это и так понятно. В остальном же надо иметь в виду, что на Cortex-ах используется разновидность АРМ-овского набора команд thumb/thumb-2 (правильное произношение близко к [сам]), машинное слово которого размером в 16 бит. Т.е. плотность кода увеличивается за счёт более развитого ядра (по сравнению с АВР). Соответственно, при переносе проектов, можно примерно прикидывать 1-к-1 по флэш-памяти. IMHO.

[HHIMERA]

Как только появляется USB, куча математики, солидное меню... все алес... появляется жесткая невлезаемость в 32к, хотя на меге8-128 кода было-бы явно меньше.
............
............
Вот и получается, что "Medium Density" не такой уж и безграничный как это кажется сначала

Ващета... medium-density... у STM32F103, например... 64 и 128К...
Как-то всё это не вяжется...

[HHIMERA]

Соответственно, при переносе проектов, можно примерно прикидывать 1-к-1 по флэш-памяти. IMHO.

В STM32 нужно шире использовать богатство железа... тогда либо экономится флэш, либо расширяется функционал...

Вот пример... первый попавшийся...
viewtopic.php?f=57&p=2123453#p2123453

Нужно использовать режим изменения состояния ножки OC по совпадению. В прерывании по совпадению загружаете новое значение в OCR, как старое значение + длительность импульса, настраиваете сброс ножки OC по совпадению. В следующем прерывании загружаете новое значение в OCR, как старое значение + (период - длительность импульса), настраиваете установку ножки OC по совпадению. И так далее. Импульсы будут генериться аппаратно без всякого джиттера. Главное, чтобы прерывание успело обработаться от момента текущего совпадения до момента следующего совпадения. Т.е. нельзя делать длительность импульса очень близкой к периоду.

Даже на полукопеечном STM8S003 это делается всё намного проще... без прерываний...
На STM8L15x и подавно... На копечном STM32F030 тем более...
И таких примеров можно привести целую кучу...

[menzoda]

В остальном же надо иметь в виду, что на Cortex-ах используется разновидность АРМ-овского набора команд thumb/thumb-2 (правильное произношение близко к [сам]), машинное слово которого размером в 16 бит.

Немного подправлю. Не машинное слово, а размер инструкций, и не 16 бит, а 16/32 бита. Где-то видел циферки, что размер кода в среднем меньше на (вроде) 40% по сравнению с 32-битным набором инструкций. Но лично мне эти их заморочки с урезанными наборами инструкций кажутся абсолютно неоправданными: пропало полноценное условное выполнение инструкций, ядро усложнилось, а зачем? Память стоит копейки, занимает все меньше места, вон уже SD-карту на 512 Гб выпустили, а они экономят на нескольких килобайтах. Просто смешно.

[shodan]

SPL используете?

Естественно! Это-же неоспоримый плюс при миграции проекта, да и читабельность кода растет в разы. Кстати SPL не так уж и сильно дует код. сам писать начну, тоже буду к структурам и функциям прибегать, посему камнями в SPL кидать не стоит.

Как-то всё это не вяжется...

Химерыч, да никто и не вязал, не надо искать слона там где его нет.

[menzoda]

Естественно! Это-же неоспоримый плюс при миграции проекта, да и читабельность кода растет в разы.

Чую запахло холиваром.

[oleg110592]

Еще раз попробовал куб для F0 - задействовал периферию, только инициализация:

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

static void MX_GPIO_Init(void);
static void MX_ADC_Init(void);
static void MX_CRC_Init(void);
static void MX_RTC_Init(void);
static void MX_SPI1_Init(void);
static void MX_TIM1_Init(void);
static void MX_TIM3_Init(void);
static void MX_TIM14_Init(void);
static void MX_USART1_UART_Init(void);  

еще ничего не писал, а уже набежало:
Program Size: Code=6512 RO-data=256 RW-data=24 ZI-data=1552
для маленьких и дешевеньких стмчиков расточительно считаю

[shodan]

Кстати некоторые данные:
Дозик на меге8 весит 54 кб сырцов, компилился в 8 кб флеша, 2 кб еепрома и кушал 720 байт оперативки.
Дозик на STM32 весит 183 кб сырцов(без учета SPL, только самописный код), компилится в 38 кб флеша, ~100 байт еепрома и кушает 13 кб оперативки.
Причем в первом случае еепром используется как флеш, т.е. по сути 10 кб флеша получается.

Итог то один и тот-же, и тут и там на выходе дозиметр, но на STM32 он получается в 4 раза больше, с немного расширенным фунуционалом, вот такая вот статистика

[HHIMERA]

Где-то видел циферки, что размер кода в среднем меньше на (вроде) 40% по сравнению с 32-битным набором инструкций.

Там не всё так однозначно... Но доступ к байту, полуслову и слову... это сила...

[HHIMERA]

посему камнями в SPL кидать не стоит.

Точно... оно даже камней не стоит...
При юзании SPL вы теряете связь с железом... с богатым железом... что является огромным минусом...

Еще раз попробовал куб для F0 - задействовал периферию, только инициализация:
...............
для маленьких и дешевеньких стмчиков расточительно считаю

100% !!!
Тем более что... общаясь плотно с железом... узнаёшь много интересного и полезного...

[shodan]

Бросай курить, вставай на лыжи, и кодом будешь не обижен.

Какую еще связь я теряю? если чего-то там нет меня интересующего я всегда могу это дописать.
Если ты от использования SPL потерял "связь", это печально но виной тому не она.

[HHIMERA]

Если ты от использования SPL потерял "связь", это печально но виной тому не она.

Угу... просто поверю на слово... можно???
SPL вообще не использую... ну почти... только когда сильно лень вникать... и ничего смертельно не напрягает...

[shodan]

еще ничего не писал, а уже набежало

Кстати после установки в Keil опции "One FLF Section per function" код весьма хорошо жмется, но это накладывает ряд ограничений
на неявный вызов функций, и возможно на что-то еще, хотя я заметил только багу с неявным переходом в функции.
Как результат: "Program Size: Code=28480 RO-data=796 RW-data=2244 ZI-data=11076"
Но это затрагивает только очень специфичные алгоритмы, и в принципе как я вижу решается.

Как глосит апнот кейла "The One ELF Section per Function option tells the compiler to put all functions into their own individual ELF
sections. This allows the linker to remove unused functions."

Так что думаю опции компиляции "-O3 -Osize --split_sections" спасут от разрастания флеша на твоем примере

[HHIMERA]

опции компиляции "-O3

А всегда ли есть в этом смысл??? -О2 не хватает???
Может если разобраться с ключами и кодом... то не всё так окажется скверно???