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

[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]

И всётаки вопрос: Если применяешь с компиллер, то оптимизация описанным путём, - это же явная привязка к конкретному компилятору. И даже, вероятней всего, к его конкретной версии.

вопроса-то вроде и нет, Вы сами все верно сказали.

Еще дополню относительно третьего вопроса..

Третий. Насколько сложно программу написанную на IAR "заставить" компилится на GCC. Может у кого есть спец. ".h" файлы.

Зависит от привязки к компилятору. Чем больше текста написано на plain C, без использования прагм, ключевых слов характерных для конкретного компилятора, тем проще будет "заставить" код компилироваться другим компилятором. Хотя с ключевыми словами просто - можно создать хедер с соответствеющими макросами и все (пример osnwt).. А прагм не так уж много.. ;>
Существенное отличие между IAR и GCC на мой взгляд заключается наверное в том, что GCC основан на стандарте C99 и позволяет определять переменные только в начале функций, т.о. выражения вида for(int i; i=0;....}, прекрасно воспринимаемые компилятором IAR, в gcc компилироваться не будут. Соответственно лучше сразу ими не пользоваться и в IAR...

Мне для впихивания навороченного USB крипто-загрузчика в 4 килобайта бут-блока меги32 пришлось соптимизировать примерно 200 лишних байтов. Ясное дело, что не только таким способом - многое пришлось переписать по другому. Но результат был достигнут.

Я бы "навороченный" криптозагрузчик писал бы полностью на ассемблере, если бы мне потребовался действительно небольшой объем. А так (с упованием на оптимизацию компилятора C) могу только сказать "овчинка выделки не стоит". Появится новая версия компилятора и код, вполне возможно, уже не втиснется в 4k.

Сообщение отредактировал defunct - Mar 11 2006, 23:58

[osnwt]

Я бы "навороченный" криптозагрузчик писал бы полностью на ассемблере, если бы мне потребовался действительно небольшой объем. А так (с упованием на оптимизацию компилятора C) могу только сказать "овчинка выделки не стоит". Появится новая версия компилятора и код, вполне возможно, уже не втиснется в 4k.

Дело в том, что 2 килобайта - это USB драйвер, еще килобайт - это дешифровщик. Тем самым мы уже вылезли за пределы 2Кбайт. Остальное - это протокольная часть со всякими штуками.

Естественно, что можно все написать на асме, если писать с нуля. Но переписывать 3/4 кода просто из спортивного интереса я не могу себе позволить, поскольку это не моя работа, а всего лишь хобби. Я предпочту уделить это время написанию собственно того, что можно загружать этим загрузчиком, к примеру.

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

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

[defunct]

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

Вот именно, и это как раз тот случай когда применение ассемблера действительно оправдано!

Дело в том, что 2 килобайта - это USB драйвер
....
В другой ситуации будет лучше все писать с нуля и на асме, но не в этой. Естественно, это всё IMHO.

Возможно, а возможно было бы целесообразно применить код Igor Cesko о котором Вы упоминали...

[osnwt]

Кроме того, бут - это такая штука, которая едва ли будет часто меняться или развиваться.

Вот именно, и это как раз тот случай когда применение ассемблера действительно оправдано!

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

Дело в том, что 2 килобайта - это USB драйвер
....
В другой ситуации будет лучше все писать с нуля и на асме, но не в этой. Естественно, это всё IMHO.

Возможно, а возможно было бы целесообразно применить код Igor Cesko о котором Вы упоминали...

Цитата с сайта автора avr-usb (выделено мною):

Advantages over other Firmware-Only Implementations

A similar driver for the AVR series of microcontrollers is available from Igor Češko. Our USB driver has the following advantages over Igor's driver:

* All customizable code written in ANSI-C and thus easier to maintain.
* Modular concept: easier to integrate into existing designs.
* Slightly smaller code size in spite of high level language modules.
* Faster: All encoding/decoding (USB requires NRZI coding and bit stuffing) is done in real-time, not in the main loop after storing away the raw data stream.
* AVR-USB comes with a free shared Vendor- / Product-ID pair.
* The level of standards conformance is documented (description of limitations and potential problems).
* Available for free with Open Source license. (See the file License.txt in the distribution.)

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

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

Не вижу ничего странного. При различных методах адресации кода и данных нужно помнить разные типы указателей или использовать нечто вроде generic типа указателя в IAR, который крайне неэффективен. Доступ к данным тоже осуществляется совершенно по разному. Вроде, мелочь - но, видимо, существенная.