Новичок на С, Помогите разобраться со структурой проекта Опции

[SasaVitebsk]

Доброго времени суток. Помогите начинающему. Долгое время писал на асме для разных микропроцессоров. В том числе большие проекты. На IBM приходилось писать вспомогательные програмки на Delfi. "C" использовать не приходилось. В данный момент приходится осваивать для реализации крупного и длительного проекта. "С" так, как есть вариант впоследствии перейти на др. МП. Почитал, - синтаксис языка вполне понятен. Хоть сейчас в бой. Но нек. моменты не понятны.
Во-первых, не хочу обидеть чьи-нибудь чувства, но более дебильной и запутанной IDE среды чем IAR Wb я не встречал. Но к этому привыкну. Скачал PDFы и сделал книжечки. По возможности изучил. Сделал маленькую прогу, но всё равно остался ряд вопросов по организации проги.
1) Как определять какие библиотеки включать?
2) Если необходимы прерывания достаточно ли такого объявления или необходимо что-то ещё (например переходы):

#pragma vector=USART_RXC_vect
__interrupt void rxint(void)
{

}

3) Как понимать следующие строки? (В смысле на языке высокого уровня)

jmp_buf main_task;
jmp_buf iprx_task;
jmp_buf iptx_task;
char iprx_rstack[8];

и вот эти пжлст

#pragma vector=USART_RXC_vect
__interrupt void rxint(void)
{
if (!setjmp(main_task)) //Запомнили контекст осн. задачи
{
longjmp(iprx_task,1); //Перешли в контекст IPrecive
}
}


4) Что необходимо описывать чтобы грамотно сделать проект в котором несколько файлов ".С"
5) При использовании кольцевого буфера правильнее открыть буфер в виде массива или использовать указатели.
6) Профи, если можно вышлите какой-нибудь файл(ы) исходников (можно не рабочих, урезанных или с ошибками) по которым я мог бы посмотреть структуру программы. Лучше с прерываниями. Обязуюсь не распространять и использовать в качестве учебных. Пожалуйста не присылайте слишком больших, а то я зароюсь.

Заранее благодарен. e-mail: sasa@c32dvina.com

[SasaVitebsk]

Чувствую, что я скоро всем надоем, и отвечать мне никто не будет.
Но у меня уже есть прогресс! Я написал большую часть проги и откомпиллил её без ошибок!!!

Вот такой вот вопрос:
Есть объявление функции. В качестве параметра 32 битное число. Я хочу использовать его побайтно.
Могу я сделать так?

union uint32_u {
uint32_t dw;
uint8_t bt[4];
};

в вызове использовать типа: uint32_u addr;

а при обращении использовать unsigned long int addr.

Или как поступить в данном случае. Как обратится к байтам длинного числа не пребегая к операциям типа ">> 8 ...."

[osnwt]

Или как поступить в данном случае. Как обратится к байтам длинного числа не пребегая к операциям типа ">> 8 ...."

Кстати говоря, с большой долей вероятности при достаточном уровне оптимизации компилятор сам не будет использовать сдвиги, а просто возьмет нужный байт из регистра или из памяти. Во всяком случае, IAR так делает.

Вообще, очень полезно бывает смотреть на сгенерированный компилятором код, чтобы что-то там оптимизировать (если это хочется сделать). Пример:

Код

unsigned char CRC(...)
{
    int crc;
    ...
    return crc ? 1 : 0;    // 0 - все в порядке, не ноль - ошибка
}

Дает совершенно правильный, но не слишком оптимальный для AVR код (на IAR). Вычисление кода возврата по return компилируется в 10 байтов.

Можно улучшить ситуацию, записав вот так:

Код

    return (crc | (crc >> 8));    // 0 - все в порядке, не ноль - ошибка

При видимом усложнении кода получаем вместо 10-ти уже 6 байтов. Неплохо.

Но самое интересное будет, если переставить местами операнды и добавить лишние 0xff:

Код

    return ((crc >> 8) | (crc & 0xff));    // 0 - все в порядке, не ноль - ошибка

Это компилируется всего в 4 байта, несмотря на увеличение количества операций.

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

[defunct]

Код

    return ((crc >> 8) | (crc & 0xff));    // 0 - все в порядке, не ноль - ошибка

Это компилируется всего в 4 байта, несмотря на увеличение количества операций.

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

на ассемблере для этой задачи (0- все в порядке, не 0 - ошибка crc16) требуется всего одна команда or al, ah (2 байта), поэтому при необходимости получить оптимальный код, неплохо бы изучить ассемблер конкретного процессора.. Вопрос, лишь в том оправдается ли затраченное время (немалое) на получение оптимального кода для конкретного процессора?

[osnwt]

Код

    return ((crc >> 8) | (crc & 0xff));    // 0 - все в порядке, не ноль - ошибка

Это компилируется всего в 4 байта, несмотря на увеличение количества операций.

на ассемблере для этой задачи (0- все в порядке, не 0 - ошибка crc16) требуется всего одна команда or al, ah (2 байта), поэтому при необходимости получить оптимальный код, неплохо бы изучить ассемблер конкретного процессора.. Вопрос, лишь в том оправдается ли затраченное время (немалое) на получение оптимального кода для конкретного процессора?

Одна команда - это два байта. Вторые два байта - это, собственно, ret. Фрагмент листинга компилятора:

// 159
// 160 // returned 0 means CRC is OK
// 161 return ((crc >> 8) | (crc & 0xff));
OR R16, R17

Однозначно ассемблер надо знать, иначе смысла смотреть на генерируемый код нет никакого.

А насчет оправдания затрат - во первых, это надо сделать примерно раз и дальше использовать везде.

Во вторых, это дает результат, и не такой малый. Скажем, компилированная GCC ассемблерная часть USB драйвера от Objective Development получается на 166 байтов короче, чем она же, но скомпилированная IAR. А на написанном мной куске того же объема результат прямо противоположный, и при этом я не оптимизировал тот свой код вручную. Это - результат вполне определенной оптимизации исходника USB под GCC, о чем вполне определенно пишет автор в readme IAR порта (не уверен, появился ли тот порт на их сайте или еще нет, так как последняя версия лежит у меня, всё ход не дойдет ее дотестировать).

В третьих, всё подряд оптимизировать не имеет смысла. Но в ряде случаев это просто необходимо. Когда мой бут вылез за пределы 4-х кило на 200 байтов, мне пришлось приложить ряд усилий, чтобы вернуть его обратно. При этом ничем не было пожертвовано, и код не потерял читабельности. Правда, пришлось переписать часть кода Atmel, да и свой немного поправить. Зато всё осталось на C, и поддерживать его будет проще.

Я сам был поборником ассемблера, ибо в свое время общался больше чем с десятком-полутора разных вариантов. Но с некоторых пор мнение изменил. Проще поддерживать все же C код. А на ассемблер надо переносить только критически важные участки: ISR и т.п. Вот это реально будет экономить время на поддержке.

[osnwt]

Я вот тут подумал, чем надеяться на оптимизация компилятора не проще ли просто писать, то что требуется:

Код

return crc != 0

Увы, нет. Сравните с предыдущим листингом:

Код

//  160     // returned 0 means CRC is OK
//  161 //    return ((crc >> 8) | (crc & 0xff));
//  162     return crc != 0;
        OR    R16, R17
        BREQ    ??crcApplicationCheck_1
        LDI    R16, 1
        RJMP    ??crcApplicationCheck_2
??crcApplicationCheck_1:
        LDI    R16, 0
??crcApplicationCheck_2:

Логическая операция должна вернуть 0 или 1. А побитовая - что угодно, лишь бы не ноль.

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

ЗЫ. В приведенном примере я сам поражен: и это - максимальная оптимизация в IAR??? Ведь LDI R16, 0 - совершенно излишняя команда в данном случае.

Сообщение отредактировал osnwt - Mar 8 2006, 11:29

[defunct]

Увы, нет. Сравните с предыдущим листингом:

После того как написал пост - проверил, заметил, потому и удалил пост...

ЗЫ. В приведенном примере я сам поражен: и это - максимальная оптимизация в IAR??? Ведь LDI R16, 0 - совершенно излишняя команда в данном случае.

Да поразительно работает оптимизация..