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

[Мурик]

раз функция, два функция и все.

А если прерывание произойдет?

[oleg110592]

Нету там прерываний, из периферии таймер и порт:

Идеальный микроконтроллер для любителя трудностей

[pvit]

PIC-и нынче вообще на любителя, т.к. си-пригодные альтернативы достаточно подешевели и стабилизировались.

[oleg110592]

Опять китайское развитие
The ARM chip that wont cost an arm and a leg

SWM050 highlights:
– operates from 3.3v or 5V
– max 36Mhz using internal clock
– ARM Cortex-M0
– 8KB FLASH, 1KB SRAM
– 6/10 GPIO
– 2 32bit timers with PWM
– Watchdog timer
– (almost hobbyist) friendly tsop8 or tsop16 package

"It has not got very impressive peripherals, but when it comes to its price it is a killer".
"У этого нет очень впечатляющих периферийных устройств, но когда дело доходит до его цены, это убийца". (переводчик)
Есть плагин для JLINK JTAG Segger. Любитель сделал отладочную плату
Исходный код мигалки, файлы pcb и фото находятся на GitHub, ссылки тут:
http://smdprutser.nl/blog/the-arm-chip- ... and-a-leg/
код мигалки:

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

#include <SWM500.h>

void main(void)
{
	PORT->PORTA_SEL.PA05=0;			// normal operation
	PORT->PORTA_PULLU.PA05=0;		// no pullup
	PORT->PORTA_INDIS.PA05=1;		// port enabled(?)
	GPIOA->DIR.DIR_5=1;			// output
	while(1)
	{
		GPIOA->DAT.DAT_5=1;
		GPIOA->DAT.DAT_5=0;
	}
} 

[ARV]

в коде мигалки нет задержки - на 36 мегагерцах быстровато мигать будет

Добавлено after 12 minutes 11 seconds:
а вот просветите меня, темного (и ленивого): вот, предположим, команда сложения - её опкод же в ARM тоже 32-битный? то есть в плане ассемблерного кода имеем удвоение объема (по сравнению с 16-битными опкодами тех же AVR) при идентичном алгоритме? или все не так?

[VladislavS]

Thumb-2.

[Sergi]

Посмотрел в дебагере например ADDS r0,r0,r2 2 байта

[dosikus]

ARV, специально для любознательных, без оптимизаций ...

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

;;;45     			if (TimeOut) {
000024  481f              LDR      r0,|L3.164|
000026  6800              LDR      r0,[r0,#0]  ; TimeOut
000028  2800              CMP      r0,#0
00002a  d004              BEQ      |L3.54|
;;;46     				TimeOut--;
00002c  481d              LDR      r0,|L3.164|
00002e  6800              LDR      r0,[r0,#0]  ; TimeOut
000030  1e40              SUBS     r0,r0,#1
000032  491c              LDR      r1,|L3.164|
000034  6008              STR      r0,[r1,#0]  ; TimeOut
                  |L3.54|
;;;47     			}
;;;48     			
;;;49     			if ( cntdiskio++ >= 10 ) {
000036  481c              LDR      r0,|L3.168|
000038  7801              LDRB     r1,[r0,#0]  ; cntdiskio
00003a  7800              LDRB     r0,[r0,#0]  ; cntdiskio
00003c  1c40              ADDS     r0,r0,#1
00003e  4a1a              LDR      r2,|L3.168|
000040  7010              STRB     r0,[r2,#0]
000042  290a              CMP      r1,#0xa
000044  db29              BLT      |L3.154|
;;;50     		   cntdiskio = 0;
000046  2000              MOVS     r0,#0
000048  4611              MOV      r1,r2
00004a  7008              STRB     r0,[r1,#0]
;;;51     	
;;;52     			if(TIM2->CNT>900)TIM2->CNT=0;
00004c  2001              MOVS     r0,#1
00004e  0780              LSLS     r0,r0,#30
000050  6a40              LDR      r0,[r0,#0x24]
000052  21e1              MOVS     r1,#0xe1
000054  0089              LSLS     r1,r1,#2
000056  4288              CMP      r0,r1
000058  d902              BLS      |L3.96|
00005a  2000              MOVS     r0,#0
00005c  0709              LSLS     r1,r1,#28
00005e  6248              STR      r0,[r1,#0x24]

[jcxz]

[uquote="dosikus",url="/forum/viewtopic.php?p=3466821#p3466821"]ARV, специально для любознательных, без оптимизаций ...[/uquote]
Понятно что без оптимизаций. Ведь с оптимизацией вероятность появления 4-байтовых команд сильно возрастает.
По крайней мере на M3/M4, за M0 не скажу.

[VladislavS]

У меня есть один проект, который перетащили с ATMega128 на STM32F103. Немного, правда, добавив в функционале, иначе перетаскивать было не за чем. Но совсем немного, я бы оценил добавку в 10-15%. Привожу расход памяти с обоих проектов. Компилятор в обоих случаях IAR.

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

 4 766 bytes of CODE  memory (+             8 range fill )
   286 bytes of DATA  memory (+ 41 absolute )
    13 bytes of XDATA memory

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

  7 732 bytes of readonly  code memory
    304 bytes of readonly  data memory
  1 456 bytes of readwrite data memory

[ARV]

благодарю за инфу. 16-битные команды - это теперь я понял.

Немного, правда, добавив в функционале

даже любопытно, какое-такое "немного" дало увеличение в 10 раз потребности в RAM? или я чего-то не понял?

[jcxz]

[uquote="ARV",url="/forum/viewtopic.php?p=3466804#p3466804"]в плане ассемблерного кода имеем удвоение объема (по сравнению с 16-битными опкодами тех же AVR) при идентичном алгоритме? или все не так?[/uquote]
Попробуйте скомпилить:

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

u32 Mul1(u32 x0, u32 x1) 
{ 
  u64 q = x0 * (u64)x1;
  return (u32)(q >> 32) + ((u32)q >> 31);  
}

на любимом AVR и сравнить с объёмом кода на Cortex-M "при идентичном алгоритме"...

[dosikus]

[uquote="jcxz",url="/forum/viewtopic.php?p=3466826#p3466826"]Понятно что без оптимизаций. Ведь с оптимизацией вероятность появления 4-байтовых команд сильно возрастает. [/uquote]

Ну зачем так сразу, у ARV снова батхерт случится. То что код уменьшится и скорость возрастет ему по барабану...

[VladislavS]

[uquote="ARV",url="/forum/viewtopic.php?p=3466831#p3466831"]даже любопытно, какое-такое "немного" дало увеличение в 10 раз потребности в RAM? или я чего-то не понял?[/uquote]Исключительно настройки стека и кучи. В версии для ARM стек 1024 и куча 256 установлены. В AVR стек 160 без кучи.

[ARV]

Попробуйте скомпилить

я заметил, что за деревьями никто не желает видеть леса.
разумеется, речь шла только об опкодах "идентичных" команд. в AVR нет команд для работы с 32-битными операндами, и сравнивать корректно только команды байтной обработки данных, т.е. команд ассемблера, выполняющих идентичные алгоритмы вычислений. без примеси ЯВУ.

То что код уменьшится и скорость возрастет ему по барабану

насколько я понял, код останется тем же по размеру, т.к. у AVR и ARM команды 16-битные. скорость возрастет только благодаря более высокой тактовой частоте - так? а работа с байтами может оказаться даже медленнее, т.к. байт - не нативный формат данных для ARM. все преимущества проявляются только при 32-битных данных, не так ли?

интересно, делал ли кто-нибудь сравнение производительности ARM с теми же AVR при одинаковой частоте и работе с однобайтными данными? наверное, выигрыш только при умножении/делении...

[VladislavS]

[uquote="ARV",url="/forum/viewtopic.php?p=3466882#p3466882"]все преимущества проявляются только при 32-битных данных, не так ли?[/uquote]Не так. Все шины шире плюс кэши и другие архитектурные плюшки.

[Reflector]

[uquote="ARV",url="/forum/viewtopic.php?p=3466882#p3466882"]интересно, делал ли кто-нибудь сравнение производительности ARM с теми же AVR при одинаковой частоте и работе с однобайтными данными? наверное, выигрыш только при умножении/делении...[/uquote]
Есть у ARM всякие вставки битовых полей за такт или сдвиги за такт, хоть на 31 бит. И почему сравнивать нужно на однобайтных данных, AVR позиционируется как гибридный 8/16-bit AVR CPU, both 8- and 16-bit arithmetic is supported. Правда это уже про хмеги маркетологи стали так загонять, но набор инструкций там старый, так что долой устаревшие стереотипы, раскроем истинную мощь AVR сравнивая на 16-ти битных данных

[VladislavS]

И почему частоту надо ограничивать? Если AVR не может больше 16-20 МГц работать, то это его проблемы. Таких искусственных ограничений можно напридумывать... Давай, например, на кварце 8 МГц сравним?

[ARV]

[uquote="VladislavS",url="/forum/viewtopic.php?p=3466901#p3466901"][uquote="ARV",url="/forum/viewtopic.php?p=3466882#p3466882"]все преимущества проявляются только при 32-битных данных, не так ли?[/uquote]Не так. Все шины шире плюс кэши и другие архитектурные плюшки.[/uquote]
если я буду делать uint8_t + uint8_t на ARM - это будет быстрее, чем на AVR при той же частоте? поможет кэш и прочие плюшки?
пересылка uint8_t из регистра в память и обратно быстрее будет?

раскроем истинную мощь AVR сравнивая на 16-ти битных данных

сравнение ради сравнения? или чтобы доказать, что слон сильнее моськи? не смешно самому-то?

например, обработка RGB-цвета делается по цветовым составляющим, т.е. побайтно. насколько я понимаю, невыровненные данные в ОЗУ имеют наихудшее время доступа в ARM, так? вы поправляйте меня, не стесняйтесь, я в ARMах не спец, могу нести ересь... тут будет выигрыш от 32-битных операций?

[Reflector]

[uquote="ARV",url="/forum/viewtopic.php?p=3466936#p3466936"]сравнение ради сравнения? или чтобы доказать, что слон сильнее моськи? не смешно самому-то?[/uquote]
Я не знаю, сам же первым предложил сравнивать AVR с донельзя урезанным ARM, хотя практической пользы от этого никакой нет. Для чего? Чтобы доказать, что моська не слабее слона хотя бы в таком случае?

например, обработка RGB-цвета делается по цветовым составляющим, т.е. побайтно. насколько я понимаю, невыровненные данные в ОЗУ имеют наихудшее время доступа в ARM, так? вы поправляйте меня, не стесняйтесь, я в ARMах не спец, могу нести ересь... тут будет выигрыш от 32-битных операций?

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