Один хрен возня будет, когда 16x16 при помощи A и B будет компайлер считать.Сообщение от fk0
Да и с делением засада.
Один хрен возня будет, когда 16x16 при помощи A и B будет компайлер считать.
Да и с делением засада.
Совершенно верно. Абсолютно бесполезные команды для решения моей задачи (в процедуре деления команда div вообще не используется ни разу). Этот момент я хорошо понял когда посмотрел на сайте www.8052.com набор арифметических процедур для контроллера. Данные команды подходят только для 8-ми битных операций. Даташитсы я ессно от начала и до конца изучил.
Да, и ещё - я все-таки не понял, подходит ли метод Брезенхема для решения моей задачи или он работает только для заранее известного кол-ва вычислений? Или я останавливаюсь на своей реализации классической формулы для такого типа задачи (благо она уже работает)?
Последний раз редактировалось PheeL; 03.03.2005 в 17:10.
Ну да - деление в топку, но вот таки умножение полезно. 16x16->32 можно делать столбиком из четырёх 8x8->16 и большой возни =)
Брезенхем применим, когда у тебя шаг по одной координате всегда 1, и надо посчитать вторую. У тебя видимо это не так, так что брезенхем не подойдёт.Да, и ещё - я все-таки не понял, подходит ли метод Брезенхема для решения моей задачи или он работает только для заранее известного кол-ва вычислений? Или я останавливаюсь на своей реализации классической формулы для такого типа задачи (благо она уже работает)?
Кстати, ты на сях пишешь? Работать и успешно выполнять свою задачу код успевает? Ну так и забей =) Лучше на forever 1к-интру накодь =)
Да, значит все-таки Брезенхем не подойдет. А жаль, он бы здорово убыстрил вычисления.
Сам импульсный табличный генератор я пишу на голом асме. Процедура небольшая да и низкоуровневое программирование мне ближе. Также будет написана "связка" в виде редактора табличек с последующим заливанием их в память контроллера. Эту часть я реализую на Delphi, так как мне нужна лёгкость и гибкость в программировании именно интерфейсной части.
Там вся байда по скорости в том, что моя процедура будет входить в состав многозадачного ядра (мой препод по диплому мощный персонаж - переделал ядро QNX под I8052) и будет высокий приоритет по исполнению, но отнюдь не наивысший. Поэтому кол-во итераций будет прямо пропорционально кол-ву вызовов моей процедуры этим ядром. В этом моменте и отпадает метод Брезенхема. Но поскольку контроллер работает на частоте ~20 МГц (на самом деле используется ADuC842, поэтому и такие частоты ядра), и команды исполняются за 1 такт, то вроде бы скорости хватает. Реальной железки у меня нет, но на эмуляторе по выходным значениям напряжения от времени с DAC вроде бы все в порядке (я даже граф. анализатор на Дельфях для этого накатал).
Да какой тут Кипр... На кафедре разборки между преподами и я как раз нечаянно меж двух огней попадаю.ну как успехи, давно не слышно
или уже полностью ld de,Кипр?
Насчет процедуры. Твой метод верный и он будет работать. Но! При больших задержках между вызовами процедуры интерполяции, соответственно возрастает и кол-во вызовов процедуры рисующей отрезок по методу Брезенхема. Ну понятно, да? Чтобы высчитать следующую точку ему надо построить отрезок до неё и если расстояние между точками в следствие задержки возрастает, то пропорционально возрастает и кол-во вызовов процедуры и также пропорционально снижается скорость. И может наступить такой момент, что из-за возросшего числа вызовов вся прелесть метода по части отсутствия умножения и деления уйдет в нуль, а то и в минус. Моя же реализация классической формулы будет тормозить всегда одинаково в любой вычисляемой точке
Sinclair ZX Spectrum 128k (Toastrack) + ZX Spectrum +3 + DivMMC EnJOY
Commodore 64c + 1541 Ultimate II
Commodore Amiga 1200 + 8Mb Fast + CF 8Gb + GOTEK
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием