Первое знакомство. Первые грабли. Светофор на Attiny13A

[Alkul]

AndTer писал(а):

Не совсем понятен смысл использования ассемблера? АВР заточены под С.

Интересное утверждение. А чем AVR принципиально отличаются от, скажем, х51 ?
Там гарвардская архитектура и тут гарвардская архитектура, там АЛУ и тут АЛУ, там блок РОН и тут блок РОН, там флеш-память программ и ОЗУ и тут флеш-память программ и ОЗУ. Система команд отличается, и что?
Почему AVR заточены под С, а х51 - нет? А чем AVR и х51 вместе взятые принципиально отличаются от старших моделей PIC?
Вас послушать, так все микроконтроллеры под С заточены.
Я рискну утверждать следующее:
1. Код, написанный хорошим программистом на ассемблере, всегда будет меньше по объему, чем код, написанный на С для решения той же задачи.
2. Код, написанный хорошим программистом на ассемблере, почти всегда будет иметь бОльшее быстродействие, чем код, написанный на С для решения той же задачи

Естественно, в случае с С имею в виду "чистый" С, без ассемблерных вставок, ибо это "читерство"

[АлександрЛ]

Alkul писал(а):

1. Код, написанный хорошим программистом на ассемблере, всегда будет меньше по объему, чем код, написанный на С для решения той же задачи.
2. Код, написанный хорошим программистом на ассемблере, почти всегда будет иметь бОльшее быстродействие, чем код, написанный на С для решения той же задачи

Естественно, в случае с С имею в виду "чистый" С, без ассемблерных вставок, ибо это "читерство"

Человеку нужна МИГАЛКА ТРЕМЯ СВЕТОДИОДАМИ, которая, даже будучи написана на бейсике с использованием простейшего цикла, в этом МК займёт мизер памяти, а вы пустились рассуждать о "высоких материях"..

зы.. Не учите меня жить, лучше помогите материально..

[Аlex]

чем код, написанный на С для решения той же задачи

Кем ? Вы не написали кем
Отсюда можно утверждать :
Код, написанный на С профессионалом, будет гораздо эффективней кода, написанного на АСМ

[AndTer]

Alkul писал(а):

Я рискну утверждать следующее:
1. Код ... всегда будет меньше по объему...
2. Код ... будет иметь бОльшее быстродействие...

1. И куда же девать столько свободной памяти? Отсыпать в коробку, а потом поменять на талоны на молоко?
2. А что, для того чтобы мигать 3 светодиодами без ассемблера не обойтись?
Времена когда нужно было экономить каждый байт и каждый цикл МК давно прошли.
Сейчас проще взять более производительный МК с достаточным объёмом памяти и богатой периферией.
Нет дефицита, да и цены более чем доступные. Вплоть до того, что можно купить многократно более производительный МК с большим объёмом памяти и богатой периферией дешевле чем старый авр или пик.

И надо понимать, что самый ценный ресурс это время. Оно как ресурс невосполнимо и ограничено.
Я у ТС спрашивал, какая у него цель. Ассемблер ради ассемблера или ради светофора.
Если ради ассемблера, то можно смело ковырять до нового 2025 года. А если ради светофора, то взять и написать на С за часик и порадовать ребёнка.

Что касаемо понимания работы мк... вот мы раньше читали книги, изучали простую логику и регистры, это было действительно надо, потому что ассемблер... Но если писать на С, то такая глубина не нужна и общие принципы можно изучить по блочным схемам из даташитов на МК. В общем, каждому своё.

[Alkul]

АлександрЛ писал(а):

Человеку нужна МИГАЛКА ТРЕМЯ СВЕТОДИОДАМИ

Вы внимательно прочли фразу, которую я процитировал, и на которую я отвечал?

Не совсем понятен смысл использования ассемблера? АВР заточены под С.

Если бы автор написал

Не совсем понятен смысл использования ассемблера в данном проекте

не было бы вопросов.
Я отвечал на очень спорное высказывание, что "AVR заточены под С"

АлександрЛ писал(а):

лучше помогите материально

Я по субботам не подаю. И по понедельникам тоже.

Добавлено after 9 minutes 43 seconds:

Аlex писал(а):

чем код, написанный на С для решения той же задачи

Кем ? Вы не написали кем

Хоть кем. Код, написанный профессионалом на ассемблере, будет эффективнее, чем код, написанный профессионалом на С. Хотя бы потому, что машинный код во втором случае создается не человеком-профессионалом, а компилятором.
Естественно, что это справедливо и для случая, если код на ассемблере пишет профессионал, а код на С - новичок.
А вот если на ассемблере пишет новичок, тогда конечно, профессионал на С напишет лучше, чем новичок на асме.

[ARV]

прошу прощения за оффтоп, но налицо противоречие

И куда же девать столько свободной памяти? Отсыпать в коробку, а потом поменять на талоны на молоко?

Сейчас проще взять более производительный МК с достаточным объёмом памяти

невыносимо достали рассуждения про то, что "сейчас все дешево и сердито"

[AndTer]

Здесь нет противоречия.
В первом случае речь идёт об экономии ресурсов в процессе написания кода, которое выливается в переходе на ассемблер и соответствующих временных затратах. ДА и о практической невозможности решать сложные задачи.
Во втором случае речь идёт о избыточных ресурсах которые не стоят никакого времени, да ещё и за меньшие деньги.
А то что дёшево и сердито... то это факт, а не рассуждения.

Ну что у вас с логикой то?
Один прицепился к спорному утверждению(рассматривать надо в комплексе, ресурсов мк и компиляторов, одно дело z80 с внешней паматью где каждый байт на счету, другое дело 8 ногая тинька с 8кБ флеша, я не представляю какую задачу надо решать на ней чтобы забить 8кБ флеша работая с ассемблером). При этом игнорирует все аргументы против его доводов. Другой никак не может понять разницу между экономией ресурсов и их избыточностью.

[Alkul]

AndTer писал(а):

1. И куда же девать столько свободной памяти? Отсыпать в коробку, а потом поменять на талоны на молоко?

"Столько памяти" понадобится, когда понадобится реализовать проект посложнее, чем мигание тремя светодиодами.

AndTer писал(а):

2. А что, для того чтобы мигать 3 светодиодами без ассемблера не обойтись?

Осваивать язык надо от простого к сложному. Это раз. Осваивать надо, решая полезную задачу, а не абстрактно (это продуктивнее). Это два.

AndTer писал(а):

Сейчас проще взять более производительный МК с достаточным объёмом памяти и богатой периферией.

Как все просто. То есть Вы, для задачи, которую можно решить на 8-ми разрядном контроллере средней руки, предлагаете взять сразу 32-х разрядный с высоким быстродействием.
Ну, чтобы голову над эффективными алгоритмами и правильным программированием не ломать. Понятно. Пусть вместо мозгов работают мегагерцы и мегабайты. Но что будет, когда встанет задача, решение которой на 32-х разрядном контроллере потребует привлечения тех самых эффективных алгоритмов и правильного программирования? В предыдущий раз Вы предпочли не ломать над этим голову, просто взяли МК следующего поколения. А в этом случае что делать? Навык оттачивается от простого к сложному, а Вы как раз предпочли его не оттачивать.

AndTer писал(а):

И надо понимать, что самый ценный ресурс это время. Оно как ресурс невосполнимо и ограничено.

Время, потраченное на обучение и освоение новых навыков, никогда не бывает потрачено зря.

[BOB51]

Alkul писал(а):

...
Интересное утверждение. А чем AVR принципиально отличаются от, скажем, х51 ?...

У АВР(и у ПИКов) нет возможности работать в режиме микропроцессора - совмещенной внешней памяти программ/данных.

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

Это ежли нету сил и времени освоить многофайловики под ассемблером - надо отдать должное это ешшо тот садомазохизьм!

[oleg110592]

BOB51 писал(а):

У АВР(и у ПИКов) нет возможности работать в режиме микропроцессора - совмещенной внешней памяти программ/данных.

а как же ATmega162 – Up to 64K Bytes Optional External Memory Space
или PIC18F8520 External Memory Addressing (up to 2 Mbytes)

[pyzhman]

Господа! Вы не забыли, о чём идёт речь?

[akl]

vasyatky писал(а):

завтра обновлю схему. попробую прогнать макет.

Думаю, все чудеса от некорректного включения кнопок. Можно попробовать тестовую программу

Спойлер

Код:

.include "tn13Adef.inc"

;   Константы
;=======
.equ   Fo=9600000/8

.org   0
   RJMP   START
TB_SVET_TIME:
   .DB   0b00000111,BYTE3(3*Fo/5-1),BYTE2(3*Fo/5-1),BYTE1(3*Fo/5-1)   ;все включены   ;красный
   .DB   0b00000001,BYTE3(3*Fo/5-1),BYTE2(3*Fo/5-1),BYTE1(3*Fo/5-1)   ;красный
   .DB   0b00000011,BYTE3(5*Fo/10/5-1),BYTE2(5*Fo/10/5-1),BYTE1(5*Fo/10/5-1)   ;красный+желтый
   .DB   0b00000100,BYTE3(3*Fo/5-1),BYTE2(3*Fo/5-1),BYTE1(3*Fo/5-1)      ;зелёный
TB_SVET_TIME_END:

START:
   SER   R19
   OUT   DDRB,R19

   LDI   ZH,HIGH(TB_SVET_TIME*2)
   LDI   ZL,LOW(TB_SVET_TIME*2)
CIKLE:
   LPM   R19,Z+
   LPM   R20,Z+
   LPM   R21,Z+
   LPM   R22,Z+
   OUT   PORTB,R19
   RCALL   GO_DEL
   CPI   ZL,LOW(TB_SVET_TIME_END*2)
   BRLO   CIKLE
   RJMP   START

GO_DEL:
   SUBI   R22,BYTE1(1)
   SBCI   R21,BYTE2(1)
   SBCI   R20,BYTE3(1)
   BRNE   GO_DEL
   RET
.EXIT

[BOB51]

oleg110592 писал(а):

BOB51 писал(а):

У АВР(и у ПИКов) нет возможности работать в режиме микропроцессора - совмещенной внешней памяти программ/данных.

а как же ATmega162 – Up to 64K Bytes Optional External Memory Space
или PIC18F8520 External Memory Addressing (up to 2 Mbytes)

Это ВНЕШНЯЯ ПАМЯТЬ ДАННЫХ,
НО НЕ СОВМЕЩЕННАЯ ПАМЯТЬ ПРОГРАММ/ДАННЫХ
Выполнять напрямую программы оттуда эти МК НЕ В СОСОТЯНИИ.
А вот ежли работать с машинными кодами через предустановленный в ПЗУ МК интерпретатор то тогда подобие будет (но то ведь не прямое исполнение, а имитация целевого процессора - как частность так имитировали Z80 с помощью АВР).

ПОКА...
Ждемс корректную схемку от топикстартера... на посмотрямс...

[oleg110592]

ТС-у бы еще железный отладчик - "другой вопрос: как это происходит на самом деле, в камне?"
для BOB51 из документации:

The External Memory Bus (EMB) allows the device to
access external memory devices (such as Flash,
EPROM, SRAM, etc.) as program or data memory. It
supports both 8-bit and 16-bit Data Width modes and
four address widths from 8 to 20 bits.

[Мурик]

ATTiny13 поддерживает отладку по debugWIRE, но отладчик нужно поискать. Готовые на Али стоят больше 100$. Кроме того, интерфейс debugWIRE имеет ограничения.

Спойлер

Программные точки останова формируются с помощью входящей в систему команд AVR команды Break. Интегрированная среда разработки обеспечивает сохранение оригинальной команды, заменяемой Break в памяти настольного компьютера, с последующим её восстановлением и продолжением исполнения программы. Таким образом использование программных точек останова тратит ограниченный ресурс данных микроконтроллеров — максимально возможное количество циклов записи стирания программной памяти. Нужно следить, чтобы отладчик не израсходовал его полностью.

Поскольку для отладки используется вход внешнего сброса RESET, становится невозможным проверять схемы внешнего сброса.

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

В режиме с разрешённой отладкой потребляемая процессором мощность возрастает, поэтому не следует забывать по окончании отладки перевести fuse-переключатель DWEN в исходное состояние.

Не пойму неужели разработчики не могли сделать нормальную отладку? И без фьюзов конечно же не обошлось. В нормальных МК вместо них программная конфигурация.

[oleg110592]

как вариант у китайцев есть AVR JTAG дешево, можно и самому спаять (прошивка вроде в папке AVR Studio). Но тини13 не поддерживает - придется на поддерживаемой типа mega16 отладить, а потом перенести в тини13.

[Мурик]

Вот и я про это. Дешевых debugWIRE отладчиков (или схем с прошивкой) в сети найти не удалось. Может плохо искал?

[ARV]

"железный отладчик" для attiny13?!
это может потребоваться только в случае, если разработчик полный неизлечимый даун

[Мурик]

ARV, это может понадобится в начале изучения МК чтобы лучше понимать как он работает. У ТС как раз такой случай.

[AndTer]

Чего то далеко занесло от темы)
И всё же, ждём вестей от ТСа и держим пальцы.
Ведь пока папка играется с асмом, ребёнок ждёт светофор...