Перейти к содержанию

    

Dmitro25

Свой
  • Публикаций

    60
  • Зарегистрирован

  • Посещение

Репутация

0 Обычный

Информация о Dmitro25

  • Звание
    Участник
  • День рождения 11.10.1978

Контакты

  • Сайт
    http://todvk.narod.ru
  • ICQ
    0

Посетители профиля

1 227 просмотров профиля
  1. Сегодня протестировал изменённую схему: одну линию перенёс на CBUS3, а оставшуюся включил инверсно (то есть теперь оптопара включается "1"). Описанные эффекты ушли. Теперь при подключении USB и при загрузке компьютера никаких лишних срабатываний исполнительных устройств. Всем спасибо за участие.
  2. Цитата(@Ark @ Nov 12 2017, 12:10) Что там за оптопары у Вас? Например, для PC817A достаточно 1-2 мА. Тем более, вопрос о скорости переключения, как я понял, не актуален. Питаются же от этих выводов индикаторные светодиоды, оптопара не сильно от них отличается. TLP621-2, 10 мА на каждый вход
  3. Цитата(@Ark @ Nov 10 2017, 20:21) В таком случае, используйте линию CBUS3, непосредственно, для питания ваших оптопар. Или для включения питания оптопар через транзистор. Кстати, для этого она и предназначена по умолчанию. Я думал об этом, но, боюсь, линия может не потянуть по току две оптопары (в описании на саму микросхему недостаточно информации по нагрузочной способности, но в документе по её программированию написано, что выводы, которые "high current io", должны "тянуть" до 12 мА). А транзистор ставить буду только в крайнем случае (если другие способы не заработают), т.к. плата уже изготовлена.
  4. Цитата(mantech @ Nov 10 2017, 23:24) А что мешает сделать так, как положено, поставить в добавок какой-нить дохленький мк, на подобии тини2313 или вообще что-нить 8и-лапое за копейку и работать с байт-ориентированными командами по уарту? Тогда все будет гарантированно надежно... Я в шапке не всё описал для простоты: у меня FT232 занимается опросом датчиков по RS-485, параллельно ещё встала задача управления реле и клапаном - вот я и решил не ставить дополнительный микроконтроллер, а использовал имеющиеся возможности. С микроконтроллером тоже проблемы: его нужно как-то программировать, плюс в маленьких не всегда бывает UART, плюс осциллятор к нему надо, если встроенный в температуре сильно плавает.
  5. Цитата(@Ark @ Nov 10 2017, 18:22) Тогда посмотрите, заодно, что там на TX происходит при старте... Может его можно будет использовать, через Break... Я в шапке не всё описал для простоты: у меня ещё датчики по RS-485 опрашиваются, так что линии Rx/Tx используются по назначению. Сейчас пробую одну линию перебросить на CBUS3, а у второй поменять полярность, чтобы активный уровень был высокий - есть подозрение, что "1" микросхема на выходах при включении не устанавливает. Цитата(mantech @ Nov 10 2017, 18:46) А вы не подумали над тем, что винда видит устройство, как посл. порт со всеми вытекающими последствиями, а именно, детектирование вновь подключенных устройств к порту, попытка их идентификации по методу plug n play, подумайте? Я писал уже выше, что переключение выводов наблюдается даже при инициализации BIOS, когда Windows ещё не начала грузиться. Ну, и если порассуждать отвлечённо, то даже во время того, как Windows пытается как-то работать с микросхемой, с чего бы ей устанавливать линии общего назначения (не имеющие отношения к последовательному порту), если у неё (микросхемы) внутри прописано, что это именно линии общего назначения. Цитата(mantech @ Nov 10 2017, 18:46) ЗЫ. для подобных задач есть мс ft 2232 и ft245, там есть порты, которые так себя не ведут. Что-то меня теперь относительно этого терзают смутные сомнения... Я бы на всякий случай перепроверил.
  6. 2Ark RTS я уже попробовал помониторить. Там тоже наблюдается малообъяснимая (с моей точки зрения) активность вывода, правда, импульсы имеют другой характер (количество и длительность). DTR не пробовал, но что-то мне подсказывает, что будет как на RTS. Насчёт "зря вы их назначили" я не понимаю - производители (FTDI) специально встроили в свои чипы возможность конфигурирования выводов, для этого в самом чипе стоит EEPROM, почему микросхема прямо при старте не устанавливает там положенное Z-состояние? Какая разница, каково назначение вывода по умолчанию, если в конфигурации (к которой у самой микросхемы прямой доступ) прописано "I/O mode"? Кстати, проверил работу остальных bit-bang выводов: на CBUS2 то же, что на CBUS0 и CBUS1, а вот на CBUS3 - никакой посторонней активности как при подключении разъёма USB, так и при загрузке компьютера. Но одной линии мне мало...
  7. Здравствуйте. Решил использовать bit-bang ножки FT232RL для управления реле и клапаном (на 24-вольта) с компьютера. Для этого подключил ножки CBUS0, CBUS1 FTDI к оптопарам TLP621-2, дальше всё стандартное. Оптопары включаются нулём. FT и оптопары питаются от USB. Запрограммировал FT232RL: Hardware Specific - IO Controls - (C0=I/O mode; C1=I/O mode; C2=TXDEN) Hardware Specific - HighIO (High Current I/O's)=True Далее через библиотеку попробовал - всё нормально управляется. Но обнаружился неприятный эффект: 1. Если от платы отключить кабель USB и снова подсоединить, то при подключении кабеля реле и клапан срабатывают 3 раза, т.к. на bit-bang ножках проскакивают импульсы с активным низким уровнем (один длинный импульс порядка 80 миллисекунд и два коротких (по 30 мс каждый)). 2. При включении компьютера пока не загрузилась Windows реле и клапан срабатывают 8-10 раз, причём по крайней мере один раз ещё в BIOS, до загрузки драйверов Windows. Может быть, кто-то сталкивался с подобным поведением, подскажите, как этого можно избежать.
  8. Как задать размер CSTACK?

    Всё, разобрался. Дело оказалось в startup-файле (я его взял из демо-примеров отладочной платы на LM3S6965). Поменял его на на файл "arm\src\lib\thumb\cstartup_M.c", находящийся внутри IARa, добавил дополнительные вектора, обработчик по умолчанию и всё заработало. Единственное важное дополнение: перед определением таблицей векторов необходимо вставить "__root" (в файле от IAR его нет), иначе таблица векторов заменяется линковщиком на взятую из автоматически подключаемой для используемого процессора библиотеки rt7M_tl.a.
  9. Как задать размер CSTACK?

    Здравствуйте. Начал осваивать ARM, использую для компиляции и отладки IAR. Столкнулся с проблемой некорректно работающей функции printf, причина проблемы оказалась в недостаточном размере стека (CSTACK). Что меня неприятно поразило - так это то, что в настройках линкера размер стека задан достаточно большим для моего проекта (0x400). Однако, когда я стал запускать проект в эмуляторе, оказалось, что указатель стека (R13) принимает при старте программы не указанное мной значение, а значительно меньшее. Увеличить начальное значение указателя стека удалось изменением следующей строчки в strtup-файле: Кодstatic unsigned long pulStack[64] @ ".noinit"; Размер массива был увеличен с 64 до 256. Далее pulStack фигурирует в таблице векторов прерываний: Код__root const uVectorEntry __vector_table[] @ ".intvec" = {     { .ulPtr = (unsigned long)pulStack + sizeof(pulStack) }, ... Я так понял, что в качестве первого вектора в таблице прерываний указывается начальный размер стека. Но тогда почему при инициализации вектора не используются константы, связанные с задаваемым размером CSTACK? В результате получается, что заданный для линкера размер CSTACK нигде в программе не фигурирует? Возможно, я взял "неправильный" startup-файл или упускаю какую-то другую важную деталь? PS: контроллер ARM Stellaris Cortex M3 LM3S9971; компилятор IAR for ARM v6.50
  10. М-Плата Спасибо за ответ. Да, с информацией на сайте производителя туговато. Как Вы думаете, упоминаемый выше Pro'sKit 608-384N для обжима подойдёт? И какой лучше провод использовать?
  11. Здравствуйте. Подскажите, пожалуйста, каким инструментом обжимать и какой провод необходим для такого разъёма (шаг 1.25 мм): http://www.aukconnector.com/SeriesDtl.asp?...&Serial=202 Можно ли его как-то паять и обжимать вручную (хотя бы на тонкий МГТФ)? Наши монтажники сильно ругаются на такие разъёмы, но в настоящее время заменить его не на что (платы с ответной частью данного разъёма уже заказаны).
  12. litv Информационная скорость примерно 600 Бод. Допуск примерно от 450 до 750 Бод. С частотой дискретизации сложнее: я планирую сделать декодирование на микроконтроллере общего назначения. Посмотрев реальный сигнал, понял, что можно просто использовать прерывания по фронтам для запуска отдельных частей алгоритма. Если считать по частоте счёта таймера/счётчика, который будет использоваться для измерения длительности положительных/отрицательных импульсов, получается величина частоты дискретизации примерно 1,4МSPS. Тут попробовал модифицировать свой алгоритм следующим образом: сигнал сначала пропускается через некоторое подобие ФНЧ (на входе и выходе которого квантованный по уровню сигнал) - чтобы удалить просечки из сигнала. Затем измеряется длительность импульса логической "1" и длительность следующего за ним логического "0". Длительности сравниваются: если "1" длиннее - считаем, что приняли информационный символ "1"; если "0" длиннее - приняли символ "0". Первые пробы на записанном ранее сигнале показывают более высокую вероятность приёма посылки, чем алгоритм, описанный в моём первом посте. Наверное, стоит ещё подумать над тем, чтобы делать предсказание относительно информационной скорости и в зависимости от него изменять постоянную времени ФНЧ...
  13. litv Да, согласен, данные я уже записал с осциллографа. Не совсем понятно с синхронизатором, как он должен подстраиваться под информационную скорость принимаемого сигнала. ФАПЧ?
  14. litv Вы имеете в виду идею Синхронизатора? А как он будет работать на разных информационных скоростях?
  15. Здравствуйте. Встала тут задача демодуляции ШМ-ПЧ сигнала (точнее, ШМ2-ПЧ сигнала), вот такого: Сигнал с выхода приёмника имеется только квантованный (т.е. значения только "0" и "1"). В присутствии шумов в сигнале появляются "просечки" из "0" в "1" и из "1" в "0", меняется ширина импульсов. Самое неприятное, что частота (т.е. информационная скорость) передатчика может варьироваться плюс/минус 20% от номинальной, а также то, что в сигнале нет ни преамбулы, ни слова синхронизации. Длина одной посылки - 48 бит. Информационная скорость, естественно, может отличаться для разных посылок, а не внутри одной посылки. Можете ли подсказать, как наиболее оптимально декодировать такой сигнал или где можно прочитать про это? Сейчас просто "тупо" измеряю ширину импульса, когда сигнал = "1", при этом отфильтровываю слишком короткие просечки в "0" и в "1". Если ширина импульса укладывается с определённым допуском в диапазон коротких импульсов - считаю, что принят "0", если длинных - "1".