Проблема передачи GSM-модема

У меня проблема с работой этого модема GSM с FPGA (Spartan 3). Я уже реализовал передачу UART на стороне FPGA, MAX232 для преобразования TTL-> RS232 и сдвиг логического уровня 3,3V-> 5V для взаимодействия FPGA с MAX232.

Я могу видеть сообщения, отправленные FPGA на моем ПК (используя последовательный монитор Arduino) с помощью этого FTDI Breakout . Я также могу общаться с GSM-модемом, используя последовательный монитор Arduino для входа в режим AT-команд и отправки текстовых сообщений.

Однако, когда я отправляю то же сообщение с FPGA на модем, я получаю пустое текстовое облачко на свой телефон. Я дважды проверил настройки скорости передачи данных, структуру строки (включая возврат каретки в конце каждого текстового сообщения) и порядок подключения TX (FPGA) -> RX (GSM).

Я до сих пор не понимаю, почему терминал Arduino может связываться с модемом, но то же самое сообщение, отправленное с FPGA, не передается на мой телефон.

Настройки UART: 115200 бод, 8 бит данных, 1 стоповый бит, без четности, без управления потоком. Передача VHDL UART и компонент генератора тактовой частоты 115200 Гц показаны ниже для справки.

РЕДАКТИРОВАТЬ: Как работает модем:

Модем требует использования AT-команд к нему через SMS или Serial для его настройки. Мне нужно, чтобы просто отправлять текстовые сообщения, поэтому для этого я должен установить скорость передачи данных, которую будет использовать FPGA, т.е. по умолчанию 115200 Гц и режим работы, т.е. SMS. Затем выйдите из режима AT и возобновите прозрачный режим. См. стр. 5 и 7 для описания прозрачного режима и иллюстрации процесса передачи.

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

Таким образом, модем находится в прозрачном режиме и ожидает данных текстового сообщения, когда он подключен к FPGA. Модем не передает никаких данных на хост (FPGA/последовательный монитор) в прозрачном режиме. Он ищет только данные текстового сообщения в т.е. RX (GSM)

Генератор бод:

 clk_115200Hz : process(clk,reset,clock3_tmp)
        variable a3: integer range 0 to 217;
            begin
                if(reset='1') then
                    a3:=1;
                    clock3_tmp<='0';
                elsif rising_edge(clk) then
                    a3 :=a3+1;
                if (a3 = 217) then
                    clock3_tmp <= not clock3_tmp;
                    a3 := 1;
                end if;
            end if;
         clock3 <= clock3_tmp;
     end process;

Уарт-передача:

  uart_transmit: process (clk,reset)
     variable bit_count: integer range 0 to 9:=0;
     begin
        if(reset='1') then
            tx_line<=idle;
            bit_count:=0;
            TX_DONE<='0';
            elsif rising_edge(clk)then 
                if(enable= '1')then
                    if(TX_READY = '1')then
                     if(bit_count=9)then
                        TX_DONE<='1';
                        tx_line<=idle;
                        bit_count:=0;
                     else 
                        tx_line<=TX_MESSAGE(bit_count);
                        bit_count:= bit_count+1;
                        TX_DONE<='0';
                     end if;
                    elsif(TX_READY = '0')then
                     tx_line<=idle;
                    end if;
              end if;
            end if;
     end process;
Попытка сделать это только с помощью HDL-кода неразумна, правильное управление мобильным модемом для передачи данных действительно требует программируемого ядра, которое может запускать программное обеспечение . И вы не можете просто бросать ему вещи, вам нужно отслеживать ответы и отправлять только тогда, когда они указывают, что он находится в надлежащем состоянии.
@ChrisStratton Я согласен с вами, однако я студент, и это требование моего проекта, поэтому у меня действительно нет возможности использовать другой способ управления модемом. Так что мне нужно, чтобы этот способ работал. Но я посмотрю на то, что вы упомянули, спасибо
См. UART - это асинхронная логика без часов. Вот почему нам нужно установить скорость передачи априори. Из вашего кода я вижу, что вы выбираете скорость передачи = 115200 Гц. Генератор считает до 217. Это означает, что вы установили clk = 25 МГц (24,998 МГц, если быть точным). Теперь, когда я смотрю на вашу логику uart_trnasmit, вы вовсе не используете clock3. Вот где опечатка! В логике uart_transmit вы должны использовать clock3 вместо clk. Потому что сейчас технически вы работаете со скоростью 25000000 бод.
@SourabhTapas на самом деле не следует использовать разделенные часы в FPGA, скорее логика должна использовать сгенерированные часы DLL (или что-то еще), но использовать разделенный сигнал в качестве включения часов .
Академические настройки @SimeonR иногда выбирают неправильную платформу. Рассмотрим небольшой процессор с программным ядром в вашей ПЛИС. Даже если вы попытаетесь сделать это на HDL, вам нужно будет сначала построить асинхронный последовательный приемник и сделать так, чтобы все правильно реагировало на ответы модема. Посмотрите на фактическое программное обеспечение , которое управляет этими модемами, чтобы понять, что вам нужно построить - требование не меняется, вы просто выбрали более сложный, чем необходимо, способ, чтобы попытаться реализовать это требование.
@SourabhTapas Генератор бод и объекты передачи находятся в разных файлах. Таким образом, синхронизация связана с передающим объектом через другой объект, но я не показывал его, потому что это было бы слишком много кода для публикации. Если бы моя плохая скорость была отключена, я не думаю, что серийный монитор Arduino что-нибудь уловил бы.
@SimeonR - разные приемники будут иметь разную устойчивость к ошибкам скорости передачи. Но ваша проблема, вероятно, заключается в отправке модему неправильных данных в неподходящее время, а не только в скорости передачи данных.
@Simon R Сопоставили ли вы порт clock3 с clk файла/компонента uart_transmit? Дайте мне знать. Последовательный монитор Arduino — это другая реализация, верно! Он должен иметь некоторую логику кода на языке C! Не так ли? Или это просто терминал? Я использовал Тератерм.
@SourabhTapas Да, я сопоставил порт clock3 с uart_transmit. Также да, я просто использую последовательный монитор, как вы использовали бы Тератерм. Должен ли я вместо этого попробовать Тератерм?
@ChrisStratton Вот почему я запутался, потому что я уже настроил модем с номером получателя, рабочим режимом (SMS) и т. д. Так что все, что он делает в прозрачном режиме, это берет любые данные, которые он получает, и отправляет их в виде текста. Я посмотрел на форму волны, которую FTDI производит по сравнению с FPGA, на осциллографе, и они идентичны с точки зрения битовых переходов, что касается времени, и мне придется вернуться к нему.
Без точных сведений о том, что вы отправляете, или объяснения того, что должен делать модем (ссылки на покупку не в счет! ) или информации о принимающей стороне, вряд ли вы получите ответ.
@simon R Да, вы можете попробовать общаться с помощью Teraterm. Это не займет много усилий. Скачать из поиска Google. Убедитесь, что вы все еще получаете «пустой текстовый пузырь»?
@ Крис Стрэттон согласился, Мы можем использовать PLL/DLL для часов. Я предоставляю входные данные на основе того, что он уже реализовал для генератора бод. В любом случае, для UART и этой скорости передачи данных 115200 x 217 = 24,998 МГц такой допуск вполне допустим. Я бы сказал, что 218 тоже подойдет.
@ChrisStratton Я добавил дополнительную информацию о модеме. Надеюсь, это поможет.
@SourabhTapas, пустой текстовый пузырь все еще отображается на моем телефоне, однако сообщение приходит через тератерм

Ответы (1)

На самом деле проблема заключалась в ошибке часов, как указано в комментариях к моему первоначальному вопросу. Была задержка в два такта, когда я тянул линию передачи от низкого уровня к высокому, чтобы сигнализировать о начале, а затем снова от высокого к низкому, чтобы сигнализировать об остановке (от одного из моих других объектов, которые отвечали за переключение сигнала TX_READY) . Покопавшись в руководстве, я обнаружил, что он использует проверку часов, чтобы определить, когда он готов передать данные на телефон, а задержки заставили модем сбросить свой буфер, а затем передать все, что он получил, что из-за задержки было ничем.

Спасибо пользователям Sourabh Tapas и Chris Stratton за помощь в выявлении этих проблем.