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

"быстрее" не надо. Надо заполучить НАВСЕГДА. Это главная цель. А то как "бысто" зайдешь, так быстро и выкинут. Да еще слава останется, что выкинули.

Я очень хорошо умею работать, поскольку руковожу и сам собой, и результат выражается не в выбитой "премии".




Нестыковка - если действительно ПИСАТЬ, то зачем писать явно жрущий, если можно писать и НЕ жрущий. Это если ДЕЙСТВИТЕЛЬНО писать и понимать, что пишешь.

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

Ну а самое явное это когда под плис пишу. Могу конвейер сделать, а могу тупо один блок размножить. Первое лучше по ресурсам, но думать надо, второе грубая сила, звто очень быстро и тесты увязок стадий ненужны...

Так что баланс скорость - ресурсы все же есть. Но я не буду платить за это перейдя на баланс скорость - качество...

НЕ можно. Это разные вещи. И если до приемлимого результата "давится усередненим", то и фильтруется левой ногой с такими-же затратами "интеллекта".

Ок

Всегда хотел узнать у тех, кто не использует "глюкавые библиотеки от индусов", а пишут свой гениальный "код по даташитам": RTOS или ip-стек, работа с файловой системой, обработка графики, всё это тоже "сама-сама"?

Есть же и нормальные решения, в том числе и платные. Проблема не в библиотеках вообще, а в некоторых конкретно, и работе без проверки

Я не использую. RTOS в большинстве случаев своя ветка FreeRTOS. IP-стек с 90х годов тоже свой растущий из Waterloo TCP, но есть и даже не нано, а скорее пико стек буквально в несколько сот байт и порт стека FreeBSD. Работа на нижнем уровне с железом исключительно по даташитам с БОЛЬШИМ количеством "лабораторных" работ по уточнению поведения. Файловые системы простые - подчищеный FatFS от чана с НОРМАЛЬНО и аккуатно выписанным железным уровнем. Серьезные варианы - коммерческие продукты. То-же и с графикой - простые - тексты с иконками и рамочками свои. Тяжелые коммерческие.
Только вот ведь все это на самом деле проходные стандартные МЕЛОЧИ, которые Вам кажутся серьезными. Настоящая работа ведь это не такое сшить белыми или сделать "контроллер светодиода" на линуксе.

Это Ваша реальность - это реальность базара? Где лишь-бы продать кое-как сделанную халтуру, а там хоть трава не расти, хоть заказчик сразу выкинет ваше барахло, зарёкшись в следующий раз связываться с таким продавцом.
А Вам видно никогда не приходилось:
- ездить по объектам заказчика с вашим оборудованием, которое установлено не на столе в тёплой комнате возле кофейного автомата и улыбчивой девочки-секретарши, а где-нибудь в тайге, в холодной подстанции, когда при -50 градусах пальцы примерзают к клавишам ноутбука, а на железном полу не спасают даже валенки с двумя шерстяными носками. А если летом - сопровождающий советует не отходить вооон на тот край территории даже пописать, так как там утром видели мишку, забор вон помял, и вообще лучше по территории лишний раз не шляться, мало ли что;
- не приходилось перешивать ваше устройство, подключенное к силовым проводам, без его отключения, но с разборкой его (работающего!) чтобы воткнуть кабель программатора внутри шкафа,
где в нескольких сантиметрах толстенные шины на 10кВ. Потому что если отключить щкаф, то остановятся насосы качающие раствор, а для их перезапуска, нужно много времени, а за это время раствор в трубах замёрзнет (на улице-то температура ниже 50), порвёт эти трубы и тогда страшно будет подумать о сумме ущерба, вашей конторе дешевле будет вообще закрыться;
- вашей конторе не приходилось снимать с текущих работ всех кого можно в авральном порядке и засылать их на объекты заказчика, с оплатой проезда, проживания, аренды вертолётов для доставки
к объектам, куда иначе никак не добраться;
- вашей конторе не приходилось разбираться с заказчиком, который выставляет штрафные санкции, размером в тысячи Ваших месячных окладов, за ущерб нанесённый ему вашим повисшим оборудованием или потерей данных по вине этого оборудования;
- вашей конторе не приходилось слышать после этого от вашего многолетнего заказчика, что для следующего проекта, для следующей группы своих новых объектов, он предпочитает купить оборудование
другого производителя, так как у него хоть и гораздо дороже, зато надёжнее.

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


И горели и сталкивались. Но достаточно было пару раз хорошо обжечься, когда убытки от халтуры и траты на устранение её последствий многократно перекрывали потом эти 90% прибыли, чтобы понять одно простое правило:
НЕ ВСЕ ЗАКАЗЧИКИ == ОЛУХИ

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


Ясное дело, все делают халтуру, моргающую светодиодом. И только Вы - элитный продуктЪ. Неужели так трудно понять, что реальность имеет многогранна. Одни пишут софт для атомного реактора, выверяя каждый байт. Там и пико-ip-стек из 90-х и подчищенный FAT. А другие делают медиа-плееры, читающие фильмы в десятках форматов, читающие с любых флешек с разными ФС, обновлением прошивок через инет и трансляцией в твиттер. И второй программист не хуже первого или наоборот. Просто у каждого своя специфика.

... или читаем в очередных новостях, что опять у нас где-то что-то взорвалось или утонуло или очередной Фобос-в-грунт...


Потому что потом, набыдлокодив в простом проекте, привыкаешь и это превращается в твой стиль работы везде.

Да ну? Пробовали покупать, использовать?

А лично Вы вообще УМЕЕТЕ исходники читать? Пусть даже не мегабайты? Чем Вам лично греет душу наличие исходников Линукса? Способны разобраться, найти виноватого и исправить? Серьезно???!!!

Ну так НЕ тратьте здесь время.



Да все много проще - "второй" просто НЕ программист. Не называть-же программистом или поваром человека нажавшего несколько кнопок на микроволновой печке и разогревший в ней пиццу.

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

Пробовали, покупаем, используем. И баги в них находим. Производитель потом их устраняет в новых релизах. Или что из этого? Или Вы полагаете, что за деньги разработчики ошибок не делают?


Умею. И в статический анализ кода умею, а Вы? И не один я. На том опен-соурс и строится. И находят, и исправляют


Запамятовал, где я просил у Вас совета, что мне делать?

Если надо написать быстро, я не ищу в инете чужие куски. Я требую от схемотехников использовать те МК, которые уже хорошо изучил, для которых написал много отлаженного своего кода,
или те микросхземы, с которыми уже работали ранее.
Кстати - именно из-за этого долго не получалось слезть с LPC17xx

Я не про тех которые "находят и исправяют", я лично про Вас спрашивал.

Это не совет.

Представьте себе, почти так и есть.
На RTOS (uCOS ещё какой-то старой версии) обожглись, долго искал баг, нашёл в процедуре завершения системного обработчика ISR, в результате полностью переписав весь код порта uCOS для ARM7/9.
Хотя это конечно баг был не в самом uCOS, а в его порте. С тех пор использую uCOS во всех проектах, но со своими портами (портировал потом и для Cortex-M).
Использовали какой-то TCP-стек (даже толком не знаю чей, взят был программистом до меня, я потом только расхлёбывал). Вис очень редко, невоспроизводимо, но намертво.
Долго искал, потом долго матерился когда нашёл - писатель сего стека такое наворотил с машиной состояний, что видно сам запутался и наделал несколько багов в работе машины состояний.
В результате - также почти полностью переписал этот стек.
FatFS от Чана тоже пользовал, но также писал свой нижний уровень.
Были и другие примеры.
По личному опыту - почему-то почти каждый раз как только использовал чужой код, наступал на грабли в нём...

Я не против совсем от использования чьего-то кода, но только хорошо проверенного многими пользователями, от проверенного производителя (!). И всё равно при этом нужно тестить и тестить....

Лично про себя отвечаю: находил и исправлял. И, повторюсь, я не один такой, а на этом принципе построена целая культура разработки ПО. Мне показалось, что для Вас это будет более убедительным, чем мой личный опыт.

Процесс, конечно, болезненный, когда со своего уходить приходится. Но я как-то и к такому привычный, тем более после того, как лет пять назад взялся полностью софт для одной большой системы переделывать. Вот уж где контроллеров разных наелся по полной.
Сделали ее на грантовские деньги. Сделали всем миром - от канадцев, до юаровцев с австралийцами. Кто во что горазд. И даже изготовили, причем часть оборудованя в десятках тысяч экземплеров. Только не работало все это. Пришлось расхлебывать.
Перепахли и заставили работать нем неменее, потом выжали все, что можно. Сейчас уже спокойно уже по своему второе поколение делаем по своему уму. А один из масовых перефитийных контроллеров LPC15/17xx Ну в заметной степени, конечно, наработки повлияли .

В своём-то коде граблей не бывает... Или всё же они вылавливются в процессе разработки? А по времени то на то и выходит. Уже написал выше: Ваши проекты позволяют ограничиться минимальной ОС, минимальным стеком и своей файловой системой. ОК, это Ваша специфика. А у других разработчиков условия иные. Им и стек нужен полноценный, и кодеки, и ФС.


Именно. "Тестить и тестить".

Здесь согласен с Corvus. Наступали на грабли и в платных решениях. Причём на такие грабли, что ощущение как будто это писали школьники. Это вспоминается WT12 от Bluegiga...


По нашему опыту - чаще не устраняет, а говорит что-то типа "Да, есть у нас такой баг, признаём. Возможности исправить его нет, так как ПО писалось командой, работавшей у нас по субподряду и этой команды уже нет. И вообще - прошивка находится в ROM и обновить её невозможно. Но у нас вышла новая микросхема, с улучшенными характеристиками и там этого бага уже стопроцентно нет, покупайте её".
Только кто заменит эту микросхему на тысячах изделий, эксплуатирующихся уже у заказчика???
Или кто гарантирует что в новой, взамен исправленного бага, нет десятка новых, когда по стилю бага виден уровень разработчиков, писавших то глюкавое ПО.

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

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

Бывают конечно. Но баги в своём коде выловить на порядки быстрее, потому что раз я это написал, значит я досконально знаю как оно работает, и даже по приблизительным симптомам уже знаю где искать баг.
А в чужом ковыряться - на порядки дольше и даже неясно куда копать. Часто в этом случае проще всё с нуля переписать.
Вот как раз только что наступили у нас на такое. Наследство от давно ушедшего товарища... Отдали разбираться одному коллеге. Он месяц просидел - пытался разобраться с этим кодом.
Результат == 0. Хотя все ему сразу советовали переписать всё с нуля.

PS: Ладно - пойду-ка я спать. Боюсь, что ТС, глянув завтра на здешний тред, вообще передумает слезать с AVR

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


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

+5

В точку! Я тоже всегда с этого начинаю