Jump to content

    

Andy_Mozzhevilov

Свой
  • Content Count

    867
  • Joined

  • Last visited

Community Reputation

0 Обычный

About Andy_Mozzhevilov

  • Rank
    Знающий
  • Birthday 01/23/1971

Контакты

  • Сайт
    Array
  • ICQ
    Array

Информация

  • Город
    Array

Recent Profile Visitors

3073 profile views
  1. Так и есть. В USB данные будут ходить с той скоростью, сколько USB позволит. То, что вы устанавливаете, это фактически настройки для реального COM порта, который может торчать с другой стороны USB. Они уходят отдельными командами и могут быть использованы, если нужно. Например можно сделать конвертер USB-COM и по переданным параметрам устанавливать нужную скорость UART.
  2. а __iar_system_Mtxinit у вас вызывается при инициализации системы? Можете в отладчике это проследить? И еще, как идея, посмотрите про опцию линкера --threaded_lib
  3. Я не думаю, что вы найдете какую-то универсальную платформу "на поиграться" с такими характеристиками, потому что то, что вы ходите обычно не делается универсальным, а проектируется под конкретные требования к сопряжению с какими-то реальными датчиками и объеками управления.
  4. Все зависит от того, что вам требуется. Какой-то субмодуль, где разведена память и процессор, к примеру, или закончанная плата для какого-то специального применения.
  5. Еще добавлю, что как правило TVS не ставят прямо на вход цепи, в которую приходит МИП. TVS ставят уже как второй каскад защиты, а в первом лучше ставить либо варисторы, либо разрядники, либо их комбинацию, в зависимости от защищаемой цепи. Вы бы схему входной цепи привели, чтобы было понятно о цем речь.
  6. Как правило в характеристиках элементов защиты от импульсных перенапряжений указывается и формы импульса тока, для которого приведены их характеристики. В ГОСТ также указана форма импульса тока испытательного генератора для случая его работы в режиме КЗ выхода. Вот вам нужно все это вместе свести и выбрать элемент защиты или цепочку из них.
  7. Определите, какое выходное сопротивление генератора помехи будет применяться для ваших цепей. По ГОСТ может быть 3 варианта: 2 Ом, 12 Ом и 42 Ом. Если речь идет о цепях ввода-вывода, то скорее всего речь будет идти о 42 Ом. Исходя из этого определяйте ток, который должен пропустить через себя элемент защиты, падение, которое на нем будет при этом токе, соответственно будете знать рассеиваемую мощность. Дальше по этим параметрам выбираете нужный элемент или составляете схему из них. МИП - достаточно простая и предсказуемая помеха, разве что мощная.
  8. Требование к сопротивлению изоляции предъявляется к цепям, находящимся под напряжением. В зависимости от величины напряжения есть требования к прочности. То, о чем пишете вы - относится к цепям электропитания 220В. Тут вроде как вопрос по гальванически-изолированным низковольтным цепям. Типа сделали развязку через DC-DC и оптроны интерфейсных схем. Там напряжение в этих цепях не превышает обычно 12В, то есть ниже 48, а для таких цепей требования к прочности изоляции либо не предъявляются, либо они ниже (500В по-моему, не хочется в ГОСТ сейчас лезть). Что касается испытаний на прочность изоляции устройств, где предусмотрены элементы защиты, особенно по питанию со стороны 220, то в этом случае при испытаниях на прочность элементы, установленные для обеспечения ЭМС, удаляются. Это тоже где-то в ГОСТе было.
  9. Читайте тут касательно того, по каким интерфейсам можно заливать флеш через встроенный бутлоадер, USB там тоже есть. http://www.st.com/web/en/resource/technica.../CD00167594.pdf По схеме SK-STM32F417, которую я бегло просмотрел, можно джампером J8 поставить на BOOT0 лог.1, а BOOT1 затянут резистором к нулю. Таким образом получаете активацию системного бутлоадера. Дальше конфигурируете джамперами USB так, чтобы USB-В разъем подключался к PA11 и PA12 портам (тоже это можно сделать, судя по схеме). Ну и все должно заработать для загрузки по USB через DFU. Вопрос такой, если получится, отпишитесь. И что за софт используется для загрузки по USB в этом случае? Бегло искал на ST информацию по этому поводу, но не нашел. Особой надобности не было, правда. А вообще лучше через JTAG или SWD зашивать флеш при отладке, это удобнее гораздо.
  10. Почитайте о принципах работы CAN протокола в стандартах. Там дело в скорости распространения сигнала, поскольку на шине узлы выигрывают арбитраж, подтверждают успешный прием сообщения от передающего узла и т. п. Или уточните, для каких скоростей вы расчет делаете.
  11. Чтобы послать баг с надеждой на его исправление и не имея тех.поддержки крайне желательно его локализовать в неком очень небольшом коде, который бы собрался в составе мелкого проекта, созданного в IDE IAR, архив которого им и отсылать. В вашем же коде просто кусок из программы, который не соберется. А если начать выкидывать что-то, может и баг исчезнуть. Собирайте проект в 5.50, а отладку запускайте хоть в 6.40. Там все совместимо по форматам out файлов. Главное, чтобы сам компилятор мог делать код для нужного ядра. на 6.30 тоже его нет.
  12. Как вы определяете факт старта платы? У вас есть динамическая инициализация, т.е. вы используете С++ и глобальные объекты классов, или у вас чисто С код? Те 20-30 секунд, когда плата находится в непонятном для вас состоянии, осциллятор запускается? Все это происходит только по включению питания, или нормально заработавшая плата может в такое состояние переходить, если ей дернуть Reset?
  13. Вы все же разобрались, стартует у вас бутлоадер, ваш код, или ни то и ни другое и контроллер находится в каком-то неопределенном вами состоянии? Не понятна фраза "Ресет так же не помогает и в течении секунд 20-30 программа нормально стартует." Может кратко в одном посте можете описать последовательность действий и состояний контроллера?
  14. Я достаточно давно ловил баг еще в какой-то 4-й версии компилятора и отправлял им, официальной поддержки не было, ессно. В следующей версии компилятора баг был поправлен, не знаю уж, по моему репорту или нет. Я email посылал не с просьбой о поддержке, а именно как bug report. В конце концов это в их интересах улучшать компилятор. Во всяком случае попробовать надо, особенно если баг хорошо локализован на небольшом участке кода.
  15. Чтобы поправили, надо бы им в поддержку отписать. А то ж они - не телепаты.