Захотелось чтобы препроцессор вычислял значение которое нужно запихнуть в UBRR...
решил сделать вот так:

В результате получил 176 а не 25

тогда попробовал вот так:


и получил желанные 25


Но ведь записи то одинаковые, а результаты разные... ???

дальше хочу определить ошибку вот таким вариантом

результат который хотелось видеть 1 (т.е. 0.1%) а получил 0

И хотелось бы выводить само значение ошибки, нашел директиву



но оно не позволяет выводить результат расчета
типа


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

Препроцессор не умеет считать, его функция - развернуть все определённые в программе #define-ы, включить все #include-ы и т.п. Собственно обсуждаемая константа формируется компилятором, и то, что полученное значение неверно, значит, что #include составлен неправильно.
В первом случае BAUND присваивался char-у или int-у, и компилятор привёл константы к соотв. типу, результат, конечно, получился не тот, что нужно. Правильно было бы указать тип констант явно:



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



Чтобы этого избежать, макросы обычно заключаются в скобки:

Ты забыл явно указать тип. А в С, если тип не указан, по умолчанию считается что тип int.
в результате эта запись: (Fosc/(_BAUND*16))-1
эквивалентна такой: (Fosc/(int)(_BAUND*16))-1
т.е. при умножении _BAUND*16 получается число 163600, что больше 65535, а затем оно обрезается до int, с получением 22528.
Чтобы этого избежать надо записть так:

Т.е. после 16 добавить букву L - указание, что умножать следует на (long)16 с получением результата типа long.
Аналогичто следует поступать, если хочешь получить рузльтат вещественного типа:

16.0 - число типа double и результат выражения будет типа double.
Если написать 16.0f - будет типа float.

Сообщение отредактировал starter48 - Nov 21 2005, 09:07

Спасибо, помогло.
#define _BAUND 9600
#define Fosc 4000000
#define BAUND ((Fosc/(_BAUND*16L)))-1 = 25
#define _UBRR (Fosc/(BAUND+1))/16L - 9615
#define BAUND_ERROR (((_UBRR*10000L) - (_BAUND*10000L))/_BAUND) = 15

Вот только не понятно почему 4000000L и 4000000 воспринимаются одинаково верно, или компилятор когда видит константу автоматом присваивает ей нужный тип ?
А как все таки с выводом на экран полученного значения, возможно ли ?

Вообще грамотнее использовать округление!
#define BAUND (unsigned)((Fosc/(_BAUND*16))-0.5)

А вот с выводом посчитанного значения проблема

Ясно. Спасибо всем откликнувшимся... ))

Да.

Хз. У меня нет идей

Не понял...
будет (unsigned)((4000000/(int)(9600*16))-0.5)
или (unsigned)(177-0.5)
или (unsigned)(176.5)
или просто 176
т.е. вычитание 0.5 здесь ничего не даст, т.к. все вычисления до этого целочисленные.

Может ты хотел предложить считать как вещественные числа?
вот так: #define BAUND ((unsigned)(Fosc/(_BAUND*16.0f))-1)
Можно, но осторожно, т.к. иногда при вычислении вещественных чисел иногда возникает погрешность, которая при обрезании дробной части даст ошибку на целую 1. Например вместо числа 10.0 может получится 9.999999999 - после обрезания будет 9, а не 10. Так что лучше именно целочисленную арифметику использовать.

нет именно -0.5 бывает надо округлять в другую сторону
например
для 14400 и 8 mhz
(unsigned)((8000000/(14400*16))-0.5) = 34

а если счиать в целых и вычитать 1 будет 33

8000000/(14400*16)-1=33.722222 и надо окурглять вверх


а 9.99999 получится если надо примерно 9.5 и в общем все равно куда округлять вверх или вниз.

Согласен, но тогда допиши .0f после 16, иначе -253 будет
Вот так: (unsigned)((8000000/(14400*16.0f))-0.5) = 34
Но как раз в таких случаях встаёт проблема с округлением о которой я говорил.
Например может вместо 10.5 в выражении (Fosc/(_BAUD*16.0f)) получиться 10.4999999 и, отняв 0.5, мы получим 9.9999999, что обрежется до 9


Неа, будет -253
Чтобы получить 33.72, как в математике, надо в вещественных числах всё считать:
#define BAUD ((unsigned)(8000000/(14400*16.0f)-1))
и тогда дествительно можно отнимать 0.5 вместо 1, чтобы повысить точность при округлении.


Это справедливо, если ты считаешь через long, но тогда 0.5 вычитать не имеет смысла, т.к. вычитаешь ты его от уже целого числа и вычитание 0.5 равносильно вычитанию 1.
Ведь выражение 8000000/(14400*16) - целочисленное.

Вот идея для округления в целочисленной записи:
#define BAUD ((Fosc-(_BAUD*8L))/(_BAUD*16L))

И завязывайте писать слово BAUD через N

Сообщение отредактировал starter48 - Nov 21 2005, 12:35

И все вроде хорошо только вот _BAUD_ERROR по умолчанию int и компилятор сообщает

Warning[Pe061]: integer operation result is out of range

если сделать попытку приведения типа


то вообще ругается
Error[Pe059]: function call is not allowed in a constant expression

Как быть ?

Я проверил эту конструкцию на Borland C. Нормально работает.
Похоже, препроцессор IAR сравнивать умеет только целые числа. (long) не поможет.
Считай в сотых долях процента, чтобы в диапазон целых чисел входило:


У меня тут предложение возникло...
А почему бы тебе не поставить кварц на 11.059MHz? Тогда стандартные скорости получишь без погрешности.
Только не говори, что 4000000 - частота внутр. RC генератора
У меня нестабильно работало, когда я пытался от RC тактировать контроллер с посл. портом, т.к. термостабильность низкая у RC. Т.е. при прогреве контроллера или изменении напряжения питания частота RC уходила.

Сообщение отредактировал starter48 - Nov 24 2005, 09:43

Конечно, я тоже не экономлю на кварцах ) Просто на C недавно перешел и перевожу свои библиотеки под IAR. Поэтому раз уж С то решил сделать типа универсального.
По поводу сравнений идея понятна, а что это IAR по поводу функции говорит ? Что у него на уме ?

И вот еще такой вопрос:
Захотел попробовать в качестве битов использовать битовое поле:

и вот вопрос:

Возможно ли обратиться к структуре чтобы разом установить несколько битов ?
Просто ведь у IAR обращение например к порту можно сделать:


Или при таких желаниях мне лучьше подойдут Битовые маски ?

// ????????????? ??????? ????? ??? ??? ???????
// ?????????? ??????? ??????, (?? ????? ?? ?????? ?????-??????)
#define SET_BITS(Reg, Bit) (Reg |= (Bit)) // ????????? ????? ? ?????
#define CLEAR_BITS(Reg, Bit) (Reg &= (~Bit)) // ????? ????? ? ?????
#define CHECK_BIT(Reg, Bit) (Reg & (Bit)) // ???????? ???? ? ?????

#define SET_BIT(Reg, Bit) Reg |= (1<<Bit) // ?????????? ???
#define CLEAR_BIT(Reg, Bit) Reg &= ~(1<<Bit) // ???????? ???
#define INVER_bit(Reg, Bit) Reg ^= (1<<Bit ) // ????????????? ???
#define GET_BIT(Reg, Bit) (Reg & (1<<Bit)) // ????????? ???

То же самое. Вообще, работать должно
Видать препроцессор у IAR не поддерживает явное указание типа.
Может у него опции есть какие-нибудь для включения совместимости.
Я не знаю. Почитай документацию в каталоге avr\doc.

Посмотри как PORT в .h задаётся.
там даже специально дан пример:

Здесь к переменной AVR можно обращаться как к char: AVR=111,
а можно через биты: AVR_Bit5=1