Господа, помогите тормозящему.
Надо получить библиотеку для RS-485 (это я так упражняюсь).
Все бы ничего, но есть ножка, переключающая прием/передачу, и расположение ее не определено.
Ясно, что #define здесь не годится.
Объявление

Тоже неприемлемо, потому что мы пытаемся получить инструкции sbi/cbi
Значит, надо объявить extern inline функцию.
Как правильно это сделать - не могу найти.
Помогите,пожалуйста.

Очень полезные макросы. Чуть-чуть поправить #ifdef и будут работать с avr-gcc.

А вот тут они же, но уже под avr-gcc, спасибо сказать ReAlу

Спасибо, но я имел ввиду чуть другое.
Хотел отвязаться от порядка компиляции модулей, из-за чего не хочется пользоваться макросом.
Так, чтобы линкер подставил то ,что надо, а именно Flow_Port |=(1<<Flow_Pin); .

Например:


Может, это вообще невозможно?

А макросы великолепные.

Сообщение отредактировал _Pasha - Feb 11 2008, 13:14

Подумал и понял свою ошибку.
Это ошибка анализа задачи. Т.е. не там выстраивал иерархию абстракций.
Извините за тему.
Тема закрыта.

Так вам не нужно это выносить в функцию. Вместо описания отдельных Flow_Port и Flow_Pin сделайте А чтобы сделать что-то "без пролога/эпилога и вообще вызова подпрограммы", функцию можно определить как static inline __attribute__((__always_inline__)).

Так ведь для библиотеки это не пойдёт?

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

Неужели нет какого-нибудь механизма? Было бы очень соблазнительно иметь возможность передавать порты в качестве параметров при инициализации библиотечных модулей...
Вот из faq:


То есть, если в библиотеке держать ссылку на порт (на два порта) и маску, то всё получится?
Типа:


Немного накладно конечно...

Сообщение отредактировал AHTOXA - Feb 12 2008, 17:39

C ссылкой может и получится, но ссылка - это C++, а не С. В вашем примере в ОЗУ выделяется место, в котором хранится указатель на порт и компилятор при всей своей способности к оптимизации обязан считать из него адрес собственно порта. К тому же объявив указатель статическим, вы исключили возможность присвоить ему что-либо за пределами этого (библиотечного) файла. К сожалению, в С нет типа данных "константный адрес", который тут бы подошел (правда это можно обойти через приведения типа). Но главное - компилятор не имееет (насколько я знаю) механизма подстановки аргументов команд sbi, cbi на этапе линковки, только на этапе компиляции. Поэтому любая попытка передать адрес порта "извне" приведет к генерации команд lds/in, andi(ori), sts/out вместо sbi, cbi. Может быть можно как-то через инлайн-ассемблер это сделать, но я пока не представляю как и не имею (пока) необходимости разбираться. Я предпочитаю библиотеки в виде исходных текстов - так их легче хранить в репозитории

Так это-то как раз хорошо:-) Чтобы я (или не я) не мог лазать в этот порт иначе как через функции библиотеки.



Да, получается накладнее. Зачастую это приемлемо. Зато — библиотека! Откомпилил, протестил и забыл:-)



Да я тоже в исходных текстах храню. Но эта куча дефайнов... Да и код лишний линкуется. (Я читал топик про способ этого избежать, но пока не пробовал.)

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

Дык, я же написал:

Это будет в main(), библиотеку перекомпилировать не надо:-)

Все, теперь понял. Я изначально зациклился на получении в библиотеке команд sbi, cbi, ну в крайнем случае lds/sts, но никак не на указателях в явном виде. Как-то это расточительно - всю свою сознательную жизнь кристалл будет вынимать из одной и той же ячейки одно и то же значение указателя только из-за того, что у программиста не сложилось вшить этот адрес непосредственно в команду. И ведь понимаю, что это из серии asm vs C, но ничего с собой поделать не могу

Это ещё что! Говорят, некоторые на C++ программируют! :-)
А если чуть серьёзнее, то я не думаю, что для меги 128 и не очень быстрой периферии (типа ЖКИ) это даст сколько-нибудь заметный оверхед.
Надо будет попробовать, вдруг понравится:-)

Дык с этим аттрибутом Winavr все равно умудряется иногда сформировать подпрограмму. Когда подключал работу с eeprom, заметил это, хотя чтение вызывалось всего один раз. Поэтому не стал разбираться, а задал вопрос.

Повторюсь, что вопрос вызван ошибкой в проектировании и явился следствием долгого писания на асме. ИМХО, правильная портируемая библиотека должна на своем нижнем уровне, работающем с железом, как раз и иметь все варианты через #ifdef..#endif, следовательно, подлежать самой частой перекомпиляции. На примере с RS-485 на данном уровне достаточно экспортировать функции
настройки / работы с буферами, на котором сидят прерывания / единую кодировку ошибок.

И все это с выбором номера порта.

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