Работа с COM - портом

Пишу программу программатора для PIC контроллеров. Схема - простой JDM программатор.

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

Как создать таймер с микросекундной задержкой, который можно вызвать из основной программы?
Есть ли возможность создать небольшой модуль на АСМ-е, который бы формировал импульсы на выводах COM-порта в соответствии с алгоритмом программирования?

 

Кое-что удалось сделать. Доступ к порту получен с помощью giveio.sus

Код (Text):

1. ; Выставляем на выходе RTS COM1 значение bit
2. ; сбрасываются биты по адресам 3FB  - 9, 3FC - 1
3.  
4.   MOV word DX,3FBh
5.   in ax,dx
6.   and ax,0FDFFh
7.   out dx,ax
8.   inc DX
9.   in ax,dx
10.   and ax,0FFFDh
11.   out dx,ax

Но проблема в том, что времени на отработку такой команды уходит 12 микросекунд из под винды.
Видимо винда хоть и разрешила работать с портом напрямую, но всё равно все обращения идут через неё. Иначе просто нечем объяснить такое торможение.
Возможно ли запустить такой код из под ДОС, а после отработки вернуться в основную прогу?

 

Да, все обращения к портам виртуализируются. Напрямую - только в драйвере.

Что подразумевается под ДОСом ? Консольное окно под Виндовс ? Не поможет.

 

Partner через винды было бы если он DeviceIoControl для обмена с драйвером юзал а in и out напрямую (я с HDD так баловался одновременно с виндами и прога успевала отработать а если DevIoCtl тогда винды уже занимали драйв) этот драйвер IOPM настраивает как я понял так что никакой задержки при обращении к портам быть не может (система ни как не может перехватить работу с портами (ну разве что на хардварный брейкпоинт поставть) а может только разрешить или залочить), вы забываете что винда НЕ система реального времени и постоянно происходит переключение задач...
kaligraf
Во первых вы не перепутали мкс и мс? И во вторых повысьте приоритет своей проге до реал-тайма если не поможет пишите драйвер, на васме полно статей об этом, в третьих КОМ порт далеко не такой быстрый девайс и если речь идёт о мкс он может просто не успевает переключать свои режимы, да и последнее таймер с мкс задержкой в виндах сделать врядли возможно - в лучшем случае 1-2 миллсекунды.

З. Ы. А вообще по хорошему временные интервалы должен микроконтроллер формировать иначе колхоз это, а так грзанул в него прошивку и он сам программирует.

 

Согласен, напутал.

 

kaligraf попробйте порботать с LPT он пошустрее свои ноги переключает кстати...

 

Partner в современных камях кстати есть такая фича как виртуализация IO пространства, но в этом не разбирался - таких железок пока в руки не попало

 

Partner

Может плскажете где простенько написано, как превратить ассемблерные письмена в драйвер?
Exp10der

Да прога программатора и схема - всё заточено под COM порт.

 

kaligraf
я же сказал

...изза винды по крайней мере

 

Да здесь же на васме поищите. Но учтите, написание драйверов традиционно считается достаточно сложной задачей.

Кроме того, если речь идет действительно о микросекундах, а не о милисекундах, то боюсь ничего у вас не получится.

 

Exp10der

Я так понял, речь идет не о задержке одтельного обращения к порту, а о последовательности команд.
Если это не реал тайм, то переключение задач может вызывать задержку.

 

да я об этом в первом своём посте и написал

 

Попробую более подробно описать задачу, может удастся выяснить причину задержки, которой вроде бы быть не должно.
Вот описание процесса программирования:

Код (Text):

1. Описание процесса программирования микросхем.
2.  
3. Большинство современных микросхем содержит флэш-память,
4. которая программируется
5. Посредством протокола I2C или подобных протоколов.
6.  
7. Перезаписываемая память есть в PIC , AVR и других контроллерах,
8.  микросхемах памяти типа 24Cxx, и подобных им, различных картах
9.  памяти типа MMC и SD, обычных флэш USB картах, которые
10. подключаются к компьютеру через USB разъём.
11.  
12. Рассмотрим запись/чтение информации во флэш память микроконтроллера PIC16F628A.
13.  
14. Есть 2 линии DATA и CLOCK, по которым передаётся  информация.
15.  Линия CLOCK служит для подачи тактовых импульсов, а линия
16. DATA для передачи информации.
17.  
18. Чтобы передать в микроконтроллер 1 бит информации, необходимо
19. выставить 0 или 1(в зависимости от значения бита) на линии данных(DATA)
20. и создать спад напряжения (переход от 1 к 0) на линии тактирования(CLOCK).
21.  
22. Один бит  для контроллера – маловато. Он ждёт вдогонку ещё пять, чтобы
23. воспринять эту посылку из 6-ти бит как команду. Контроллеру очень
24. нравятся команды, а состоять они должны именно из 6-ти бит – такова
25. уж природа у PIC16.
26.  
27. Вот список и значение команд, которые PIC способен понять. Команд
28. не так уж и много – словарный запас у этого контроллера невелик,
29. но не надо думать, что он совсем глуп – бывают устройства и с меньшим
30. количеством команд
31.  
32. "LoadConfiguration"           000000    -   Загрузка конфигурации
33. "LoadDataForProgramMemory"  000010    -   Загрузка данных в память программ
34. "LoadDataForDataMemory" -   000011    -   Загрузка данных в память данных(EEPROM)
35. "IncrementAddress"             000110   -    Увеличение адреса PC МК
36. "ReadDataFromProgramMemory"  000100    -   Чтение данных из памяти программ
37. "ReadDataFromDataMemory"  000101   -   Чтение данных из памяти данных(EEPROM)
38. "BeginProgrammingOnlyCycle"  011000   -    Начать цикл программирования
39. "BulkEraseProgramMemory"    001001   -    Полное стирание памяти программ
40. "BulkEraseDataMemory"       001011   -    Полное стирание памяти данных(EEPROM)
41. "BeginEraseProgrammingCycle"  001000    -    Начать цикл программирования
42.  
43. Реагирует контроллер на эти команды по-разному. По-разному после выдачи
44. команды нужно и продолжать с ним разговор.
45.  
46. Для того чтобы начать полноценный процесс программирования необходимо ещё
47. подать напряжение 12 вольт на вывод MCLR контроллера, после этого подать на
48. него напряжение питания. Именно в такой последовательности подачи напряжений
49. есть определённый смысл. После подачи питания, если PIC сконфигурирован на
50.  работу от внутреннего RC генератора, он может начать выполнение собственной
51. программы, что при программировании вещь недопустимая, так как неизбежен
52. сбой.
53. Предварительная подача 12-ти вольт на MCLR позволяет избежать такого развития
54. событий.
55.  
56. При записи информации во флэш память программ МК после команды
57.  
58. "LoadDataForProgramMemory"      000010    -   Загрузка данных в память программ
59.  
60. необходимо отправить в контроллер сами данные - 16 бит,
61. которые выглядят так:
62.  
63.  “0xxxxxxxxxxxxxx0”.
64.  
65. Крестики в этом слове – это сами данные, а нули по краям отправляются как
66. обрамление – это стандарт для PIC16. Значащих битов в слове всего 14. У этой
67. серии контроллеров 14-ти битный формат представления команд.
68.  
69. После окончания передачи слова с данными PIC ждёт следующую команду.
70.  
71. Так как нашей целью является запись слова в память программ МК, следующей
72.  командой должна быть команда
73.  
74. "BeginEraseProgrammingCycle"      001000    -    Начать цикл программирования
75.  
76. Получив её, контроллер отключается от внешнего мира на 6 миллисекунд, которые
77.  нужны ему, чтобы завершить процесс записи.

У меня всё это реализовано с помощью обращения к выводам порта посредством API функций, встроенных в компилятор(всё в общем то работает нормально).
При оптимизации кода обнаружил, что время выставления одного сигнала на ножке порта около 10 микросекунд, хотя по идее должны быть доли микросекунды.
Вот и подумалось, что средствами асма можно улучшить этот показатель и уменьшить время записи одного килослова в МК секунды на 2.
При замене API на асм код оказалось, что время выставления/сброса бита на порту оказалось даже несколько больше, чем через API функции. 12 микросекунд вместо 8 микросекунд...?

 

kaligraf винды многозадачная ОСь ты когда лезешь к портам система может запросто переключить процесс и всё.. ты получаешь свою задержку, приоритет до реалтайма повысь, или пиши драйвер в котором на время работы с портами будут запрещены все мыслимые и не мыслимые прерывания, или работай с линухом там есть реалтаймовые дистры..

 

Exp10der
Тут нестолько винды виноваты, сколько сам комп для этого не преднозначен.
Наибольшая стандартная скорость COM. 115 000 бод в секунду откуда 1/115 000 имеем 8.6 мкс. Быстрее только нестондартные.

 

kaligraf
Чтобы уменьшить задержку используй FIFO и IRQ.

 

Pavia знаю но ТС не ч-з RS232 данные передаёт, а юзает ком как SPI впрочем что ком тормознутый об этом писал уже..
kaligraf покаж схему своего девайса

 

COM не тормазнутый просто если использовать класическую схему, то он ждет пока не произойдет чтение запись 8 бит с заданной скоростью. И скорость определяет именно частота накоторой он работает. У LPT частота побольше.
Но так никто не делает уже давно был придуман механизм буферезирования FIFO. И именно через него и надо делать. Не нужно жаловаться на то что порт тормазит когда вы просто неумеете с ним работать.

 

Exp10der
Схема и краткое описание здесь:
http://kaligraf.narod.ru/programmator/USB_programmator.html
Pavia

Трудный вопрос оказался - а казалось всё так просто

 

У LPT кстати тоже буфферизация FIFO есть и скорости нехилые можно выжать из него, но софтварный программатор не самое лучше решение имхо, я бы на контроллере сделал...