На главную Наши проекты:
Журнал   ·   Discuz!ML   ·   Wiki   ·   DRKB   ·   Помощь проекту
ПРАВИЛА FAQ Помощь Участники Календарь Избранное RSS
msm.ru
Страницы: (2) [1] 2  все  ( Перейти к последнему сообщению )  
    > Atmel AT90S2313 + COM порт , помогите плиз передать данные
      Нужно передать данные с одного компа на другой через COM порт хотя бы в симплексном режиме.
      Есть плата, на которой размещены контроллер Atmel AT90S2313+RS232+кварцевый генератор и кое-какие необходимые мелочи, от нее отходит два кабеля, заканчивающиеся 9-пиновым COM разъемом, в котором используется только 3 пина - TXD, RXD, GND.
      Софт для WinXP написан в Visual Studio C++ 6.0 с использованием класса CSerialPort, скачанного с этого сайта.
      Вот ключевые кусочки кода:
      Пересылка данных:
      ExpandedWrap disabled
        CSerialPort port;
        clock_t start, finish;
        double  duration;
        char temp[20];
        char service='$';
        port.Open(1, 2400);
        if (!port.IsOpen())
        {
            MessageBox("PORT FAILS");
            return;
        };
        port.Write(&service, 1);
        start = clock();
        int Transf=port.Write(Data, Size);
        finish = clock();
        port.Write(&service, 1);
        duration = (double)(finish - start) / CLOCKS_PER_SEC;

      Прием данных (в др функции) :
      ExpandedWrap disabled
        CSerialPort port;
        port.Open(1,2400);
        if (!port.IsOpen())
        {
            MessageBox("PORT FAILS");
            return;
        };
         
        m_VEdit2="Receiving...";
        UpdateData(false);
        start = clock();
        Transf=port.Read(Data,MAXBUFFER);
        finish = clock();
        duration = (double)(finish - start) / CLOCKS_PER_SEC;

      глобальные переменные:
      const int MAXBUFFER=1000;
      char Data[MAXBUFFER];
      int Size;
      А теперь вопросы:
      1) Я правильно понимаю, что ,как правило, COM1, который юзается и для передачи, и для приема на др компе, на матке находится выше, чем СОМ2 (если смотреть на заднюю стенку)?
      2) Реально ли вообще передавать данные чисто через TXD/RXD, без вникания в протокол и использования служебных пинов типа DCD, DTR или WinAPI без них откажется просто отсылать/считывать сигнал по TXD/RXD с заданной частотой(с учетом стартового, стопового и паритетного бита)? А можно ли с использованием ассемблерной вставки получить доступ к этим пинам напрямую?
      3) как будет выглядеть Atmel ASM код, который нужно зашить в микроконтроллер? там наверно в пределах 6-7 строк. :unsure:
      Заранее спасибо
        1. Обычно да, если их несколько
        2. Точно не отвечу, не работал с СОМ портом
        3. Код полностью зависит от того что должен делать контроллер, как построена схема, какие элементы и т.д.
        Плюс можно писать и на сишке. Есть компиляторы C для AVR, например WinAVR (http://winavr.sourceforge.net/)
        И ещё момент, AT90S2313 давно снят с производства. Он заменен ATTiny2313. Распиновка та же, только более современный и мощьный.
          Цитата Radagast @
          Реально ли вообще передавать данные чисто через TXD/RXD, без вникания в протокол и использования служебных пинов типа DCD, DTR
          да.

          Цитата Radagast @
          А можно ли с использованием ассемблерной вставки получить доступ к этим пинам напрямую?
          нет.
            Цитата
            AT90S2313 давно снят с производства

            плата уже готова :) надо заставить ее работать
            trainer
            уточните плиз, вот тот С++ -шный код с 1го поста будет работать корректно, даже если служебные пины не задействованы?
              Цитата Radagast @
              уточните плиз, вот тот С++ -шный код с 1го поста будет работать корректно, даже если служебные пины не задействованы?
              Я не знаю внутреннего устройства CSerialPort. Чтобы не влияли DTR/DSR, RTS/CTS, XON/XOFF, надо в параметрах порта выключить программное/аппаратное управление потоком данных.
                trainer
                описание класса:
                ExpandedWrap disabled
                  void Open( int nPort, DWORD dwBaud = 9600, Parity parity = NoParity, BYTE DataBits = 8, StopBits stopbits = OneStopBit, FlowControl fc = NoFlowControl, BOOL bOverlapped = FALSE);

                Метод использующийся для контроля потока данных. Может принимать след. значения:

                enum FlowControl
                {
                NoFlowControl,
                CtsRtsFlowControl,
                CtsDtrFlowControl,
                DsrRtsFlowControl,
                DsrDtrFlowControl,
                XonXoffFlowControl
                };

                bOverlapped TRUE если Вы хотите открыть в режиме overlapped, иначе FALSE для использования блокирующих вызовов.

                походу по умолчанию весь контроль отключен... :unsure:
                а что значит overlapped?
                Сообщение отредактировано: Radagast -
                  Цитата Radagast @
                  2) Реально ли вообще передавать данные чисто через TXD/RXD, без вникания в протокол и использования служебных пинов типа DCD, DTR или WinAPI без них откажется просто отсылать/считывать сигнал по TXD/RXD с заданной частотой(с учетом стартового, стопового и паритетного бита)? А можно ли с использованием ассемблерной вставки получить доступ к этим пинам напрямую?
                  3) как будет выглядеть Atmel ASM код, который нужно зашить в микроконтроллер? там наверно в пределах 6-7 строк. :unsure:
                  Заранее спасибо

                  2) да... на прямую - нет...про частоту...
                  а) необходимо знать параметры настроек со стороны МК. Подбирать можно если Вы знаете тактовую МК, тип МК, приблизительно что передаёт (имееться ввиду сами данные)...
                  б) частота последовательной передачи сильно зависит от кварца служащего для тактирования МК. Лучше всего со скоростями определиться - заглянув в даташит на данный МК. Вы сможете точно определить верхнию границу тактовой...
                  в) после нахождения параметров связи (параметры инициализации ком порта) - рекомендую выключить буфферизацию на передачу и делать тайм-ауты между байтами. Задержку подобрать лучше экспериментально и немного увеличить. Дело в том, что буффер приёма на МК как правило в один байт. Нужно обеспечить выемку со стороны МК переданного байта. Не всегда программа на принимающей стороне реализована так, чтобы обеспечивать прохождение без доп. тимингов...
                  3) код может выглядеть по разному...вариант а) - обслуга по прерыванию...смысл - при приёме очередного байта - прерывание которое вынимает байтик из буффера и сохраняет его в ОЗУ, либо обрабатывает - зависит от логики.. б) - обслуга по спулингу. ком порт постоянно опрашивается в некотором общем цикле для всей программы. при приходе символа - идёт сохранение в буффере и(или) обработка...

                  передача как правило всегда синхронна, хотя опять же никто не мешает и её навертеть асинхронную...если микроконтроллер AVR - вряд ли 6,7 строк... немного поболее :))) элементарные примеры - смотрите в даташитах на тот или иной МК. Примеры, как правило, есть на азме и на сях.


                  с уважением
                  (круглый)
                  ЗЫ
                  Рекомендую заюзать обращение к порту напрямую (хотя - хз, может класс Вам и поможет). При обращении напрямую к порту - не забывайте сбрасывать статус порта (помойму после каждого приёма) - иначе может затнкуться в неподходящий момент времени...
                    Цитата Radagast @
                    А можно ли с использованием ассемблерной вставки получить доступ к этим пинам напрямую?

                    Если Win выше 98 - нет.
                    Цитата Radagast @
                    как будет выглядеть Atmel ASM код, который нужно зашить в микроконтроллер? там наверно в пределах 6-7 строк.
                    Заранее спасибо

                    Побольше. Настройка генератора, настройка пинов для работы в режиме порта, настройка самого порта, включение модуля порта, настройка прерывания от порта, разрешение прерывания - все это навряд ли уложится в 7 строк asm кода микроконтроллера. :D
                      Итак, пока что тестируем МК сам по себе. Хочу посмотреть на тестере, что выдается на TXD при работе UART'a. Такой ведь код правильный?
                      ExpandedWrap disabled
                        .DEVICE AT90S2313
                        .CSEG
                            LDI UBRR, 95    ;4800 bauds, clock 7.3728 MHz
                            SBR UCR, 3  ;transmit enable
                            LDI R0, 0xFF    ;output "1"
                        LOOP:   LDI UDR, R0
                            JMP LOOP

                      и еще одна вещь меня очень беспокоит...
                      логическая "1" для CОМ порта это от -3 до -12 В, "0" от +3 до +12 В
                      а вот для ОМК (и UART'a ? ) "0" это скорее всего 0 В, а "1" где-то 5 В
                      в офиц документации точных цифр так и не нашел <_<
                      т.е. придется еще лепить кучу транзисторов для преобразования? или можно как-то программно заставить МК работать по-другому?
                        Цитата Radagast @
                        т.е. придется еще лепить кучу транзисторов для преобразования?

                        МАХ232,SD232 - микросхемы конвертеры - и ничего "лепить" не нужно. :D
                        Цитата Radagast @
                        или можно как-то программно заставить МК работать по-другому?

                        Насколько я знаю - нет. Но даташит на контроллер обязан прояснить эту ситуацию. :)
                          Цитата
                          МАХ232,SD232 - микросхемы конвертеры

                          спасибо, попробую заюзать :)
                          а код-то из 9го поста правильный?
                            Цитата Radagast @
                            а код-то из 9го поста правильный?

                            Нет. При таком раскладе модуль USART не включен - выводы контроллера работают как биты порта D, причем на ввод (по умолчанию после сброса). Попытка вывести байт FFH даже при включенном USART - максимум, что ты увидишь на экране осциллографа - высокий уровень, за который (ошибочно) можно принять и импеданс (особенно если на выходе будет вход МАХ"а). :) Что бы четко увидеть - рекомендую передавать 55Н - будешь наблюдать перепады уровня на выходе. :D

                            Добавлено
                            Еще маленькое но. Передачу следующего символа (загрузку регистра передатчика) нужно производить не ранее окончания передачи предыдущего, о чем тебя известит прерывание от передатчика (которое нужно настроить и, соответственно, разрешить + написать обработчик, расположенный по нужному вектору) т.к. очередь передатчика не резиновая и состоит всего из одного дополнительного регистра - следовательно передача различных байт в таком виде приведет к потере 3 байта, о чем тебя тоже известит регистр статуса передатчика, который ты и не подумал проверить перед подачей в передатчик очередного байта. :D Вывод - нужно более "трепетно" относится к рекомендациям разработчиков, которые они "доносят" до нас в даташитах. :D
                              medved_68 я не уверен, что получится достать осциллограф, хотелось бы просто увиделть +5 В на вольтметре, т.е. постоянную логич. "1" (ятп логич "0" это ~0 В) - на выходе TXD и примерно -10 В на выходе MAX232 - убедиться, что МК вообще работает и прошивается.
                              Цитата
                              модуль USART не включен - выводы контроллера работают как биты порта D, причем на ввод (по умолчанию после сброса).
                              а как это решается? Оо разве загрузки регистров UBRR и UCR недостаточно? при том, что по умолчанию все прерывания отключены

                              я исправил код:
                              ExpandedWrap disabled
                                .include "2313def.inc"    
                                    ldi r16,95  ;4800 bauds, 7.3728 MHz
                                    out UBRR,r16
                                    sbr r16, 3  ;transmit enable
                                    out UCR,r16
                                    ldi r16, 0xFF   ;output "1"
                                LOOP:   out UDR, r16
                                    rjmp LOOP
                              Сообщение отредактировано: Radagast -
                                Цитата Radagast @
                                что готовый проект компилится нормально, а те же самые команды, которые я написал, вызывают ошибку?

                                Есть такая директива - include. При помощи этой директивы подключается файл где есть такое:
                                ExpandedWrap disabled
                                  UBRR equ 0x0009;
                                и т.д. Этим ты даешь понять компилятору, что метку UBRR нужно заменить на адрес регистра 09Н. Иначе:
                                Цитата Radagast @
                                Illegal argument type or count

                                тебе же русским языком говорят, что плохой, неизвестный и т.п. аргумент. :D Если ты не знаешь, где этот файл подключен (нет исходника работающего кода и т.д.), то изволь вручную набить в начале своей программы все эквиваленты регистров или же оперировать не мнемоникой (типа UBRR), а реальными адресами в НЕХ коде. :)
                                Цитата Radagast @
                                а как это решается? Оо разве загрузки регистров UBRR и UCR недостаточно?

                                А каким битом ты его включаешь и где? :)
                                  medved_68 я отредактил пост, глянь плиз :)
                                  теперь все норм компилится, отослал HEX на прошивку...

                                  Добавлено
                                  у меня есть этот инклуд
                                  0 пользователей читают эту тему (0 гостей и 0 скрытых пользователей)
                                  0 пользователей:


                                  Рейтинг@Mail.ru
                                  [ Script execution time: 0,0713 ]   [ 16 queries used ]   [ Generated: 24.04.24, 13:04 GMT ]