В аттаче проект для WinAVR. Я же пишу в CodeVision.
Как переделать - даже не знаю с чего начать.

Если не трудно, гляньте одним глазком и подскажите хоть что нибудь.

Хм,
там же все на асме....

Ну основной то файл на C.
Там интересно сделано - куча асмовых файлов+Сишный - компилируется в библиотеку libglcd.a

А далее тестовый файл написанный на чистом С, который может быть и запустился бы в CV - просто использует эту библиотеку, которая исключительно для WinAVR.

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

А вот комплятор видит.
Для начала я попытался включить некоторые хидеры:




Выдается куча ошибок. Например для строки
extern int strncasecmp_P(const char *, PGM_P, size_t) __ATTR_PURE__;

комплятор пишет - declaration syntax error

для строки
extern int strncmp_P(const char *, PGM_P, size_t) __ATTR_PURE__;

комплятор пишет function must be return a value

подскажите тогда, что ли как библиотеку собрать в codevision...

Вот это уже дело.
функции из avr_libc:
strncasecmp_P - сравнить строку с флешом с учетом регистра
strncmp_P - без учета регистра
меняйте на родные для CV не забывая об extern.

PS Что-то я в архиве этого не нашел - в каком они файле?

В файле glcd.h есть ссылка на io.h и pgmspace.h - стандарты WinAvr естественно их нет в архиве.

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


Если вам не трудно, попробуйте сами скомпилировать эту библиотеку. Нет, я не прошу Вас сделать работу для меня. Тем более, вы говорите что все так просто.

Иначе это будет долгий разговор "корифея" с "чайником", причем первый будет настоятельно рекомендовать читать мануал и все прочее.

Почему я это говорю? Да потому что я сделал, как вы сказали и вот что вышло:


Я подключил АСМ файл - не знаю правильно или нет, но через оболочку CodeVision подключаются исключительно ".c" файлы.

После этого компилятор выдает мне, что для вызова функции glcdLine недостаточно параметров. ЧТо за бред, эта прога прекрасно компилируется в WinAVR.

И САМОЕ ИНТЕРЕСНОЕ - компилятор пишет что у меня нет функции main ()

[quote] А насчет родных функций для CV - будьте любезны, подскажите, вам из вашей памяти извлечь наверное проще. [/quote]
Никогда серьезно не работал с CV, так посмотрел что к чему. В основном живу с gcc и IAR. Так, что придеться таки читать документацию.
io.h - описание битов портов
pgmspace.h - описание функций работы с флэшом [
quote] И САМОЕ ИНТЕРЕСНОЕ - компилятор пишет что у меня нет функции main () [/quote]
Значит проект сконфигурирован неправильно.
Тут ничем не могу помочь, это фичи самого CV.

Инклудить asm бессмысленно, т.к. этим Вы заставляете компилятор Си транслировать совершенно не сишный код.
Почти уверен, что main не находится как раз по этой причине.
Проект нуждается в оформлении по правилам CV (см. встроенный хелп и примеры в examples\).

хм... вот я о том и говорил. В противовес утверждениям, что нет ничего специфичного для CV в этой библиотеке. Будем разбираться.
Просто хотелось помощи людей, у которых это быстрее получилось бы.

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

Оставьте пустой main, вставьте в проект асм файлы и собирайте.
Ошбки можете запостить.


Кстати есть еще один прием достаточно быстрой переделки

glcd.h у меня включен.
Через него включаются пресловутые IO.h и pgmspace.h, вследстве чего выдаются те же ошибки, что указаны выше.

В общем сложности в структуре кода. Постепенно вчитыаясь в него я уже начинаю представлять всю его архитектуру. По-моему все-таки нужно отследить все что это код берет из стандартных библиотек и попытаться заменить на CV-функции.

Кстати, в glcd.h напротив каждой функции стоит extern. Это признак того, что заголовок написан для создания библиотеки, не так ли? Может быть в этом причина?

к вопросу о специфичности кода:

typedef uint16_t glcdColor_t; - это codeVision не понимает.

Только потому, что uint16_t сам получен в результате typedef'а. Которого в тексте и include'нных файлах нет.
Смысл простой - 16-разрядное беззнаковое число.

эээ... напрягаем ламерские мозги.... unsigned long?
Непонятно, зачем тогда этот typedef нужен?

Блин, надоело мне... Буду выдирать код по кускам и поэтапно проверять. Вопрос только в том стоит ли? А посему скажите мне, верны ли утверждения, что CodeVision генерит более громоздкий и глючный код по сравнению с WinAvr? И так ли это ужасно? Может лучше перейти на WinAVR?

ОФФТОП: как-то переделывал програмку из CV в WinAVR. для автоматизации написал скрипт на PERL, который делает некоторую рутиную работу. Если кому надо могу поделиться. Может кто-нибудь и до ума доведёт....

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

Начинаю ковырять.

Выяснил - вот это приводило к появлению ошибки "the program hs no void main() function"



Что это, чем чревато удаление этого и если чревато плохими последствиями, как это сделать в CodeVision?

P.S. этот код располагался в конце файла regs.inc

declaration syntax error.

Как вышеприведенное выражение должно писаться в Codevision?

Более или менее разобрался с заголовочником. А простите, как добавить асмовские файлы в проект? через интерфейс редактора можно добавить только сишные файлы.

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

Возможно проблема в битовых полях(попробуйте локализовать), включить их поддержку в CV.

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

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

Наш общий друг [banned]123.

потому что CV не позволяет делать безымянных полей.

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

Попробуйте так:

#asm
.include "file.asm"
#endasm

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

Итак, поехали ковырять.

Вот что у меня получилось с первой функцией:

файл s65.c - главный



Фрагмент файла glcd.h



Запускаем - на программу С компилятор не ругается, однако пишет ошибку при ассемблировании - выдает ассмблированную программу:



В строке 1257 : syntax error unexpect "("


файлы glcd.inc и regs.inc находятся в приаттаченом в анчале темы архиве.

Что делать и кто виноват?

Так разобрался я как включать асмы в проект, но при компляции ругается на invalid directive .section, .global

Это тоже специфика WinAVR?

Похоже не понимает hi8()/lo8(). Замените на стандартный ассемблер AVR или напишите эти макросы.

Да это специфично.

оххх...

Наивный вопрос, но нельзя ли как-нить в WinAVR скомпилить унифицированную библиотеку, чтобы можно было использовать с CodeVision?

Нет. CV работает только с исходниками.

Перейти что ли на WinAVR? Блин, CodeVision удобен, больше похож на среду разработки, чем WinAVR. Вот как например в WinAVR узнать размер получившейся программы? КОнсоль выдает Total 17900, хотя это не соответствует истине - файл заливается в Mega16 без проблем.

Существуют ли библиотеки для WinAVR для работы с 1-Wire ?

Существуют ли библиотеки для WinAVR для работы с 1-Wire ?

Да на avrfreaks.org

Перейти что ли на WinAVR? Блин, CodeVision удобен, больше похож на среду разработки, чем WinAVR.

Озадачен примерно темже, только в плане что выбрать для работы на С++ с AVR, правда я выбираю в большей степени между IAR и avr-gcc.


Как мне показалось IAR распространен больше, но WinAvr будет легче изучать (ибо ни gcc ни make для меня не новость, только с avrlibc разобраться)

Я конечно понимаю, что переползать с одного комплятора на другой муторно и требует усидчивости, но все же - бесят элементарные проблемы. Как было просто в CodeVision



в WinAVR вроде тоже есть такая библиотека, и функция так же обзывается, но


Выдает ошибку undefined refefrence delay_us

Ну что с этим делать.

P.S. У кого-нить есть рабочий пример для датчика DS18B20 для WinAVR

Ну что с этим делать.

Загляните в delay.h, там все описано. Эта фунция обьявлена как:
void
_delay_us(double __us)

Она кстати и в документации на avr-libc также упоминаются.

Код это .text, .data .bss .noinit - данные, .eeprom надеюсь понятно.

По умолчанию WinAVR включает Programmers Notepad (под которым кстати пишу и под ARM и под РС и HTML).Нет особых сложностей прицепить его под любой другой редактор кода, хоть под Visual Studio. Главное, чтобы редактор позволял подключать внешние программы и захватывал их выход.

В документе avr-libc-user-manual очень подробно рассмотрены все функции, а также фокусы с секциями, встраиванием ассемблера etc.

После компиляции в окне Programmer Notepad
text data bss dec hex filename
9412 0 405 9817 2659 dvdavtomat.elf

По моему все ясно

Для задержек изучите нижеуказанный хидер /include/util/delay.h
заодно посмотрите как ассемблер юзать в WinAVR

А библиотек столько написано что вы приятно удивитесь скачав и распаковав
http://hubbard.engr.scu.edu/embedded/avr/avrlib

#ifndef _UTIL_DELAY_H_
#define _UTIL_DELAY_H_ 1

#include <inttypes.h>

/** \defgroup util_delay <util/delay.h>: Busy-wait delay loops
\code
#define F_CPU 1000000UL // 1 MHz
//#define F_CPU 14.7456E6
#include <util/delay.h>
\endcode

\note As an alternative method, it is possible to pass the
F_CPU macro down to the compiler from the Makefile.
Obviously, in that case, no \c \#define statement should be
used.

The functions in this header file implement simple delay loops
that perform a busy-waiting. They are typically used to
facilitate short delays in the program execution. They are
implemented as count-down loops with a well-known CPU cycle
count per loop iteration. As such, no other processing can
occur simultaneously. It should be kept in mind that the
functions described here do not disable interrupts.

In general, for long delays, the use of hardware timers is
much preferrable, as they free the CPU, and allow for
concurrent processing of other events while the timer is
running. However, in particular for very short delays, the
overhead of setting up a hardware timer is too much compared
to the overall delay time.

Two inline functions are provided for the actual delay algorithms.

Two wrapper functions allow the specification of microsecond, and
millisecond delays directly, using the application-supplied macro
F_CPU as the CPU clock frequency (in Hertz). These functions
operate on double typed arguments, however when optimization is
turned on, the entire floating-point calculation will be done at
compile-time.

\note When using _delay_us() and _delay_ms(), the expressions
passed as arguments to these functions shall be compile-time
constants, otherwise the floating-point calculations to setup the
loops will be done at run-time, thereby drastically increasing
both the resulting code size, as well as the time required to
setup the loops.
*/

#if !defined(__DOXYGEN__)
static inline void _delay_loop_1(uint8_t __count) __attribute__((always_inline));
static inline void _delay_loop_2(uint16_t __count) __attribute__((always_inline));
static inline void _delay_us(double __us) __attribute__((always_inline));
static inline void _delay_ms(double __ms) __attribute__((always_inline));
#endif

/** \ingroup util_delay

Delay loop using an 8-bit counter \c __count, so up to 256
iterations are possible. (The value 256 would have to be passed
as 0.) The loop executes three CPU cycles per iteration, not
including the overhead the compiler needs to setup the counter
register.

Thus, at a CPU speed of 1 MHz, delays of up to 768 microseconds
can be achieved.
*/
void
_delay_loop_1(uint8_t __count)
{
__asm__ volatile (
"1: dec %0" "\n\t"
"brne 1b"
: "=r" (__count)
: "0" (__count)
);
}

/** \ingroup util_delay

Delay loop using a 16-bit counter \c __count, so up to 65536
iterations are possible. (The value 65536 would have to be
passed as 0.) The loop executes four CPU cycles per iteration,
not including the overhead the compiler requires to setup the
counter register pair.

Thus, at a CPU speed of 1 MHz, delays of up to about 262.1
milliseconds can be achieved.
*/
void
_delay_loop_2(uint16_t __count)
{
__asm__ volatile (
"1: sbiw %0,1" "\n\t"
"brne 1b"
: "=w" (__count)
: "0" (__count)
);
}

#ifndef F_CPU
/* prevent compiler error by supplying a default */
# warning "F_CPU not defined for <util/delay.h>"
# define F_CPU 1000000UL
#endif

/**
\ingroup util_delay

Perform a delay of \c __us microseconds, using _delay_loop_1().

The macro F_CPU is supposed to be defined to a
constant defining the CPU clock frequency (in Hertz).

The maximal possible delay is 768 us / F_CPU in MHz.
*/
void
_delay_us(double __us)
{
uint8_t __ticks;
double __tmp = ((F_CPU) / 3e6) * __us;
if (__tmp < 1.0)
__ticks = 1;
else if (__tmp > 255)
__ticks = 0; /* i.e. 256 */
else
__ticks = (uint8_t)__tmp;
_delay_loop_1(__ticks);
}


/**
\ingroup util_delay

Perform a delay of \c __ms milliseconds, using _delay_loop_2().

The macro F_CPU is supposed to be defined to a
constant defining the CPU clock frequency (in Hertz).

The maximal possible delay is 262.14 ms / F_CPU in MHz.
*/
void
_delay_ms(double __ms)
{
uint16_t __ticks;
double __tmp = ((F_CPU) / 4e3) * __ms;
if (__tmp < 1.0)
__ticks = 1;
else if (__tmp > 65535)
__ticks = 0; /* i.e. 65536 */
else
__ticks = (uint16_t)__tmp;
_delay_loop_2(__ticks);
}

#endif /* _UTIL_DELAY_H_ */