[-=az=- 0]

Ну тогда вам ассемблер нужен. По моему опыту яр для стм8 плохенько умеет оптимизировать. Делал i2c ногодрыгом с разгоном (порядка 2 Мбит/м) - сделал на ассемблере. Отлично получилось. Могу пример предоставить.

 

С ногодрыгом очень интересно посмотреть вашу реализацию функций delay us()

а вот получить тип 64 пока красиво не получается, чтобы можно было без заморочек выполнять операции с ними | << >> &

 

[aiwa 0]

а вот получить тип 64 пока красиво не получается, чтобы можно было без заморочек выполнять операции с ними | << >> &

Если Вы считаете это красивым, то как пример

typedef unsigned char uchar; 
typedef unsigned int uint;  
typedef unsigned long ull; 


class t_ULL_64
{
 uchar Values[8];
 public:
 //----------
 t_ULL_64()
 {
   *this=0;
 }
 t_ULL_64(uint a)
 {
   *this=a;
 }
 t_ULL_64 operator = (ull B )
 {
   *((ull*)&Values[4])=0;
   *((ull*)&Values[0])=b;
 return *this;  
 }

 t_ULL_64 operator = (t_ULL_64 B )
 {
   *((ull*)&Values[4])=*((ull*)&b.Values[4]);
   *((ull*)&Values[0])=*((ull*)&b.Values[0]);
 return *this;  
 }

t_ULL_64 operator<<(uint B )
{
 if(b==0) return *this;
 if(b>64) {*this=0; return *this;}
 while(B )
 {
   // сдвижка на 1 бит    
      *((ull*)&Values[4])<<=1;
      if(Values[3]&0x80) Values[4]|=0x01;
      *((ull*)&Values[0])<<=1;

      b--;
 }   
 return *this;  
}
};


int main()
{

 t_ULL_64 i;
 i=((t_ULL_64)1)<<0x20; 

}

Изменено 25 декабря, 2015 пользователем IgorKossak

[-=az=- 0]

Без С++ class не собирается, как правильно это на С сделать?

Изменено 27 декабря, 2015 пользователем IgorKossak
бездумное цитирование

[aiwa 0]

Жестокий у Вас препод, если С++ не разрешает.

На С реализация только через структуры и функцию заменяющую "<<", потому что переопределение операторов С не поддерживает.

Поэтому у Вас, при условии на С и обязательно оставить "<<", есть два варианта:

1. Уговорить участников группы стандартизации С внести в стандарт желаемые изменения.

2. если оператор действительно работает для 64-бит как Вы это утверждаете, то попытаться использовать этот бонус, предоставленный IARом.

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

 

P.S. Чтобы Вы не теряли время на проверку работоспособности: скорее всего IAR действительно добросовестно производит сдвиг,

но начиная с момента когда сдвигаемая единица вылазит за 32 бита в 7-й байт, переменная всегда будет равна 0, а не (1<<0x20) и т.д.

Изменено 27 декабря, 2015 пользователем aiwa

[DogPawlowa 0]

но начиная с момента когда сдвигаемая единица вылазит за 32 бита в 7-й байт, переменная всегда будет равна 0, а не (1<<0x20) и т.д.

Я потерял нить, почему? Компилятор вдруг забыл тип переменной?

[-=az=- 0]

Ну тогда вам ассемблер нужен. По моему опыту яр для стм8 плохенько умеет оптимизировать. Делал i2c ногодрыгом с разгоном (порядка 2 Мбит/м) - сделал на ассемблере. Отлично получилось. Могу пример предоставить.

 

как вы реализовали функции delay ? на TIM4 ? а то с этим у stm8 тоже проблемы.........

[aiwa 0]

Я потерял нить, почему? Компилятор вдруг забыл тип переменной?

 

Потому что для STM8 IAR декларировал разрядность типа 'long long' в 32 бита в отличие например от их же AVR8, где она 64 бита.

Поэтому качестве оператора '<<' будет выступать ассемблерная подпрограмма производящая сдвижку только по 4-м байтам, т.е. 32 бита.

 

Картина похожая на ту, если к 'unsigned char' прибавлять число, большее 256 и результат вылазит за пределы байта,

только с тем отличием, что при сложении в переменная будет содержать кусок результата по модулю 256,

а при сдвиге механизм сдвижки обнуляет освободившийся хвост, и переменная будет = 0;

 

 

 

[DogPawlowa 0]

декларировал разрядность типа 'long long' в 32 бита

Да, проверил, 64-битные переменные и в stdint не работают, даже с #pragma language=extended

Значит, только ручками.