#include <dos.h>
#include <conio.h>
void tm_delay(int ticks) {
_asm {
push si
mov si, ticks
mov ah, 0
int 1ah
mov bx, dx
add bx, si
delay_loop:
int 1ah
cmp dx, bx
jne delay_loop
pop si
}
}
Создание задержки <= 1мкс
В программе (BC++B6.0, Windows NT) потребывалось создавать задержку не превосходящую 1 мкс. Нашел функцию 86h прерывания BIOS INT 1Ah, предназначенную для этого.
Но в asm-вставке вызов прерывания не проходит. Можно ли обойти проблему, связанную с вызовом прерывания и если да, то как?
Или есть другие способы создания такой задержки?
Но в asm-вставке вызов прерывания не проходит. Можно ли обойти проблему, связанную с вызовом прерывания и если да, то как?
Или есть другие способы создания такой задержки?
А ты уверен что не работает эта задержка? Попробуй увеличить ее к примеру раз в 100 ^_^
Вообще задержку в 1 мкс мона сделать при помощи функции sleep
Поищи ее реализацию, либо поставь опцию компилятора выдать тебе ассемблерный код ее и глянь как реализована она если нужно меньше 1 мкс.
Вообще задержку в 1 мкс мона сделать при помощи функции sleep
Поищи ее реализацию, либо поставь опцию компилятора выдать тебе ассемблерный код ее и глянь как реализована она если нужно меньше 1 мкс.
Микросекунда, эта штука которая на 3 порядка меньше милисекунды, ИМХО в виндах программно не генериться.
Функция Sleep работает с миллисекундами (10^-3 сек.), а не с микросекундами (10^-6 сек.), но даже она не генерит "честных" задержек, т.к. задержка не системная, а потока программы.
Сделать программно задержку меньше 1 микросекунды (несколько наносекунд) в винде не реально. Да и микросекундную задержку тоже.
Кстати, а для чего такие маленькие задержки понадобились? Для какой то коммуникации?
Функция Sleep работает с миллисекундами (10^-3 сек.), а не с микросекундами (10^-6 сек.), но даже она не генерит "честных" задержек, т.к. задержка не системная, а потока программы.
Сделать программно задержку меньше 1 микросекунды (несколько наносекунд) в винде не реально. Да и микросекундную задержку тоже.
Кстати, а для чего такие маленькие задержки понадобились? Для какой то коммуникации?
Да, такие маленькие задержки нужны для коммуникации.
Есть функция на ассемблере, которая делает задержку на заданное число тиков таймера. Эта задержка большая по сравнению с 1 мкс:
1 / 18.2 с = 55мс. Но в той функции тоже используются прерывания в asm-вставке:
Можно ли ее как-нибудь адаптировать для использования в BCB?
Есть функция на ассемблере, которая делает задержку на заданное число тиков таймера. Эта задержка большая по сравнению с 1 мкс:
1 / 18.2 с = 55мс. Но в той функции тоже используются прерывания в asm-вставке:
Код:
Можно ли ее как-нибудь адаптировать для использования в BCB?
ИМХО, при коммуникации, такими задержками манипулируют соответствующие устройства сопряжения, а не операционка с запущенной программой.
Можно немного конкретики, что за устройство, какой интерфейс?
Можно немного конкретики, что за устройство, какой интерфейс?
Цитата:
Можно немного конкретики, что за устройство, какой интерфейс?
Контроллер(в спец. датчике с которого надо очень быстро снимать показания) с i2c-интерфейсом через спец. адаптер соединен с параллельным портом. На определенных контактах порта для соблюдения протокола трбуется удерживать заданный уровень(1 или 0) сигнала не менее X мкс. Но более X мкс тоже нельзя удерживать(этого уже требует специфика задачи). Эти X - разные, но все очень маленькие(все они есть в описании i2c-интерфейса): по 4, по 5 мкс.
Адаптер(устройство сопряжения) очень простой и никак задержками манипулировать не может. Поэтому это возлагается на программу.
Я сам работал со схожим интерфейсом 1-wire. Задержки возлагаются не на программу, а на контроллер паралельного порта.
Вы переключаете скоростной режим Com порта и шлете пакеты с нужным Вам распределением задержек.
К примеру, Com порт переведен в режим 9600 бод. Значит за 1 секунду он передает 9600 бит. Отсюда вычисляем, что на один бит уходит примерно 0,0001секунда. Т.е. 10 мкс. Соответственно отсылая пакет 0101, мы получаем 10микросекундную задержку между отправкой единичек.
При этом увеличивая скорость com порта, мы можем генерить еще более точные задержки.
При этом тайминги непосредственно между отсылаемыми пакетами не так критичны и могут составлять секунды. Т.е. комманды можно отсылать хоть вручную.
Вы переключаете скоростной режим Com порта и шлете пакеты с нужным Вам распределением задержек.
К примеру, Com порт переведен в режим 9600 бод. Значит за 1 секунду он передает 9600 бит. Отсюда вычисляем, что на один бит уходит примерно 0,0001секунда. Т.е. 10 мкс. Соответственно отсылая пакет 0101, мы получаем 10микросекундную задержку между отправкой единичек.
При этом увеличивая скорость com порта, мы можем генерить еще более точные задержки.
При этом тайминги непосредственно между отсылаемыми пакетами не так критичны и могут составлять секунды. Т.е. комманды можно отсылать хоть вручную.
Цитата:
Задержки возлагаются не на программу, а на контроллер паралельного порта.
Параллельный порт работает в режиме SPP, со скорость присущей этому режиму(я читал, что при полной загрузке процессора удавалось разгонять порт до 100 - 150 Кбайт/с).
Поэтому задержки в программе нужны хотя бы для того, чтобы то, что записано в регистры порта успевало выплюнуться раньше, чем содержание регистров обновиться. Непосредственно в регистры пишет моя программа.
Извиняюсь... Недосмотрел, что речь про паралельный... Честно говоря не в курсе как он там работает. Хотя подозреваю, что основы не особо отличаются от последовательного...
А что, буфер приема и буфер передачи и порта один и тот же?
Т.е. грубо говоря, Вам нужно удостовериться, что времени выполнения программы хватит для забивания регистра?
Неужели в I2C протоколе такие маленькие задержки между командами? А иначе, что мешает Вам заранее подготовить нужный пакет и поместить его в буфер для отправки?
А что, буфер приема и буфер передачи и порта один и тот же?
Т.е. грубо говоря, Вам нужно удостовериться, что времени выполнения программы хватит для забивания регистра?
Неужели в I2C протоколе такие маленькие задержки между командами? А иначе, что мешает Вам заранее подготовить нужный пакет и поместить его в буфер для отправки?
Делал задержку в мкс, используя тактовую частоту процессора.
Код:
void Sleep_mks(double time)
{
unsigned clock0 = 0;
unsigned clock = 0;
extern int FcpuMHz; //частота процессора в МГц
__asm rdtsc; //получаем текущий такт процессора (в eax)
__asm mov [clock0], eax; //переписываем eax в clock0
do
{
__asm rdtsc; //получаем текущий такт процессора (в eax)
__asm sub eax, [clock0]; //eax = eax - clock0
__asm mov [clock], eax; //переписываем eax в clock
}
while (clock < (FcpuMHz * time));
}
{
unsigned clock0 = 0;
unsigned clock = 0;
extern int FcpuMHz; //частота процессора в МГц
__asm rdtsc; //получаем текущий такт процессора (в eax)
__asm mov [clock0], eax; //переписываем eax в clock0
do
{
__asm rdtsc; //получаем текущий такт процессора (в eax)
__asm sub eax, [clock0]; //eax = eax - clock0
__asm mov [clock], eax; //переписываем eax в clock
}
while (clock < (FcpuMHz * time));
}
Можно с помощью ассемберных pause либо rep nop на нужное число тактов процессора. Защитить от оптимизаций компилятора с помощью volatile, а процессор сериализовать с помощью, например, cpuid. Инфы навалом в сети.