Цитата(MKdemiurg @ Feb 5 2014, 20:31)
Может кто видал такую?
Перевод в строку в виде десятичного числа 8 байт long long
Время обработки не лимитировано...Между запросами по 2-3 секунды ожидания.
Так вроде нет ничего сложного в переводе:
Код
//---------------------------------------------------
void my_ltoa(signed long long int data, unsigned char *pRes)
{
unsigned char buff[22];
unsigned long long int int_path, fract_path, val;
unsigned int sign_flag=0;
if(data<0)
{
int_path = (unsigned long long int) (-data);
sign_flag = 1;
}
else
{
int_path = (unsigned long long int) data;
}
//max длина long long int 19 символов - 9223372036854775807
for(unsigned int i=0; i<19; i++)
{
val=int_path;
int_path = val/10;
fract_path = val%10;
buff[i] = fract_path+'0';
buff[i+1] = '\0';
if(int_path == 0) break;
}
//копируем результат наоборот
val = strlen((const char*) buff);
//проверяем знак флага
if(sign_flag)
{
buff[val] = '-';
buff[val+1] = '\0';
val++;
}
for(unsigned int i=0, j=val-1; i<val; i++, j--)
{
pRes[j] = buff[i];
}
pRes[val] = '\0';
}
//---------------------------------------------------
Буффер под хранение результата должен быть не меньше длины max long long int.
Делалась для cortex-m3 с расчётом на встроенный аппаратный делитель. Для AVR процедура будет не оптимальна из-за отсутствия в нём аппаратного делителя.
P.S. Но судя по листингу long long int делить на cortex-m3 также неудобно. Для обычного long int IAR использует ассемблерную команду UDIV R0,R2,R3,
а для long long int сам листинг в 5 раз больше, так ещё и библиотечная __aeabi_uldivmod вызывается. Если разработчики IAR применили там аппаратный делитель, то круто, иначе - огромная потеря производительности. На 8мибитнике дела будут обстоять ещё хуже...
