Gorby

Таких не бывает. А вот что бывает: - Датчик углового ускорения. По-народному - MEMS гироскоп. Интегрируя его показания можно с (не очень большой) точностью вычислять положение тела при вращении его вокруг оси. - Датчик давления. Используя барометрическую формулу, можно вычислять положение тела по высоте. - Датчик ускорения (акселерометр). Позволяет вычислять много чего, в том числе и угол наклона. Но существует ряд ограничений. - магнитометр (частный случай - компас). Очевидно. - Трубка Пито. Измеряет относительное давление. Можно вычислить относительную скорость. А уже из него - перемещение, затем и положение. Используется в авиации. - тупо уровень строительный. Есть с электрическими контактами. Недостатки - те же, что и у акселерометра.

Ну что за ересь... Разберитесь, как правильно осциллографом пользоваться. Станьте скопом на землю. Убедитесь, что видите опять же иголки 100 милливольт. Подумайте, откуда они там. И ЕСТЬ ли они там на самом деле. А уж потом стройте гирлянды стабилизаторов. Подсказка: на маленькой макетке сделайте на подходящем операционнике усилитель с Ку=20-50, запитайте его от батарейки и заэкранируйте. его входы подключите локально короткими проводниками к земле и к измеряемой цепи РЯДОМ. К выходу этого усилителя подключаете скоп. Смотрите. Анализируете. Говорите "аааааааааа".

unsigned long Mylong = 4294967294; char buffer[9]; // 8+null terminator sprintf (buffer, "%Xl", Mylong); while(*buffer) TransmittChar(*buffer++); union { unsigned long Mylong; char buf[4]; }MyUnion; MyUnion.Mylong = 4294967294; TransmittChar(MyUnion.buf[3]); TransmittChar(MyUnion.buf[2]); TransmittChar(MyUnion.buf[1]); TransmittChar(MyUnion.buf[0]); Действительно, не совсем понятно, что вам нужно. Привел два примера. В первом получите искомую текстовую строку. Во втором - настоящие хексы. Надеюсь, оно вам надо.

//--------------------------- // IAR - AVR IAR Compiler [ICCAVR] (Current Version) // required includes #include <processor-specific include> #include <inavr.h> // Architecture include // brings in __enable_interrupt() and __disable_interrupt() // not requred for the ISR itself, but will be needed to // enable interrupts in your code //handler declaration #pragma vector=interrupt-vector-name __interrupt void my_name_for_this_isr(void) { //rest of code } // NOTE: The ISR function must immediately follow the #pragma Все верно. Вы случайно угадали правильный синтаксис. http://www.avrfreaks.net/index.php?name=PN...pic&t=54318 Загляните по ссылке, как раз для Вас. А вообще - читать доку на компилятор. Там много есть интересного.

Как-то не согласуется одно утверждение с другим :) Прерывания НЕ являются частью языка Си. Их НЕЛЬЗЯ правильно объявить, пользуясь K&R Си. Ибо прерывание - очень особая функция, требует особых пролога-эпилога и команду возврата. Поэтому объявление прерываний абсолютно зависит от компилятора. Ищите в хелпе на компилятор. В общем случае это будет void UART1TransmittComplete(void); А где-то рядом с ним будет ключевое слово interrupt, ISR или как там у вашего компилятора. Также может указываться вектор прерывания (номер в таблице прерываний, или иная релевантная информация). Удачи!

Не шунт, а шут... Гороха... Спецификация USB ограничивает ток на уровне 500 миллиампер (0.5 А). Как и емкость конденсатора по цепи питания - 10 микрофарад. Ах да, USB-3 даже 0.9 А. А ничего, что даже гипотетически предполагаемые 5 ампер будут только в начале зарядки? По мере заряда конденсатора ток при данной схеме построения цепи (резистор 1 Ом) будет падать. Топикстартеру неплохо бы подучиться, если работает. Ну или в армию, если учится... Ага, вижу схему. Беру свои слова обратно.

Mentor Hyperlynx может такое рассчитывать. Как избежать: 1 Разнести провода на разные слои платы, поместив между ними земляной слой. То есть разносим по вертикали. 2 Поместить между проводами третий провод, подключенный к земле, желательно с переходными отверстиями. 3. Ограничить скорость нарастания напряжения на проводе-агрессоре, помеха уменьшится. 4. Найти толковую книжку по SI (Signal Integrity) и читать, читать, читать.... Удачи!

Он не запускался уже в 10-й версии ISE. Похоже, со скриптами накосячили. В более ранних - работало нормально. Но Вам похоже шашечки, а не ехать...

В линуксе файлы, имя которых начинается с точки, невидимы. Как скрытые файлы в виндовс. Скорее всего он создался, но вы его не видите.

Ferrite Bead - дроссель на феррите с высокими внутренними потерями. Ставится последовательно в цепи питания и сигнальные цепи тоже для подавления ВЧ гармоник. Характеризуется импедансом на заданной (высокой) частоте. Обычно это 100МГц. Пример: http://www.vishay.com/docs/34024/ilbb0603.pdf

Наверное, автор все-таки имел в виду ГОСТ , определяющий "нормальные условия". Или Вы будете спорить, что давление и влажность влияют на напряжение пробоя?

А вопросы задаете студенческие, космического масштаба. Типа "как симуляторы отрабатывают код, по каким алгоритмам" От Вас ожидалось примерно следующее: "вот, в функциональной симуляции в этом месте сбоит, а в post-layout все нормально. Где могут быть грабли?" А Ваша постановка вопроса показывает, что Вы не понимаете разницы между ними. Иначе бы проверили. А если бы работали 4 года с ФПГА, то забили бы на функциональное моделирование вообще, оставив его только для проверки маленьких блочков кода. Самое достоверное - post-layout симуляция, и то не на все 100 %. Ибо не учитывает сигналы за пределами кристалла, да и PLL внутри не всегда адекватно симулируется. Был тут один, всё супернадежными компиляторами бредил. Постоянно находил баги в Си-компиляторах. Я не смеялся. Это было отчаяние :-). И рабочее решение Вам предоставил. А начинающим представляют не того, кто спрашивает, а того, кому по профилю 23 года, а он уже 4 года ФПГА занимается :-) Удачи!

Было бы правильно - топика бы не было.

Ааааааа... держите меня трое.... Почитайте лучше про триггер. Про его setup и hold, например. А дельта-задержек не существует. Это абстракция. В отличие от времени срабатывания триггера. И хоть один раз доведите свою схему до имплементации. Очень умильно на Ваших диаграммах выглядят сигналы, меняющиеся строго по клоку. Жизнь реальная, она куда как суровее будет. Ну и не забывайте про плохого танцора... А то всё у Вас САПР виноват А что, в Моделсиме есть разделение на функциональное и временное моделирование? Запустите туда чистый VHDL без задержек и он Вам напоказывает... А кое-кто взвизгнет "очередную багу Моделсима нашёл!"

Вы поняли правильно. Только без категоричного обобщения "все присваивания". На самом деле симулятор не так плох, чтобы тупить в таком каноническом случае. А вот сделайте счетчик десятичный (ну чтобы обратные связи от самого себя были) - тут же наколетесь.

Коллега des333 абсолютно точно выразил мысль. И недоумевал - имеет право. А Вы оскорбляете. Ответьте за базар. Скриншот симулирования двух идеальных триггеров - в студию.

Он не "зачем", а "как работает в конкретном симуляторе". Имеем тот эффект, что время срабатывания описанного кривыми руками триггера равно нулю. А нуль, очевидно (жаль, не всем), всегда меньше любой дельты. Причем этот эффект влияет не на текущий триггер (он-то сработал), а на последующий за ним, по цепочке. Или на текущий тоже, если перед ним стоял триггер тактируемый тем же клоком. А поскольку порядок обработки симулятором триггеров непредсказуем, то от изменения мест триггеров в проекте меняется результат симуляции.

Повторяю: это НЕ баги. Тем более, не баги сред моделирования. (у сред тоже бывают баги, но их вы повстречаете гораздо позже и реже). Баг - в вашей голове, если Вы думаете, что существует идеальный триггер. Давайте проведем мысленный эксперимент. Есть два идеальных Д-триггера. Клок общий. Выход первого соединен со входом второго (последовательно). Изменяем сигнал на входе Д первого триггера. Так вот, в нарушение всех законов очевидности и причинно-следственности, Вы увидите изменившийся сигнал на выходе ВТОРОГО триггера по ТОМУ ЖЕ фронту клока, который зарегистрировал изменение входа на первом. Ибо состояние выхода первого триггера изменилось ОДНОВРЕМЕННО с фронтом клока. И уже ИЗМЕНЕННОЕ, зафиксировалось как входное для второго триггера. Таким образом, сигнал "пролетит" любое количество триггеров. Вы ведь своими руками построили такую модель. Самое неприятное, что разные симуляторы разруливают такую ситуацию по-разному. Ибо ситуация сродни делению нуля на ноль. Возможное решение я Вам уже указал. Теперь чем "кишит" Моделсим. Моделсим показывает Вам Ваши собственные ошибки. Научитесь внимательно разбираться, чего он от Вас хочет. Как и компилятор Си, без причин он не ругается.

Оба не правы. Отвлекитесь от программизма. И подумайте, что физически происходит в триггере. А потом соотнесите это с вашей моделью. А то сразу "авторемонтное изменение сосудов..." (с)Жванецкий Правильный ответ: если хочется симулировать именно поведенческую модель, то после КАЖДОГО присваивания сигналу (не переменной) ставим волшебное слово "after 1nS". Хорошенько подумайте, зачем. Если бы вы были более последовательны, то сделав имплементацию вашего творения в кристалл и получив модель для post-layout симуляции (с реальными таймингами), вы были бы приятно удивлены: всё бы работало, как задумано. Хорошенько подумайте, почему. Подсказка: в реальном чипе ВСЕГДА имеется промежуток времени от фронта клока до изменения выхода триггера. А в вашей идеальной симуляции триггер изменяет свое состояние через 0 пикосекунд после фронта. Что вызывает массу интересных побочных эффектов. Удачи.

Например плата с датчиком (она небольшая, 1 см2) приклеивается к объекту на двухстороннюю клейкую ленту из вспененной резины. Если недостаточно мягко, то на два слоя. Или между ними поролоновая прокладка. В общем как сделаете, так и будет. Купите любой датчик ускорения, подключите осциллограф и посмотрите. Многие вопросы отпадут сами собой.

Итак, у Вас есть: - предмет массой 20 кг - киянка - компьютер с последовательным портом Действие: киянкой бьют по предмету. Результат: Вот тут непонятки. Что же Вам нужно на самом деле? Возможные варианты - зафиксировать факт удара, превысившего определенный уровень (обычный акселерометр на мягкой прокладке, компаратор и триггер для запоминания, или один микроконтроллер); - измерить силу удара (приблизительно) (нужен обычный акселерометр на мягкой прокладке, микроконтроллер) - измерить силу удара (более-менее точно) (нужен акселерометр с большим пределом, быстрый АЦП, микроконтроллер) Как видите, решений может быть несколько. Зависит от задачи. Кроме того, более-менее точные измерения не бывают малопотребляющими. Да хоть драйвер порта RS232 потребляет больше, чем акселерометр, а сигнал же оцифровать еще надо, обработать.

Вообще я приветствую идею метапрограммирования. Это удобно, не пухнет голова и быстро получается. Только зачем во избежание использования одного ассемблера (Верилога) пользуем свежеизобретенный ассемблер же? Нативным для обсуждаемой области есть представление КА в виде направленного графа состояний. Рисунок такой с зелеными кружочками и переходами между ними. На нем как раз очень НАГЛЯДНО видна вся функциональность проектируемого автомата. Ни на секунду не поверю, что автомат на 50 состояний на вашем метаассемблере понятен еще кому-то, кроме автора (а через месяц и он не вспомнит). Но оказывается, "все украдено до нас" (с). В Актив ХДЛ есть приложение, в котором рисуешь КА "как в книжке", возможна вложенность КА. А потом нажатием одной кнопки получаем исходник на VHDL. Понятно, что есть много параметров настройки. Вот про Верилог не скажу - мне не нужен был. В конце концов, есть конверторы. И голова. Если и делать, то прогу такого уровня (хоть отдаленно). Понятно, один человек такое не потянет даже за деньги. Про бесплатно молчу. Автору топика - спасибо, что готов поделиться плодом своих усилий. Наверное, у каждого из нас есть несколько самописных "утилит". Но это не значит, что всем они нужны.

Сами и заметили, что предлагаете плавное регулирование. А вот автор топика однозначно "забила" релейную схему. И не озвучила требуемую точность поддержания температуры. Ведь те 28 градусов будут ТОЛЬКО в месте установки термометра. Уже на расстоянии 20 см от него температура будет отличаться. Вообще говоря, надо бы отталкиваться от назначения нагревателя и регулятора. Если это "поддержание комфортной температуры в жилом помещении", то "все изобретено до нас" (с). Имеются в продаже великолепные термостаты Cronoterm фирмы Honeywell, способные поддерживать разную температуру в четырех различных временных интервалах (утро, день, вечер, ночь) и отдельно на выходные, причем умеют обучаться (знают, за сколько минут комната нагревается на 1 градус) и имеют релейный выход.

Вполне работоспособный вариант. А теперь вопрос: зачем же так заморачиваться с обратной связью по постоянному току, если входной каскад (эмиттерный повторитель) и так охвачен 100 % ООС как по переменке, так и по постоянке? При правильном выборе резистора в базе этот каскад будет хорошо работать при любых (в технологических пределах) h21э, тем более что ограничение ему не грозит - он имеет единичный Ку по напряжению. Ну-ну. Подстроечные резисторы до сих пор выпускаются. И применяются. Так вот, там где НАДО, ставят подбираемые элементы. Ибо у подстроечных надежность и долговечность на порядки ниже. И проблема подстраиваемости в аналоговой электронике никуда не ушла. И операционные усилители с выводами коррекции нуля по-прежнему есть. А вот пути решения проблемы сильно изменились. Теперь дешевле поставить микроконтроллер с ШИМом или цифровой управляемый делитель и все нужные подстройки делать "в цифре". Но факта необходимости подстройки в аналоговых схемах это увы, не упраздняет.

Можно рассматривать АРУ как петлю Отрицательной Обратной Связи по амплитуде с постоянной времени, значительно большей, чем период усиливаемого сигнала. Как правило, это достигается детектором и после интегратором. Теперь все просто : для малого сигнала - усиление максимальное, при увеличении входного сигнала усиление падает. Причем вид этой зависимости может быть разный - зависит от параметров цепи обратной связи.