Поясните по написанию драйверов

Думаю, что это можно реализовать, только нигде таких проектов не видел. Зато вот с FPGA полно.

эт не просто хардкорище, это ебический вынос мозга на полгода как минимум, даже для опытного профессионала. да и PCI уж сдох давно, вместо него уже PCIe всюду навешан.
новичку за глаза хватит какого-нить тягомотного SPI с ленивой пересылкой битиков, без запарок с тактовыми частотами и тонкостей арбитража на шине.

А вот на арме запилить обычную писиайку

Запитить можно, только работать не будет. «Замучаешься пыль глотать» дергая ножками на частоте 33МГц. Да и не у всякого арма есть достаточно GPIO.

А вот на плисе можно. Сейчас почти всё можно собрать из блоков мошевозя, с минимумом HDL. Можно даже DMA запилить.

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

«Замучаешься пыль глотать» дергая ножками на частоте 33МГц

Бери пожирней чип, где FSMC есть. Фигачь через DMA и будет тебе щассье.

Но для начинающего конечно лучше работающую железку

Тады можно взять какой-нибудь древний CAN-контроллер и попытаться его модуль с kernel2.x переписать на kernel4.x

Бери пожирней чип, где FSMC есть. Фигачь через DMA и будет тебе щассье.

К сожалению, с FSMC щассья не видать. Потому что пришлось бы как-то сопрягать 16-ти разрядную асинхронную шину с 32-х разрядной синхронной. Да еще заставить мастера работать слейвом. Без плисы тут снова не обойтись.

это всё теория. поделки студентов, которые «запилили PCI» на каком-нить FPGA - это чисто их упражнение в теории. на практике стандарты соблюдаются нестрого и чтобы девайс заработал хотя бы с основными мэйнстримовыми производителями материнок, придётся не один месяц попотеть с осциллом, анализируя частоты, профили сигналов, пытаясь понять, почему на одной мамке это работает, а на другой - нет, и так далее. да даже сделать сам разъём без необходимости допиливания надфилем иногда бывает непросто. а это ещё полбеды. при том, что осцилл на несколько десятков гигагерц стоит, как квартира в Подпосковье, а чтобы снимать сигналы с шины нужно купить специальные примочки, иначе усеришься подлазить щупами к контактам. и это только начало всей фигни. а дальше начнётся DMA и сращивание взаимодействия прошивки с памятью, писательство дров и их отладка. а потом ещё обеспечение питания, отключения питания PCI осями, которые зело беспокоятся об экономии милливаттов и запускают принудительный D3 и все проблемы с потерей контекста, вот это всё...

Не нужно ничего пилить, всё уже напилено до нас. Корки PCI есть в открытом доступе (если постараться, можно найти и в закрытом), с остальным то-же самое.

Ну и для PCI гигагерцовый осциллограф не нужен, достаточно недорогого китайского 100МГц с памятью. Да и смотреть там особо нечего, разве что глитчи ловить (а их наличие зависит от кривизны рук пейсателя), достаточно SignalTap или ChipScope.

Если PCIe, то там осциллограф в общем тоже не нужен, потому что работа обычно делается на отладках, которые разведены с учетом signal integrity, на плисах стоят тыщу раз проверенные приемопередатчики, а с логической отладкой справляются другие срадства.

Но это в любом случае для для топикстартера. Даже правильно соединить IP-блоки не так просто - нужно и почитать и потрахаться. Ради изучения драйверописательского ремесла это слишком кривой путь.

Точно. Я не инженер и вообще не электрик. Осциллограф видел один раз в жизни.

Ну и что? Я вообще по образованию астрофизик. Но это не мешает мне разрабатывать электронику и железо пилить (зачастую в буквальном смысле слова).

Я взял плату с протухшим армом и фпга, подключенным к нему по smc шине. На фпга накостылил простенький интерфейс чтения/записи ворда по 32 битам адреса, ну и накостылил драйвер для линукса, чтобы можно было из юзерспейса засылать данные в фпга. Но там ядерного кода на 500 строк.

А мне понравилась идея с драйвером виртуально ФС а-ля /sys для демонстрации возможностей этой железки. Как Эдди сказал, echo 1 > /sys/cortexm4/leds/01 или echo -ne "\xFF43" /sys/cortexm4/gpio/word

Железка у тебя уже есть и, наверняка, с предустановленным линуксом. Никакого PCI распаивать не надо. Иди на сайт производителя и ищи спецификации на процессор и плату. Для таких плат они обычно открыты и, скорее всего, есть на диске, который должен был бы быть в комплекте. Находишь, изучаешь, выясняешь, на какой порт (обычно GPIO) подвешен (или есть возможность подвесить) светодиод, затем, как минимум, изучаешь ldd3, учишься создавать модуль ядра, работать с оборудованием средствами ядра подглядывая в исходники других драйверов, выбираешь, какой тип устройства будешь использовать для управления своим светодиодом (последовательное подходит лучше чем блочное или сетевое, я полагаю, но особые извращенцы могут решить иначе), выбираешь способ, как будешь управлять: через read/write или ioctl, реализуешь функционал и радуешься, как оно входит и выходит.

А вот зачем оно тебе нужно и будет ли результат стоить затраченных усилий, это, знаешь ли, тебе надо себя спрашивать.

ну, это, опять же, теория. а я на практике всё это видела, в разработке автоматизации. и не раз. поэтому я пишу про то, что реально есть в разработке и как обычно это происходит. гемора там предостаточно, даже если брать готовые мосты для PCI или чипы, которые поддерживают некоторые шины из коробки. физика изрядно мешает. одно дело написать прошивку, и совсем другое - убедиться, что какой-нибудь резистор на выходе не съедает твои сигналы. и что материнка не имеет каких-нибудь неожиданных особенностей.
на бумажках в стандартах всё красиво. а в реальности стандарты весьма размыты, корпорации кладут болт на многие вещи и под каждый такой мэйнстримовый косяк надо подстраиваться.
я думаю, что для начинающего изучать PCI нет смысла. потому что даже выпуск чипов для работы с PCI давно прекращён. технология устарела. но PCIe сложнее и тоже не годится в качестве экспериментов для начинающего.

ну, это, опять же, теория

Не скажите. Это теория, подкрепленная годами практики.

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

А я не только видел, но и делал (хотя есть тут некоторые, которые не верят).

гемора там предостаточно

Гемора везде предостаточно, если руки кривые.

одно дело написать прошивку, и совсем другое - убедиться, что какой-нибудь резистор на выходе не съедает твои сигналы

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

и что материнка не имеет каких-нибудь неожиданных особенностей.

А их не должно быть у грамотного специалиста. Нет, конечно всего знать и учесть нельзя, но целостность сигналов - это первое, что должен знать проектировщик высокоскоростных ПП. Кроме того, большинство косяков обнаруживается на этапах пред- и посттопологического моделирования.

А если мы говорим о PCI, то там вообще ничего этого не надо, скорости не те. Нужно просто соблюсти некотрые элементарные правила разводки. Даже длины выравнивать не надо.

корпорации кладут болт на многие вещи и под каждый такой мэйнстримовый косяк надо подстраиваться

Это вы из программирования притащили. В электронике я такого не встречал.

но PCIe сложнее и тоже не годится в качестве экспериментов для начинающего.

А не надо самому рисовать схему, разводить плату и писать PCIe Endpoint на верилоге. Можно просто взять отладку с каким нибудь циклоном-5 или цинком, воткнуть ее в разъем PCIe на своем компьютере и спокойно возить мышью, соединяя IP блоки. И ни о какой физике, которая изрядно мешает, заботиться не надо.

В любом случае, наш спор ни о чем, потому что ТС не будет ничего этого делать.

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

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

Это вы из программирования притащили. В электронике я такого не встречал.

нет. это именно железо. я очень хорошо понимаю разницу. про софт я тут вообще ничего не говорила. несовместимости железа существуют всегда и везде. и особенно в реализации разных чипсетов для материнок у разных производителей. и особенно у промышленных плат и разного рода эмбеддеда. так что отладка какого-нить сложного PCIe девайса с разными специфическими мамками - та ещё развлекуха с осциллографом.

А не надо самому рисовать схему, разводить плату и писать PCIe Endpoint на верилоге. Можно просто взять отладку с каким нибудь циклоном-5 или цинком, воткнуть ее в разъем PCIe на своем компьютере и спокойно возить мышью, соединяя IP блоки. И ни о какой физике, которая изрядно мешает, заботиться не надо.

ну, это вот и есть чистая теория. конечно, можно так играться. но от реальности это далеко-далеко. соглашусь, что для ТС это малопонятная задача.

Вот налезли в тред и засрали всяким непотребством. А убирать кто будет?

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

С чем я вас и поздравляю. Мы тут пиписьками будем меряться? Хотя, о чем это я...

А я не только увлекаюсь, но еще это моя профессия в течение последних двадцати лет.

так что отладка какого-нить сложного PCIe девайса с разными специфическими мамками

Не путайте теплое с мягким. Совместимость «сложного PCIe девайса с разными специфическими мамками» зависит исключительно от кривизны рук инженера, который проектировал ПП. И с одной и с другой стороны. Про китайцев со всей ответственностью могу сказать, что руки у их инженеров обладают сильно повышенной кривизной. По этому не берите у них «мамки». Тем не менее, даже с китайскими платами можно гарантировать совместимость, если чуть чуть постараться при проектировании платы и схемы.

ну, это вот и есть чистая теория. конечно, можно так играться. но от реальности это далеко-далеко.

Вы наверное живете в какой-то другой реальности. На отладках делается бОльшая часть работы. Всегда. За исключением случаев, когда нет нужной отладки или устройство достаточно простое, чтобы сразу реализовать его в железе.

Это ты про меня и Iron_Bug? Ну прости, люблю поспорить :)

Взгляни сюда.