Tommyknocker

Ну хорошо, в смысле не очень хорошо, но тем не менее...Как в таком случае мне нужно записать эти данные ? Как мы помним PCI девайс не обладает своим контролером DMA. Данные по каманде просто формируются на шине, по 8 16-битных пакетов. Программный I/O здесь ведь кажется тоже не подойдет, поскольку адресовать нечего.

Имеется PCI устройство. Собственным DMA адаптером не обладает. Однако у данного устройства существует режим, когда оно по команде начинает "выдавать" на шину PCI посылки данных (по восемь 16-ти битных слов... всего около 100 МБ). Вопрос: как я могу записать эти данные? Могу ли я применить в данном случае DMA материнской платы ? Если да, то просьба вкратце изложить последователность моих действий. Должен ли я своему устройству сообщать что-то кроме собственно команды "выдавай очередной пакет"? Должен ли я сообщать ему адрес куда копировать или это возмет на себя контроллер DMA материнской платы? Должно ли мое устройство (сделано на FPGA) генерировать прерывание после окончания каждой посылки?

Here is the situation: I have a PCI board I use as a platform to train in NT driver development. The board uses 3 resources: 1. IRQ; 2. Memory (Mem0 - contains 32-bit control registers ) 3. Memory (Mem1 - contains data registers ) All the resources are processed smoothly in my StartDevice function (below are debug messages from my StartDevice ): MC431PCI - PNP Request (IRP_MN_START_DEVICE) MC431PCI - Resources: type CmResourceTypeMemory start 03FDFFF00 length 100 type CmResourceTypeMemory start 03FE00000 length 200000 type CmResourceTypeInterrupt level 16, vector 16, affinity FFFFFFFF MC431PCI - Translated Resources: type CmResourceTypeMemory start 03FDFFF00 length 100 type CmResourceTypeMemory start 03FE00000 length 200000 type CmResourceTypeInterrupt level 8, vector 194, affinity 3 MC431PCI - Found control memory block. Physical base address - 3FDFFF00, length - 255 MC431PCI - Found data memory block. Physical base address - 3FE00000, length - 2097152 MC431PCI - Got Interrupt Resource 2 MC431PCI - Mapping control memory ... MC431PCI - Control memory virtual base address F7CD9F00 MC431PCI - Mapping data memory ... MC431PCI - Data memory virtual base address A9687000 After that I probe my control registers (which called RUK#) using READ_REGISTER_ULONG(): MC431PCI Reading ruk0: 0h MC431PCI Reading ruk1: 0h MC431PCI Reading ruk2: 0h MC431PCI Reading ruk3: 1h MC431PCI Reading ruk4: 0h MC431PCI Reading ruk5: 0h MC431PCI Reading ruk6: 0h MC431PCI Reading ruk7: 0h MC431PCI Reading ruk9: 12000012h MC431PCI Reading ruk10: 0h MC431PCI Reading ruk11: 0h MC431PCI Reading ruk12: 0h MC431PCI Reading ruk13: 0h As we can see they are all read ok. Bit 15 of RUK2 controls onboard LED. So just to make sure everything's ok I set bit 15 high, writing 0x8000 to RUK2 and my LED goes bright red. MC431PCI Reading ruk2: 0x8000h. After that I leave my HandleStartDevice routine feeling absolutely confident my board is ready to accept control codes and actually execute them. Device manager shows the board just the way i described it in the inf file and resources pane shows the resources settings correct. I connect to my device via CreateFile and then use DeviceIoControl to send the control code to turn off the LED (remember it's still on). The code which I believed should be written was: WRITE_REGISTER_ULONG((PULONG) (pdx->membase0 + p->RUK), p->buffer);, where p is a pointer to my PARAMS structure that arrived with the IRP. It simply contains address and data; Here is what my DispatchControl says to me: .... MC431PCI - DATA TO BE WRITTEN: 0h MC431PCI - ADDR TO BE WRITTEN TO: 8h MC431PCI - WRITING 0h TO RUK2 .... MC431PCI - SEE WHAT'S IN RUK2: FFFFFFFFh ..... Well as we can guess the LED is still on and I end up being unable to write nor can i read from my device. So the question is why once I leave HandleStartDevice routine I lose contact with the PCI board. I can no longer read or write. I even tried to address my register directly avoiding HAL : first writing into RUK2 still hoping to turn off that LED: *((PULONG)(pdx->membase0+RUK2)) = 0x00; and then reading from it *((PULONG) (pdx->membase0+RUK2)). The result is still FFFFFFFFh . I of course can turn it off while still in HandleStartDevice. Any idea where to look? What happens once HandleStartDevice returns?

да, про утилиту build.bat я знаю и ее скачал, но еще не пробовал. Утилита Волтера Они подкупает тем, что в секунды можно сделать весь скелет драйвера и затем заполнять его своим кодом. Вообщем это удобно и работает под VC 6.0, а build.bat кажется под 7-ую студию заточена, а это нужно перенастраивать машину, что хотелось бы избежать.

Кто-нибудь пользовался утилитой WDMWIZ, которую написал Walter Oney для VC++. Проблема в том, что когда я пытаюсь делать сборку драйвера, мне возвращается такая ошибка: fatal error C1189: #error : Compiler version not supported by Windows DDK Error executing cl.exe. Понятно что происходит: запускается компилятор не DDK, а компилятор, который входит в VC++. Но вот как заставить чтобы сборка шла с компилятором DKK я пока не могу понять. Вроде настроил все как по документации и переменные окружения и все прочее.

Кто-нибудь пользовался утилитой WDMWIZ, которую написал Walter Oney для VC++. Проблема в том, что когда я пытаюсь делать сборку драйвера, мне возвращается такая ошибка: fatal error C1189: #error : Compiler version not supported by Windows DDK Error executing cl.exe. Понятно что происходит: запускается компилятор не DDK, а компилятор, который входит в VC++. Но вот как заставить чтобы сборка шла с компилятором DKK я пока не могу понять. Вроде настроил все как по документации и переменные окружения и все прочее.

Так случислось, что мне удалось найти по твоей ссылке этот файл. если еще актуально могу выложить.

Морион в самом деле наша фирма. Делают хорошие генераторы. Какие у Вас требовапния по климатике и габаритам ? Вообще с такими нестабильностями это скорее всего буду генераторы с термостабилизацией, а это девайасы приличных размеров. Вы строите канал спутниковой связи ? Если так, то чтобы не выдумывать ничего, то лучше заглянуть в стандарт по данному напрвлению. Во вторых можно прочитать соответсвующий раздел у Спилкера (Цифровая спутниковая связь) о влиянии фазовых шумов на работу ФАПЧ, а следовательно что происходит с вероятностью правильной демодуляции сообщения. К примеру на некторые спутниковые системы записано (диапазон ~1.6ГГц): ... " Спектральная плотность фазовых шумов немодулированной несущей должна быть такова, что ФАПЧ, имеющая одностороннюю шумовую полосу 10 Гц, обеспечивает точность слежения за фазой несущей частоты не хуже 0,1 радиан (среднеквадратическое значение). " .... Вообщем-то те стабильности, которые ВЫ называете для канала передачи данных будут достаточными в том случае, если просто несущая модулируется только сообщением без расширения спектра (нет какой-либоб кодовой последовательности, по которой нужно было бы синхронизоваться, то есть делать накопление). В этом случае система получается безпоисковая и вообщем-то можно будет обойдись в рамках кварцевых генераторов. Пока такие предварительные соображения.

Спасибо большое за помощь. Я забыл сказать, что к компьютеру это устройтсво подключаться не будет, а финский logging system как раз под PC заточен :smile3046: Если и будет общаться с писюком, то через ГПРС. И то вряд ли. Я собираюсь пока микроконтроллером отправлять СМСки через сименсовский телефон. Протокол проще реализовать :) (чем TCP через IP через GPRS) А если юзать чипсет то BGA - это слишком неприятный для меня вариант :huh: В любом случае спасибо. Вы меня больше утвердили в мысли, что совсем универсальных готовых решений не бывает, делать всё придётся самому. Теперь ищу готовые модули. Ижевский радиозавод молчит. Шифруются. :ninja: <{POST_SNAPBACK}> ну а какой бюджет у Вас на плату приемника ? Скорее всего никакой ижевск Вам и не ответит. В россии вообще 4 фирмы кто реально разрабатывает и выпускает приемники GPS/ГЛОНАСС: РНИИ КП, РИРВ, МКБ КОМПАС и НАВИС. Так что по ним и работайте.

Был бы признателен. Цена имеет значение. И доставабельность без особых усилий. Точность - хватит 20 - 30 метров, на счёт динамики - не представляю. Желательно, чтобы быстро включался. И аккумулятор автомобильный не садил за сутки. :) Требуется всё упаковать (вместе с моим устройством) в небольшую коробочку 100x150 мм. Вот, наверное, и все требования... <{POST_SNAPBACK}> вот финская фирма, которая делает приемники на чипсете uNav http://www.fastrax.fi/ вот data sheet на сам чипсет 04_05_10__uN8130_ES5_Advance_DS.pdf , которые кстати тоже делают фины а вот data sheet на logging data logging system, которая делается компанией fastrax. (http://www.fastrax.fi/) Autonomous_Data_Logging_System.pdf что касается доставаемости, то не сложно просто написать email в fastrax. Писать именно туда, а не в uNav, потомучто они, то есть fastrax, делают уже готовые GPS платки на базе чипсетов от uNav и соответствующий софт. Стоит это дорого не будет. Я общался с этим фастррэксом - отзывчивые ребята вообщем. Сам прибор по точности вас устроит, по времени включения тоже. Вообщем неплохой бытовой GPS прибор. Кстати uNav очень тесно работает с NOKIA, чтобы прорваться в сотовую телефонию в рамках "Mobile Location Services".

Было бы идеально иметь программируемый мною чип с интегрированным приёмником и внешним интерфейсом уже вшитыми... Такое я уже отчаялся найти :unsure: поэтому и ищу уже что-нить на отдельном чипе, только готовое. Скорее всего придётся юзать готовый модуль, общаться с ним через RS232 по протоколу NMEA... писать программу для микроконтроллера я точно заколебусь... <{POST_SNAPBACK}> Ну что значит отчаялся ? Не спеши пока отчаиваться. Какие вообще требования по точности и по динамике ? Если скромные, то рассмотрите систему на кристалле от uNav. http://www.unav-micro.com/ Могу скинуть по ним более подробные Data Sheets

По-видимому самое эффективное в данном случае это использовать анализатор шины PCI (Bus analyzer). Я еще не использовал, но присматриваюсь. Если вдруг контроллер не заработает, то нужно же как то выяснять что происходит. http://www.smartelec.ru/res/pci.shtml

Попытайтесь выяснить нет ли возможности договорится с разработчиком приемника, чтобы он Вам "выделил часть" процессора. ТО есть поставил бы вам компилятор и свои библиотеки. Понятно, что исходники всего софта он Вам не даст, да он Вам и не нужен. Нужно только "подоткнуться" в части внешнего интерфейса и работы с флэшкой, которая кстати должна быть подходящего размера для хранения Вашей траектории. А вообще-то есть приемники, в которых все это уже сделано, в смысле возможность делать data logging, а потом скидывать ее по запросу, поэтому может просто поискать сответствующий приемник ?

:) Пожалуй не буду Вас удерживать я выполню Вашу просьбу и можете считать себя в самом деле уволенным. Тем не менее, дабы все таки в самом деле "нашу молодежь" , к которой я в силу объективных причин также отношусь, то есть нас, молодежь, не сбивали с толку с провалами знаний в некоторых областях "старики" (которые еще к тому же пытаются их компенисровать обращаясь к дяде гуглу и не стесняются этого), болезненно реагирующие на вообщем-то вещи, которые требуют соверешенно серьезного подхода, а не необоснованных эмоций я пожалуй продолжу. Так вот, пусть тема хоть и возникла давно и пусть автор потерялся, но с тезисом "любительское сообщение" совершенно нельзя согласиться. Не возникают подобные задачи в умах любителей. Почему "любитель" может озаботиться тем, что какой-то злоумышленник задумает именно ему, любителю, ставить помеху, блокирующую работу его GPS приемника ? У нас у всех есть телефоны мобильные, вообщем-то мы ими пользуемся да пользуемся, ну... то есть любители вообщем-то сотовой телефонии и врядли многие из нас думают о том, что как же обнаружить потенциального постановщика помех, препятствующему вести бесперебойный разговор с нашими родственниками или друзьями. Мне представляется такой вывод: если Вы этим проффессионально не занимаетесь, то вряли Вы будете проводить исследования в этой области. Поэтому фраза Old Nick, сказанная выше "А может автор первого поста предварительно интересовался глубиной проблемы, чтобы сообразить какую пачку специалистов нанять" по-моему где-то очень близка к происходящему. Другое дело, зачем он зупустил это в форум ? В форуме такие поиски врядли стоит вести. Теперь по технике: Не самый вообщем-то хороший приемник СРНС имеет чувствительность приемного тракта ~-135 ДБВт. Уровень сигнала(помехи) согласно постановки задачи в точке приема -120 ДБВт. Обычный GPS приемник утратит работоспособность при таких условиях. Уровень сигнала СРНС в точке приема на поверхности Земли составялет -160 ДБВт. Налицо стоит задача обеспечения работоспособности аппаратуры СРНС при отношении суммарного уровня помех к сигналу по крайней мере в 40 Дб.

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