Jump to content

    
ViKo

А вот какой мелкий контроллер использовать?

Recommended Posts

Только что, adnega сказал:

Т.е. против новой тини10 с одним из вариантов этой системы команд вы ничего не имеете?

А это вы меня с ТС перепутали, ему надо было определиться.

Я лишь только подтвердил правильность выбора PIC-кнопки.

Он его сможет быстрее освоить и запрограммировать за день.

Share this post


Link to post
Share on other sites
1 минуту назад, byRAM сказал:

А это вы меня с ТС перепутали, ему надо было определиться.

В таком случае прошу соряна.

1 минуту назад, byRAM сказал:

Я лишь только подтвердил правильность выбора PIC-кнопки.

Он его сможет быстрее освоить и запрограммировать за день.

Глянул цены на эти pic. Подтверждаю, если нужен минимальный BOM, то все верно с pic.

Но мне (и многим другим) проще поставить M0 или AVR, т.к. с ценой МК вообще никаких проблем нет.

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

Share this post


Link to post
Share on other sites

Способ лучше? - двигайте имена (define), а не числа.


Вот они "золотые слоава" ;-)

Не хочет. А они есть в виде .EQU/define.


На приводившемся скриншоте? Да ну?

Ну да ладно в "игнор" его.


Взаимно: "...сразу - свободен" ;-)

Share this post


Link to post
Share on other sites
11 часов назад, byRAM сказал:

5. AVR имели такой ужасный глюк

Когда это был такой глюк, не напомните? Активно работал с этими микроконтроллерами в 2003 - 2013 годах. Активно участвовал в обсуждениях на различных форумах. А глюка такого не припоминаю.

11 часов назад, byRAM сказал:

Могу только разжевать и в рот положить:

Благодарю, теперь ваша мысль предельна ясна.

11 часов назад, byRAM сказал:

неистовые фанаты STM32 против всех остальных недалёких :biggrin:

Так это политика фирмы ST постаралась. Дешёвые отладочные платы (ну недавно, по крайней мере), "развитые" средства поддержки пользователя: кубы, либы. И не важно, что качества, мягко говоря, не очень высокого. Зато позволяют пользователю максимально быстро въехать в тему. Правда некоторы так и остаются на этих "либах", даже вроде бы въехав. При этом совершенно не читают документацию на сам микроконтроллер или читают её по диагонали. А зачем: в либах куча комментариев, на диске гора примеров) Я на примере одного коллеги своего рассказываю))

 

11 часов назад, byRAM сказал:

Это неопровержимый факт.

Забавненько. Ещё раз повторяю что почти за десятилетнюю карьеру именно с AVR впервые о таком глюке слышу. Не приведёте какие-либо ссылочки на баталии тех времён именно об этом глюке?

10 часов назад, byRAM сказал:

Так о том и речь, что у PIC-контроллера такой блокировки не наблюдалось от слова совсем

Это некорректное сравнение.

 

10 часов назад, byRAM сказал:

И это при том, что выставлялись без галочек.

Гм ещё раз. Тоже не помню. Программировал через STK200 и STK500. Может быть на другом программаторе проявлялось ?

 

8 часов назад, adnega сказал:

везде avr от Atmel`a. А это точно не дураки.

Они же, кстати, стоят (столи?) в некоторой периферии для ПЛК от Siemens. Да и в самих модулях ввода-вывода, если не ошибаюсь, я их встречал.

Share this post


Link to post
Share on other sites
Только что, MrBearManul сказал:

Когда это был такой глюк, не напомните? Активно работал с этими микроконтроллерами в 2003 - 2013 годах. Активно участвовал в обсуждениях на различных форумах. А глюка такого не припоминаю.

Забавненько. Ещё раз повторяю что почти за десятилетнюю карьеру именно с AVR впервые о таком глюке слышу. Не приведёте какие-либо ссылочки на баталии тех времён именно об этом глюке?

Ну вот, например, на этом форуме:

 

Только что, MrBearManul сказал:

Гм ещё раз. Тоже не помню. Программировал через STK200 и STK500. Может быть на другом программаторе проявлялось ?

У меня дракон так глючил. Раза с пятого-шестого понял, как обойти, но деталей уже не помню. Давно это было, году эдак в 2008-2010.

Там весь секрет был в последовательности действий при внутрисхемной прошивке/отладке. Явно не для начинающего.

Только что, MrBearManul сказал:

Это некорректное сравнение.

В данной теме вполне корректное.

ТС не имел дела ни с теми, ни с другими, поэтому напороться на самопроизвольную установку Lock я ему не желаю.

У PIC-контроллеров ничего подобного никогда не было, потому что это исключено в принципе внутрисхемной отладки.

Edited by byRAM

Share this post


Link to post
Share on other sites

Кто не имел дела? Я не имел? Я программировал 8085, 8051, Atmel 8953 (что-то такое, с кучей ошибок в datasheet, с перепиской, навсегда отбившей желание связываться с Atmel), PIC10, PIC12, PIC16, STM32 всяких... "Казань брал. Шпака (AVR...) не брал." 

Share this post


Link to post
Share on other sites
16 часов назад, byRAM сказал:

1. PIC32 имеют только 30 с чем-то команд против 90 с чем-то AVR. Но бОльшая часть команд AVR - это вариации 30 с чем-то PIC-овских. Это + в счёт AVR, так как оптимальнее компиляция при написании на Си.

PIC32 - это MIPS архитектура. 32-разрядные МК у Microchip. Появились лет на 15 позже AVR. Эти семейства МК находятся в разных весовых категориях, и PIC32 уместно сравнивать с Cortex-M. Откройте даташит на MIPS32 и посчитайте количество команд. Их больше сотни. Да, там есть родственные типа варианты условных переходов или AND с регистром или с константой, но тем не менее это разные опкоды - разные инструкции.

16 часов назад, byRAM сказал:

3. В то же время AVR со своей сотней не мог тягаться по математическими способностями MCS51 или Z80.

AVR при той же тактовой был быстрее на порядок (сиречь в 10 раз) чем классический MSC-51. Да, Z80 был на математике побыстрее за счёт 16-разрядного ALU, но в целом тоже уступал. К тому же это микропроцессор, а не микроконтроллер, и сравнивать их бессмысленно - разные ниши.

16 часов назад, byRAM сказал:

5. AVR имели такой ужасный глюк, как самозащёлкивание при внутрисхемном программировании.

Чушь. Уже сказали неоднократно. В прямых руках ничо не защёлкивалось. У AVR в ранних партиях были проблемы с сохранностью EEPROM, когда при выключении процессор уже терял способность работать правильно, но напряжения питания ещё хватало на какие-то действия - чаще всего страдала ячейка EEPROM по адресу 0. Лечилось блокировкой при снижении напряжения питания. Внешней. На эту тему была апнота. Потом и внутри добавили brown-out detector.

 

К AVR на самом деле большинство вопросов архитектурные. Но тут уж ничего не поделать. И для своего времени они были революционными - флешовые с внутрисхемным программированием, хорошее соотношение "инструкция/такт", достаточно эффективно на них ложился С (по утверждениям Atmel это семейство специально проектировалось для эффективной реализации кодогенерации с языка С - согласовывали те или иные моменты с разработчиками компиляторов, правда вот недоработали тут), в отличие от того же PIC16 и MSC-51 (у первого из-за аппаратного стека адресов возврата глубиной 8, у второго из-за неэффективной косвенной адресации, что плохо влияет на работу со стеком).

 

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

Share this post


Link to post
Share on other sites
11 hours ago, byRAM said:

А неистовых зомби-фанатиков AVR продолжает плющить и колбасить :girl_crazy:

Справедливости ради "неистово колбасит" в этой теме почему-то именно Вас. Остальные более-менее беспристрастны и технически корректны.

У меня об AVR остались теплые воспоминания. Устройства моей разработки выпускались тысячными тиражами. Одно выпускается мелкосерийно до сих пор. Никаких перечисленных ужасов с ними не наблюдалось. При этом против ПИКов ничего не имею.

Share this post


Link to post
Share on other sites
20 часов назад, ViKo сказал:

Сделать максимально дёшево и быстро

По-видимому, просто хотят сказать, что на PIC наоборот, дорого и долго — исходя из объёмов сказанного, наверное в разы, а то и на порядки.

Share this post


Link to post
Share on other sites
58 minutes ago, Plain said:

По-видимому, просто хотят сказать, что на PIC наоборот, дорого и долго — исходя из объёмов сказанного, наверное в разы, а то и на порядки.

Просто автор топика поначалу немного "путался в показаниях". То ему надо сильно подешевле, то оказалось что стоимость контроллера в общей смете проекта исчезающе мала. То ему "хотелось изучить что-то новое", то надо сделать очень быстро и на знакомом семействе...

Это породило много ненужных советов.

Edited by MDD

Share this post


Link to post
Share on other sites

Так, мысли. Написать на Си, то что надо - задача простая, сконпелять в XC8 для пика12 и avr tiny, сделать отчет. Я сделал простой тест для XC8 и GCC на tiny13 и был несколько в недоумении от оптимизации:

//xc8 C
volatile uint8_t a, b, c;

int main(void)
{
	a = 1;
	b = 2;
	
	
	
    while(1)
    {
		
		c=a+b;
		c = c*3;
		c++;
		c=c/21;
		
		

    }
}

// результат

Disassembly of section .text:

00000000 <__vectors>:
   0:	0c c0       	rjmp	.+24     	; 0x1a <__ctors_end>
   2:	5e c0       	rjmp	.+188    	; 0xc0 <__bad_interrupt>
   4:	5d c0       	rjmp	.+186    	; 0xc0 <__bad_interrupt>
   6:	5c c0       	rjmp	.+184    	; 0xc0 <__bad_interrupt>
   8:	5b c0       	rjmp	.+182    	; 0xc0 <__bad_interrupt>
   a:	5a c0       	rjmp	.+180    	; 0xc0 <__bad_interrupt>
   c:	59 c0       	rjmp	.+178    	; 0xc0 <__bad_interrupt>
   e:	58 c0       	rjmp	.+176    	; 0xc0 <__bad_interrupt>
  10:	57 c0       	rjmp	.+174    	; 0xc0 <__bad_interrupt>
  12:	56 c0       	rjmp	.+172    	; 0xc0 <__bad_interrupt>

00000014 <.dinit>:
  14:	00 60       	ori	r16, 0x00	; 0
  16:	00 63       	ori	r16, 0x30	; 48
  18:	80 00       	.word	0x0080	; ????

0000001a <__ctors_end>:
  1a:	11 24       	eor	r1, r1
  1c:	1f be       	out	0x3f, r1	; 63
  1e:	cf e9       	ldi	r28, 0x9F	; 159
  20:	cd bf       	out	0x3d, r28	; 61

00000022 <__do_copy_data>:
  22:	e4 e1       	ldi	r30, 0x14	; 20
  24:	f0 e0       	ldi	r31, 0x00	; 0
  26:	40 e0       	ldi	r20, 0x00	; 0
  28:	17 c0       	rjmp	.+46     	; 0x58 <__do_clear_bss+0x8>
  2a:	b5 91       	lpm	r27, Z+
  2c:	a5 91       	lpm	r26, Z+
  2e:	35 91       	lpm	r19, Z+
  30:	25 91       	lpm	r18, Z+
  32:	05 91       	lpm	r16, Z+
  34:	07 fd       	sbrc	r16, 7
  36:	0c c0       	rjmp	.+24     	; 0x50 <__do_clear_bss>
  38:	95 91       	lpm	r25, Z+
  3a:	85 91       	lpm	r24, Z+
  3c:	ef 01       	movw	r28, r30
  3e:	f9 2f       	mov	r31, r25
  40:	e8 2f       	mov	r30, r24
  42:	05 90       	lpm	r0, Z+
  44:	0d 92       	st	X+, r0
  46:	a2 17       	cp	r26, r18
  48:	b3 07       	cpc	r27, r19
  4a:	d9 f7       	brne	.-10     	; 0x42 <__DATA_REGION_LENGTH__+0x2>
  4c:	fe 01       	movw	r30, r28
  4e:	04 c0       	rjmp	.+8      	; 0x58 <__do_clear_bss+0x8>

00000050 <__do_clear_bss>:
  50:	1d 92       	st	X+, r1
  52:	a2 17       	cp	r26, r18
  54:	b3 07       	cpc	r27, r19
  56:	e1 f7       	brne	.-8      	; 0x50 <__do_clear_bss>
  58:	e9 31       	cpi	r30, 0x19	; 25
  5a:	f4 07       	cpc	r31, r20
  5c:	31 f7       	brne	.-52     	; 0x2a <__do_copy_data+0x8>
  5e:	03 d0       	rcall	.+6      	; 0x66 <_etext>
  60:	00 c0       	rjmp	.+0      	; 0x62 <_exit>

00000062 <_exit>:
  62:	f8 94       	cli

00000064 <__stop_program>:
  64:	ff cf       	rjmp	.-2      	; 0x64 <__stop_program>

Disassembly of section .text:

000000c0 <__bad_interrupt>:
  c0:	9f cf       	rjmp	.-194    	; 0x0 <__TEXT_REGION_ORIGIN__>

Disassembly of section .text.startup:

00000066 <main>:

volatile uint8_t a, b, c;

int main(void)
{
	a = 1;
  66:	81 e0       	ldi	r24, 0x01	; 1
  68:	80 93 62 00 	sts	0x0062, r24	; 0x800062 <a>
	b = 2;
  6c:	82 e0       	ldi	r24, 0x02	; 2
  6e:	80 93 60 00 	sts	0x0060, r24	; 0x800060 <__DATA_REGION_ORIGIN__>
    {
		
		c=a+b;
		c = c*3;
		c++;
		c=c/21;
  72:	25 e1       	ldi	r18, 0x15	; 21
	
	
    while(1)
    {
		
		c=a+b;
  74:	90 91 62 00 	lds	r25, 0x0062	; 0x800062 <a>
  78:	80 91 60 00 	lds	r24, 0x0060	; 0x800060 <__DATA_REGION_ORIGIN__>
  7c:	89 0f       	add	r24, r25
  7e:	80 93 61 00 	sts	0x0061, r24	; 0x800061 <c>
		c = c*3;
  82:	80 91 61 00 	lds	r24, 0x0061	; 0x800061 <c>
  86:	98 2f       	mov	r25, r24
  88:	99 0f       	add	r25, r25
  8a:	89 0f       	add	r24, r25
  8c:	80 93 61 00 	sts	0x0061, r24	; 0x800061 <c>
		c++;
  90:	80 91 61 00 	lds	r24, 0x0061	; 0x800061 <c>
  94:	8f 5f       	subi	r24, 0xFF	; 255
  96:	80 93 61 00 	sts	0x0061, r24	; 0x800061 <c>
		c=c/21;
  9a:	80 91 61 00 	lds	r24, 0x0061	; 0x800061 <c>
  9e:	62 2f       	mov	r22, r18
  a0:	03 d0       	rcall	.+6      	; 0xa8 <__udivmodqi4>
  a2:	80 93 61 00 	sts	0x0061, r24	; 0x800061 <c>
  a6:	e6 cf       	rjmp	.-52     	; 0x74 <main+0xe>

Disassembly of section .text.libgcc.div:

000000a8 <__udivmodqi4>:
  a8:	99 1b       	sub	r25, r25
  aa:	79 e0       	ldi	r23, 0x09	; 9
  ac:	04 c0       	rjmp	.+8      	; 0xb6 <__udivmodqi4_ep>

000000ae <__udivmodqi4_loop>:
  ae:	99 1f       	adc	r25, r25
  b0:	96 17       	cp	r25, r22
  b2:	08 f0       	brcs	.+2      	; 0xb6 <__udivmodqi4_ep>
  b4:	96 1b       	sub	r25, r22

000000b6 <__udivmodqi4_ep>:
  b6:	88 1f       	adc	r24, r24
  b8:	7a 95       	dec	r23
  ba:	c9 f7       	brne	.-14     	; 0xae <__udivmodqi4_loop>
  bc:	80 95       	com	r24
  be:	08 95       	ret

Оптимизация максимальная, больше только в ПРО.

Чего он постоянно сует переменные в рам а потом их высовывает оттуда?

Share this post


Link to post
Share on other sites
13 часов назад, adnega сказал:

Я порой подумываю ESP начать задействовать как МК общего назначения (без WiFi). Из-за размера ОЗУ в основном, но останавливает отсутствие защиты прошивки и дыры в документации по некоторым вопросам. Дал бы кто описание CAN в ESP32, я бы тут же начал его применять у себя масштабно.

Получается - документации (официальной) на него нет? В этом случае я бы поостерёгся использовать его для более менее серьёзного проекта.

Ведь кто мешает производителю завтра что-то молча "подправить" в периферии? Он же не гарантировал Вам, что по такому-то адресу будет такой-то регистр в котором будет такой-то бит. И он будет прав. А вы сядете в лужу с уже разработанным девайсом.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.