[uquote="КРАМ",url="/forum/viewtopic.php?p=4154360#p4154360"]Эпический олигофрен... 
[/uquote]
Визги необразованного УОшника под ником КРАМ продолжаются.
[uquote="КРАМ",url="/forum/viewtopic.php?p=4154360#p4154360"]Для вывода флоата в строку, его вначале нужно преобразовать из нормализованной формы в отдельно мантиссу и порядок ФОРМАТА ОТОБРАЖЕНИЯ. Затем преобразовать в двоично-десятичный формат вывода (десятичная дробь или экспоненциальная). И лишь потом выводить в стринг, прежде преобразовав в ASCII.[/uquote]
Садись два, клоун. Никаких стрингов не существует в языке C как типов.
Строка это тип char, цифры с плавающей точкой это тип float.
При преобразование любой целой циферки (int,long,char, long64,int64, unsigned char) на платформе с архитектурой x86/x64 необходимо число раздробить на части к примеру 2022
Дробим на DEC 2 2 0 2
Потом DEC 2 складываем c HEX 0x30 получаем символ "2" в ASCII 0x32 символы загоняем в буфер char Text[] рекурсией
DEC 0 + HEX 0x30 = 0x30 ASCII "0"
....
И так далее
Потом реверс байтов в буфере Text[]
Плюс "стоповый" ноль 0x00
Получаем массив байтов в формате ASCII где пользовательский GUI схавает.
А теперь дурень, расскажи как ты разложишь число в float = 2021.0123
Тут тебе ишаку приходят на помощь вышеуказанные опкоды которые разделяют число, вручную с помощью математики такое не выполнить. Как раскладывать число с плавающей точкой быстро и на аппаратном уровне я озадачился в 2010 году, написав быстрые алгоритмы, которые по сей день успешно работают.
При использование FPU потери и погрешности неизбежны
[uquote="КРАМ",url="/forum/viewtopic.php?p=4154360#p4154360"]1. В каком месте здесь вообще FPU?[/uquote]
Ровно в том месте, где ты влез в тему с плавающей точкой на архитектуре x86 x64 не понимая от слова совсем.
Запомни дурень, на архитектуре x86 x64 типы float обрабатывает модуль FPU и ничего более.
[uquote="КРАМ",url="/forum/viewtopic.php?p=4154360#p4154360"]При расчете в симуляторе, преобразования в формат вывода делаются ОДИН РАЗ ЗА ВЕСЬ ЦИКЛ РАСЧЕТА СХЕМЫ. И делают это посредством[/uquote]
Учитывая, что симулятор исполняется на архитектуре x86 x64, при расчете цифр с плавающей точкой брехня неизбежна и еще больше брехни при преобразование и округлении. Так что отдыхай.
[uquote="КРАМ",url="/forum/viewtopic.php?p=4154360#p4154360"]Никто в АСМе эту убогую хрень не считает.
Обтекай, придурок.[/uquote]
Ишак, на ASM вовсю пишут, где требуется скорость и качество кода. К примеру операционная система Windows при её создание = написании используют Asm вставки или целые листинги с asm, не считая драйверов, где asm в порядке вещей.
Это твоим говнокодом на 256 ... 65535 байт умещающийся в EEPROM никто не пользуется в твоем говноподелии содранным из Reference Design, как и никто твой говнокод не видел, на GNU так же нет твоих sorce code. Поэтому обсыхай ушлепок. Ничего ты не смог вновь доказать, плаваешь в теме, как сокетами и запросами GET, POST, HEAD летом. Жаль нет программистов на архитектуре x86 x64, они тебя бы также обсмеяли из засрали просто в край. Пинаю тебя виртуально с превеликим удовольствием.
И да что бы спорить на тему FPU нужно иметь знания и опыт, слепо искать в гугле околотемы с FPU не получится.
[uquote="КРАМ",url="/forum/viewtopic.php?p=4154360#p4154360"]Какая разница какой интерфейс?[/uquote]
Большая разница дурень, потому что на 1000% ты в своем говноподелии подключил дисплей к аппаратной шине I2C
где дергая по адресам аппаратный порт I2C просто читаешь и пишешь и собственно все.
Ты видимо плохо воспринимаешь информацию, процитирую заново:
[uquote="Transformer-V",url="/forum/viewtopic.php?p=4154245#p4154245"]Не фантазируй, так как передача данных через USB-мост-GPIO-LCD
. Выдыхай.[/uquote]
GPIO дурень, GPIO! Реализация шины 8 bit DATA + 4 bit DATA программная, с применением масок, логики битовых операций. И все это исполняется на очень большой скорости без SLEEP - задержек благодаря предпроцессорной подготовки и отправки в FIFO.
А теперь сравни со своей ахинеей
[uquote="КРАМ",url="/forum/viewtopic.php?p=4154360#p4154360"]Работать с параллельным всегда проще, патамушта он не требует поддержания протокола последовательной шины в виде экнолиджей и прочих шняг.[/uquote]
Программная реализация I2C сильно проще чем 8 bit DATA + 4 bit DATA, I2C можно реализовать за 15 минут на компьютере c OS Windows используя порт RS232 и его служебные выводы DTR, CTS, RTS в связке с HC244
[uquote="КРАМ",url="/forum/viewtopic.php?p=4154360#p4154360"]Выводить в монохромный STN с частотой 60 Гц будет только клинический идиот, который не понимает, что этот тип матрицы просто физически не способен регенерировать изображение с такой скоростью.
Обтекай...
[/uquote]
Может клинический идиот, может, могу даже видео запилить c модулем DOT-LCD ST7920 и вновь осадить тебя ниже некуда.
И так что там с задачей, которую я тебе задавал, где ты бился об заклад,
что сможешь её решить? Уже засчитывать слив? Или высрешь очередной перл?
P.S.
Представляю как было весело FAKIR-у дискутируя с КРАМ об изобретении, одни сопли и скабрезности КРАМ, которые никакого отношения к теме не имеют.
[/uquote]Визги необразованного УОшника под ником КРАМ продолжаются.
[uquote="КРАМ",url="/forum/viewtopic.php?p=4154360#p4154360"]Для вывода флоата в строку, его вначале нужно преобразовать из нормализованной формы в отдельно мантиссу и порядок ФОРМАТА ОТОБРАЖЕНИЯ. Затем преобразовать в двоично-десятичный формат вывода (десятичная дробь или экспоненциальная). И лишь потом выводить в стринг, прежде преобразовав в ASCII.[/uquote]
Садись два, клоун. Никаких стрингов не существует в языке C как типов.
Строка это тип char, цифры с плавающей точкой это тип float.
При преобразование любой целой циферки (int,long,char, long64,int64, unsigned char) на платформе с архитектурой x86/x64 необходимо число раздробить на части к примеру 2022
Дробим на DEC 2 2 0 2
Потом DEC 2 складываем c HEX 0x30 получаем символ "2" в ASCII 0x32 символы загоняем в буфер char Text[] рекурсией
DEC 0 + HEX 0x30 = 0x30 ASCII "0"
....
И так далее
Потом реверс байтов в буфере Text[]
Плюс "стоповый" ноль 0x00
Получаем массив байтов в формате ASCII где пользовательский GUI схавает.
А теперь дурень, расскажи как ты разложишь число в float = 2021.0123
Тут тебе ишаку приходят на помощь вышеуказанные опкоды которые разделяют число, вручную с помощью математики такое не выполнить. Как раскладывать число с плавающей точкой быстро и на аппаратном уровне я озадачился в 2010 году, написав быстрые алгоритмы, которые по сей день успешно работают.
При использование FPU потери и погрешности неизбежны
[uquote="КРАМ",url="/forum/viewtopic.php?p=4154360#p4154360"]1. В каком месте здесь вообще FPU?[/uquote]
Ровно в том месте, где ты влез в тему с плавающей точкой на архитектуре x86 x64 не понимая от слова совсем.
Запомни дурень, на архитектуре x86 x64 типы float обрабатывает модуль FPU и ничего более.
[uquote="КРАМ",url="/forum/viewtopic.php?p=4154360#p4154360"]При расчете в симуляторе, преобразования в формат вывода делаются ОДИН РАЗ ЗА ВЕСЬ ЦИКЛ РАСЧЕТА СХЕМЫ. И делают это посредством[/uquote]
Учитывая, что симулятор исполняется на архитектуре x86 x64, при расчете цифр с плавающей точкой брехня неизбежна и еще больше брехни при преобразование и округлении. Так что отдыхай.
[uquote="КРАМ",url="/forum/viewtopic.php?p=4154360#p4154360"]Никто в АСМе эту убогую хрень не считает.
Обтекай, придурок.[/uquote]
Ишак, на ASM вовсю пишут, где требуется скорость и качество кода. К примеру операционная система Windows при её создание = написании используют Asm вставки или целые листинги с asm, не считая драйверов, где asm в порядке вещей.
Это твоим говнокодом на 256 ... 65535 байт умещающийся в EEPROM никто не пользуется в твоем говноподелии содранным из Reference Design, как и никто твой говнокод не видел, на GNU так же нет твоих sorce code. Поэтому обсыхай ушлепок. Ничего ты не смог вновь доказать, плаваешь в теме, как сокетами и запросами GET, POST, HEAD летом. Жаль нет программистов на архитектуре x86 x64, они тебя бы также обсмеяли из засрали просто в край. Пинаю тебя виртуально с превеликим удовольствием.
И да что бы спорить на тему FPU нужно иметь знания и опыт, слепо искать в гугле околотемы с FPU не получится.
[uquote="КРАМ",url="/forum/viewtopic.php?p=4154360#p4154360"]Какая разница какой интерфейс?[/uquote]
Большая разница дурень, потому что на 1000% ты в своем говноподелии подключил дисплей к аппаратной шине I2C
где дергая по адресам аппаратный порт I2C просто читаешь и пишешь и собственно все.
Ты видимо плохо воспринимаешь информацию, процитирую заново:
[uquote="Transformer-V",url="/forum/viewtopic.php?p=4154245#p4154245"]Не фантазируй, так как передача данных через USB-мост-GPIO-LCD
. Выдыхай.[/uquote]
GPIO дурень, GPIO! Реализация шины 8 bit DATA + 4 bit DATA программная, с применением масок, логики битовых операций. И все это исполняется на очень большой скорости без SLEEP - задержек благодаря предпроцессорной подготовки и отправки в FIFO.
А теперь сравни со своей ахинеей
[uquote="КРАМ",url="/forum/viewtopic.php?p=4154360#p4154360"]Работать с параллельным всегда проще, патамушта он не требует поддержания протокола последовательной шины в виде экнолиджей и прочих шняг.[/uquote]
Программная реализация I2C сильно проще чем 8 bit DATA + 4 bit DATA, I2C можно реализовать за 15 минут на компьютере c OS Windows используя порт RS232 и его служебные выводы DTR, CTS, RTS в связке с HC244
[uquote="КРАМ",url="/forum/viewtopic.php?p=4154360#p4154360"]Выводить в монохромный STN с частотой 60 Гц будет только клинический идиот, который не понимает, что этот тип матрицы просто физически не способен регенерировать изображение с такой скоростью.
Обтекай...
[/uquote]Может клинический идиот, может, могу даже видео запилить c модулем DOT-LCD ST7920 и вновь осадить тебя ниже некуда.
И так что там с задачей, которую я тебе задавал, где ты бился об заклад,
Спойлер
[uquote="КРАМ",url="/forum/viewtopic.php?p=4154266#p4154266"]И что должно следовать из этой частоты? Ты полагаешь, что я не в состоянии ее посчитать?[/uquote] P.S.
Представляю как было весело FAKIR-у дискутируя с КРАМ об изобретении, одни сопли и скабрезности КРАМ, которые никакого отношения к теме не имеют.
Последний раз редактировалось Transformer-V Ср янв 05, 2022 19:07:51, всего редактировалось 1 раз.
