Объявление

Свернуть
Пока нет объявлений.

CAN протоколы высокого уровня

Свернуть
X
Свернуть

  • CAN протоколы высокого уровня

    Введение

    Нажмите на изображение для увеличения. 

Название:	pict1.gif 
Просмотров:	1 
Размер:	21.9 Кб 
ID:	1363 alt="" />
    CAN протокол получил всемирное признание как очень универсальная, эффективная, надежная и экономически приемлемая платформа для почти любого типа связи данных в передвижных системах, машинах, техническом оборудовании и индустриальной автоматизации. Основанная на базе протоколов высокого уровня CAN-технология успешно конкурирует на рынке распределенных систем автоматизации. Под терминами "CAN стандарт" или "CAN протокол" понимаются функциональные возможности, которые стандартизированы в ISO 11898. Этот стандарт объединяет физический уровень (Physical Layer) и уровень канала данных (Data Link Layer) в соответствии с 7-ми уровневой OSI моделью. Таким образом, "CAN стандарт" соответствует уровню сетевого интерфейса в 4-х уровневой модели TCP/IP. Однако, практическая реализация даже очень простых распределенных систем на базе CAN показывает, что помимо предоставляемых сервисов уровня канала данных требуются более широкие функциональные возможности : передача блоков данных длинной более чем 8 байтов, подтверждение пересылки данных, распределение идентификаторов, запуск сети и функции супервизора узлов. Так как эти дополнительные функциональные возможности непосредственно используются прикладным процессом, вводится понятие уровня приложений (Application Layer) и протоколов высокого уровня. Обычно их и называют термином "CAN протоколы".
    OSI модель протоколов высокого уровня на базе CAN,протоколов TCP/IP

    Для систем реального времени на базе CAN нет необходимости в реализации полной 7-ми уровневой модели OSI(рис. 1). Это связано с тем, что типичная CAN система имеет в своей основе единственный канал данных для обмена сообщениями между устройствами, все устройства ориентированы на конкретный способ передачи данных по каналу, а приложения пишутся именно под данную архитектуру сети и данный протокол. Поэтому нет необходимости в реализации уровня представлений, уровня сеанса и сетевого уровня из 7-ми уровневой модели OSI и были оставлены только 3 уровня этой модели : физический уровень, уровень канала данных и уровень приложений(рис. 2). Причем последний реализует некоторые функции транспортного уровня.
    Нажмите на изображение для увеличения. 

Название:	pict2_1.gif 
Просмотров:	1 
Размер:	3.8 Кб 
ID:	1364 alt="" />
    Рис. 1

    Нажмите на изображение для увеличения. 

Название:	pict2_2.gif 
Просмотров:	1 
Размер:	16.6 Кб 
ID:	1365 alt="" />
    Рис. 2

    Из-за широко использования CAN сетей с различными целями и требованиями существуют несколько главных стандартов CAN-протоколов высокого уровня : CAL (CAN Application Layer), OSEK/VDX, SAE J1939, CANopen, DeviceNet, SDS (Smart Distribution Systems),CAN-Kingdom. Далее более подробно будет рассмотрен стандарт DeviceNet для сравнения с TCP/IP.
    Основные возможности протоколов высокого уровня на базе CAN

    Рассмотрим основные возможности, которые предоставляют протоколы высокого уровня:
    • система назначения идентификатора для сообщения
    • метод обмена данных процесса
    • прямая(peer-to-peer) связь
    • метод установления связей для обмена данных процесса
    • сетевое управление
    • модели и профайлы устройств
    Идентификаторы сообщений

    Метод назначения идентификатора сообщения является главным архитектурным элементом CAN систем, так как идентификатор CAN-сообщения определяет относительный приоритет сообщения и следовательно время обработки сообщения (latency time). Это также влияет на возможность применимости фильтрования сообщения,на использование возможных коммуникационных структур и эффективность использования идентификатора. Что касается назначения идентификаторов сообщений, существуют различные подходы для систем на базе CAN. Некоторые (CANopen) не применяют предопределение идентификаторов для общих структур системы, DeviceNet и SDS делают это.
    Устройства (nodes) в DeviceNet получают постоянный идентификатор. Максимальное количество узлов составляет 64. Каждый узел имеет некоторое множество идентификаторов в одной из 3-х групп в зависимости от приоритета сообщения (рис. 3).
    Нажмите на изображение для увеличения. 

Название:	pict3_11.gif 
Просмотров:	1 
Размер:	3.1 Кб 
ID:	1366 alt="" />
    Рис. 3

    Группа 1 сообщений обеспечивает до 16 высоко приоритетных сообщений на устройство, группа 3 сообщений - до 7 низко приоритетных сообщений на устройство. Группа 2 сообщений предназначена для поддержки устройств с ограниченными способностями фильтрования сообщений. Поэтому для данной группы идентификаторов было выбрано фильтрование согласно номеру узла (MAC-ID). Это означает, что приоритет сообщений этой группы прямо определяется номером узла. MAC-ID группы 2 может быть адресом источника или адресом назначения.
    DeviceNet использует также предопределенное Master/Slave множество связей для облегчения взаимодействия в Master/Slave системной конфигурации (рис. 4):
    Нажмите на изображение для увеличения. 

Название:	pict3_12.gif 
Просмотров:	1 
Размер:	9.4 Кб 
ID:	1367 alt="" />
    Рис. 4

    Поддерживаются следующие функции канала обмена I/O сообщениями и явными (Explicit) сообщениями между Master и Slave устройствами из предопределенного множества связей:
    • явный канал сообщений
    • изменение Master статуса канала (Master Poll Change of State/Cyclic channel)
    • изменение Slave статуса канала (Slave I/O Change of State/Cyclic channel )
    • Bit Strobe канал
    Явный канал сообщений главным образом служит для конфигурации устройства. С изменением Master статуса канала Master может запрашивать данные ввода - вывода от устройства и посылать данные на Slave устройство. C изменением Slave статуса канала Slave устройство может передать данные Master-устройству. При помощи Bit Strobe команды Master-устройство может запросить данные у любого из 64 Slave устройств посредством одного сообщения.
    Oбмен данных процесса

    Передача данных процесса между устройствами распределенной системы - цель системы на основе CAN протокола. Поэтому передача прикладных данных (данные процесса, данные ввода - вывода) системы должна быть выполнена наиболее эффективным путем. CANopen и DeviceNet обеспечивают весьма схожие механизмы связи для передачи данных обслуживания / конфигурации процесса. У CANopen передача данных процесса происходит посредством так называемых "Объектов Данных Процесса (PDOs)", у DeviceNet посредством " I/O-сообщений ".
    В таблице 1 приведены основные характеристики для протоколов CANopen, DeviceNet and SDS. Одним из главных различий является обеспечение протоколами DeviceNet and SDS фрагментации пакетов без подтверждения, что делает возможным передачу данных длиной более 8 байт. Также поддерживаются 3 различных протокола (рис. 4) по отношению к подтверждению приема данных ("Transport Classes") . Например, классы 2 и 3 могут быть использованы для эффективного опроса(polling) устройств. Для той цели master устройство имеет коммуникационные объекты (connection objects), связанные с каждой командой опроса как клиентский транспортный класс 2 или 3. Каждое slave устройство имеет коммуникационные объекты серверного транспортного класса 2 или 3 для получения команд опроса и передачи соответствующих ответных данных.
    Таблица 1. Exchange of Process Data in CANopen, DeviceNet and SDS (Multicasting)

    CANopen DeviceNet SDS (V2.0)
    Name of Communication Object Process Data Object I/O-Message Multicast Channel APDU
    Maximal Number of Communication Objects per Device 512 Transmit PDOs 512 Receive PDOs 27 I/O- Transmit Messages 1701 I/O Receive Messages per device 32 Multicast Channels for each of up to 32 Embedded Objects per device
    Maximal length of Data Field 8 bytes 8 bytes fragmented: Arbitrary length 6 bytes fragmented: 64 * 4 bytes
    Protocol Unfragmented: No overhead, Notify/Read "Stored-Event"-protocol (CAL/CMS) Unacknowledged Unfragmented: No overhead, three "Transport Classes" supported:
    • Unacknowledged,
    • Acknowledged by Server Connection Object,
    • Acknowledged by Application
    Unfragmented: 2 byte protocol overhead, Unacknowledged
    Fragmented: Unacknowledged fragmented protocol 1 byte protocol overhead per frame Fragmented: Acknowledged fragmented protocol with Acknowledge after reception of complete block 4 bytes protocol overhead per fragment
    Message Production Triggering Modes
    • On Request of local or remote application
    • Cyclic/acyclic synchron
    • Cyclic
    • Change-of-State
    • Application specific
    Specified by object model
    Mapping of Application Objects Maximum number of mappable application objects/PDO dependent on data size of objects (1-bit objects: 64 application objects mappable) Definition of Application objects by means of "Mapping Parameter Record" (configurable) Dynamic mapping supported Arbitrary number of Application objects mappable with fragmented protocol. Definition of Application objects by means of Assembly Object (several Assembly Objects possible) Dynamic mapping supported Network Data Descriptor defines size, granularity and data type of I/O data of Embedded Object (V1.8)
    Нажмите на изображение для увеличения. 

Название:	pict3_22.gif 
Просмотров:	1 
Размер:	5.3 Кб 
ID:	1368 alt="" />
    Рис. 5. Device Net Transport Classes

    Вызов (triggering) сообщений

    Все рассматриваемые протоколы поддерживают различные способы вызова сообщений. DeviceNet поддерживает циклический (Cyclic), по состоянию (Change-of-State) и программный (Application) способы вызова. Циклический вызов осуществляется по истечению времени таймера и начинается передача сообщения. Передача по состоянию начинается, когда статус определенного объекта изменяется. В этом случае сообщение также передается, когда истекает определенный интервал времени, в котором не осуществлялась передача сообщения. Программным способом сам объект решает, когда начать передачу сообщения. В этом случае сообщение также передается, когда истекает определенный интервал времени без передачи сообщения.
    Установление соответствий (mapping) для программных объектов

    Сетевые устройства обычно содержат более одного программного объекта и передача I/O сообщения более чем одному программному объекту внутри одного PDO является необходимым требованием. В DeviceNet объединение прикладных данных осуществляется посредством трансляционных (assembly) объектов, которые определяют формат передаваемых данных. Устройство может содержать более одного I/O трансляционного объекта и выбор подходящего (consumed/ produced_connection_path) может быть настраиваемой опцией устройства.
    Прямые (peer-to-peer) коммуникационные каналы

    Для конфигурации устройств посредством конфигурационных средств требуются специальные функции у устройств или программы, обеспечивающие многоцелевые каналы связи. Это не критичные по времени каналы связи. Передача данных в них осуществляется посредством протокола с подтверждениями и фрагментацией. Любой из протоколов высокого уровня, которые поддерживают некоторую конфигурацию устройств, должны обеспечивать этот вид связи.
    DeviceNet обеспечивает многоцелевые устройство ориентированные каналы и сервисы. Запись и чтение атрибутов объектов, контролирование объектов (reset, start, stop etc.), сохранение/восстановление атрибутов объектов осуществляется посредством явных (Explicit) сообщений. Намерение использовать данное сообщение определяется в поле данных CANа. На рис. 7 показан формат поля данных фрагментированного Explicit сообщения. В запросе сервиса указывается номер класса, номер экземпляра(instance), номер атрибута (в поле Service specific arguments).
    Нажмите на изображение для увеличения. 

Название:	pict3_31.gif 
Просмотров:	1 
Размер:	4.8 Кб 
ID:	1369 alt="" />
    Рис. 6. DeviceNet Fragemented Explicit Message Data Field Format (Request/Response)

    Explicit(прямая) связь устанавливается посредством менеджера сообщений (Unconnected Message Manager (UCMM)). UCMM предоставляет два сервиса для открывания и закрывания подобных соединений. Каждое устройство, поддерживающее UCMM, резервирует у себя идентификаторы сообщений для запросов и ответов для UCMM. Для устройств 2-й группы, которые не поддерживают UCMM порт, master устройство сперва должно разместить Explicit соединение в предопределенном множестве соединений. Запрос к устройству группы 2 передается как Explicit запрос без предварительного установления соединения (Unconnected Explicit Request ) с зарезервированным идентификатором сообщения.
    Сравнительные характеристики протоколов CANopen, DeviceNet и SDS в отношении прямых (peer-to-peer) коммуникационных каналов представлены в таблице 2.
    Таблица 2. Main Characteristics of Peer-to-Peer Communication Channels

    CANopen DeviceNet SDS (V2.0)
    Name Service Data Channel Explicit Message Peer-to-peer Channel
    Maximum number of channels 128 Client SDOs, 128 Server SDOs per device 27 Explicit Transmit Messages 1701 Explicit Receive messages per device 4 channels per Embedded Object. 32 Embedded Objects per Logical Device
    Protocol < 5 byte: Acknowledged unfragmented 4 byte: Fragmented transmission (7 bytes per fragment) Each frame acknowledged Any length (CAL Multiplexed Domain protocol) < 7 byte: Acknowledged unfragmented 6 byte: Fragmented transmission. (6 bytes per fragment) Each frame acknowledged Any length < 6 bytes Acknowledged unfragmented 5 byte Fragmented transmission (3 bytes per fragment) Acknowledgement of complete data block. Max. 255 byte
    Establishing of Connections
    • Dynamic establishment by means of Unconnected Message Manager
    • Group 2 Only devices: Allocation of Explicit Message from Predefined Connection Set
    • Dynamic establishing by means of Connection Manager
    • Master/Slave Set of Connections Set
    • Dynamic establishment by means of SDO Manager
    • Default predefined connections
    Connection Services and Arguments Initiate, Abort Upload/Download Segment/Domain Open/Close Creation, Configuration, Start, Stop, Reset etc. of Objects Open/Close Read, Write, Event, Action
    Index and Subindex of addressed Object Directory Entry Object attribute access path, Service arguments Channel Number, Attribute/Action/Event Identifier
    Установление связей для обмена данных процесса

    Распределение идентификаторов для передаваемых сообщений и , соответственно, получаемых сообщений устанавливает коммуникационные пути в CAN сети. Установление взаимодействия возможно через использование предопределенного множества сообщений с уже размещенными идентификаторами сообщений или через переменное распределение идентификаторов для сообщений.
    В системе с предопределенным множеством сообщений "функции" и идентификаторы сообщений уже определены. DeviceNet также использует предопределенное множество сообщений для системы со структурой 1:n. Master устройство, предварительно разместив у себя множество связей со Slave устройствами, "знает" ID сообщений для передачи запроса и ID сообщений для получения ответа, который включает Slave MAC-ID в соответствии с предопределенным множеством связей. Также возможно не предопределять идентификаторы сообщений.
    Сетевое управление

    Так как в CAN-сети мы имеем дело с распределенными приложениями, должны отслеживаться определенные события(отказы различных частей приложения или отказ устройств). Поэтому главными задачами сетевого управления становятся обнаружение и вывод ошибок в сети и предоставление сервисов, позволяющих контролировать статусы устройств и вести координацию устройств. В зависимости от системных решений сетевое управление может вестись явным или косвенным путем.
    В DeviceNet каждое соединение контролируется. Поэтому каждая ожидающая сообщение конечная точка имеет "Inactivity/Watchdog" таймер, чтобы контролировать прибытие сообщения согласно предопределенному времени ожидания. Если время истекает, соединение выполняет действие "Timeout". На рис. 7 показана диаграмма изменения состояний у объекта I/O.
    Нажмите на изображение для увеличения. 

Название:	pict3_51.gif 
Просмотров:	1 
Размер:	3.9 Кб 
ID:	1370 alt="" />
    Рис. 7. Device Net I/O Connection Object State Transition Diagram

    После получения вызова CREAT ( Explicit сообщение) соединение настраивается при помощи подходящей последовательности вызовов явных сообщений и после этого устанавливается. Перед получением доступа к сети каждое устройство должно совершить проверку на дубликат своего MAC-ID. Определенные алгоритмы выбора гарантируют уникальность MAC-ID.
    Контроль может осуществляться также посредством Heartbeat сообщения, которое может посылаться устройствам посредством UCMM в форме сообщения. В поле данных этого сообщения передается состояние устройства. Heartbeat сообщение вызывается объектом Idendity.
    Профайлы устройств

    Для открытых автоматических систем помимо обеспечения связи от входящих в их состав устройств требуется также обеспечение возможности взаимодействия и взаимозаменяемости. Поэтому протоколы высокого уровня (такие как DeviceNet) описывают функциональные возможности устройств в виде модели устройства ("Device Model").
    Помимо описания функциональности устройств модель устройства должна также содержать ряд важных параметров (статус, диагностическую информацию, коммуникационные возможности, конфигурационные параметры и т.д.). На рис. 8 показана модель устройства DeviceNet.
    Нажмите на изображение для увеличения. 

Название:	pict3_61.gif 
Просмотров:	1 
Размер:	4.6 Кб 
ID:	1371 alt="" />
    Рис. 8. DeviceNet Object Model

    DeviceNet профайл должен содержать следующую информацию:
    • модель объекта для устройства
    • формат данных I/O для устройства
    • конфигурационные данные и внешние интерфейсы для этих данных
    В таблице 3 показаны главные функции объектов в DeviceNet.
    Таблица 3. Objects of a DeviceNet node

    Object Function
    Connection Instantiates connections (I/O or Explicit Messaging)
    DeviceNet Maintains configuration and status of physical attachments to DeviceNet.
    Message Router Routes received Explicit Messages to appropriate target objects
    Assembly Groups attributes of multiple objects into a single block of data, which can be sent and received over a single connection
    Parameter Provides a standard means for device configuration and attribute access
    Identity Provides general information about the identity of a device
    Application Supplies application-specific behaviour and data
    Заключение

    Протокол CAN применяется в real-time системах для решения различных задач. В настоящий момент развиваются несколько видов CAN протоколов высокого уровня, таких как CAL ,OSEK/VDX, SAE J1939, CANopen, DeviceNet, SDS ,CAN-Kingdom , в основе которых лежит канальный протокол CAN2.0 (Bosch) , и на основе этих протоколов можно решать проблемы, возникающие в real-time системах, которые невозможно разрешить при помощи других известных протоколов, скажем, TCP/IP.

      Возможность размещать комментарии к сообщениям отключена.

    Метки статей

    Свернуть

    Меток пока нет.

    Новые статьи

    Свернуть

    • Стандартный параллельный интерфейс на PC
      admin
      Основным назначением интерфейса Centronics (аналог-ИРПР-М) является подключение к компьютеру принтеров различных типов. Поэтому распределение контактов разъема, назначение сигналов, программные средства управления интерфейсом ориентированы именно на это использование. Вто же время с помощью данного интерфейса можно подключать к компьютеру и другие внешние устройства, имеющие разъем Centronics, а также специально разработанные УС.

      Основным достоинством использования Centronics для подключения УС по сравнению с ISA является значительно меньший риск вывести компьютер из строя. Главный недостаток этого подхода - значительно меньшая скорость обмена. Назначение 36 контактов разъема Centronics приведено в таблице 1.

      Таблица 1. Назначение контактов разъемов Centronics

      1 /STROBE Out Strobe (Строб)
      2 D0 Out Data Bit 0
      3 D1 Out Data Bit 1
      4 D2 Out Data Bit 2
      5 D3 Out Data Bit 3
      6 D4 Out Data Bit 4
      7 D5 Out Data Bit 5
      8 D6 Out Data Bit 6
      9 D7 Out Data Bit 7
      10 /ACK In Acknowledge (Подтверждение)
      ...
      08.02.2017, 22:45
    • Современные микросхемы драйверов RS-485 фирмы MAXIM
      admin
      Журнал «Схемотехника» №10 2002 г.
      Олег Николайчук
      Целью настоящей статьи является ознакомление читателей с современными микросхемами драйверов сети RS485 фирмы MAXIM, их основными параметрами и особенностями.
      Интерфейс RS485 наиболее часто используется при создании современных локальных сетей различного назначения, как в промышленных изделиях, так и в любительской практике. Основными преимуществами интерфейса являются:
      • Относительно низкая себестоимость микросхем драйверов, что снижает стоимость аппаратной реализации сетевых диспетчеров, т.е. узлов связи между сетевой средой (линиями связи) и ядром станции (узла) сети, т.е. микроконтроллерной или микропроцессорной системой;
      • Использование в сетях на базе интерфейса RS485 всего трех проводов (третий, общий, не всегда является обязательным), что значительно снижает себестоимость всей системы, поскольку известно, что себестоимость сетевой среды современных локальных сетей практически всегда составляет более 60% от стоимости всей системы;
      • Микросхемы драйверов имеют малые габаритные размеры. Наиболее часто используются микросхемы, выполненные в корпусе DIP8 со стандартным расположением выводов, ставшим , промышленным стандартом. Микросхемы драйверов используют всего несколько дискретных элементов для цепей защиты, использование которых не является обязательным. Малые габаритные размеры микросхем драйверов и минимальное количество обвязки экономит площадь печатной платы, что также положительно сказывается на стоимости системы;
      • Современные микросхемы имеют достаточно низкое энергопотребление, многие из них при отсутствии активности в сети автоматически переходят в режим экономии, что снижает энергопотребление системы;
      • Современные микросхемы драйверов имеют повышенную нагрузочную способность. Если раннее большинство микросхем было насчитано на работу с 32 станциями, то современные модели обеспечивают нормальное функционирование до 256 станций;
      • В настоящее время выпускаются микросхемы в высокой предельной скоростью передачи. Это позволяет создавать высокоскоростные сети, и снижает количество ошибок в сети за счет улучшения формы передаваемого сигнала;
      • Драйверы интерфейса RS485 имеют достаточно простое управление. Особенности организации сетей, их схемотехника, способы управления доступом к каналу и примеры программирования достаточно описаны [1-11].
      • Микросхемы интерфейса RS485 выпускают многие фирмы мира [12]. Однако несомненным лидером в разработке и выпуске новых микросхем драйверов является известная фирма MAXIM [13]. В настоящее время фирма выпускает более 80 типов микросхем драйверов интерфейса RS485/422.
      Все микросхемы драйверов можно условно разделить на 4 группы: микросхемы с питанием +5 В, микросхемы с расширенным диапазоном питания от 3 до 5.5 В, низковольтные микросхемы с питанием 3.3 В и микросхемы со встроенной оптической изоляцией. Основные технические характеристики этих групп микросхем приведены в таблицах 1 — 4 соответственно.
      В приведенных таблицах приняты следующие обозначения:
      В колонке «Разрешение RxD»: P — обозначает, что управляющий вход приемника переключает его либо в открытое состояние, либо переводит его в режим энергосбережения, O — означает, что управляющий вход тоько включает/выключает приемник.
      В колонке «Режим»: H — означает полудуплексный режим, т.е. интерфейс RS485, F — обозначает полный дуплексный режим, т.е. интерфейс RS422.
      Прежде чем приступить к анализу таблиц, определим критерии отбора микросхем для последующего рассмотрения. Мы ставим своей целью ознакомление читателя с широко используемыми микросхемами интерфейса RS485 (но не RS422), т.е. с микросхемами, работающими в полудуплексном режиме, которые в колонке «Режим» имеют символ «H». У этих микросхем входы приемника объединены с выходами передатчика и образуют две линии приема/передачи, «A» и «B». Мы не будем рассматривать ряд микросхем, содержащих только приемники или только передатчики, поскольку их применение также весьма ограничено. И наконец, мы будем рассматривать только микросхемы, выпускаемые в корпусе с восемью выводами (кроме микросхем со встроенной оптической изоляцией и микросхем в корпусе 6/5/SO), как наиболее распространенные и используемые.
      Таблица 1. Микросхемы драйверов интерфейса RS485/422 с питанием +5 В
      ТИП Нали чие TxD Нали чие RxD Разре шение TxD Разре шение RxD Состо яние RxD Режим Быстро действие, Mbps Кол-во стан ций Защ ита ESD Пит ание, V Ток потре бления, mA Ток эко номии, чA Корпус
      MAX1481 1 1 NC F 0.25 256 - 5 0.3 0.1 10/µMAX
      MAX1482 1 1 O F 0.25 256 - 5 0.02 0.1 14/PDIP.300
      14/SO.150
      MAX1483 1 1 O H 0.25 256 - 5 0.02 0.1 8/µMAX
      8/PDIP.300
      8/SO.150
      MAX1484 1 1 NC F 12 256 - 5 0.3 - 10/µMAX
      MAX1485 1 1 - NC H- F 0.25 256 - 5 0.3 - 10/µMAX
      MAX1486 1 1 - NC H- F 12 256 - 5 0.3 - 10/µMAX
      MAX1487 MAX1487E 1 1 O H 2.5 128 -
      ±15kV
      5 0.23 - 8/µMAX
      8/PDIP.300
      8/SO.150
      MAX3040 4 0 - - - 0.25 - ±10kV 5 1 0.002 16/SO.150
      16/SO.300
      16/TSSOP
      MAX3041 4 0 - - - 2.5 - ±10 kV 5 1 0.002 16/SO.150
      16/SO.300
      16/TSSOP
      MAX3042B 4 0 - - - 20 - ±10 kV 5 1 0.002 16/SO.150
      16/SO.300
      16/TSSOP
      MAX3043 4 0 - - - 0.250 - ±10 kV 5 1 0.002 16/SO.150
      16/SO.300
      16/TSSOP
      ...
      08.02.2017, 22:45
    • Системный контроллер ввода-вывода для сопряжения шин PCI и ISA
      admin
      Журнал «Chip News» №6 2001 г.
      Ракович Н. Н.
      Мы уже беседовали на страницах журнала о продукции компании Winbond [Л.1], выпускающей широкую гамму разнообразных микросхем, начиная с памяти и микроконтроллеров и заканчивая приборами для мобильных средств связи и распознавания речи. Примерно в середине этого списка находятся ИС для компьютеров. В данной статье рассмотрим контроллеры ввода-вывода W83С553F и W83С554F, которые выполняет функции моста между шинами PCI и ISA. Тема эта должна быть интересна хотя бы уже потому, что смена поколений компьютеров требует от разработчиков встроенных плат с интерфейсом ISA стремительной модернизации оборудования, с тем, чтобы не потерять своих заказчиков.

      Терминология (более чем кратко)....
      08.02.2017, 22:45
    • Реализация последовательной асинхронной передачи данных в микроконтроллерах PIC
      admin
      Введение.
      Серия PIC16Cxx от Microchip Technology, Inc. - это второе поколение высокопроизводительных восьмиразрядных микроконтроллеров на базе EPROM. Некоторые микроконтроллеры из этой серии (например PIC16C71 и PIC16C84) не имеют встроенного последовательного асинхронного порта. Эта статья содержит описание последовательного асинхронного интерфейса ( полудуплексное RS-232 соединение ) с программной обработкой прерывания для микроконтроллеров PIC16Cxx. Эти микроконтроллеры могут работать на очень большой скорости, с минимальной длительностью такта 250нс ( при частоте 16МГц ). Для тестирования RS-232 режима предлагается использовать простой цифровой вольтметр / систему опроса данных ( Digital Volt Meter / Analog Data Acquisition Systems ) выполненный на PIC16C71, Этот прибор принимает команды от ПК и передает обратно восмибитные значения с выбранного АЦП канала.

      Реализация.
      Ниже приведено подробное описание реализации полудуплексного RS-232 интерфейса с программной обработкой прерывания для PIC16C71. В программе примера в качестве передающего выхода используется RB7, а для приема – RTCC/RA4. Конечно, и вход и выход соединяются через соответствующий преобразователь уровней сигнала RS-232 / ТТЛ. Описание преобразователя уровней напряжения дано в разделе Аппаратная часть.

      Режим передачи. Передающий режим в программе напрямую связан с и...
      08.02.2017, 22:45
    • Простой конвертер RS-232-TTL
      admin

      Журнал «Схемотехника» №1 2000 г.
      Александр Нечаев
      При разработке различного рода электронных устройств с использованием микроконтроллеров очень часто оказывается полезной возможность подключения их к персональному компьютеру через последовательный порт. Однако напрямую это сделать невозможно, поскольку по стандарту...
      08.02.2017, 22:45
    • Программирование портов ввода/вывода LPT и ISA
      admin
      Данный материал основан на моём (его) личном опыте работы с материнской платой неизвестного (нет, не солдата) производителя. Чипсет - SIS. Если вдруг в Вашем случае дело будет обстоять другим образом, напишите мне. Также хочу сразу предупредить - я не профессиональный программист!!! Поэтому не ругайте меня за отсутствие проф. терминов, может быть кривых объяснений или ещё каких недочётов,...
      08.02.2017, 22:45
    Обработка...
    X