Сопоставление проектов С и АСМ, Немного цифр Опции

[SasaVitebsk]

Написал сначала проект на ASM в AVR Studio, а позже очень похожий на Си. И там и там вылизывал по скорости. Точнее особо не вылизывал. В обоих случаях камни с большим запасом. Естественно во втором проекте было всё намного грамотнее построено. Вопервых дробление шагов на основе ШИМ с большим коэффициентом, во вторых более красивое движение стрелок обеспечено. 18 скоростей с плавным переключением. Фильтрация более красивая. Обработка CAN некоторое место занимает. Тем не менее сравнивать можно

Результаты достаточно любопытны для неопределившихся. Попробовал свести в небольшую таблицу.

Код

Камень       ! atmega8 ! at90can128 !
язык         !   asm   !    IAR C   !
-------------+---------+------------+
Число ШД     !    6    !     6      !
управл.      ! дрб 6   ! ШИМ дрб 16 !
Вх аналоговые!    6    !     3      !
Вх частотные !    0    !     1      !
Вх CAN       !    0    !     2      !
Цифр. флтр   !    +    ! + более слж!
Плавность    !    -    ! спец алг   !
Авар         !    +    !+ более слж !
-------------+---------+------------+
Размер кода  !  5019   !   6901     !
без доп табл !   -     !    672     !
Итого        !  5019   !   6229     !
Итого %      !   81    !    100     !
RAM          !  241    !    415     !
Итого %      !   58    !    100     !
-------------------------------------

Несколько попозже буду перетаскивать Этот проект на м8. То есть можно будет сопоставить практически 1 к 1 (с учётом значительных улучшений).

[_Pasha]

Вот это совсем другое дело!
Че-то WINAVR тормозит немного. А может я торможу - начитался мануалов, а уже все работает. Пойду проверю.
Насчет диспетчера кучи: я так понял, надо либо собрать все указатели, работающие с выделяемыми объектами, в одну секцию. Тогда при дефрагментации памяти сравнительно легко все перемещается. Либо не париться и держать дескрипторы.

[ReAl]

Вот это совсем другое дело!
Че-то WINAVR тормозит немного.

Ну, у avr-gcc код как правило похуже, с этим не спорю.

Код

#include <stdint.h>
#include <avr/pgmspace.h>
#define MAX_FONTS 10 // от балды, в приведеннмо примере не было задано. Но оно неважно

// структура данных по символам
struct CharZnak
{
uint16_t            sm;                        // Смещение от начала фонта
uint8_t            width;                    // Ширина символа
};

extern const  uint8_t   Fonts[MAX_FONTS][2] PROGMEM;
extern const  struct    CharZnak    struct_fnt[MAX_FONTS-2][223] PROGMEM;
extern uint8_t tekfonts, tekkern;

uint8_t sx(uint8_t Znak)
{
    return pgm_read_byte( & struct_fnt[tekfonts-2][Znak].width ) + tekkern;
}

CODE

.file "tst.c"
__SREG__ = 0x3f
__SP_H__ = 0x3e
__SP_L__ = 0x3d
__tmp_reg__ = 0
__zero_reg__ = 1
.global __do_copy_data
.global __do_clear_bss
.text
.global sx
.type sx, @function
sx:
/* prologue: frame size=0 */
/* prologue end (size=0) */
ldi r25,lo8(3)
mul r24,r25
movw r30,r0
clr r1
lds r24,tekfonts
ldi r25,lo8(0)
ldi r18,lo8(669)
ldi r19,hi8(669)
movw r20,r24
mul r20,r18
movw r24,r0
mul r20,r19
add r25,r0
mul r21,r18
add r25,r0
clr r1
add r30,r24
adc r31,r25
subi r30,lo8(-(struct_fnt-1336))
sbci r31,hi8(-(struct_fnt-1336))
/* #APP */
lpm r30, Z
/* #NOAPP */
lds r24,tekkern
add r30,r24
mov r24,r30
ldi r25,lo8(0)
/* epilogue: frame size=0 */
ret
/* epilogue end (size=1) */
/* function sx size 31 (30) */
.size sx, .-sx
/* File "tst.c": code 31 = 0x001f ( 30), prologues 0, epilogues 1 */

Катастрофической я бы разницу не назвал - ни в написании текста, ни в сгенерированном коде.
Сравнивать надо одинаковые фрагменты, в приведенном выше куске часть регистров уже "откуда ни возьмись" заполнены и используются, тут всё "автономно".

По поводу "писАть на С" - я "С" терпеть не могу еще с 1992 года

Я года с 1987..88 использую и ничего. Что-то писалось чисто асмовое, что-то с делением "это пусть на С, а эта часть на асме".
Сейчас если очень хочется - пишу вставку на асме. В последнее время хочется всё реже.

2. Переопределять стандартные функции НЕ ХОЧУ.

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

[singlskv]

Ну извините... Так можно дойти до "а на асме я могу что-то другое делать, пока EEPROM пишется, а С-шная программа станет колом на всё время записи блока, во какой плохой язык С".

Вотъ, это тоже хотелось бы обсудить, хотя конкретно это, я уже пытался обсуждать,
но большинство опонентов высказалось в том смысле, что в IAR удобно обращаться к
таким(EEPROM) переменным и все тут...

А сейчас я вот задался интересным вопросом, если кто еще не заметил, в новых AVR (mega48/88/......)
есть такая фича, можно отдельно стирать ячейку и можно отдельно ее программировать...

Вопрос:
кто-нить уже пробовал записать в ячейку 2 раза без стирания ?
ИМХО, это открывает новые возможности для увеличения количества записи в eeprom,
но конечно, этот факт, требует дополнительной проверки, добровольцы есть ?

[Petka]

Вопрос:
кто-нить уже пробовал записать в ячейку 2 раза без стирания ?
ИМХО, это открывает новые возможности для увеличения количества записи в eeprom,
но конечно, этот факт, требует дополнительной проверки, добровольцы есть ?

Велосипед уже изобретён. Atmel AN "AVR103"

[singlskv]

Велосипед уже изобретён. Atmel AN "AVR103"

Спасибо за наводку,
этот апликайшн как-то мимо меня пролетел...