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

shans

Свой
  • Постов

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

  • Посещение

Репутация

0 Обычный

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

  • Звание
    Участник
    Участник
  1. ATmega16-16AI и ATmega16-16AU

    В обновленных даташитах атмела эта информация уже появилась.
  2. Требуется доступный в продаже DC-DC преобразователь с возможностью внешнего управления выходным напряжением. Управление может быть как аналоговым, так и цифровым, принципиального значения не имеет. Входное напряжение не менее 30В, выходное 24В с возможностью изменения минимум процентов на 30 в меньшую сторону. Максимальная выходная мощность 50 Вт. Существует ли что-то подобное?
  3. Яйцо с курицей не сравнивайте :cranky: RS485 - физический уровень. CAN - два уровня OSI.(аппаратный арбитраж, фильтрация пакетов и т.п.) А вот так и сравниваю. CAN в любом случае нужно привязывать к физическому уровню, а RS485 к программной реализации. Да и не только это. Вот и смотрю, во что выльется решение в целом в том и другом случае. Предложите свой подход - рассмотрю и его.
  4. LIN работает при помощи открытых коллекторов, т.е. по монтажному ИЛИ. При 20 кбод на 40 м работает. CAN на 40 метрах может работать в полный рост - 1Мбод при родном драйвере, это в _50_ раз быстрее... Кстати где то читал что есть драйверы позволяющие тянуть CAN более чем на километр(если незапамятовал то до пяти) и работать на скорости более мегабита правда при уж совсем децких расстояниях. Ну тогда неправильно выбран интерфейс.CAN это полевая шина(название говорит само за себя) и предназначен для распределения девайсов в пространстве.Тут подошел бы ethеrnet(благо он сильно подешевел и в виде XPortа нетребует вобще никакой разработки) или вобще чтонибудь децкое типа SPI,I2c или нахудой конец проверенный веками RS-485. SPI, I2C не катят однозначно, а вот RS-485 тоже рассматривается как один из вариантов. Насчет полевой шины: интерфейс был изначально разработан для автомобильных дел. Сомневаюсь, что там километры шины :)
  5. Ну не такие уж копейки, а на километр мне тянуть не нужно, всего несколько метров. Собственно я сам за использование драйверов, дабы не создавать себе же лишние проблемы. Однако, как водится, на любой дополнительный корпус смотрят косо, и его использование нужно мотивировать :)
  6. Если в системах на базе RS-232 это может и прокатит но вот в RS-485 и CAN(который использует похожую физическую линию) нет.Во первых потому что это шинные интерфейсы(т.е подразумевается что устройств будет больше двух) а главное то что в обычно используемой физической линии CAN нет состояний 0/1 а есть доминантное и рецесивное. Если кратко то эти состояния неравноценны(как 0 и 1) и когда одно устройство выставляет рецесивное состояние другое устройство может задавить его доминантным чем и достигается контроль передачи и неразрушающий арбитраж.Вот эта фича и обеспечивается драйвером. Как это делается в других физических линиях(оптика и блютуз) мало понятно но скорее всего идет эмуляция привычной CANу физической линии. Ну а если объединить по монтажному "И"? Вполне получаем доминантный и рецессивный уровень. А стоимость реализации значительно ниже. Понятно, что с уровнями под стандарт ISO 11898 не попадаем, но это уже другой вопрос. Извиняюсь, если задаю бестолковые вопросы :), просто хочу уяснить преимущества решения с использованием трансиверов.
  7. Так насколько я понял, физический уровень не оговорен, т.е. почему бы уровням линии не совпадать с уровнями контроллера?
  8. Только начал разбираться с CAN-интерфейсом, что-т не догоняю: обязательно ли использование трансиверов? Или возможно подключение без них?
  9. Согласен с тем, что было сказано выше. Выходная мощность меньше 1Вт, если не нужна гальваническая развязка, то просто умножитель и линейный стабилизатор. Если нужна - то разделительный транс с умножителем на выходе, либо повышающий без умножителя (что под рукой окажется) и опять-таки линейный стабилизатор. При данной выходной мощности массо-габариты транса минимальны, поэтому нет резона связываться с импульсным преобразователем: особо ничего не выиграете, а реализация сложнее. Хотя когда-то достаточно просто реализовывали 12В -> 3000В 10ма со стабилизацией напряжения и ограничением тока: двухтактный ШИМ с неизменным коэффициентом заполнения, повышающий транс, умножитель(пришлось поставить, так как коэф. трансформации большой), обратная связь по току и напряжению. Стабилизация осуществлялась путем управления входным напряжением.
  10. pin change interrupt - прерывания по изменению состояния вывода, реализованы во многих tiny, которые достать не проблема. Только не забывайте, что если вы разрешили это прерывание, то оно будет генерироваться, даже если выводы сконфигурированы как выходы, т.е. при изменении состояния вывода ВАШЕЙ ЖЕ ПРОГРАММОЙ. А если вывод является входом внешнего прерывания (int0, например), то будут возникать сразу два прерывания, правда этот момент сам не проверял :)
  11. Именно. Это особенон полезно когда уже отправлена огромная партия товара, а после этого обнаружен баг в программе. Стоимость пересылок намного выше стоимости перепрошивки заказчиком, а шифрование позволяет соблюсти авторские права. Второй случай - выходят новые фичи для уже проданного товара. Пользователь может проапдейтить ПО с сайта производителя. Мы сейчас в основном для армейки разрабатываем, там, как понимаете, конечный пользователь еще тот :) Так что такие проблемы пока не стоят. Однако возьму на заметку, думаю, еще придется с этим столкнуться.
  12. Именно. Ага, понял, мне такой вариант не приходил в голову :) Спасибо.
  13. Не совсем понял: можно же просто залочить контроллер. Или подразумевается возможность последующего обновления прошивки самим пользователем?
  14. Может, конечно, дурацкий вопрос... :) При разработке устройств как-то никогда не приходилось использовать возможность самопрограммирования. То есть я знаю что это такое и как использовать, но вот для чего... Дальше возможности обновления прошивки (типа как сделано в jtag ice) и записи каких-либо калибровочных констант фантазия что-то не работает :). Может, кто-нить поделится опытом и натолкнет на красивые решения (или ссылки)?
  15. DELPHI

    Не знаю насчет плохой копии... Собственно, единственное, что требуется - вызов нужных API- функций, по-моему должно работать в любом случае. А вызовом расширенных команд с помощью функции EscapeCommFunction можно произвольно управлять ногами TxD, RTS, DTR, реализуя протоколы, отличные от стандартного. Повторюсь насчет ссылки на статью Олега Титова - неплохо расписано. Если что - пишите :)
×
×
  • Создать...