Например TDA7294

 Форум РадиоКот • Просмотр темы - C для AVR -- пишем аккуратно.
Форум РадиоКот
Здесь можно немножко помяукать :)



Текущее время: Пн янв 21, 2019 18:44:59



Часовой пояс: UTC + 3 часа [ Летнее время ]


ПРЯМО СЕЙЧАС:



Начать новую тему Ответить на тему  [ Сообщений: 112 ]  1, , , , ,  
Автор Сообщение
Не в сети
 Заголовок сообщения: C для AVR -- пишем аккуратно.
СообщениеДобавлено: Пт авг 24, 2012 14:35:36 
Опытный кот
Аватар пользователя

Карма: 8
Зарегистрирован: Чт дек 31, 2009 20:27:45
Сообщений: 842
Откуда: Бровари, Україна
Рейтинг сообщения: 2
Выделено из темы про ассемблер AVR. Начало тут.
Цитаты оттуда:
shads писал(а):
Сообразил тут декодер радиоканала на тиньке 13-й, в двух вариантах, на С и на асме, так вот мож кому интересно будет узнать, разница в весе кода - больше чем в 2 раза, на С - 870 байт, а на асме тоже самое - 420 байт.....
Помоему асма остается актуальной для таких мелкашек как tiny13
http://asis-kbr.ru/forum/viewtopic.php?f=9&t=122

avreal писал(а):
Я даже больше скажу -- если написать на асме программу размером байт десять, то С-шный вариант проиграет раз в пять-восемь, так как С (по крайней мере WinAVR) и всю таблицу прерываний заполняет переходом на ловушку необработанных прерываний, и прочие «общеподготовительные» вещи могут место занять. Т.е. у С-шной программы даже без желания автора обычно несколько другой функционал.
...
Увидел всё по линку, гляну по свободе. На носу куча выходных :-)

Ну вот и глянул.

Табличка результатов на разных версиях avr-gcc.
orig -- код по ссылке
patch -- то, что я с ним сделал.
Ключи компиляции везде одинаковые, взяты из стандартного проекта. Для 4.7.1 ещё добавлялся ключ -fno-ivopts, чтобы он менше чудил с оптимизацией induction variables в циклах. Они там что-то в «корневом» gcc похимичили, для процессоров с развитыми адресациями точно стало лучше, для AVR компилятор иногда слишком «мудрит» и сам себя перехитрить умудряется.
Код:
version  orig    patch   avr-gcc build

3.4.6    884     702     WinAVR-20060421
4.2.2    874     678     WinAVR-20071221
4.3.3    872     658     WinAVR-20100110
4.7.1    844     674     MobileChessBoard 4.7.1rc1 (-fno-ivopts -> 668)

4.3.4    894     680     Ubuntu-10.04
4.5.3    860     660     Ubuntu-12.04
«MobileChessBoard» -- это такие сборки свежего avr-gcc для Windows.

Т.е. проигрыш у ассемблера уже не два, а полтора раза (675 / 450) :-)

Но сейчас я не о том, насколько проигрывает C ассемблеру на проектах такого размера, а о том, что можно сделать с нормальным в принципе С-шным кодом для уменьшения размера прошивки байт так с 870-ти до байт так 670-ти (больше, чем на четверть).

Причём смотрел «обще-микроконтроллерно-С-шные» вещи, там осталась одна большая беда именно avr-gcc, IAR должен бы ещё короче сделать на несколько десятков байт, но мне лень проверять.

Пришиваю новый исходник, надеюсь, оно будет работать :-)
Немного позже (сейчас гости пришли) напишу немного по принципы — «общие» и что там осталось специфического для avr-gcc


Вложения:
receiver_433-win1251.c [8.86 KiB]
Скачиваний: 354

_________________
Лень в виде мании величия: «ты гений, зачем стараться?». В виде комплекса: «всё равно не выйдет, зачем упираться?». Как логика: «если достаточно, зачем знать и уметь больше?». Цель одна: остановить. Не любит тепло работающих мышц и шум работающего мозга.
Вернуться наверх
 
Не в сети
 Заголовок сообщения: Re: C для AVR -- пишем аккуратно.
СообщениеДобавлено: Пт авг 24, 2012 16:46:05 
Опытный кот
Аватар пользователя

Карма: 8
Зарегистрирован: Ср фев 22, 2012 02:25:21
Сообщений: 878
Рейтинг сообщения: 0
Гы..... С трудом узнал свою программу.....
Даже не верилось что она заработает, НО..... она работает.....
Спасибо за уделенное внимание. Хотя для понимания она стала сложнее (по крайней мере для меня, т.к. я тока начал писать на С), но надо будет обязательно разобраться, чего это вы там такого понаписали :)


Вернуться наверх
 
JLCPCB, 10 прототипов ПП всего за $2 и 2 дня доставка!

Крупнейший производитель печатных плат в Китае, 300,000+ заказчиков, 10,000+ он-лайн заказов в день.

Рассчитайте цену онлайн:https://jlcpcb.com/quote

Не в сети
 Заголовок сообщения: Re: C для AVR -- пишем аккуратно.
СообщениеДобавлено: Пт авг 24, 2012 16:52:32 
Друг Кота
Аватар пользователя

Карма: 79
Зарегистрирован: Вт мар 16, 2010 23:02:27
Сообщений: 8764
Откуда: ДОНЕЦК (ЮГО-ВОСТОК ua/DPR)
Рейтинг сообщения: 0
однако в конце-концов всеравно все сводится к машинным кодам :)
корректность программы на С во многом зависит от качества компилятора (и знаний правильных приемов работы с оным), а в ассемблере львиная доля - знание аппаратной структуры и схемотехники устройств
в идеале - знание того и другого (да еще минимум на всех базовых семействах)
из С более перспективным выглядит микроси - единый подход ко всем 4-м "ходовым" семействам.... но... полные версии уж "оччень платные" :cry:


Вернуться наверх
 
PCBWay - всего $5 за 10 печатных плат, первый заказ для новых клиентов БЕСПЛАТЕН

Сборка печатных плат от $88 + БЕСПЛАТНАЯ доставка по всему миру + трафарет

Второй конкурс по дизайну печатных плат от PCBWay!
Не в сети
 Заголовок сообщения: Re: C для AVR -- пишем аккуратно.
СообщениеДобавлено: Пт авг 24, 2012 20:49:31 
Друг Кота
Аватар пользователя

Карма: 69
Зарегистрирован: Вс мар 29, 2009 23:09:05
Сообщений: 7374
Рейтинг сообщения: 0
Я, кстати, достаточно подробно разбирал, чего генерирует AVR-GCC в нагрузку к основному коду.

_________________
Разница между теорией и практикой на практике гораздо больше, чем в теории.


Вернуться наверх
 


Не в сети
 Заголовок сообщения: Re: C для AVR -- пишем аккуратно.
СообщениеДобавлено: Пт авг 24, 2012 21:05:55 
Опытный кот
Аватар пользователя

Карма: 8
Зарегистрирован: Чт дек 31, 2009 20:27:45
Сообщений: 842
Откуда: Бровари, Україна
Рейтинг сообщения: 0
shads писал(а):
Гы..... С трудом узнал свою программу.....
Так я же в ней ничего принципиального не менял :-)
Так, точечно, «тактически»., а «стратегически» все осталось как было.

Итак, пошли сверху вниз по тексту.
Код:
#define INLINE   inline __attribute__((__always_inline__))
#define NOINLINE __attribute__((__noinline__))
GCC-шные штуки, эквивалентные IAR-овским #pragma inline и т.п. Команды компилятору принудительно «инлайнить» (встраивать по месту как макросы) и ни в коем случае не инлайнить определённые функции. Будут использованы ниже.

Код:
//прототипы функций
static void Receive(void);
static void Int100Hz(void);
Каждая функция используются только в данном файле, поэтому её стоит объявить как static. При этом компилятор знает, что снаружи она не может быть вызвана и поступает с ней по собственному усмотрению. Если функция вызывается из одного места, то он практически гарантированно её встроит по месту, а не будет вызывать. Если функция вызывается из нескольких мест, но она короткая — тоже может встроить.
При встраивании единожды вызываемой функции экономи размера кода небольшая, но есть.
Для небольшой функции без static может быть вообще плохо — он её и по месту встроит (маленькая, экономия на саом вызове и на стандартной передаче параметров может быть больше размера функции), но и отдельно тело тоже оставит. Так как при компиляции из .c в .o компилятор не знает, что файл один, оставляет функцию на случай, если ее кто-то снаружи вызовет. Т.е. функция займёт место во флеше дважды.
Кроме того, static-объекты не захламляют глобальное пространство имён, не занимают место (и время) в соответствующих таблицах при работе компилятора и линкера.
Объявлять как static все функции и переменные, которые не используются за пределами файла — «правило хорошего тона».

Код:
enum { DW_B0 = 0, DW_B1 = 1, DW_B2 = 2, DW_B3 = 3 };  // LITTLE ENDIAN CPU
// enum { DW_B0 = 3, DW_B1 = 2, DW_B2 = 1, DW_B3 = 0 }; // BIG ENDIAN CPU
union {
    uint32_t dw;
    uint8_t  b[4];
} ReceiveData;      //4 байта для чтения кода с радиоканала
Я уже об этом писал, для приёма битового потока удобно объявить объединение, т.е. наложение в памяти двух переменных: 32-битного целого и 4-бійтового массива. Слдвиг делается в 32-битовое поле dw, а разбор потом — из байтового массива.
Перед ним «для порядку» объявлено перечислимый тип, который описывает порядок байтов в 32-битном слове. Надо было бы ещё и #ifdef LITTLE_ENDIAN или там #if BYTE_ORDER == LITTLE_ENDIAN, но тут я так, для демонстрации того, что такую вещь можно при желании сделать переносимой и она скомпилируется для любого процессора.
Это место сэкономило довольно много кода — при записи в EEPROM и при сравнивании с таблицей кодов пропали >> 8, >> 16, которые хоть и делаются пересылкой байтов, но все же…
Было:
Код:
   eeprom_write_byte (&EEData[EEPntTmp +0], (unsigned char) (ReceiveData >> 0));
   eeprom_write_byte (&EEData[EEPntTmp +1], (unsigned char) (ReceiveData >> 8));
   eeprom_write_byte (&EEData[EEPntTmp +2], (unsigned char) (ReceiveData >> 16UL));
Стало:
Код:
            EEWrite(ee_addr,     ReceiveData.b[DW_B0]);
            EEWrite(++ee_addr,   ReceiveData.b[DW_B1]);
            EEWrite(++ee_addr,   ReceiveData.b[DW_B2]);
(а временная переменная ee_addr практически только для удобства записи, на размер кода не влияет).

Код:
static NOINLINE void delay(uint8_t ticks10ms)
{
   while(ticks10ms--) _delay_ms(10);
}
В ассемблерном варианте для задержки везде вызівается функция с параметром времени в 10мс квантах. В С-шном везде было _delay_ms(). Но это макрос, который по месту вставляет все те вложенные циклы, при многократном применении флеш разлетается ужасающим образом. Это для малых, микросекундных задержек там три команды выходит, не так и жалко.
Но вот тут понадобилось NOINLINE, так как функция короткая и некоторые из оттестированных версий компиляторов норовили вставить тело по месту.
У меня NOINLINE и компания вместе с уже упоминавшимися INIT() сидят в gcc_macros.h и я для таких небольших функций со специально вынесенным отдельно кодом ставлю практически рефлекторно.


Пойду попью чаю…

_________________
Лень в виде мании величия: «ты гений, зачем стараться?». В виде комплекса: «всё равно не выйдет, зачем упираться?». Как логика: «если достаточно, зачем знать и уметь больше?». Цель одна: остановить. Не любит тепло работающих мышц и шум работающего мозга.


Последний раз редактировалось avreal Пт авг 24, 2012 21:26:42, всего редактировалось 1 раз.

Вернуться наверх
 
Впервые на русском языке! «Поваренная книга разработчика аналоговых схем: Операционные усилители»

Практическое руководство «Разработчика аналоговой электроники по операционным усилителям», созданной инженерами компании Texas Instruments. Содержит схемы, примеры типовых расчетов с указанием формул и последовательности действий. Результаты расчетов дополнительно проверяются в программе SPICE-моделирования.
Подробнее...
Не в сети
 Заголовок сообщения: Re: C для AVR -- пишем аккуратно.
СообщениеДобавлено: Пт авг 24, 2012 21:23:50 
Опытный кот
Аватар пользователя

Карма: 8
Зарегистрирован: Чт дек 31, 2009 20:27:45
Сообщений: 842
Откуда: Бровари, Україна
Рейтинг сообщения: 0
YS писал(а):
Я, кстати, достаточно подробно разбирал, чего генерирует AVR-GCC в нагрузку к основному коду.
О, значит про это можно не писать :-)
Только добавлю (недавно писал на этом форуме), что обработчик незадействованого прерывания можно определить в своей программе, он заменит тот по умолчанию переход на старт.

_________________
Лень в виде мании величия: «ты гений, зачем стараться?». В виде комплекса: «всё равно не выйдет, зачем упираться?». Как логика: «если достаточно, зачем знать и уметь больше?». Цель одна: остановить. Не любит тепло работающих мышц и шум работающего мозга.


Вернуться наверх
 


Не в сети
 Заголовок сообщения: Re: C для AVR -- пишем аккуратно.
СообщениеДобавлено: Пт авг 24, 2012 21:34:21 
Друг Кота
Аватар пользователя

Карма: 69
Зарегистрирован: Вс мар 29, 2009 23:09:05
Сообщений: 7374
Рейтинг сообщения: 0
Цитата:
обработчик незадействованого прерывания можно определить в своей программе


Ага. BADISR_vect его вектор.

#pragma offtopic

А AVReal еще не поддерживает FTBB?

_________________
Разница между теорией и практикой на практике гораздо больше, чем в теории.


Вернуться наверх
 


Не в сети
 Заголовок сообщения: Re: C для AVR -- пишем аккуратно.
СообщениеДобавлено: Пт авг 24, 2012 21:50:21 
Опытный кот
Аватар пользователя

Карма: 8
Зарегистрирован: Ср фев 22, 2012 02:25:21
Сообщений: 878
Рейтинг сообщения: 0
Ооо.... Спасибо avreal, многое постараюсь применить, я тут как раз одну страшную весч затеял, думаю в итоге под 8кб коду будет (mega8), так что надо будет экономить. Пока только начало, нашкрябал 1,5кб.....


Вернуться наверх
 
Не в сети
 Заголовок сообщения: Re: C для AVR -- пишем аккуратно.
СообщениеДобавлено: Пт авг 24, 2012 22:33:35 
Опытный кот
Аватар пользователя

Карма: 8
Зарегистрирован: Чт дек 31, 2009 20:27:45
Сообщений: 842
Откуда: Бровари, Україна
Рейтинг сообщения: 0
Начинаем продолжать…

Код:
static NOINLINE void EEWrite(uint8_t addr, uint8_t data) { … }
static NOINLINE uint8_t EERead(uint8_t addr) { … }
Библиотечные функции работы с EEPROM принимают «как бы указатель» на переменную в EEPROM. Оно выглядит красиво, но EEMEM только атрибут размещения и всё равно тот указатель как указатель не работает (в gcc 4.7 добавлены пространства памяти и в avr-gcc они использованы, но это другая история).
Соответственно в функции eeprom_* нужно передавать 16-битный аргумент и для вычисления адресов используется 16-разрядная арифметика. Но ведь в ATtiny13 всего 64 байта EEPROM!
Не ленимся и пишем свои функции, принимающие 8-битный номер ячейки. Тоже NOINLINE, так как иначе некоторые версии компилятора их встраивают (особенно Read, она совсем короткая).

Теперь иллюстрация к моим словам «т.е. у С-шной программы даже без желания автора обычно несколько другой функционал.»
Тут с некоторым желанием, но всё же.
Исходно:
Код:
unsigned char EEData[EEDataLen] EEMEM;
unsigned char EEPnt EEMEM;

      for (unsigned char i=0; i<EEDataLen; i++)
         eeprom_write_byte(&EEData [i], 0);
      eeprom_write_byte(&EEPnt, 0);
Всё вроде бы нормально. Ассемблерная программа зануляла не глядя всю EEPROM-ину, а тут одна из переменных зануляется отдельно. Лишний вызов (а в исходном варианте ещё и с передачей 16-разрядного адреса). И сохранить «высокоуровневость» с занулением только необходимой части, причём не обязательно начиная с нулевого адреса, и сэкономить код можно объединением массива и индекса в структуру (имена такие с целью упрощения редактирования текста). Зануляем всю структуру одним махом:
Код:
#define EEDataLen 60            /*длина буфера данных в EEPROM */
struct {
    unsigned char Data[EEDataLen];  //массив данных в EEPROM
    unsigned char Pnt;         //указатель на байт массива в EEPROM (0-59)
} EE EEMEM;

        uint8_t from = (unsigned)&EE;
        uint8_t to   = (unsigned)&EE + sizeof(EE);
        do  { EEWrite(from, 0); ++from; } while(from < to); //цикл стирания данных EEPROM
При обращении используем адреса полей
Код:
            EEWrite((unsigned)&EE.Pnt, EEPntTmp+3);
            uint8_t ee_addr = (unsigned)&EE.Data[EEPntTmp];


Дальше мелочи.
Код:
        //сдвиг буфера и запись в младший разряд принятого бита
        unsigned long ultemp = ReceiveData.dw << 1;
        if (BitLoPartCoun < BitHiPartCoun) ultemp |= 1;
        ReceiveData.dw = ultemp;
об этом я тоже уже писал — компилятору тут желательна подсказка в виде временной переменной и он перестаёт делать лишнее сохранение после сдвига.
Код:
        //ReceiveData &= 0x00ffffff;      //очистить лишние старшие 8 бит
Это я сразу закомментировал, еще до создания union для приёмного буфера. Старший байт в программе нигде не анализировался, ничего страшного, если там поболтается мусор.

Ну вот, собственно, и всё… Не так уж и много изменил. Сделать было быстрее, чем описать :)))

Что осталось:
1. Обще-С-шная беда, особенно сильно проявляющаяся у AVR -- у него много регистров, а при обработке прерывания их нужно сохранить.
Если обработчик делает всё «сам», то компилятор знает, какие регистры он задействовал и сохраняет/восстанавливает только их.
Если из обработчика вызывается какая-то функция, то в обработчике сохраняются все регистры, которые вызываемая функция не обязана сохранять. Даже если она их не использует — компилятор-то про это «не знает» и сохраняет на всякий случай все *) Из-за обилия регистров у AVR стоит избегать вызовов не-inline функций из обработчиков. Вот даже тут если поменять функции EERead/EEwrite на INLINE, то код увеличится, но ненамного, так как пропадёт с десяток push/pop (т.е. десятка четыре байт). Для avr-gcc 4.3.4 из убунты 10.04 NOINLINE даёт 680 байт, а INLINE, размноживший тела функций по месту, 712.

2. Чисто avr-gcc-шная беда. Он почему-то экономит указательные регистры и предпочитает 4-байтовые lds/sts, которых там в обработчике немеряно. Даже если собрать все используемые в Receive() переменные в одну структуру, завести в подпрограмме указатель на эту структуру (под использование ldd/std), то он всё равно радостно скажет «да это же не какая-то неизвестная и каждій раз другая структура, это вот она одна конкретная фиксированная я ее вижу», выбросит указатель и будет напрямую lds/sts использовать.
IAR, насколько я знаю, умеет сам собирать рядом объявленные переменные в структуру и использовать смещение к адресной регистровой паре. Прикидочно, на этом в данной программе можно сэкономить ещё около полусотни байт.
avr-gcc иногда удаётся убедить использовать указатель, но это если вообще не поленюсь, то уж не в эти выходные.

*) Keil/MCS51 умеет вкупе с линкером делать глобальную регистровую оптимизацию, анализируя по дереву вызовов использование регистров. Не помню, работает ли это с обработчиками прерываний, они у меня на асме написаны были. На 25-килобайтной программе эта оптимизация давала около килобайта выиграша (для всех своих ассмблерных подпрограмм я тоже дал описания используемых регистров, иначе от них вверх по дереву шло «неизвестно, а значит надо беречь всё»).
Возможно, в GCC что-то поправится в связи с LTO, но, опять таки, не уверен, что на обработчики преріваний это повлияет.

_________________
Лень в виде мании величия: «ты гений, зачем стараться?». В виде комплекса: «всё равно не выйдет, зачем упираться?». Как логика: «если достаточно, зачем знать и уметь больше?». Цель одна: остановить. Не любит тепло работающих мышц и шум работающего мозга.


Последний раз редактировалось avreal Пт авг 24, 2012 22:41:25, всего редактировалось 1 раз.

Вернуться наверх
 
Не в сети
 Заголовок сообщения: Re: C для AVR -- пишем аккуратно.
СообщениеДобавлено: Пт авг 24, 2012 22:34:36 
Опытный кот
Аватар пользователя

Карма: 8
Зарегистрирован: Чт дек 31, 2009 20:27:45
Сообщений: 842
Откуда: Бровари, Україна
Рейтинг сообщения: 0
YS писал(а):
#pragma offtopic
А AVReal еще не поддерживает FTBB?
Ну вот как меньше буду по форумам сидеть, так и найду время :-)

_________________
Лень в виде мании величия: «ты гений, зачем стараться?». В виде комплекса: «всё равно не выйдет, зачем упираться?». Как логика: «если достаточно, зачем знать и уметь больше?». Цель одна: остановить. Не любит тепло работающих мышц и шум работающего мозга.


Вернуться наверх
 
Не в сети
 Заголовок сообщения: Re: C для AVR -- пишем аккуратно.
СообщениеДобавлено: Сб авг 25, 2012 11:22:27 
Держит паяльник хвостом
Аватар пользователя

Карма: 16
Зарегистрирован: Ср мар 28, 2012 22:45:24
Сообщений: 905
Откуда: ВО
Рейтинг сообщения: 0
Ну так это уже на статью тянет


Вернуться наверх
 
Не в сети
 Заголовок сообщения: Re: C для AVR -- пишем аккуратно.
СообщениеДобавлено: Сб авг 25, 2012 12:51:25 
Опытный кот
Аватар пользователя

Карма: 8
Зарегистрирован: Чт дек 31, 2009 20:27:45
Сообщений: 842
Откуда: Бровари, Україна
Рейтинг сообщения: 0
«Охота пуще неволи» («Начинаем продолжать - 2»).

Мелкая правка:
Поменял имена типа LedPin на LedMask и завёл LedPIN как именно регистр PIN, запись в него инвертирует ножку. Таким образом мигание светодиодом ещё укоротилось (это же и для асм-варианта полезно).

Тяжёлая артиллерия (заставляем avr-gcc работать со структурой через указатель и смещения — struct_receiver.c):
Объединил переменные состояния приёма и буфер приёма в одну структуру (связанные логикой программы переменные я чаще всего сразу объединяю в структуру), добавил в Receive() переменную-указатель и макрос для предзагрузки указателя (там в исходниках ссылка на сайт, где обсуждается этот фокус).
После столь убедительной просьбы avr-gcc начинает таки использовать ldd/std и размер программы для всех версий, кроме 3.4.6, упал до значений в диапазоне 600-620 байт, в минимуме 598.
Уже только на треть больше 450-байтового ассемблерного варианта у которого все переменные в регистрах и прямая работа с ними на месте. Было бы переменных больше и они не лезли бы все в регистры, так разница была бы еще меньше.
Хотя асмовый вариант тоже можно немного сократить.

Если ещё такое же сделать для Int100Hz(), причём в ту же структуру затолкать и счётчик Div100, то размер упадёт ниже отметки 600 байт уже для большинства версий компилятора.

Веником его, веником (reg_struct_receiver.c):
Почти все глобальные переменные размещены в регистрах при помощи конструкций вида
Код:
register uint8_t RelayOnCoun asm("r2");
Нужно в ключах добавить
Код:
-ffixed-r2 -ffixed-r3 -ffixed-r4 -ffixed-r5 -ffixed-r6 -ffixed-r7 -ffixed-r8
При этом компилятор все равно иногда работает с ними плохо («I like to move it move it»), вместо dec r2 может влупить mov r16, r2 $ subi r16, 1 $ mov r2, r16, но всё равно код выходит короче и быстрее.

Повтор таблички с новой колонкой ptr для результатов со структурой и указателем и с колонкой reg для принудительного размещения переменных в регистрах.
Не зря я не люблю насиловать компилятор размещением в регистрах. Две версии (*** в соответствующей колонке) просто взглюкнули, выбросив почти весь код receive():
Код:
avr-gcc   orig    patch   ptr     reg     avr-gcc build

3.4.6     884     702     646     616     WinAVR-20060421
4.2.2     874     678     620     586     WinAVR-20071221
4.3.3     872     658     598     ***     WinAVR-20100110

4.7.1     844     674     612     576     MobileChessBoard 4.7.1rc1
4.7.1     844     668     606     570     MobileChessBoard 4.7.1rc1  -fno-ivopts

4.3.4     894     680     620     ***     Ubuntu-10.04
4.5.3     860     660     598     566     Ubuntu-12.04

И новые исходники


Вложения:
struct_receiver.7z [3.74 KiB]
Скачиваний: 197

_________________
Лень в виде мании величия: «ты гений, зачем стараться?». В виде комплекса: «всё равно не выйдет, зачем упираться?». Как логика: «если достаточно, зачем знать и уметь больше?». Цель одна: остановить. Не любит тепло работающих мышц и шум работающего мозга.


Последний раз редактировалось avreal Сб авг 25, 2012 13:09:31, всего редактировалось 1 раз.
Вернуться наверх
 
Не в сети
 Заголовок сообщения: Re: C для AVR -- пишем аккуратно.
СообщениеДобавлено: Сб авг 25, 2012 13:06:40 
Опытный кот
Аватар пользователя

Карма: 8
Зарегистрирован: Чт дек 31, 2009 20:27:45
Сообщений: 842
Откуда: Бровари, Україна
Рейтинг сообщения: 0
ILYAUL писал(а):
Ну так это уже на статью тянет
Так это ж нужно садиться и делать хоть маленькую, но дополнительную работу :-)
Надо сначала отлежаться/отлизаться :-)

_________________
Лень в виде мании величия: «ты гений, зачем стараться?». В виде комплекса: «всё равно не выйдет, зачем упираться?». Как логика: «если достаточно, зачем знать и уметь больше?». Цель одна: остановить. Не любит тепло работающих мышц и шум работающего мозга.


Вернуться наверх
 
Не в сети
 Заголовок сообщения: Re: C для AVR -- пишем аккуратно.
СообщениеДобавлено: Сб авг 25, 2012 14:37:47 
Опытный кот
Аватар пользователя

Карма: 8
Зарегистрирован: Ср фев 22, 2012 02:25:21
Сообщений: 878
Рейтинг сообщения: 0
Уххххх......
Высший пилотаж! Я уж и боюсь вникать во все эти тонкости, стока их.....

Для начала попробую разобраться, как это вы просите компилятор использовать ldd/std вместо команд прямой загрузки, ато он немерено жрет ресурсов чтобы переменную загрузить и выгрузить. Я на асме вообще всегда резервировал регистровую пару с адресом начала оперативки, и всегда пользовался ldd/std. Честно говоря сначала в шоке был когда увидел что на обращение к переменной С тратит целых 8 байт..... это кроме операций с самой переменной.....

Со структурами пока страшновато, постепенно думаю буду вникать в ваши уроки.

Еще раз спасибо!


Вернуться наверх
 
Не в сети
 Заголовок сообщения: Re: C для AVR -- пишем аккуратно.
СообщениеДобавлено: Сб авг 25, 2012 15:37:07 
Друг Кота
Аватар пользователя

Карма: 69
Зарегистрирован: Вс мар 29, 2009 23:09:05
Сообщений: 7374
Рейтинг сообщения: 0
Приятно посмотреть на качественную работу с кодом! :beer:

_________________
Разница между теорией и практикой на практике гораздо больше, чем в теории.


Вернуться наверх
 
Не в сети
 Заголовок сообщения: Re: C для AVR -- пишем аккуратно.
СообщениеДобавлено: Сб авг 25, 2012 16:10:55 
Опытный кот
Аватар пользователя

Карма: 8
Зарегистрирован: Чт дек 31, 2009 20:27:45
Сообщений: 842
Откуда: Бровари, Україна
Рейтинг сообщения: 0
shads писал(а):
Для начала попробую разобраться, как это вы просите компилятор использовать ldd/std вместо команд прямой загрузки
...
Я на асме вообще всегда резервировал регистровую пару с адресом начала оперативки, и всегда пользовался ldd/std.
...
Со структурами пока страшновато, постепенно думаю буду вникать в ваши уроки.
Вот когда на асме регистровая пара на начало оперативки — фактически, все переменные начинают характеризоваться не своим абсолютным адресом, а смещением относительно того начала.
Структуры в С чем-то на это похожи.
Объединяя переменные в структуру мы говорим компилятору «они должны лежать вместе, рядом, нас будут интересовать смещения относительно начала структуры». Причём самих переменны=-структур может быть несколько одинаковых, при работе с каждой пользуемся смещениями относительно её начала.
Адресация к «полям» — элементам структуры (переменной соответствующего типа) идёт через точку, например
Код:
   имя_структуры.имя_поля = 0;
Это кже неплохая подсказка компилятору о том, что можно в указательную пару загрузить адрес начала структуры и работать дальше по смещению.
Но в оптимизаторе gcc/avr-gcc где-то недоработка. Возможно, несколько неправильно расставлены «стоимости» операций / «ценность» регистров. И он почему-то считает нежелательным занимать пару регистров. Приходится обращаться через указатель
Код:
   имя_указателя_на_структуру->имя_поля = 0;
и загружать вручную указатель в пару макросом PRELOAD()
После ручной загрузки регистровая пара «уже потрачена» и компилятор её использует.

_________________
Лень в виде мании величия: «ты гений, зачем стараться?». В виде комплекса: «всё равно не выйдет, зачем упираться?». Как логика: «если достаточно, зачем знать и уметь больше?». Цель одна: остановить. Не любит тепло работающих мышц и шум работающего мозга.


Вернуться наверх
 
Не в сети
 Заголовок сообщения: Re: C для AVR -- пишем аккуратно.
СообщениеДобавлено: Сб авг 25, 2012 17:16:35 
Друг Кота

Карма: -14
Зарегистрирован: Вс дек 05, 2010 07:10:34
Сообщений: 4583
Откуда: ЮВ
Рейтинг сообщения: 0
Подобные костыли и порождают трудноуловимые глюки...
Не потому ли компилерописатели "пропустили" подобные "обороты"??? ))))))))

_________________
"Я не даю готовых решений, я заставляю думать!"(С)


Вернуться наверх
 
Не в сети
 Заголовок сообщения: Re: C для AVR -- пишем аккуратно.
СообщениеДобавлено: Сб авг 25, 2012 17:58:05 
Опытный кот
Аватар пользователя

Карма: 8
Зарегистрирован: Чт дек 31, 2009 20:27:45
Сообщений: 842
Откуда: Бровари, Україна
Рейтинг сообщения: 0
HHIMERA писал(а):
Подобные костыли и порождают трудноуловимые глюки...
А подробнее? Конкретно что за костыль, какие, к примеру, глюки? Из собственного либо чужого опыта…

HHIMERA писал(а):
Не потому ли компилерописатели "пропустили" подобные "обороты"??? ))))))))
Шо, и тут всемирный заговор?

_________________
Лень в виде мании величия: «ты гений, зачем стараться?». В виде комплекса: «всё равно не выйдет, зачем упираться?». Как логика: «если достаточно, зачем знать и уметь больше?». Цель одна: остановить. Не любит тепло работающих мышц и шум работающего мозга.


Вернуться наверх
 
Не в сети
 Заголовок сообщения: Re: C для AVR -- пишем аккуратно.
СообщениеДобавлено: Сб авг 25, 2012 18:31:30 
Друг Кота

Карма: -14
Зарегистрирован: Вс дек 05, 2010 07:10:34
Сообщений: 4583
Откуда: ЮВ
Рейтинг сообщения: 0
Мне проще посчитать свой пост вопросом, а не утверждением... чем впадать в полемику...
(Просто мне лениво)...

_________________
"Я не даю готовых решений, я заставляю думать!"(С)


Вернуться наверх
 
Не в сети
 Заголовок сообщения: Re: C для AVR -- пишем аккуратно.
СообщениеДобавлено: Сб авг 25, 2012 19:41:01 
Опытный кот
Аватар пользователя

Карма: 8
Зарегистрирован: Чт дек 31, 2009 20:27:45
Сообщений: 842
Откуда: Бровари, Україна
Рейтинг сообщения: 0
Понятно. Ляпнуть было не лениво, а отвечать — лениво.

Вы — трепло.

Можете считать мой пост вопросом, а не утверждением, так Вам будет проще, не надо будет отвечать за свои слова.

_________________
Лень в виде мании величия: «ты гений, зачем стараться?». В виде комплекса: «всё равно не выйдет, зачем упираться?». Как логика: «если достаточно, зачем знать и уметь больше?». Цель одна: остановить. Не любит тепло работающих мышц и шум работающего мозга.


Вернуться наверх
 
Показать сообщения за:  Сортировать по:  Вернуться наверх
Начать новую тему Ответить на тему  [ Сообщений: 112 ]  1, , , , ,  



Часовой пояс: UTC + 3 часа [ Летнее время ]


Кто сейчас на форуме

Сейчас этот форум просматривают: Dmittry и гости: 10


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  


Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Русская поддержка phpBB
Extended by Karma MOD © 2007—2012 m157y
Extended by Topic Tags MOD © 2012 m157y