halfdoom

А вы пробовали просто менять адрес и передавать остаток пакета как есть? Мне попадался счетчик, который при работе по IRDA протоколу анализировал поле адреса, в котором последним байтом шла КС адреса, а затем отдельно считал КС для оставшихся данных. Что касается поиска алгоритма подсчета КС, то повезти может только в случае, если разработчик использовал что-то известное т.к. даже разгадать даже незначительную "адаптацию" весьма сложно из за большого количества неизвестных. Конечно, прежде чем отчаиваться, следует попробовать получить пакеты отличающиеся всего одним битом. Но самый быстрый способ, это, как уже говорили, попробовать слить прошивку.

Это да, только в третьей(!) версии снизошли до этого. Учитывая еще несколько заметных изменений, питоны 2 и 3 можно считать похожими, но разными языками. Что, собственно, и подтверждается отказом некоторых разработчиков адаптировать свой код к питону 3. Но если эти несовместимости еще как-то можно обходить, то фундаментальные проблемы с зависимостью синтаксиса от форматирования и необходимости указания "self." там, где оно не очень нужно, исправить уже не получится. Ну, разве что, выпустив еще одну несовместимую версию.

Последний параметр задает шаг -1, что эквивалентно последовательности: "123"[-1:] + "123"[-2:-1] + "123"[-3:-2] Как и многие вещи в Питоне, это не работает со строками в юникоде, в Ruby все проще и понятнее (и работает хоть с иероглифами): "我爱你".reverse => "你爱我"

Иногда бывает так: некая контора известной направленности направляет вам письмо о подозрении в использовании нелицензионного софта. Ее, естественно, игнорируют, но через некоторое время по заявлению от этой конторы с проверкой приходят уполномоченные органы, которые проверяют даже давно отключенные компьютеры. Последствия, понятно, не самые приятные. Что касается приобретения лицензий очень дорого софта, то иногда это можно сделать за счет заказчика, например, когда он требует выполнить разработку в заданном формате.

Недавно был один пример, когда использование библиотек типа HALa может оправданным. Попросили сделать небольшой и дешевый контроллер для управления простым устройством по WIFI. У нас есть подходящая серийная плата на STM, но цена и размеры несколько великоваты. Сотрудник предложил вариант на ESP8266 - дешево и вроде даже работает. Поскольку заказ разовый, особая надежность не требуется, то вполне оправдано использовать обертки вроде ардуин, поскольку полное изучение и написание с нуля абсолютно не целесообразно. В итоге все работает и все довольны, но понятно, что на промышленное применение такое не пойдет.

Надеюсь, это не из той же серии, когда производитель, погрязнув в непонимании работы собственного-же глючащего поделия, просит покупать новое - "the latest and greatest". Ну, представьте себе привод, таскающий стол с чушкой на пару сотен кг. Как всегда, двигать нужно быстро, точно и безопасно. Поведение привода должно быть абсолютно детерминировано, поскольку даже незначительные дефекты перемещения приводят к повышенному износу механики, а иногда и к ее разрушению. В такой задаче HAL применить, конечно, можно, но придется проползти весь код, поправить обработчики ошибок, выкинуть лишние проверки и добавить отсутвующие. А потом повторить все еще раз, при выходе очередной версии HALa. Мы этот путь уже проходили, и пришли к выводу, что собственные библиотеки это меньшее из двух зол. При этом, ведь никто не заставляет писать все с нуля - если есть проблемы с пониманием документации (или она просто никудышная), то всегда можно базировать свой код на уже написанном. К сожалению, такой узкоспециализированный код всегда приходится писать самим, что не отменяет широкого использования ОСРВ и готовых библиотек в задачах, которые это позволяют.

Основными факторами деградации являются ток и температура. В некоторых даташитах можно найти эти данные (вроде у Avago). Когда-то вывел простое правило по ним: если рабочий ток не превышает половины допустимого, а температура кристалла не выше 60С, то при постоянно включенном оптроне, деградация CTR составит максимум 10-15% за 25 лет.

Речь, большей частью, идет об оптимальности кода и в ней HAL проигрывает по всем статьям специализированному коду. А инспекция кода HAL, при его использовании, необходима, т.к. требуется выловить все побочные эффекты каждого вызова API. Здесь можно углубиться в непролазные дебри обсуждения каждой функции с избыточным кодом, поэтому просто отмечу - мы уже пытались базировать свой код на HAL и результат заметно хуже по времени разработки, объему бинарника и быстродействию. Но, повторюсь, у нас задачи далеки от отправки десяти байт через GSM. И это тоже. Для сравнения, один из наших "умников" (в хорошем смысле слова), унифицировал внутренний API до такой степени, что прикладная задача практически не видит разницы между применяемыми МК семейства С2000 (TI) и STM32F3. И да, совсем забыл - все библиотеки и обертки написаны на C++ с очень жесткой типизацией всего чего только можно, поэтому даже выставить бит в одном регистре пользуясь дефайном от другого, весьма проблематично.

Немного не так. HAL можно использовать в проектах, где цена ошибки не велика и быстродействие не критично. Если же приходится инспектировать каждую строчку чужого, далеко не всегда оптимального кода, то действительно, проще написать обертку в рамках своего фреймворка.

Куб действительно удобен для начального раскидывания ножек и периферии. Можно подсмотреть в инициализацию и реализацию. Но на этом все - дальше все равно используем свои библиотеки, т.к. камни выбираем не 3-х кратным запасом и, практически всегда, в задачах жесткий реалтайм.

А прошивка тем сиглентовская, или что-то свое? У нас SDG-5082, немного другой, конечно, но после нескольких обновлений вроде работает стабильно.

Нет, подразумевалось "грамотно развести", что бы получить годный и рабочий результат с минимумом итераций. Если у трассировщика нет спецификаций сигналов и требований по рабочим токам, то развести-то он разведет, но это будет минное поле. Другое дело, что на плате ТС узких мест, требующих повышенного внимания, не много, что, соответственно, снижает вероятность допущения радикальных ошибок.

Вполне корректное. Нельзя грамотно развести, равно как и проанализировать, плату не глядя на схему и имея только соединенные футпринты. По вашим картинкам ПП можно давать лишь общие рекомендации, в пределах видимых догадок о назначении цепей. Вот, например, уже говорили о танталовом конденсаторе, который был на 12В, затем на 35В, и все равно, этого не достаточно, т.к. тантал на 35В в бортсеть напрямую не включают, а разбираться, откуда и что идет по дорожкам, является бесполезной тратой времени.

Тут, кроме стоимости, далеко не последнюю роль играет фактор "освоенности" МК. Сейчас периферия/архитектура настолько развесистая и сложная, что на написание и отладку HAL'a под свои задачи уходит весьма приличное время. STM32 не самая навороченная серия, но предлагает удачный баланс функциональность/стоимость и практически беззатратную миграцию внутри семейства (хотя перенос между семействами может быть не очень простым). Поэтому, несмотря на наличие интересных МК, приходится многие вещи решать в рамках изученных кристаллов, а новые осваивать только в случае необходимости или возможности.

Если ускорение упирается в инерцию ротора и механизма, то тут поможет только оптимизация механики или замена на серводвигатель. Последний заметно дороже, поэтому можно поискать "оптимизированные" ШД - там иногда попадаются модели с большими моментами при той-же инерции.

Очень внимательно смотрите на изоляцию DC/DC. В мелких преобразователях обычно зазоры весьма малы и не ответствуют требованиям для объектов связанных с первичной сетью.

Думал, вы пробовали экспериментировать с экспонированием уже нанесенного фоторезиста. У нас соседи пытаются заточить под такой процесс не совсем приспособленный для этого станок, так у них это уже вылазит. Правда, им не для печатных плат это все нужно, но разрешения для линий 0,2/0,2 добились только сканированием стола и программной корректировкой неровностей. Подозреваю, что еще и лазер у них не самый лучший - сильно похож на ширпотреб с ибея.

Все верно, нужно принимать меры для работы с коэффициентом заполнения близким и равным 100%.

А как вы решили проблему фокусировки из за неровного текстолита и/или перекоса стола относительно каретки по высоте?

Если у вас нет уверенности, что ваше устройство подключено через УЗО, то никаких заземлений. Но, как писал wim, должна быть быть обеспечена изоляция вторичной обмотки согласно требованиям. Если будете проходить сертификацию, то секционированный каркас практически гарантирует отсутствие проблем по этой части. Y-конденсатор хотя и не относится к вашему случаю, но тоже должен отвечать требованиям безопасности, ибо его пробой так-же ведет к неприятным последствиям. И да, в некоторых, особо упоротых случаях, приходится секционировать даже импульсные трансформаторы.

Неплохо. Хотя для повторения конструкция не очень подходит.

А зачем это нужно в базовом драйвере ШД?

Комната без окон не самым хорошим образом влияет на продуктивность работы. Лет десять назад нам пришлось временно переехать в подвальное помещение. Чистое, просторное, хорошо освещенное, тихое, с принудительной вентиляцией и климат-контролем, но без единого окна. Заметил, все стали гораздо чаще покидать помещение, что бы просто постоять на крыльце, даже если на улице лил дождь. Некоторые стали жаловаться на головную боль и сонливость. Все "болезни" закончились сразу после переезда в новый офис.

Это ваша локальная проблема. У меня логин держится месяцами. Firefox 56-x64.

Гораздо проще создать картинку для настройки, где и указать все требуемые элементы. Встречается и тот, и другой подход. Некоторые крупные западные компании при приемке аутсорсинговой разработки требуют нумерацию по плате, но их единицы. Большинство нумеруют по схеме. Первый вариант хуже, если принято рисовать пару корпусов на одном листе - поиск элемента в альбоме превращается в сплошное листание.