Рекомендации по логическим схемам и последовательной связи - PullRequest
1 голос
/ 30 января 2010

Насколько я понимаю, последовательный порт до сих пор, передача данных осуществляется через контакт 3. Как показано здесь: Serial Port Pinout

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

Мне кажется, что лучшим подходом было бы, чтобы один из выводов последовательного порта отправлял импульс, указывающий, что следующий бит готов к сохранению. Поэтому, если мы подключаем эти выводы к сдвиговому регистру, мы в основном имеем: (некоторый импульсный вывод) -> clk, tx-> d

Это обычная практика? Есть ли причина не делать этого?

РЕДАКТИРОВАТЬ

Майк не должен был удалять свой ответ. Этот I 2 C (2-контактный последовательный) подход кажется довольно близким к тому, что я сделал. На последовательном порту нет часов, вы правы, но это в основном то, что я сделал. Смотрите здесь:

private void SendBytes(byte[] data)
{
    int baudRate = 0;
    int byteToSend = 0;
    int bitToSend = 0;
    byte bitmask = 0;

    byte[] trigger = new byte[1];
    trigger[0] = 0;

    SerialPort p;
    try
    {
        p = new SerialPort(cmbPorts.Text);
    }
    catch
    {
        return;
    }

    if (!int.TryParse(txtBaudRate.Text, out baudRate)) return;
    if (baudRate < 100) return;
    p.BaudRate = baudRate;

    for (int index = 0; index < data.Length * 8; index++)
    {
        byteToSend = (int)(index / 8);
        bitToSend = index - (byteToSend * 8);
        bitmask = (byte)System.Math.Pow(2, bitToSend);

        p.Open();
        p.Parity = Parity.Space;
        p.RtsEnable = (byte)(data[byteToSend] & bitmask) > 0;

        s = p.BaseStream;
        s.WriteByte(trigger[0]);

        p.Close();
    }
}

Прежде чем кто-нибудь скажет мне, насколько это безобразно или как я разрушаю свои скорости передачи, мой быстрый ответ - меня это не волнует. Я хочу сказать, что это выглядит намного проще, чем метод, который вы описали в своем ответе nobugz. И было бы не так страшно, если бы класс .Net SerialPort дал мне больше контроля над сигналами выводов. Существуют ли другие API последовательного порта, которые это делают?

Ответы [ 2 ]

2 голосов
/ 30 января 2010

Это уже работает таким образом. Каждый байт передается с начальным битом без данных. Это позволяет приемнику синхронизировать свои часы. И есть, по крайней мере, один стоповый бит, который позволяет приемнику проверить, что скорость передачи данных не настолько велика, что последний переданный бит данных ненадежен. С 8 битами данных это дает 10 полных битов, обеспечивая 10% допуска на скорости передачи данных. Отключение больше порождает ошибку кадрирования.

Ранние разработки ПК с готовностью воспользовались этим. Часы UART были сгенерированы дешевым кристаллом, присутствующим в любом телевизоре для синхронизации несущей цветности с цветовой вспышкой, 3,579545 МГц. Генератор делит его на два, UART делит входные часы на 16, получая 3579545/32 = 111861 Гц. Затем делитель скорости передачи данных выбирает частоту, делитель для 9600 бодов равен 12. 111861/12 = 9322 бодов, ошибка 2,9%. Хорошо в пределах 10% допуска. Также объясняет, почему 110 000 бод были максимальными.

0 голосов
/ 26 марта 2010

Насколько я могу судить, подход похож на подход I2C, описанный здесь .

...