Jump to content

    

AlexZabr

Свой
  • Content Count

    900
  • Joined

  • Last visited

Everything posted by AlexZabr


  1. Как раз сейчас делаю проэктик - inclinometer для своего устройства. Требовалось отклонения в вертикальной плоскости с резолюцией 0.2-0.3 градуса, accuracy 0.1 градуса, температуры: -30 + 60, просота интерфейса с использованием локального маленького микроконтроллера. Ожидаемая полоса замера 4-6 Hz (т.е. относительно медленное изменение угла). После изучения вариантов остановился на Memsic MXD6125Q. По datasheet дает требуемый performance, интерфейс PWM что удобно для контроллера, маленкий корпус, простая системная обвязка. Купил его evaluation system - пару дней тому гоняли ее на точном наклонном устройстве (предназначен для оптической лаборатории, посему точность - велика, до минуты) - остались довольны в принципе. При достаточной фильтрации (low pass) - дает весьма стабильный выход, держит стабильно до 0.1 градуса, хотя не гоняли его в большом промежутке температур. На сайте у Memsicа есть весьма полезные application notes которые проясняют как и что, нужные калибрации как и когда и т.д. и т.п. Я бы ожидал одну проблему - температуры, но тоже вроде решаема калибрацией (смотрите appl. notes).
  2. Не далее как полтора месяца тому мы купили наш третий license (полный - Extended) на фирму. У нас проводился так сказать "съезд" юзеров Altium по стране с участием ихних начальников маркетинга по Европе и 2 инженеров field application. В качестве акции они предложили участникам данного моеопроиятия покупку полной лицензии (только одной на "душу") по цене 3к евро (не включая локальную поддержку). Мы как раз взяли нового инженера так-что как раз было кстати. Обычная цена была между 9к и 10к евро, хотя может быть сейчас и упало вследствии мирового price cut. Надо сказать что первые две лицензии которые мы покупали года полтора тому нам обошлись примерно в районе 5к US$ каждая. Пол года тому поменялся у нас представитель и цены стали в Евро и поднялись раза в полтора.
  3. Всем спасибо, все уже решено, нужные расчеты проведены, дизайн находится в активной фазе проэктировки. Остановился на MEMSIC акселерометре, дизайн включает контроллер для расчета угла + тепрературная компенсация + другие нужные вещи (замер температуры, разные интерфейсы).
  4. "Читайте классиков" PCB technologies - израильская контора, довольно крупная, весьма известная не только по стране. Московский филиал видимо ими был открыт, либо была какая-то контора в Москве, которую взял под свое "шефство" PCB. http://www.pcb.co.il/
  5. Прикол... Я-то не раз делал свои платы на PCB technology, у нас они в полутора часах езды от меня.....не знал что они уже и в Москве обосновались... Не так давно завод по сборке плат заказак мне мою плату в Китае - через полторы недели позвонили каялись что китайцы запороли платы (14 слоев, весьма плотно набитые, BGA с обеих сторон back-to-back, кучу microvias в педах BGA..). Срочно перезаказали их у на на PCB technologies - сделали все тип-топ, но почти в 2 раза дороже.. Это не реклама, это реалии... Ежели цена не проблема - PCB весьма стоящая контора (как и еще 2-3 крупных наших местных), хотя не в курсе насчет Московского отделения.
  6. PWM в PICе

    Всем спасибо, в целом более-менее понятно, программер обьяснит подробности. Крайняя экономия - не цель, посему нет проблем раоты с внешним клоком (думаю даже 50 ppm будет достаточно, хотя может быть поставлю 25).
  7. PWM в PICе

    Возможно я не совсем ясно обрисовал картину.. датчик дает уже обработанный PWM который отображает замеряемый параметер после требуемых фильтраций и т.д...это не просто A/D после которого-бы действителчно нужно было-бы фильтровать. К выходу PWM уже можно относиться как в выходному параметру (про замере PWM нужной точности). В том то и дело что я не знаком с имплементациями подобного плана контроллерами. Мое сомнение было как-раз в плане точности замера высокого/низкого участков контроллером ибо пока туго представляю как делается так что-бы достичь точности. Т.е. в случае испольования скажем FPGA/CPLD - все просто, счетчики на достаточно высокой частоте считают длительность уровней. Но тут контроллер который управляем бегущей программой...
  8. PWM в PICе

    Есть задача реализации PWM, т.е считывание PWM при сохранении достаточно высокой точности. На входе контроллера - PWM датчика, нулевой показатель - 50% (с допуском), весь range +/- 12.5% вокруг 50%. Требуемая точность считывания контроллером: 0.04375% или лучше. Полный период длится 10 msec. После считывания PWM входа - нужно делать не сложные расчеты для получения конечных данных + калибрацию датчика, посему реализация будет - простым 8-битным микроконтроллером типа PICa или Atmel ибо нужно низкое потребление. Вопрос - как обычно реализуется микроконтролером считывание PWMa учитывая требуемую точность ? Ведь там-же программа, а ее real-time есть понятие весьма относительное.... Есть понятие timerа в такого типа контроллерах, как они могут помочь тут ? Считают ли они в точности по clockу контроллера (т.е. по его crystal/oscillator) ? Прикидочные PWM вычисления: предположим 10 MHz клок, не учитываем для простоты его ppm и jitter. получаем длительность периода датчика = 100 000 клоков, 50% -> 50 000/ 100 000. Требуемая точность: 0.04375% - т.е. минимальный надежно определяемый шаг = каждые 43.75 клока (скажем 43 клока) что есть 49.957% PWM. Для чисто hardwareной системы (скажем FPGA) - это не проблема, но тут замешана программа выполения которой не всегда дает real-time относительно клока. Как оно далется контроллерами ? Спасибо
  9. Ну ессно через step-up/boost, это уже детали которые очевидны, посему и не упоминал :) А насчет процессора в power down и побудке по нажатию - это правильно. 2400 ? Тоже верно, вполне хватит...
  10. Спасибо. А что за тинька ? В принципе, работа пульта на систему ожидается эпизодическая, т.е. примерно 80-90% от времени работы системы - пульт молчит. Драйвер возьму ADM3222, он питается 3.3V, и есть у него shutdown. Так и буду имплементировать держа его это 80-90% времени в shutdownе (т.е. контроллер будет держать его в shtudownе пока не будет запрос не передачу (нажатие кнопки)). Думаю не будет проблем для батарей.
  11. Да, немаловажная деталь. У него автономное питание (батарейка indeed), надеюсь PIC контроллер + RS232 driver будут жрать по божески... :cranky: ... А вообще, сколько может жрать такой контроллер (VCC 3.3V) учитывая ьто всего софта там будет скажем рутина UARTа ? (ожидание наьатия кнопок и посылание кодов комманд как следствие) ? Думаю использовать PIC со встроенным RS232 (кроме драйвера ессно), наверно 19200 хватит (хотя сама система работает с PC на 115200), клок контроллера наверно в пределах 10 MHz..
  12. Спасибо. В принципе в системе уже есть UART, на разьем выходят RS232 (TxD, RxD, GND) ибо система общается с PC по serial. Думаю это преймущество ибо не нужно изголяться вытаскивать еще доп. пины из системы на разьем. Значит по кабелю пойдут 3 линии, хотя ежели будет экранированный - по нему можно пустить землю, тогда останутся всего 2 линии (сигналы). Почитаю насчет LINa что-бы понять будет ли он выгоден в данной ситуации или RS232 есть самое оптимальное. Думаю в пульте поставлю какой-нить PIC контроллер с встроенным UARTом да драйвеер (скажем MAX232), на GPIO контроллера навесить кнопок/джойстик пульта, ну и ессно софт UARTa (по нажатию кнопки передается по UARTу соотв. код в систему). Думаю это будет наиболее простое и надежное решение, хотя с софтом для микроконтроллеров пока не доводилось иметь дело...
  13. Сорри за наивность, что такое LIN ? Не слышал от таковом..
  14. Насчет RS232 - в принципе реально ибо само устройство имеет RS232 и TxD, RxD, GND выходят на внешний разьем. Но тогда в пульте нужно какой-нить микроконтрллер и рутины RS232 комманд. В приципе я не ограничен аппаратно в плане пульта, хотелось просто попроще (хотя и думал CPLD там ставить, но тогда возможно и микроконтроллер для RS232 будет не сложнее...) Условия эксплуатации - снаружи (т.е. в "поле").
  15. Буду благодарен в помощь/подсказки в выборе интерфейса: есть устройство управляемое несколькими кнопками/джойстиком на самом устройстве. Нужно сделать проводное дистанционное управление параллельное управлению на самом устройстве. Т.е. к разьему подключается дистанционка, там те-же кнопки/джойстик, комманды передаются по проводам на устройство. Есть две модели дистанционки по длинам: 1. пол-метра 2. до 3-5 метров. Кол-во команд - небольшое (примерно до 8 команд). В устройстве - микро-компьютер на основе PXA270 CPU, у него есть в наличии немало свободных GPIO к которым можно подключиться. так-же есть CPLD/FPGA к которому тоже можно подрубиться. Вопрос - какой интерфейс выбрать. Желание - простота реализации, надежность, меньше физических линий (кол-во свободных пинов разьема - сильно ограничено), не нужно хитроумное. Можно конечно асинхронно выставлять код комманды (3 бита) и CPU будет периодически его проверять, но тут 3 линии, да и не уверен будет ли работать надежно на длинах кабеля более полу-метра. Какие варианты ?
  16. Я был-бы только рад если-бы Альтиумовские средства FPGA были-бы широко применимы, как минимум заменяя брендовкие тулы. Возможно отчасти и так, но видимо только отчасти. Все равно видимо понадобится нормальмые, industry standard, синтезатор например что уже заставляет всеравно выкладываться на нормальный тул, симулятор - тоже самое (хороши что Альдек можно подвесить к Альтиуму, но до этого его нужно еще и купить), а без P&R бренда уж точно никуда не деться. Вот и получаем стандартный набор FPGA пакета, который как ни крути придется попкупать в дополнение к Альтиуму, но тогда и Альтиум не нужен для FPGA, разве в качестве оболочки, но это дело вкуса. Да и кстати я не в курсе насколько сегодня Альтиумовский FPGA пакет поддерживает Lattice... У меня стоит и полный Альтиум и пакет Латиса (включая Альдек и Synplify Pro), но пока не думалось попробовать иь смешать в кучу....каждый выполняет свою роль в процессе.... Лично я пока вижу только одну причину желания работы в Альтиуме в плане FPGA - это возможность привязки FPGA <-> Schematic с backannotation. Это конечно весьма удобно судя по описанию...
  17. прошел 3 startupа, знаком с кучей других start-upов, более или менее успешных, знаком с еще большей кучей людей работавших/ющих в start-upах как в моей стране так и в Штатах) - никогда не слышал об "удаленной/домашней" работе в них, ни тем более "зачуханности" и в плане интерса в работе ни в плен условий. Зачастую тема и разработки гораздо более интересные чем в крупных, солидных конторах, более динамичные, но ессно и гораздо более рисковые, ибо талант бизнесовой раскрутки start-upов - весьма редок на рынке. Не знаю о какой "паскудности" идет речь... Бывает ессно идея разрабатывается групкой (скажем 2-3 человек, часто друзей либо хороших знакомых), но тут речь идет о самом начальном этапе - обычно это вообще имеет не официалчное начало, в стадии "feasibility proving", тогда люди работают по домам, часто за счет свободного то основной работы время (что в семейном случае редко реально), но тут совсем другое дело, денег ессно нет (пока ?), но работают за свой интерес, в надежде на будущее...
  18. В свое время, когда начинал с Альтиумом, тоже прикидывал насколько стоящим будет вложение в его FPGA тулы. Оказалось что они исключительно завязаны на nanoboard, весьма дорогой, да и его "универсальность" сделала его черезчур навороченным. Предпочки EVB брендов под конкретной тематики разработки. Кроме того не слишком понял преймущества их синтезатора перед нормальным тулом который industry strandard, симулятор нормальный все-равно нужен внешний как и P&R ессно. В целом показалось красивой оболочкой, не более того, реальной ценности не представляющий для конкретный разработок на фоне стандартных тулов брендов, разве толчко ежели кто изначально подвязался на сей nanoboard.
  19. Спасибо. А что посоветуете из своего опыта ? желательно с I2C, но ежели строящие дивайсы - с другим интерфейсом - тоже буду благодарен за совет. отклонения впкруг горизонтальной оси нужны в относительно не большом обьеме, скажем в диапазоне +/- 30-60 или даже меньше, скорость 100-150гр/сек - достаточно, точность - важна, реальная способность замера 0.1, до 0.5 гр - важна. Угол по вертикали: +/- 90 диапазон, скорость - 30-60 гр/сек, статичексая точность важна, тоже 0.1 до 0.5 гр.
  20. Я имел ввиду угол отклонения, не линейный сдвиг, сорри ежели дал себя неправильно понять. С ST LY530AL кто нить имел дело ?
  21. Да вроде не путаю. В datasheet датчиков указывается ось относительно которой он меряет вращение. Значит по идее будет мерять отклонние вокруг оси в зависимости его физического расположения. Онмеряет отклонение вокруг своей вертикальной оси, т.е. по идее нужно его вртикальную ось расположить в нужной плоскости относительно нужного угла замера.
  22. Да, замер по вертикали (наклон) и горизонтали (roll). Насчет датчиков - есть например одноосевые (ось - вертикаль поверхности чипа) - ставим их в нужной плоскости - он будет мерять отклонения в соотв. оси. Нужная плоскость - ставим датчик так что-бы его меряющая ось была поперек оси предполагаемого вращения устройства - и будет замер в любой нужной оси. Пример - имее устройство, скажем, труба смотрящая вперед. Нужно датчик угла отклонения yaw (горизонта вверх/вниз). Ставим датчик вертикально в трубе так что его ось замера (его ось вертикальная к поверхности чипа) была поперек (90 градусов) к продольной оси трубы - вот он и будет мерять вертикалный угол. Ежели нужно мерять отклонения горизонта вправо/влево (roll) - ставим датчик в трубе его осью вдоль продольной оси трубы. Правда тут нужно 2 отдельных датчика (на каждую ось). Пока нашел только од analog (цена огого, да и нет ниже 5В по питанию) и ST (но только один у них есть но у него диапазон слишком широк для моих нужд). Вопрос какие еще есть варианты ...
  23. Нужна функция замера угла наклона устройства в двух осях (скажем носовой наклон и поперечный). Изменения достаточно медленные - устройство частично на штативе - частично на руке, т.е. видимо не нужно широкая bandwidth. Точность тоже не самая высокая нужна, скажем на 0.5 градуса уверенного замера уже достаточно в принципе, важно стабильность, т.е. показания не должны "плавать" при стабильном угле. Range угловой - достаточно скажем +/- 45 градусов вокруг нуля, но нужно функция обнуления в конкретном положении: т.е. обозначаем датчику положение нуля относительно которого он меряет, и он будет давать отклонения осей относительно заданного нуля. Желательно сериальный цифровой выход (например I2C было-бы идеально), размер - небольшой микросхемы, питание до 3.3В. Можно конечно взять акселерометер и интегрировать его выход, но предпочел бы готовый чип с цифровым выходом. Ежели у кого был опыт применения нечто подобного - буду благодарен за рекомендации, замечания и т.д. Спасибо.