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

k155la3

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

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

  • Посещение

Репутация

0 Обычный

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

  • Звание
    Профессионал
  • День рождения 12.01.1965

Контакты

  • Сайт
    http://
  • ICQ
    0

Информация

  • Город
    Днепр

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

8 020 просмотров профиля
  1. шо-то уж очень бИстро. Версия из даташита - 13 - 260μs Conversion Time ps Не тратьте Вы время на эти 8-разрядные, с хреновой отладкой, процессоры (IMHO). Смотрите ARM, самое "ходовое" STM - у них все побыстрее. googl, "tcd1304 stm32" Вот, например 72 MHz STM32F103 посмотрите, 2 x 12-bit, 1 µs A/D converters (up to 16 channels) отладка поддерживается самими IAR. Визуальная настройка периферии и генерация "стартового" проекта - Cube.
  2. Помеха на линии программирования "напрямую" или по (через) линии питания процессора. Уменьшите длину кабеля USB до 0.5-1 m. Устраните все возможные находящиеся рядом источники ЭМИ - импульсные БП с неизвестной родословной, флюорисцентные лампы (да и LED 220 тоже). Например рядом находящееся такое DC-DC однозначно сбивает работу STLink. Перебор разных кабелей USB проблему не вылечил. (очевидно наводка идет не на USB а на линии SW или JTAG)
  3. Я фотоаппарат привел как пример. Понятно, что Linux в коммерческих и серьезно-ответственных девайсах применять довольно "стремно", даже по причине, что спросить-то за трабл, в случае чего, не с кого. С другой стороны, если из загрузки Linux срезать 90(99) процентов отсутствующий в данном девайсе периферии - "почему нет" ?
  4. проблемы с прошивкой МК

    1. Замените для проверки источник питания программатора и процессора на аналоговый или даже батарейный, с достаточным током. И правильным напряжением. Возможно причина в импульсном преобразователе источника питания, а точнее мощной помехе от него (по линиям питания и не только). У меня аналогичная ситуация была с STM32. 2. Прошейте Вашим программатором другую плату и другим программатором Вашу плату. 3. Если используется USB - замените кабель на заведомо "правильный" с минимальной длиной (для проверки достаточно "хвостик" 10-30 см.)
  5. (1) да, один из критериев для меня - время готовности после включения. В моем случае, до 3 сек. приемлемо. (2) не военно-зеленая или медицинская, а средне-потребительского уровня (тотже Canon EOS 50D, мне нравится эргономика и "время отклика" интерфейса, да и по надежности за 5 лет эксплуатации замечаний нет ВООБЩЕ). Гибридная система из RTOS + OS интересно.
  6. Да, я видел (возможно на этом сайте) SDK под это. Но это уже "навеска" на ОС.
  7. Какая ОС в firmware фотоаппарата Canon EOS 50D итд ------ Какие ОС используются для реализации встроенного ПО серьезной (более-менее) техники, например фотоаппаратов Canon средне и старших моделей ? Вот, пока ждал ответа, сам нашел для Canon: Canon: DRYOS Но вопрос не именно в Canon, а в том, что вообще применяется для таких целей из ОС. (тайная надежда на Linux). (Смартфонные ОС меня не интересуют)
  8. Электрическая надежность STM32.

    ну так технологии изготовления "немного" отличаются, я думаю. И сложность чипа тоже. А разрабатывать схему, исходя из как-бы штатной ситуации с выгоранием пина в процессоре без выхода из строя процессора - как-то не по фен-шУ-йУ. Вышел из строя (отгорела нога на процессоре) порт входа аварийной сигнализации (красной кнопки). Процессор работает. Что дальше ?
  9. Электрическая надежность STM32.

    Работают девайсы (F100) в промышленном стендовом оборудовании, наличие импульсных токов, также двигатель+частотник присутствует. Из специфики по защите - опторазвязка по линиям связи, ограничители напр. по входным цепям, LC фильтр по питанию процессора, Иногда новые (как декларируется) процессоры имеют повышнный ток потребления, вплоть до существенного нагрева. Но это вопрос скорее, на каком "базаре" их покупали, и какими руками паяли. С MSP430 были аналогичные траблы, но до нагрева дело не доходило, ограничивалось десятком-другим mA.
  10. Если Вам приходится высчитывать наносекунды (пусть даже и сотни), то вывод - одно из двух: или надо брать более мощный процессор, или - выносить из софта критичные по времени операции во внешние (аппаратные) схемы. Есть еще вариант - изменить алгоритм, как "в консерватории подправить" :) ps - респект за настойчивость.
  11. Набор для разработки на ARM

    Вот может кто тоже интересуется STM32 + Linux Linux на STM32F429 (DISCO), STM32F7xxx https://elinux.org/STM32
  12. Красота наводит на мысль использования автомата (FSM) + события от таймера по сработке от CCR. CCR - перезагружается на требуемый интервал. Но красиво не всегда (разве что самолет) оптимально.
  13. Сделайте полный "ресет" работ. И начните его с проверки "распиновки" матрицы в соотв-ии с даташитом :) (уж очень много там пинов NC) и правильности подключения. Затем осцилографом - выполнение диаграммы сигналов по даташиту. (частота тактирования должна быть в диапазоне мин-макс).
  14. CAN не редкость, напр. STM32F103 итд. Используется как один из стандартный интерфейсов в упомянутых PLC. В протоколе должна быть как минимум реализована проверка целостности пакета по CRC (в CAN это уже имеется, как и адресация узлов). Из "сложностей" CAN - потребуется внешний трансивер 82C250 или другой (много аналогов). Развязка - по линиям Tx,Rx между трансивером и контроллером. ps развязка для CAN на оптронах pg 9
  15. 115200 - это 1-2 стандартных страницы текста в секунду. Если в лог (на драйвер) выдать 3-4, то должна отработать буферизация на передающей стороне. На принимающей стороне - аналогично (для выдачи на терминал с буферизацией входного потока после драйвера COM). Вопрос к "писателю" терминала для его корректной работы на 115200.