Вообще говоря, вся суть метапрограммирования и заключается в основном в экономии кнопкодавления, а так же ликвидации просирания ресурсов мозга на разбор бессмысленно навороченных конструкций. Если решение с метапрограммированием сложнее наивного — это бездарно примененное метапрограммирование :)
Ну так я же на него не смотрю, когда втыкаю, а на ощупь он абсолютно не симметричен: «снизу» на зарядках расположены две подпружиненные защелки, а на дата-кабелях «сверху» находится логотип. Никогда не испытывал проблем с ориентацией разъема.
Собственно, этот недо-мини-B есть в спецификации, о чем я и написал, и сделали его именно из-за проблем с прочностью.
Реальный опыт кого? Мой личный показывает ровно обратное, а статистическое исследование я с удовольствием почитаю.
Вот здесь написано, что сначала мини-B был рассчитан на 1500, а потом добавили его вариацию, которая выдерживает 5000. Там еще с совместимостью с разъемами были проблемы, кажется; помню, я с этим мучался.
The Micro plug design is rated for at least 10,000 connect-disconnect cycles which is significantly more than the Mini plug design. It is also designed to reduce the mechanical wear on the device; instead the easier-to-replace cable is designed to bear the mechanical wear of connection and disconnection.
А как вы ухитрились ее через шприц продавить? У меня ни тиноль, ни импортная паста тупо в иглу не пролезают. (Если без иглы, то получаются слишком большие капли, которые потом оставляют кучу шариков, прилипших ко флюсу.)
1. Не надо пользоваться говнофлюсами типа канифоли, паяльной кислоты, аспирина и прочего из прошлого века.
Флюс-гель на основе канифоли отлично работает, намного лучше и спиртового раствора, и твердой. Впрочем, я его использую только как дополнение припоя с флюсом (импортный Asahi с той же канифолью. Паять ПОС-61М — себя не жалеть), если что отпаять-пофиксить надо.
6. SMD паяются пастой и феном.
Неправда ваша. Если нет маски для нанесения пасты, то нанесение пасты + запайка феном + удаление шариков, пропайка непропаянного и т.д. занимают в два-три раза больше времени, чем просто пройтись тонким жалом с капелькой припоя на конце по дорожкам (для *QF*) или выводам (для пассивки).
А еще на Debian два года была дырища в openssl, которая позволяла именно что подбирать ключи. Их всего-то сотню-другую тысяч перебрать нужно было (количество pid * разные длины и типы).
Именно так. Я вообще не вижу смысла писать на ассемблере (критические куски кода в расчет не берем, это не «писать на ассемблере», это «оптимизировать»).
Во-первых, сам Си — это такой архитектурно-независимый макроассемблер (цитируя одного фрика, ассемблер для PDP-11, которому снится, что он компилятор, и в этом есть доля правды).
Во-вторых, что в нем вообще любить? Да, код для микроконтроллеров зачастую приходится писать на ассемблере. Это не меняет того факта, что такой код не переносим даже между вариантами одной архитектуры (взять хотя бы зоопарк ARM-ов с кучей нюансов), долго пишется, сложно отлаживается и так далее.
Вам никогда не удастся меня убедить, что, скажем, алгоритм PID-контроллера, который выполняет свою задачу (работает достаточно быстро и помещается в выбранный контроллер), лучше писать на ассемблере, чем на т.н. «ЯВУ» (почему в кавычках? см. выше про Си). Учитывая, что даже в самых дешевых ARM-ках (я замечу, что PIC-и не только крайне извращенные, но и весьма дорогие), ресурсов просто навалом, проблемы с крохотными контроллерами отпадают сами собой.
Не стану что-то утверждать про состояние разработки на PIC в настоящий момент; про hi-tech C я знаю и код у него, действительно, намного лучше sdcc-шного (sdcc — та еще опенсорсная поделка, но htcc не работает под всякими *nix-ами, что для меня было проблемно).
Могу только сказать, что набор инструкций у него абсолютно не совпадает по парадигме с тем, подо что заточен Си: одни банки памяти чего стоят (в результате получаем большие проблемы с планированием load/store в компиляторе), да и неидемпотентные регистры (сброс по чтению, принципиальные отличия в поведении при чтении/записи) тоже далеко не самая удобная особенность. Насколько я понимаю, порта gcc (который генерирует весьма убогий код, но все же лучше, чем sdcc) именно поэтому и нет. Те же AVR-ы существенно прямее, не говоря уж об ARM-ах.
sdcc? Во-первых, если я не ошибаюсь, то его разработка прекращена, а во-вторых он генерирует настолько неоптимальный код, что годится только для поделок. PIC-и (по крайней мере PIC8; знакомый утверждал, что в PIC24 все обстоит не менее плохо) очень хреново дружат с C.
то мою реализацию несколько более общего алгоритма (он умеет еще циклы, switch-и и обработку исключений) для ActionScript можно посмотреть здесь.
Hanlon's Razor
Собственно, этот недо-мини-B есть в спецификации, о чем я и написал, и сделали его именно из-за проблем с прочностью.
Вот здесь написано, что сначала мини-B был рассчитан на 1500, а потом добавили его вариацию, которая выдерживает 5000. Там еще с совместимостью с разъемами были проблемы, кажется; помню, я с этим мучался.
Спецификация
Если не ошибаюсь, Mini-USB рассчитан на 1000 циклов.
Флюс-гель на основе канифоли отлично работает, намного лучше и спиртового раствора, и твердой. Впрочем, я его использую только как дополнение припоя с флюсом (импортный Asahi с той же канифолью. Паять ПОС-61М — себя не жалеть), если что отпаять-пофиксить надо.
Неправда ваша. Если нет маски для нанесения пасты, то нанесение пасты + запайка феном + удаление шариков, пропайка непропаянного и т.д. занимают в два-три раза больше времени, чем просто пройтись тонким жалом с капелькой припоя на конце по дорожкам (для *QF*) или выводам (для пассивки).
Появится?! Откройте для себя Hash#delete, программисты Rails.
Array#slice тоже никакого отношения к рельсам не имеет.
Во-первых, сам Си — это такой архитектурно-независимый макроассемблер (цитируя одного фрика, ассемблер для PDP-11, которому снится, что он компилятор, и в этом есть доля правды).
Во-вторых, что в нем вообще любить? Да, код для микроконтроллеров зачастую приходится писать на ассемблере. Это не меняет того факта, что такой код не переносим даже между вариантами одной архитектуры (взять хотя бы зоопарк ARM-ов с кучей нюансов), долго пишется, сложно отлаживается и так далее.
Вам никогда не удастся меня убедить, что, скажем, алгоритм PID-контроллера, который выполняет свою задачу (работает достаточно быстро и помещается в выбранный контроллер), лучше писать на ассемблере, чем на т.н. «ЯВУ» (почему в кавычках? см. выше про Си). Учитывая, что даже в самых дешевых ARM-ках (я замечу, что PIC-и не только крайне извращенные, но и весьма дорогие), ресурсов просто навалом, проблемы с крохотными контроллерами отпадают сами собой.
Могу только сказать, что набор инструкций у него абсолютно не совпадает по парадигме с тем, подо что заточен Си: одни банки памяти чего стоят (в результате получаем большие проблемы с планированием load/store в компиляторе), да и неидемпотентные регистры (сброс по чтению, принципиальные отличия в поведении при чтении/записи) тоже далеко не самая удобная особенность. Насколько я понимаю, порта gcc (который генерирует весьма убогий код, но все же лучше, чем sdcc) именно поэтому и нет. Те же AVR-ы существенно прямее, не говоря уж об ARM-ах.