engel65536

uint8_t result = 0; for (bits_cnt = 0; bits_cnt < 3; ) { shift = rand() % 8; if ((result & (1ul << shift)) == 0) { result |= 1ul << shift; bit_cnt++; } } Генерим случайную величину сдвига, проверяем, что на этой позиции ещё не стоит 1, если не стоит - ставим и увеличиваем счётчик бит. Если вам не нужно генерить такие байты очень-очень быстро, то такое сгодится. Если количество бит не зафиксировано, то нужно быть осторожным - такой алгоритм будет долго и печально работать, если количество бит близко к размеру типа. Если такое возможно, то можно просто при количестве единиц большем, чем половина разрядности, переключаться наоборот - на генерацию нулей вместо единиц.

Добрый день. Простейшее решение - на p-канальном полевом, вот прямо первая картинка из гугла по запросу "p-channel mosfet high side switch": Если никаких особых требований к быстродействию выключения нет, то всё считается очень просто, и подходят почти любые ширпотребные транзисторы. P.S. к биполярному T1, разумеется, ещё нужна пара резисторов - в цепь базы и между базой и эмиттером - на картинке их не нарисовали.

Это значит, что вы уже используете RTC или это значит, что у вас уже все backup-регистры заняты?

Старт - одновременная запись адреса ведомого (I2C_CR2_SADD), количества байт (I2C_CR2_NBYTES) и I2C_CR2_START в CR2 (возможно, путаю, и запись I2C_CR2_START нужно делать отдельно, через |=). Передачу байт делаем записью в TXDR при получении I2C_ISR_TXIS в ISR, этот самый TXIS у вас возникнет ровно столько раз, сколько байт вы задали в CR2. При получении I2C_ISR_TC генерируете стоп записью I2C_CR2_STOP в CR2. Если я ничего не упустил, этого минимума должно быть достаточно, чтобы оно завелось. Если у вас массив больше, чем 255/256/сколько-там байт (ограничение поля NBYTES в CR2) - сначала запустите на небольших объёмах, а потом читайте reference manual, там должно быть описано, что и как надо делать для этого случая. Но имейте в виду, что так получится очень нехороший драйвер I2C. Для того, чтобы сделать его хорошим, нужно сделать корректную обработку всех получаемых событий, а не только TXIS/TC.

А частота AHB у вас, наверное, примерно 12 МГц, верно? Ведомый таймер всегда будет отставать от ведущего на один такт AHB - это при нулевом prescaler, при других - не знаю. Если нужна строгая синхронность двух таймеров - или запускайте оба ведомыми от одного ведущего, или один ведомый второй ведущий и делать поправку в CNT ведомого (инициализировать CNT не 0, а значением ARR или как-то так).

Лично мой опыт таков. Вам нужно передвинуть ваш тест-поинт, у вас два варианта - перетащить мышью или поправить координаты вручную. Если вы двигаете мышью, то щёлкаете куда-то в пад и начинаете двигать - при этом выделяется и двигается компонент (но это выделение несколько "эфемерное", после окончания перетаскивания оно пропадёт), и описываемая вами проблема никогда не возникает. Если вы двигаете правкой координат, то тут вам нужно следить, что именно вы выделяете. Это неудобно, приходится постоянно помнить про эту особенность и не пытаться двигать такие компоненты после выделения щелчком. Почему и зачем - не знаю. Может быть, уважаемый @Uladzimir прояснит этот вопрос.

А вы случаем вручную координаты в свойствах не вводили? Есть такая не очень приятная вещь - когда компонент состоит из одного пада, при выделении щелчком выделяется (может, зависит от настроек - но у меня всегда так) не компонент, а пад. Соответственно, если не обратить на это внимания, то передвинете именно пад (если не ошибаюсь - lock primitives здесь не работает и позволяет это сделать), и получите ситуацию вы описываете.

Если мне не изменяет память, то никак. Тем, что к моменту, когда мы дойдём до опроса, там уже может не быть того уровня, который вызвал срабатывание.

15 мОм (милли, не Мега), в даташите написано. Это когда он ещё не сработал. Предохранитель это PTC, и его сопротивление будет здорово расти с ростом температуры. Но к тому моменту, когда сопротивление увеличится достаточно для ваших нужд, TVS уже отойдёт в мир иной.

Вы же не надеетесь за эти 1000 мкс успеть заставить сработать ваш предохранитель, да? Если вы говорите, что то, скорее всего, у вас ничего не выйдет. Предложенная схема с ключом - замечательное решение. Если вы настойчиво продолжаете вытягивать вашу схему на работоспособность, то вот вопрос: пускай ваш конкретный экземпляр TVS имеет порог открытия ровно 15 В, вам подали на вход 15.1 В без ограничения тока. На предохранителе падает 0.1 В, что при его сопротивлении 15 мОм даёт ток 6.7 А. Выделяемая мощность: TVS 15 В × 5.2 А = 78 Вт, предохранитель 0.1 В × 6.7 А = 0.67 Вт. Кто из них первым выпустит волшебный дымок - очевидно. Что вы будете делать с этим? Да, это где-то рядом с наихудшей ситуацией, но она вполне реальна. Что-то похожее будет, когда на входе у вас будет источник с ограничением тока - предохранитель останется холодным, а TVS испустит дух. То есть, не смотря на то, что TVS умеет резко открываться по напряжению, предохранитель всё это нивелирует. И избегать этого можно в рамках вашей схемы только приняв неизбежность наличия коридора входных условий, при которых защита не работает. Коридор можно уменьшать - но ценой значительного увеличения падения на предохранителе в рабочем режиме (при штатных напряжениях). Смотрите - это два корпуса SOT23 (один из них даже SOT323 можно), стабилитрон (мелкий) и немного резисторов. По площади это займёт не сильно больше вашей текущей схемы. При этом оно: 1. Не греется вообще. 2. Четко срабатывает вне зависимости от того, какой там источник на входе. 3. Не требует никаких действий для приведения схемы в работоспособное состояние после срабатывания защиты. 4. При желании можно даже сообразить индикацию срабатывания на светодиоде. Чем это решение вас не устраивает?

Ну теперь ещё было бы неплохо выяснить, какое рабочее напряжение нам нужно. То есть ниже чего и выше чего нельзя иметь на входе схемы (уже после защиты). И тут ещё нужно задать, сколько напряжения мы имеем право потерять на нашей схеме защиты (сопротивление предохранителя или исполняющего его обязанности элемента никак не может быть нулевым). И ещё раз повторюсь: какое предельное напряжение должна выдерживать защита? Вы не сможете построить защиту, которая защитит от сколь угодно высокого напряжения.

Когда-то я тоже думал сделать что-то подобное для какого-то устройства. Когда сел прорабатывать - понял, что всё очень и очень непросто, если пытаться сделать гарантированно работающую схему, а не что-то, похожее на что-то правильное. Защиту в итоге так и не сделал. Есть проблема в том, что ток от источника может быть ограничен - и это может привести к тому, что вместо предохранителя гореть будет только TVS, потому что на нём падает много, а на предохранителе - мало. Есть всякие манёвры - например, поставить тиристор, который будет открываться при превышении напряжения и прикладывать всё напряжение к предохранителю. Но это всё не очень просто. Глупый вопрос: а банальный 7812 не спасёт отца русской демократии? (Я не знаю, сколько потребляет ваше устройство.) Поставить его на вход - и готово, на его выходе больше 12 вы не увидите, а у него самого входное до 30-40 В, если мне не изменяем память. Для варианта "настольный прибор для себя и друга, защита просто от случайной ошибки, а не для промышленных изделий" - идеальное решение, как по мне. Если 7812 не устраивает, то нужно детально анализировать, что у вас есть и что вы хотите. Какие напряжения на входе: рабочий диапазон, диапазон работы защиты (вы же понимаете, что от 230 В вы вряд ли спасётесь "за просто так"). Какой ток потребления устройства. Какие источники с какими внутренними сопротивлениями и/или ограничениями тока могут быть подключены ко входу. Какие габаритные ограничения на схему защиты. Дальше или думать самому, или выкладывать сюда все эти параметры.

Добрый день. Это в каких единицах измерения? Шаг там вроде 2.0 мм между точками, насколько я смог понять по фото. Самый главный вопрос - сколько раз нужно прошить? Если однократно несколько десятков устройств - то и придумывать ничего не нужно. Берёте гребёнку (штыревой разъём) с шагом 2 мм - вот в чипдипе есть в наличии, паяете к ней провода SWD. Дальше просто держите её под углом к плате (положение - как будто скребёте гребёнкой лёд со стекла) и прижимаете пальцем, на однократное программирование десятков как по мне это более чем.

Каюсь, про прерывания я придумал сам - мне казалось, что этот USB CDC-драйвер так построен. Так это на самом деле или нет - я уже помню, давно его ковырял. Этого нет у ТС, но это я написал к тому, что здесь может быть мина замедленного действия, когда сейчас оно заработало, а потом через пару лет, когда скрипт сборки изменится, оно упадёт, и придётся очень больно и долго искать, что не так.

Да, но здесь у вас явный вызов функции из другой единицы компиляции. Компилятор Код ТС наверняка можно переписать так, чтобы и у него работало таким образом, но это будет несколько синтетический костыль, как мне кажется. И небольшой нюанс: в итоге без volatile в такой задаче (когда физически причиной взведения флага является событие, фиксируемое в прерывании) обойтись не получится - в вашем примере этот volatile будет где-то внутри somewhat_happened. Если же его не сделать, то всегда остаётся риск, что: а) при сборке boo.c возникнет ровно та же самая проблема, что и в изначальном вопросе; б) при включении multi-file compilation всё может соптимизироваться в ничто. При multi-file compilation (такое есть как минимум у IAR) все c-файлы слепляются в одну кучу и подаются так на вход компилятора - соответственно, тела всех функций видны отовсюду, и руки комплиятора существенно развязываются.