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

[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

[defunct]

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

Тогда у меня к Вам, как к автору кода, есть пара вопросов:
1. почему нельзя было просто вызвать IPrec() в обработчике прерывания?
2. из-за чего весь сыр-бор с сохранением стеков?

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

Спасибо, что поправили меня.
Вопрос: а если вызываемая в обработчике функция определена в том же самом модуле, в котором определен и обработчик прерывания, потребуется ли определять ее как встраиваемую или компилятор и так будет "знать" какие регистры ей используются, и сгенерит код для сохранения только их?

Сообщение отредактировал defunct - Feb 9 2006, 03:56

[Rst7]

Тогда у меня к Вам, как к автору кода, есть пара вопросов:
1. почему нельзя было просто вызвать IPrec() в обработчике прерывания?
2. из-за чего весь сыр-бор с сохранением стеков?

1. Возможно вы заметили, что IPreciver есть не конечный автомат, а обычный код, скажем так, поток (нить, thread) выполнения. Посему есть ответ и на вопрос 2 - весь сыр-бор - это организация двух (точнее трех) задач - main, IPreciver, IPtransmitter. Из них IPxxx - это задачи, которые передают управление в основную задачу только тогда, когда им надо ждать символ из входного потока (IPreciver) или ждать окончания передачи символа в выходной поток (IPtransmiter). И получают они управление по соответствующим прерываниям. Почему так - объясняю. Представте, что вам надо получить в буфер 20 байт. Как вы пишете это без использования прерываний:

char s[20];
char *p=s;
char i=20;
do
{
*p++=rxchar();
}while(--i);

Просто и понятно.

Теперь представте это как автомат. Необходимо хранить указатели, состояние, и т.д. Каждое прерывание их необходимо загрузить, потом выгрузить. Весьма накладно, когда обработчик большой и сложный - как например TCP/IP. Поэтому, в том проекте, который мы обсуждаем, сделана такая многозадачка с использованием функций исключительно библиотеки. Т.е. что получается с сохранением контекста:

1. Обработчик прерываний штатно сохраняет все scratch-регистры, т.к. есть вызов функции в обработчике (функция setjmp и longjmp). Также обработчик сохраняет SREG и если AVR большой, всяческие RAMPZ. Точнее сохраняет компилятор.
2. Функция setjmp сохраняет все localstore-регистры,оба указателя стека SP и Y, а также PC. В результате имеем полностью сохраненный контекст задачи в двух местах - часть регистров лежит в CSTACK задачи, остальное - в jmp_buf.

Назад - аналогично. Прелести метода в том, что ни одной асмовской комманды нет. Единственное колдовство - инициализация задачи прямо в jmp_buf. При анализе суммарного кода почти нет потерь на на переключение, если сравнивать чисто с асм-вариантом - буквально 1 лишний CALL.

[defunct]

Теперь представте это как автомат. Необходимо хранить указатели, состояние, и т.д. Каждое прерывание их необходимо загрузить, потом выгрузить. Весьма накладно, когда обработчик большой и сложный - как например TCP/IP. Поэтому, в том проекте, который мы обсуждаем, сделана такая многозадачка с использованием функций исключительно библиотеки. Т.е. что получается с сохранением контекста:

Хорошо, имеется некая структура данных (массив и индексы), по сути в этой структуре хранится весь контекст приемника. В чем заключается сложность обращения к этой структуре из обработчика прерывания? Ни в чем. Непонятно для чего может потребоваться еще что-то сохранять, когда просто попав в обработчик прерывания можно работать непосредственно с этой структурой данных (не затрагивая других структур данных).

2. Функция setjmp сохраняет все localstore-регистры,оба указателя стека SP и Y, а также PC. В результате имеем полностью сохраненный контекст задачи в двух местах - часть регистров лежит в CSTACK задачи, остальное - в jmp_buf.

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

Код

   for(;;)
   {
      task1();
      task2();
      task3();
    }

[Rst7]

Хорошо, имеется некая структура данных (массив и индексы), по сути в этой структуре хранится весь контекст приемника. В чем заключается сложность обращения к этой структуре из обработчика прерывания? Ни в чем. Непонятно для чего может потребоваться еще что-то сохранять, когда просто попав в обработчик прерывания можно работать непосредственно с этой структурой данных (не затрагивая других структур данных).

Можно, однако это раздувает код, т.к. все локальные переменные превращаются в статические. А само сохранение регистров (и последующее восстановление) остается и никуда не девается. А так убиваем двух зайцев - код уменьшаем, улучшаем читаемость этого всего дела, т.к. весь алгоритм лежит последовательно, а не по кусочкам, выполнить то, выполнть это...

Код

   for(;;)
   {
      task1();
      task2();
      task3();
    }

Аналогично - все превращается в автомат и совершенно не читабельно. Тем более, что эта программа (это стек TCP/IP) как понимаете не самоцель, а лишь маленькая часть большой программы, а вы предлагаете весь софт писать вот так?

ЗЫ Наверное, надо другую тему организовать под названием "Какие у сапожников взгляды на искусство"

[defunct]

Можно, однако это раздувает код, т.к. все локальные переменные превращаются в статические. А само сохранение регистров (и последующее восстановление) остается и никуда не девается. А так убиваем двух зайцев - код уменьшаем, улучшаем читаемость этого всего дела, т.к. весь алгоритм лежит последовательно, а не по кусочкам, выполнить то, выполнть это...

Не все переменные превращаются в статические. Статическими будут только переменные, которые необходимо хранить между входами в обработчик прерывания. По расходу памяти если сравнить с Вашим способом - "те же консервы, вид сбоку"

Насчет улучшения читаемости - для кого? Углядеть алгоритм работы многозадачной системы - всегда сложнее чем однозадачной.

Аналогично - все превращается в автомат и совершенно не читабельно. Тем более, что эта программа (это стек TCP/IP) как понимаете не самоцель, а лишь маленькая часть большой программы, а вы предлагаете весь софт писать вот так?

я не предлагаю так писать софт, я его так пишу.

for{;;}
{
DispatchLalala();
KernelDispatchblablabla();
DoSomethingElse();
sleep();
}

ЗЫ Наверное, надо другую тему организовать под названием "Какие у сапожников взгляды на искусство"