[byRAM 24]

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

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

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

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

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

[adnega 10]

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

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

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

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

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

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

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

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

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

[AlexandrY 2]

On 1/20/2021 at 9:49 AM, ViKo said:

 Или есть более современные микроконтроллеры?

[Arlleex 131]

Он, вроде как, 5V МК хочет. Хотя, как я понял, вопрос был решен еще странице на 2 или 3

[ViKo 1]

Да, нужен 5-вольтовый.

[Obam 30]

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

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

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

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

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

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

[MrBearManul 0]

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

 

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

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

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

 

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

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

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

[byRAM 24]

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

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

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

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

 

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

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

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

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

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

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

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

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

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

Изменено 23 января, 2021 пользователем byRAM

[ViKo 1]

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

[dxp 32]

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, у второго из-за неэффективной косвенной адресации, что плохо влияет на работу со стеком).

 

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

[MDD 0]

11 hours ago, byRAM said:

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

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

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

[Plain 166]

20 часов назад, ViKo сказал:

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

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

[MDD 0]

58 minutes ago, Plain said:

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

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

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

Изменено 23 января, 2021 пользователем MDD

[Михась 2]

Так, мысли. Написать на Си, то что надо - задача простая, сконпелять в 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

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

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

[jcxz 182]

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

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

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

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