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

ЛИЧНЫЙ КАБИНЕТ 

 

Здравствуйте гость!

 

Логин:

Пароль:

 

Запомнить

 

 

Забыли пароль? Регистрация

Повышение уникальности

Предлагаем нашим посетителям воспользоваться бесплатным программным обеспечением «StudentHelp», которое позволит вам всего за несколько минут, выполнить повышение уникальности любого файла в формате MS Word. После такого повышения уникальности, ваша работа легко пройдете проверку в системах антиплагиат вуз, antiplagiat.ru, etxt.ru или advego.ru. Программа «StudentHelp» работает по уникальной технологии и при повышении уникальности не вставляет в текст скрытых символов, и даже если препод скопирует текст в блокнот – не увидит ни каких отличий от текста в Word файле.

Результат поиска


Наименование:


курсовая работа Исследование драйвера ядра Linux для шины I2C

Информация:

Тип работы: курсовая работа. Добавлен: 23.10.2012. Сдан: 2012. Страниц: 32. Уникальность по antiplagiat.ru: < 30%

Описание (план):


Министерство  общего и профессионального образования 
Российской Федерации
 

КУБАНСКИЙ ГОСУДАРСТВЕННЫЙ ТЕХНОЛОГИЧЕСКИЙ  УНИВЕРСИТЕТ 

Кафедра ВТ и АСУ 
 
 
 
 

Пояснительная записка
к курсовой работе 
 
 

по дисциплине: Системное программное обеспечение  ЭИС 

на тему: Исследование драйвера ядра Linux   для шины I2C. 
 
 

Выполнил: студент    курса 
 

Руководитель  проекта:  

Защищён                                   Оценка:                                      
                           (дата) 

Члены комиссии:                                                                                                          
                                                                                                                                        
                                                                                                                                        
                          (подпись, дата, расшифровка подписи) 
 
 

г. Краснодар
2012 

Кубанский Государственный Технологический  Университет 

Кафедра ВТ и АСУ 

                  Утверждаю:
                  Зав. кафедрой Ключко В. И. 
                   

Задание
на  курсовую работу 

Студенту:                                               Группы ____                        ___ Курса        
факультета  ___КТАС_________________________________________                 
специальности ___          ______________________________________                    

Тема проекта: Исследование драйвера Linux    для шины I2C.
Содержание  задания: Изучить общие принципы разработки драйверов для ядра ОС Linux. Исследовать один из предложенных драйверов. Исходные тексты с комментариями оформить в виде гипертекста HTML и поместить на электронный носитель. Рекомендуется воспользоваться программой типа «Highlight Code Converter» (http://www.andre-simon.de/). Выходной формат XHTML с включенной нумерацией строк. В печатный отчет приложить оригинальные исходные тексты. 

Объём работы 40 листов 

Рекомендуемая литература:
    Гук М.Ю. Аппаратные средства IBM PC. Энциклопедия. 2-е изд. - СПб.: Питер, 2004. – 923 с.: ил.
    Гук М.Ю. Шины PCI, USB и FireWire. Энциклопедия. - Спб.: Питер, 2005. - 540 с.: ил.
    Кулаков В. Программирование на аппаратном уровне: специальный справочник (+дискета). 2-е изд. - СПб: Питер, 2003. - 848 с.: ил.
    The Linux Kernel Module Programming Guide.
 
Срок выполнения проекта: с                                2011 г. По                  2011 г.
Срок защиты:                       2011 г.
Дата выдачи задания:                      2011 г. 

Руководитель  проекта Мурлин А.Г.. 
                                                подпись
Задание принял студент _____________________________________
                                                подпись,                  дата 

Реферат
Объём пояснительной записки: 48 листов.
Количество  рисунков: 15.
Ключевые  слова: драйвер, Linux, I2C, SMBus.
Содержание 
 

Введение

       Каждый, кто занимался разработкой радиоэлектронной техники, сталкивался с ситуацией, когда для соглассвания уровней  сигналов, выборки и адресации  функционально-законченных узлов, приходится использовать огромное количество промежуточных ИС.  
Для увеличения эффективности, упрощения схемотехнических решений,
Philips разработала простую двунаправленную двухпроводную шину для так называемого "межмикросхемного" (inter-IC) управления.  
Шина получила название - InterIC, или IIC (I2C) шина.

       В настоящее время только Philips производит более 150 наименований I2C-совместимых  устройств, функционально предназначенных  работы в электронном оборудовании различного назначения. В их числе ИС памяти, видеопроцессоров и модулей обработки аудио- и видео-сигналов, АЦП и ЦАП, драйверы ЖК-индикаторов, процессоры со встоенным аппаратным контроллером I2C шины и многое другое.
       I2C шина является одной из модификаций последовательных протоколов обмена данных. В стандартном режиме обеспечивается передача последовательных 8-битных данных со скоростью до 100 кбит/с, и до 400 кбит/с в "быстром" режиме. Для осуществления процесса обмена информацией по I2C шине, используется всего два сигнала линия данных SDA линия синхронизации SCL Для обеспечения реализации двунаправленности шины без применения сложных арбитров шины выходные каскады устройств, подключенных к шине, имеют открытый сток или открытый коллектор для обеспечения функции монтажного "И".
       Простая двухпроводная последовательная шина I2C минимизирует количество соединения между ИС, ИС имеют меньше контактов  и требуется меньше дорожек. Как  результат - печатные платы становятся более простыми и технологичными при изготовлении. Интегрированный I2C-протокол устраняет необходимость в дешифраторах адреса и другой внешней логике согласования.
       Максимальное  допустимое количество микросхем, подсоединённых к одной шине, ограничивается максимальной емкостью шины 400 пФ.
       Встроенный  в микросхемы аппаратный алгоритм помехоподавления обеспечивает целостность данных в  условиях помех значительной величины.  
Все I2C-совместимые устройства имеют интерфейс, который позволяет им связываться друг с другом по шине даже в том случае, если их напряжение питания существенно отличается. На следующем рисунке представлен принцип подключения нескольких ИМС с различными напряжениями питания к одной шине обмена.

       Каждое  устройство распознается по уникальному  адресу и может работать как передатчик или приёмник, в зависимости от назначения устройства.
       Кроме того, устройства могут быть классифицированы как ведущие и ведомые при  передаче данных. Ведущий - это устройство, которое инициирует передачу данных и вырабатывает сигналы синхронизации. При этом любое адресуемое устройство считается ведомым по отношению к ведущему.
       Исходя  из спецификации работы шины, в каждый отдельный момент в шине может  быть только один ведущий, а именно то устройство, которое обеспечивает формирование сигнала SCL шины. Ведущий может выступать как в роли ведущего-передатчика, так и ведущего-приемника. Тем не менее - шина позволяет иметь несколько ведущих, накладывая определенные особенности их поведения в формировании сигналов управления и контроля состояния шины. Возможность подключения более одного ведущего к шине означает, что более чем один ведущий может попытаться начать пересылку в один и тот же момент времени. Для устранения "столкновений", который может возникнуть в данном случае, разработана процедура арбитража - поведения ведущего при обнаружении "захвата" шины другим ведущим.
       Процедура синхронизации двух устройств Эта  процедура основана на том, что все I2C-устройства подключаются к шине по правилу монтажного И. В исходном состоянии оба сигнала SDA и SCL находятся в высоком состоянии.
       Состояние СТАРТ и СТОП
       Процедура обмена начинается с того, что ведущий  формирует состояние СТАРТ - ведущий  генерирует переход сигнала линии SDA из ВЫСОКОГО состояния в НИЗКОЕ при ВЫСОКОМ уровне на линии SCL. Этот переход воспринимается всеми устройствами, подключенными к шине как признак начала процедуры обмена.
       Генерация синхросигнала - это всегда обязанность  ведущего; каждый ведущий генерирует свой собственный сигнал синхронизации  при пересылке данных по шине.
       Процедура обмена завершается тем, что ведущий формирует состояние СТОП - переход состояния линии SDA из низкого состояния в ВЫСОКОЕ при ВЫСОКОМ состоянии линии SCL.
       Состояния СТАРТ и СТОП всегда вырабатываются ведущим. Считается, что шина занята после фиксации состояния СТАРТ. Шина считается освободившейся через некоторое время после фиксации состояния СТОП. 

       При передаче посылок по шине I2C каждый ведущий генерирует свой синхросигнал на линии SCL.
       После формирования состояния СТАРТ, ведущий  опускает состояние линии SCL в НИЗКОЕ состояние и выставляет на линию SDA старший бит первого байта сообщения. Количество байт в сообщении не ограничено.
       Спецификация  шины I2C разрешает изменения на линии SDA только при НИЗКОМ уровне сигнала  на линии SCL.
       Данные  действительны и должны оставаться стабильными только во время ВЫСОКОГО состояния синхроимпульса.
       Для подтверждения приема байта от ведущего - передатчика ведомым - приемником в спецификации протокола обмена по шине I2C вводится специальный бит  подтверждения, выставляемый на шину SDA после приема 8 бита данных.
       Подтверждение
       Таким образом передача 8 бит данных от передатчика к приемнику завершаются  дополнительным циклом (формированием 9-го тактового импульса линии SCL), при  котором приемник выставляет низкий уровень сигнала на линии SDA, как признак успешного приема байта. 

       Подтверждение при передаче данных обязательно. Соответствующий  импульс синхронизации генерируется ведущим. Передатчик отпускает (ВЫСОКОЕ) линию SDA на время синхроимпульса подтверждения. Приёмник должен удерживать линию SDA в течение ВЫСОКОГО состояния синхроимпульса подтверждения в стабильном НИЗКОМ состоянии.
       В том случае, когда ведомый-приёмник не может подтвердить свой адрес (например, когда он выполняет в  данный момент какие-либо функции реального  времени), линия данных должна быть оставлена в ВЫСОКОМ состоянии. После этого ведущий может выдать сигнал СТОП для прерывания пересылки данных.
       Если  в пересылке участвует ведущий-приёмник, то он должен сообщить об окончании  передачи ведомому-передатчику путем  не подтверждения последнего байта. Ведомый-передатчик должен освободить линию данных для того, чтобы позволить ведущему выдать сигнал СТОП или повторить сигнал СТАРТ.
       Синхронизация выполняется с использованием подключения  к линии SCL по правилу монтажного И.
       Это означает, что ведущий не имеет  монопольного права на управление переходом  линии SCL из НИЗКОГО состояния ВЫСОКОГО. В том случае, когда ведомому необходимо дополнительное время на обработку  принятого бита, он имеет возможность  удерживать линию SCL в низком состоянии до момента готовности к приему следующиго бита. Таким образом, линия SCL будет находиться в НИЗКОМ состоянии на протяжении самого длинного НИЗКОГО периода синхросигналов.
       Устройства  с более коротким НИЗКИМ периодом будут входить в состояние  ожидания на время, пока не кончится длинный период. Когда у всех задействованных устройств кончится НИЗКИЙ период синхросигнала, линия SCL перейдет в ВЫСОКОЕ состояние. Все устройства начнут проходить ВЫСОКИЙ период своих синхросигналов. Первое устройство, у которого кончится этот период, снова установит линию SCL в НИЗКОЕ состояние. Таким образом, НИЗКИЙ период синхролинии SCL определяется наидлиннейшим периодом синхронизации из всех задействованных устройств, а ВЫСОКИЙ период определяется самым коротким периодом синхронизации устройств.
       Механизм  синхронизации может быть использован  приемниками как средство управления пересылкой данных на байтовом и битовом  уровнях.
       На  уровне байта, если устройство может  принимать байты данных с большой  скоростью, но требует определенное время для сохранения принятого байта или подготовки к приему следующего, то оно может удерживать линию SCL в НИЗКОМ состоянии после приема и подтверждения байта, переводя таким образом передатчик в состояние ожидания.
       На  уровне битов, устройство такое как микроконтроллер без встроенных аппаратных цепей I2C или с ограниченными цепями может замедлить частоту синхроимпульсов путем продления их НИЗКОГО периода. Таким образом скорость передачи любого ведущего адаптируется к скорости медленного устройства.
       Адресация в шине I2C
       Каждое  устройство, подключённое к шине, может  быть программно адресовано по уникальному  адресу.
       Для выбора приемника сообщения ведущий  использует уникальный адресную компоненту в формате посылки. При использовании  однотипных устройств, ИС часто имеют дополнительный селектор адреса, который может быть реализован как в виде дополнительных цифровых входов селектора адреса, так и в виде аналогового входа. При этом адреса таких однотипных устройств оказываются разнесены в адресном пространстве устройств, подключенных к шине.
       В обычном режиме используется 7-битная адресация.
       Процедура адресации на шине I2C заключается  в том, что первый байт после сигнала  СТАРТ определяет, какой ведомый  адресуется ведущим для проведения цикла обмена. Исключение составляет адрес "Общего вызова", который адресует все устройства на шине. Когда используется этот адрес, все устройства в теории должны послать сигнал подтверждения. Однако, устройства могут обрабатывать "общий вызов" на практике встречаются редко.
       Первые  семь битов первого байта образуют адрес ведомого. Восьмой, младший  бит, определяет направление пересылки  данных. "Ноль" означает, что ведущий  будет записывать информацию в выбранного ведомого. "Единица" означает, что  ведущий будет считывать информацию из ведомого.
       После того, как адрес послан, каждое устройство в системе сравнивает первые семь бит после сигнала СТАРТ со своим адресом. При совпадении устройство полагает себя выбранным как ведомый-приёмник или как ведомый-передатчик, в  зависимости от бита направления.
       Адрес ведомого может состоять из фиксированной  и программируемой части.
       Часто случается, что в системе будет  несколько однотипных устройств (к  примеру ИМС памяти, или драйверов LED-индикаторов), поэтому при помощи программируемой части адреса становится возможным подключить к шине максимально возможное количество таких устройств. Количество программируемых бит в адресе зависит от количества свободных выводов микросхемы. Иногда используется один вывод с аналоговой установкой программируемого диапазона адресов, как это, к примеру, реализовано в ИМС SAA1064. При этом в зависимости от потенциала на этом адресном выводе ИМС, возможно смещение адресного пространства драйвера так, чтобы однотипные ИМС не конфликтовали между собой на общей шине.
       Все ИМС, поддерживающие работу в стандарте  шины I2C, имеют набор фиксированых адресов, перечень которых указан производителем в описаниях контроллеров.
       Комбинация  бит 11110ХХ адреса зарезервирована для 10-битной адресации.
       В общем виде процесс обмена по шине от момента формирования состояния СТАРТ до состояния СТОП можно проиллюстрировать следующим рисунком : 

       Как следует из спецификации шины, допускаются как простые форматы обмена, так и комбинированные, когда в промежутке от состояния СТАРТ до состояния СТОП ведущий и ведомый могут выступать и как приемник и как передатчик данных. Комбинированные форматы могут быть использованы, например, для управления последовательной памятью.  
Во время первого байта данных можно передавать адрес в памяти, который записывается во внутренний регистр-защелку. После повторения сигнала СТАРТа и адреса ведомого выдаются данные из памяти. Все решения об авто-инкременте или декременте адреса, к которому произошел предыдущий доступ, принимаются конструктором конкретного устройства. Поэтому, в любом случае лучший способ избежать неконтролируемой ситуации на шине перед использованием новой (или ранее не используемой) ИМС следует тщательно изучить ее описание (datasheet), получив его с сайта производителя. Более того, производители часто размещают рядом более подробные инструкции по применению.

       В любом случае, по спецификации шины все разрабатываемые устройства должны сбрасывать логику шины при получении сигнала СТАРТ или повторный СТАРТ и подготавливаться к приему адреса.
       Тем не менее основные проблемы с использованием I2C шины возникают именно из-за того, что разработчики, "начинающие" работать с I2C шиной не учитывают того факта, что ведущий (часто - микропроцессор) не имеет монопольного права ни на одну из линий шины.
       Расширение I2C
       Стандартная шина I2C со скоростью передачи данных 100 кбит/с и 7-битным адресом существует уже на протяжении более 10 лет в неизменном виде. Стандартная шина I2C принята повсеместно как стандарт для сотен типов микросхем, выпускаемых фирмой Philips и другими поставщиками. В настоящее время спецификация шины I2C расширена в двух направлениях : увеличение быстродействия и расширение адресного пространства для расширения номенклатуры вновь разрабатываемых устройств.
       Введение  спецификации "быстрого" режима, позволяющего в четыре раза увеличить  скорость передачи данных до 400кБит\сек. Необходимость в этом "расширении" стандарта потребовалось из-за необходимости пересылки больших объемов информации, и, как следствие, необходимость увеличения пропускной способности канала.
       Введение  спецификации "10-битной адресации", позволяющая использовать 1024 дополнительных адресов, т.к. большинство из 112 адресов, допустимых при 7-битной адресации, уже были использованы более чем один раз. Для предотвращения проблем с размещением адресов новых устройств, желательно иметь большее количество адресных комбинаций. Примерно десятикратное увеличение количества доступных адресов получено при использовании новой 10-битной адресации.
       Все новые устройства с I2C интерфейсом  работают в быстром режиме. Предпочтительно, они должны уметь принимать и/или  передавать данные на скорости 400 кбит/с. Как минимум они должны быть способны входить в синхронизацию в быстром режиме, с тем чтобы снизить скорость передачи (путем удлиннения НИЗКОГО периода SCL) до допустимой величины.
       Быстрые устройства как правило совместимы снизу-вверх, что означает их способность  работать со стандартными устройствами по медленной шине. Очевидно, что стандартные устройства не способны работать в быстрой шине, потому что они не могут синхронизироваться на высокой скорости и их состояние станет непредсказуемым. Ведомые быстрые устройства могут обладать как 7-битным, так и 10-битным адресом. Однако, 7-битный адрес более предпочтителен, так как его аппаратная реализация более проста и длина посылки меньше. Устройства с 7-битным и 10-битным адресами могут одновременно использоваться на одной шине, независимо от скорости передачи. Как существующие, так и будущие ведущие смогут генерировать и 7-битные, и 10-битные адреса.
       В быстром режиме протокол, формат, логические уровни и максимальная емкостная  нагрузка линий шины остается неизменными. Алгоритм синхронизации линий SDA и SCL не изменен. Однако, от "быстрых" устройствне требуется совместимости с CBUS-устройствами, так как они не могут работать на высоких скоростях. Входные цепи быстрых устройств должны иметь встроенное подавление выбросов и триггер Шмитта на обоих линиях Выходной буфер быстрых устройств должен иметь каскад с управлением временем заднего фронта линий SDA и SCL. Как правило при пропадании напряжения питания быстрых устройств выводы, подключенные к линиям I2C шины должны переходить в третье состояние . Претерпели изменения схемотехнические решения выходных каскадов для обеспечения времени нарастания переднего фронта (переход из НИЗКОГО состояния в ВЫСОКОЕ). Если для нагрузок шины до 200 пФ эту роль выполняют подтягивающие резисторы, то для нагрузок от 200 пФ до 400 пФ эту функцию выполняет источник тока или схема на переключаемых резисторах, обеспечивающая "форсированое" переключение линий I2C шины.
       10-битная  адресация также не изменяет  формат шины. Для этого используется  зарезервированная адресная комбинация 1111ХХХ первых семи бит первого байта. 10-битная адресация не влияет на существующую 7-битную адресацию. Устройства с 7-битной и 10-битной адресацией могут быть подключены к одной шине. Хотя имеются восемь возможных комбинаций последовательности 1111ХХХ, из них используются только четыре - 11110ХХ. Комбинации типа 11111ХХ зарезервированы для дальнейших улучшений шины. Назначение битов первых двух байтов 10-битный адрес формируется из первых двух байтов. Первые семь бит первого байта являются комбинацией вида 11110ХХ, где два младших бита (ХХ) являются двумя старшими (9 и 8) битами 10-битного адреса; восьмой бит первого байта - бит направления.  
"Ноль" в этом бите означает, что ведущий собирается записывать информацию в ведомого, а "единица" - что ведущий будет считывать информацию из ведомого. Если бит направления равен "нулю", то второй байт содержит оставшиеся 8 бит 10-битного адреса. Если бит направления равен "единице", то следующий байт содержит данные, переданные с ведомого ведущему.

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

       1 Шина управления I2C

       I2C – двухпроводной интерфейс, разработанный корпорацией Philips. В первоначальном техническом требовании к интерфейсу максимальная скорость передачи данных составляла 100 Кбит/с. Однако со временем появились стандарты на более скоростные режимы работы I2C. К одной шине I2C могут быть подключены устройства с различными скоростями доступа, так как скорость передачи данных определяется тактовым сигналом.
       Протокол  передачи данных разработан таким образом, чтобы гарантировать надежный прием  передаваемых данных.
       При передаче данных одно устройство является «Master», которое инициирует передачу данных и формирует сигналы синхронизации. Другое устройство «Slave» - начинает передачу только по команде, пришедшей от «Master».
       В микроконтроллерах PIC16CXXX аппаратно  реализован режим «Slave» устройства в модуле SSP. Режим «Master» реализуется программно.
       Основные  термины, используемые при описании работы с шиной I2C:
       Передатчик – устройство, передающее данные по шине
       Приемник – устройство, получающее данные с шины
       «Master» - устройство, которое инициирует передачу и формирует тактовый сигнал
       «Slave» - устройство, к которому обращается «Master»
       Multi-«Master» - режим работы шины I2C с более чем одним «Master»
       Арбитраж – процедура, гарантирующая, что только один «Master» управляет шиной
       Синхронизация – процедура синхронизации тактового сигнала от двух или более устройств
       Выходные  каскады формирователей сигналов синхронизации (SCL) и данных (SDA) должны быть выполнены  по схемам с открытым коллектором (стоком) для объединения нескольких выходов  и через внешний резистор подключены к плюсу питания для того, чтобы на шине был уровень «1», когда ни одно устройство не формирует сигнал «0». Максимальная емкостная нагрузка ограничена емкостью 400 пФ.
       Инициализация и завершение передачи данных
       В то время, когда передача данных на шине отсутствует, сигналы  SCL и SDA имеют высокий уровень за счет внешнего резистора.
       Сигналы START и STOP формируются «Master» для  определения начала и окончания  передачи данных соответственно.
       Сигнал START формируется переходом сигнала SDA из высокого уровня в низкий при высоком уровне сигнала SCL. Сигнал STOP определяется как переход SDA из низкого уровня в высокий при высоком уровне SCL. Таким образом, при передаче данных сигнал SDA может изменяться только при низком уровне сигнала SCL. 

       Адресация устройств на шине I2C
       Для адресации устройств используется два формата адреса:
       Простой 7-разрядный формат с битом чтения/записи R/W; 

       и 10-разрядный формат – в первом байте передается два старших  бита адреса и бит записи/чтения, во втором байте передается младшая часть адреса. 

       Подтверждение приема
       При передаче данных после каждого переданного  байта приемник должен подтвердить  получение байта сигналом ACK.
       Если  «Slave» не подтверждает получение  байта адреса или данных, «Master»  должен прервать передачу, сформировав  сигнал STOP.
       При передаче данных от «Slave» к «Master», «Master» формирует сигналы подтверждения  приема данных ACK. Если «Master» не подтвердит приема байта, «Slave» прекращает передачу данных, «отпуская» линию SDA. После этого «Master» может сформировать сигнал STOP.
       Для задержки передачи данных «Slave» может  установить логический нуль, указывая «Master» о необходимости ожидания. После «отпускания» линии SCL передача данных продолжается. 

       Передача  данных от «Master» к  «Slave» 

       Чтение  данных из «Slave» 

       Использование сигнала повторного START для обращения  к «Slave» 

       Режим Multi-«Master»
       Протокол  передачи данных I2C позволяет иметь более одного «Master» на шине. Для разрешения конфликтов на шине при инициализации передачи используются функции арбитража и синхронизации.
       Арбитраж
       Арбитраж  выполняется на линии SDA при высоком  уровне линии SCL. Устройство, которое  формирует на линии SDA высокий уровень когда другое передает низкий, теряет право брать «Master» и должно перейти в режим «Slave». «Master», потерявший инициативу на шине, может формировать тактовые импульсы до конца байта, в котором потерял свойства ведущего. 

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

       2 Исследование драйвера

       Для исследования была выбрана версия ядра 2.6.15.6. Драйвер шины PCI состоит из следующих основных файлов: drivers/i2c/i2c_core.c и include/linux/i2c.h. А также файлы drivers/i2c/i2c-dev.c и include/linux/i2c-dev.h.

Заключение

       В процессе выполнения курсовой работы были изучены структура и технология разработки драйверов для ОС GNU/Linux, устройство и функционирование шины I2c, повсеместно используемой в персональных компьютерах, рабочих станциях и серверах, а также в компактных компьютерах типа КПК, для установки всевозможных устройств таких как LCD-дисплеи, сенсоры и тому подобное.

Список  использованных источников

    Максвелл  Скотт "Ядро Linux в комментариях": Пер. с англ. - К.: Издательство "ДиаСофт", 2000.- 488 с.
    Гук М.Ю. Аппаратные средства IBM PC. Энциклопедия. 2-е изд. - СПб.: Питер, 2004. - 923 с.: ил.
    Гук М.Ю. Дисковая подсистема ПК. - Спб.: Питер, 2001. - 336 с.: ил.
    Кулаков В. Программирование на аппаратном уровне: специальный справочник (+дискета). 2-е изд. - СПб: Питер, 2003. - 848 с.: ил.
    Кулаков В. Программирование дисковых подсистем (+дискета). - Спб.: Питер, 2002. - 768 с.: ил.
    Зубков С.В. Assembler для DOS, Windows и UNIX. - М.: ДМК Пресс, 2000. - 608 с.: ил.
    The Linux Kernel Module Programming Guide - http://gazette.linux.ru.net/rus/articles/lkmpg.html
    Шина управления I2C - http://library.espec.ws/article.php?article=51
    Цифровая шина I2C - http://www.data-chip.ru/n/id/64.html
    Описание шины I2C - http://www.itt-ltd.com.ua/reference/ref_i2c.html

Приложение  А. Листинг драйвера I2C. Файл i2c.h

    1 /* -------------------------------------------------------------------------
    2 */
    3 /*                                       */
    4 /* i2c.h - definitions for the i2c-bus interface                 */
    5 /*                                       */
    6 /* -------------------------------------------------------------------------
    7 */
    8 /*   Copyright (C) 1995-2000 Simon G. Vogl
    9
   10     This program is free software; you can redistribute it and/or modify
   11     it under the terms of the GNU General Public License as published by
   12     the Free Software Foundation; either version 2 of the License, or
   13     (at your option) any later version.
  14
   15     This program is distributed in the hope that it will be useful,
   16     but WITHOUT ANY WARRANTY; without even the implied warranty of
   17     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
   18     GNU General Public License for more details.
   19
   20     You should have received a copy of the GNU General Public License
   21     along with this program; if not, write to the Free Software
   22     Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.            */
   23 /* -------------------------------------------------------------------------
   24 */
   25
   26 /* With some changes from Kyцsti Mдlkki <kmalkki@cc.hut.fi> and
   27    Frodo Looijaard <frodol@dds.nl> */
   28
   29 #ifndef _LINUX_I2C_H
   30 #define _LINUX_I2C_H
   31
   32 #include <linux/module.h>
   33 #include <linux/types.h>
   34 #include <linux/i2c-id.h>
   35 #include <linux/mod_devicetable.h>
   36 #include <linux/device.h>   /* for struct device */
   37 #include <linux/sched.h>    /* for completion */
   38 #include <asm/semaphore.h>
   39
   40 /* --- For i2c-isa ---------------------------------------------------- */
   41
   42 extern void i2c_adapter_dev_release(struct device *dev);
   43 extern struct device_driver i2c_adapter_driver;
   44 extern struct class i2c_adapter_class;
   45 extern struct bus_type i2c_bus_type;
   46
   47 /* --- General options ------------------------------------------------ */
   48
   49 struct i2c_msg;
   50 struct i2c_algorithm;
   51 struct i2c_adapter;
   52 struct i2c_client;
   53 struct i2c_driver;
   54 union i2c_smbus_data;
   55
   56 /*
   57 * The master routines are the ones normally used to transmit data to
   58 devices
   59 * on a bus (or read from them). Apart from two basic transfer functions to
   60 * transmit one message at a time, a more complex version can be used to
   61 * transmit an arbitrary number of messages without interruption.
   62 */
   63 extern int i2c_master_send(struct i2c_client *,const char* ,int);
   64 extern int i2c_master_recv(struct i2c_client *,char* ,int);
   65
   66 /* Transfer num messages.
   67 */
   68 extern int i2c_transfer(struct i2c_adapter *adap, struct i2c_msg *msgs, int
   69                         num);
   70
   71 /*
   72 * Some adapter types (i.e. PCF 8584 based ones) may support slave
   73                        behaviuor.
   74 * This is not tested/implemented yet and will change in the future.
   75 */
   76 extern int i2c_slave_send(struct i2c_client *,char*,int);
   77 extern int i2c_slave_recv(struct i2c_client *,char*,int);
   78
   79
   80
   81 /* This is the very generalized SMBus access routine. You probably do not
   82    want to use this, though; one of the functions below may be much easier,
   83    and probably just as fast.
   84    Note that we use i2c_adapter here, because you do not need a specific
   85    smbus adapter to call this function. */
   86 extern s32 i2c_smbus_xfer (struct i2c_adapter * adapter, u16 addr,
   87                            unsigned short flags,
   88                            char read_write, u8 command, int size,
   89                            union i2c_smbus_data * data);
   90
   91 /* Now follow the 'nice' access routines. These also document the calling
   92   conventions of smbus_access. */
   93
   94 extern s32 i2c_smbus_write_quick(struct i2c_client * client, u8 value);
   95 extern s32 i2c_smbus_read_byte(struct i2c_client * client);
   96 extern s32 i2c_smbus_write_byte(struct i2c_client * client, u8 value);
   97 extern s32 i2c_smbus_read_byte_data(struct i2c_client * client, u8 command);
   98 extern s32 i2c_smbus_write_byte_data(struct i2c_client * client,
   99                                      u8 command, u8 value);
  100 extern s32 i2c_smbus_read_word_data(struct i2c_client * client, u8 command);
  101 extern s32 i2c_smbus_write_word_data(struct i2c_client * client,
  102                                      u8 command, u16 value);
  103 extern s32 i2c_smbus_write_block_data(struct i2c_client * client,
  104                       u8 command, u8 length,
  105                       u8 *values);
  106 /* Returns the number of read bytes */
  107 extern s32 i2c_smbus_read_i2c_block_data(struct i2c_client * client,
  108                      u8 command, u8 *values);
  109
  110 /*
  111 * A driver is capable of handling one or more physical devices present on
  112 * I2C adapters. This information is used to inform the driver of adapter
  113 * events.
  114 */
  115
  116 struct i2c_driver {
  117     struct module *owner;
  118     char name[32];
  119     int id;
  120     unsigned int class;
  121     unsigned int flags;     /* div., see below      */
  122
  123     /* Notifies the driver that a new bus has appeared. This routine
  124      * can be used by the driver to test if the bus meets its conditions
  125      * & seek for the presence of the chip(s) it supports. If found, it
  126      * registers the client(s) that are on the bus to the i2c admin. via
  127      * i2c_attach_client.
  128      */
  129     int (*attach_adapter)(struct i2c_adapter *);
  130     int (*detach_adapter)(struct i2c_adapter *);
  131
  132     /* tells the driver that a client is about to be deleted & gives it
  133      * the chance to remove its private data. Also, if the client struct
  134      * has been dynamically allocated by the driver in the function above,
  135      * it must be freed here.
  136      */
  137     int (*detach_client)(struct i2c_client *);
  138
  139     /* a ioctl like command that can be used to perform specific functions
  140      * with the device.
  141      */
  142     int (*command)(struct i2c_client *client,unsigned int cmd, void *arg);
  143
  144     struct device_driver driver;
  145     struct list_head list;
  146 };
  147 #define to_i2c_driver(d) container_of(d, struct i2c_driver, driver)
  148
  149 #define I2C_NAME_SIZE   50
  150
  151 /*
  152 * i2c_client identifies a single device (i.e. chip) that is connected to
  153                                           an
  154 * i2c bus. The behaviour is defined by the routines of the driver. This
  155 * function is mainly used for lookup & other admin. functions.
  156 */
  157 struct i2c_client {
  158     unsigned int flags;     /* div., see below      */
  159     unsigned short addr;        /* chip address - NOTE: 7bit    */
  160                     /* addresses are stored in the  */
  161                     /* _LOWER_ 7 bits       */
  162     struct i2c_adapter *adapter;    /* the adapter we sit on    */
  163     struct i2c_driver *driver;  /* and our access routines  */
  164     int usage_count;        /* How many accesses currently  */
  165                     /* to the client        */
  166     struct device dev;      /* the device structure     */
  167     struct list_head list;
  168     char name[I2C_NAME_SIZE];
  169     struct completion released;
  170 };
  171 #define to_i2c_client(d) container_of(d, struct i2c_client, dev)
  172
  173 static inline struct i2c_client *kobj_to_i2c_client(struct kobject *kobj)
  174 {
  175     return to_i2c_client(container_of(kobj, struct device, kobj));
  176 }
  177
  178 static inline void *i2c_get_clientdata (struct i2c_client *dev)
  179 {
  180     return dev_get_drvdata (&dev->dev);
  181 }
  182
  183 static inline void i2c_set_clientdata (struct i2c_client *dev, void *data)
  184 {
  185     dev_set_drvdata (&dev->dev, data);
  186 }
  187
  188 /*
  189 * The following structs are for those who like to implement new bus
  190 drivers:
  191 * i2c_algorithm is the interface to a class of hardware solutions which
  192 can
  193 * be addressed using the same bus algorithms - i.e. bit-banging or the
  194 PCF8584
  195 * to name two of the most common.
  196 */
  197 struct i2c_algorithm {
  198     /* If an adapter algorithm can't do I2C-level access, set master_xfer
  199        to NULL. If an adapter algorithm can do SMBus access, set
  200        smbus_xfer. If set to NULL, the SMBus protocol is simulated
  201        using common I2C messages */
  202     int (*master_xfer)(struct i2c_adapter *adap,struct i2c_msg *msgs,
  203                        int num);
  204     int (*smbus_xfer) (struct i2c_adapter *adap, u16 addr,
  205                        unsigned short flags, char read_write,
  206                        u8 command, int size, union i2c_smbus_data * data);
  207
  208     /* --- these optional/future use for some adapter types.*/
  209     int (*slave_send)(struct i2c_adapter *,char*,int);
  210     int (*slave_recv)(struct i2c_adapter *,char*,int);
  211
  212     /* --- ioctl like call to set div. parameters. */
  213     int (*algo_control)(struct i2c_adapter *, unsigned int, unsigned long);
  214
  215    /* To determine what the adapter supports */
  216     u32 (*functionality) (struct i2c_adapter *);
  217 };
  218
  219 /*
  220 * i2c_adapter is the structure used to identify a physical i2c bus along
  221 * with the access algorithms necessary to access it.
  222 */
  223 struct i2c_adapter {
  224     struct module *owner;
  225     unsigned int id;
  226     unsigned int class;
  227     struct i2c_algorithm *algo;/* the algorithm to access the bus   */
  228     void *algo_data;
  229
  230    /* --- administration stuff. */
  231     int (*client_register)(struct i2c_client *);
  232     int (*client_unregister)(struct i2c_client *);
  233
  234     /* data fields that are valid for all devices   */
  235     struct semaphore bus_lock;
  236     struct semaphore clist_lock;
  237
  238     int timeout;
  239     int retries;
  240     struct device dev;      /* the adapter device */
  241     struct class_device class_dev;  /* the class device */
  242
  243     int nr;
  244     struct list_head clients;
  245     struct list_head list;
  246     char name[I2C_NAME_SIZE];
  247     struct completion dev_released;
  248     struct completion class_dev_released;
  249 };
  250 #define dev_to_i2c_adapter(d) container_of(d, struct i2c_adapter, dev)
  251 #define class_dev_to_i2c_adapter(d) container_of(d, struct i2c_adapter,
  252                                  class_dev)
  253
  254 static inline void *i2c_get_adapdata (struct i2c_adapter *dev)
  255 {
  256     return dev_get_drvdata (&dev->dev);
  257 }
  258
  259 static inline void i2c_set_adapdata (struct i2c_adapter *dev, void *data)
  260 {
  261     dev_set_drvdata (&dev->dev, data);
  262 }
  263
  264 /*flags for the driver struct: */
  265 #define I2C_DF_NOTIFY   0x01        /* notify on bus (de/a)ttaches  */
  266 #if 0
  267 /* this flag is gone -- there is a (optional) driver->detach_adapter
  268 * callback now which can be used instead */
  269 # define I2C_DF_DUMMY   0x02
  270 #endif
  271
  272 /*flags for the client struct: */
  273 #define I2C_CLIENT_ALLOW_USE        0x01    /* Client allows access */
  274 #define I2C_CLIENT_ALLOW_MULTIPLE_USE   0x02    /* Allow multiple access-
  275 locks */
  276                         /* on an i2c_client */
  277 #define I2C_CLIENT_PEC  0x04            /* Use Packet Error Checking */
  278 #define I2C_CLIENT_TEN  0x10            /* we have a ten bit chip address
  279 */
  280                         /* Must equal I2C_M_TEN below */
  281
  282 /* i2c adapter classes (bitmask) */
  283 #define I2C_CLASS_HWMON     (1<<0)  /* lm_sensors, ... */
  284 #define I2C_CLASS_TV_ANALOG (1<<1)  /* bttv + friends */
  285 #define I2C_CLASS_TV_DIGITAL    (1<<2)  /* dvb cards */
  286 #define I2C_CLASS_DDC       (1<<3)  /* i2c-matroxfb ? */
  287 #define I2C_CLASS_CAM_ANALOG    (1<<4)  /* camera with analog CCD */
  288 #define I2C_CLASS_CAM_DIGITAL   (1<<5)  /* most webcams */
  289 #define I2C_CLASS_SOUND     (1<<6)  /* sound devices */
  290 #define I2C_CLASS_ALL       (UINT_MAX) /* all of the above */
  291
  292 /* i2c_client_address_data is the struct for holding default client
  293 * addresses for a driver and for the parameters supplied on the
  294 * command line
  295 */
  296 struct i2c_client_address_data {
  297     unsigned short *normal_i2c;
  298     unsigned short *probe;
  299     unsigned short *ignore;
  300     unsigned short **forces;
  301 };
  302
  303 /* Internal numbers to terminate lists */
  304 #define I2C_CLIENT_END      0xfffeU
  305
  306 /* The numbers to use to set I2C bus address */
  307 #define ANY_I2C_BUS     0xffff
  308 #define ANY_I2C_ISA_BUS     9191
  309
  310
  311 /* ----- functions exported by i2c.o */
  312
  313 /* administration...
  314 */
  315 extern int i2c_add_adapter(struct i2c_adapter *);
  316 extern int i2c_del_adapter(struct i2c_adapter *);
  317
  318 extern int i2c_add_driver(struct i2c_driver *);
  319 extern int i2c_del_driver(struct i2c_driver *);
  320
  321 extern int i2c_attach_client(struct i2c_client *);
  322 extern int i2c_detach_client(struct i2c_client *);
  323
  324 /* New function: This is to get an i2c_client-struct for controlling the
  325    client either by using i2c_control-function or having the
  326    client-module export functions that can be used with the i2c_client
  327    -struct. */
  328 extern struct i2c_client *i2c_get_client(int driver_id, int adapter_id,
  329                     struct i2c_client *prev);
  330
  331 /* Should be used with new function
  332    extern struct i2c_client *i2c_get_client(int,int,struct i2c_client *);
  333    to make sure that client-struct is valid and that it is okay to access
  334    the i2c-client.
  335    returns -EACCES if client doesn't allow use (default)
  336    returns -EBUSY if client doesn't allow multiple use (default) and
  337    usage_count >0 */
  338 extern int i2c_use_client(struct i2c_client *);
  339 extern int i2c_release_client(struct i2c_client *);
  340
  341 /* call the i2c_client->command() of all attached clients with
  342 * the given arguments */
  343 extern void i2c_clients_command(struct i2c_adapter *adap,
  344                 unsigned int cmd, void *arg);
  345
  346 /* returns -EBUSY if address has been taken, 0 if not. Note that the only
  347    other place at which this is called is within i2c_attach_client; so
  348    you can cheat by simply not registering. Not recommended, of course! */
  349 extern int i2c_check_addr (struct i2c_adapter *adapter, int addr);
  350
  351 /* Detect function. It iterates over all possible addresses itself.
  352 * It will only call found_proc if some client is connected at the
  353 * specific address (unless a 'force' matched);
  354 */
  355 extern int i2c_probe(struct i2c_adapter *adapter,
  356         struct i2c_client_address_data *address_data,
  357         int (*found_proc) (struct i2c_adapter *, int, int));
  358
  359 /* An ioctl like call to set div. parameters of the adapter.
  360 */
  361 extern int i2c_control(struct i2c_client *,unsigned int, unsigned long);
  362
  363 extern struct i2c_adapter* i2c_get_adapter(int id);
  364 extern void i2c_put_adapter(struct i2c_adapter *adap);
  365
  366
  367 /* Return the functionality mask */
  368 static inline u32 i2c_get_functionality(struct i2c_adapter *adap)
  369 {
  370     return adap->algo->functionality(adap);
  371 }
  372
  373 /* Return 1 if adapter supports everything we need, 0 if not. */
  374 static inline int i2c_check_functionality(struct i2c_adapter *adap, u32
  375                                           func)
  376 {
  377     return (func & i2c_get_functionality(adap)) == func;
  378 }
  379
  380 /* Return id number for a specific adapter */
  381 static inline int i2c_adapter_id(struct i2c_adapter *adap)
  382 {
  383     return adap->nr;
  384 }
  385
  386 /*
  387 * I2C Message - used for pure i2c transaction, also from /dev interface
  388 */
  389 struct i2c_msg {
  390     __u16 addr; /* slave address            */
  391     __u16 flags;
  392 #define I2C_M_TEN   0x10    /* we have a ten bit chip address   */
  393 #define I2C_M_RD    0x01
  394 #define I2C_M_NOSTART   0x4000
  395 #define I2C_M_REV_DIR_ADDR  0x2000
  396 #define I2C_M_IGNORE_NAK    0x1000
  397 #define I2C_M_NO_RD_ACK     0x0800
  398     __u16 len;      /* msg length               */
  399     __u8 *buf;      /* pointer to msg data          */
  400 };
  401
  402 /* To determine what functionality is present */
  403
  404 #define I2C_FUNC_I2C            0x00000001
  405 #define I2C_FUNC_10BIT_ADDR     0x00000002
  406 #define I2C_FUNC_PROTOCOL_MANGLING  0x00000004 /* I2C_M_{REV_DIR_ADDR,
  407                                                          NOSTART,..} */
  408 #define I2C_FUNC_SMBUS_HWPEC_CALC   0x00000008 /* SMBus 2.0 */
  409 #define I2C_FUNC_SMBUS_BLOCK_PROC_CALL  0x00008000 /* SMBus 2.0 */
  410 #define I2C_FUNC_SMBUS_QUICK        0x00010000
и т.д.................


Перейти к полному тексту работы


Скачать работу с онлайн повышением уникальности до 90% по antiplagiat.ru, etxt.ru или advego.ru


Смотреть полный текст работы бесплатно


Смотреть похожие работы


* Примечание. Уникальность работы указана на дату публикации, текущее значение может отличаться от указанного.