Какой контроллер выбрать, Выбор микроконтроллера для дальнейшего развития Опции

[vepex]

Здравствуйте. AVR достаточно освоил, но уперся в потолок производительности. Надо расти дальше, но стою на перекрестке - не знаю что выбрать.

Хочу спросить мнение профессионалов, которые реализовали множество проектов на разных микроконтроллерах (ARM).

Что выбрать Atmel (SAM3) или STM какие плюсы и минусы в них имеются? Задача - не критичная к скорости, но критичная к стабильности работа в локальной сети (Ethernet + PHY, на микросхемах физического уровня).
Главное хочу услышать не предвзятое мнение, а то обычно кто что использует - то и хвалят.

Сам выяснил одну вещь: Atmel труднодоступнее и немного дороже чем STM. Так ли это? И что касается остального: подключение (минимальная обвязка), программирование (среда разработки и язык), прошивка - как с этим обстоят дела?

[zltigo]

1) Забудьте про Atmel что-бы он не пытался делать. Вечный догоняющий пытающийся держать на игле своих авр-щиков. Посему забудьте навсегда.
2) Если иделие штучное - сделали и забыли, то все равно. Если предполагается долгая жизнь - начните с NXP.

[vladec]

ST в настоящий момент контролирует больше половины мирового рынка "флешевых" ARMов, лучше ориентироваться на них. Если у Вас специфические задачи завязанные на Ethernet то можно посмотреть и в сторону TI (семейство Tiva c Ethernet PHY на борту)

[arhiv6]

zltigo а почему NXP? Какие у них плюсы по сравнения с контроллерами от STM, TI или Freescale?

[scifi]

2) Если иделие штучное - сделали и забыли, то все равно. Если предполагается долгая жизнь - начните с NXP.

В свете слияния NXP и Freescale непонятно, что там дальше будет. Может случиться, что сольют всю линейку LPC.
В этом плане ST пока не в зоне риска
Ну и я бы посоветовал STM32 не потому, что сам его использую (не его одного, кстати, сейчас делаю проект на LPC4370), а потому, что его многие здесь используют, поэтому могут помочь советом. Ну и вообще обширное семейство, всё там есть, работает нормально (с учётом еррат, но это у всех надо учитывать).

критичная к стабильности работа в локальной сети (Ethernet + PHY, на микросхемах физического уровня).

Нет такой проблемы "стабильность работы в сети" на уровне МК. Может быть кривой Ethernet MAC, но это должно быть написано в еррате (у STM32 в этом плане всё в порядке, ЕМНИП). Есть проблема кривых софтов. В форуме народ постоянно пишет, что мол, взяли этот пресловутый Куб, а у них потом что-то не работает. Как будто не догадываются, что все эти кубы - индусский говнокод. Что тут можно сказать? Учите язык Си, пишите хорошие софты.

Кстати, про софты: тут один участник форума постоянно нахваливает MQX, который идёт в комплекте с Kinetis от Freescale. Якобы этот софт вовсе не кривой, и всё там есть. Но тут та же неопределённость в связи со слиянием NXP и Freescale. Если бы меня попросили погадать, я бы поставил на то, что LPC сольют в пользу Kinetis.

[mempfis_]

В свете слияния NXP и Freescale непонятно, что там дальше будет. Может случиться, что сольют всю линейку LPC.
Если бы меня попросили погадать, я бы поставил на то, что LPC сольют в пользу Kinetis.

Я работал и с Kinetis и с LPC23/24/17. Ну и ещё LPC11 с CAN на борту.
Сомневаюсь что линейка LPC будет слита. У LPC, как мне кажется, много поклонников и потребителей т.к. это качественные и надёжные процессоры.
Кроме того Kinetis и LPC сильно различаются по структуре. При освоении MKL15 я думал мозг сламаю, пока разберусь что там и как друг с другом взаимодействует и что от чего зависит. LPC на порядок проще на начальном этапе освоения.
Буду считать плюсом слияния двух компаний, если Freescale сможет наладить выпуск Kinetis в Европе, или хотябы обеспечит их безпроблемную доставабельность.

Но тема топикстартера всёже не про слияние Freescale и NXP, а про выбор процессора.
LPC17 - хороший выбор для освоения и использования в серийных проектах. Простая структура, много литературы, много примеров, надёжны, доставабельны.
Kinetis - сложны для старта, но имеют отличное потребление в режиме глубокого сна (mkl15, LLS, 0.44 uA).
STM32 - тоже хороши для освоения, просты внутри. Но их портит навязывание STM своих библиотек, мешающих понять структуру и принцип работы периферии. Если забыть о существовании библиотек, то при освоении оставляют хорошее впечатление. Также поражает их цена - сейчас сам смотрю на STM32F0x стоимостью чуть больше 1$ в розницу. В нашей фирме в серийных проектах STM32 не используются (предпочитаем более надёжные на наш взгляд LPC или низкопотребляющие Kinetis), но для своих одиночных проектов с успехом применяю STM32F100/103.
Ещё упоминался Atmel - с тех времён, когда AT91SAM7S внезапно подскочил в цене и стал тяжело доставаем, ими не пользуемся, но в целом ARM7 процессоры были не плохи, думаю CORTEX тоже не стали хуже, но связываться с Atmel я бы не советовал из-за цены.

[Golikov A.]

А я бы посоветовал даже более широко, начните с ядра Кортес-М3 или М4, АРМы то разные бывают...

А в этой группе я бы выбирал между STM32 и LPC.

при сравнимой производительности и корпусе

Код

STM32
  плюсы
    обычно дешевле,
    обычно больше интерфейсов (таймеров, SPI, UART),
    у него огромное сообщество,
    есть методы быстрого старта типа библиотеки и среды куб
  минусы
    больше ошибок кристаллов
    чаще что-то не работает как написано
    есть методы быстрого старта типа библиотеки и среды куб

Код

LPC
  плюсы
    обычно работает все как написано
    тоже неплохое сообщество
    не очень большое разнообразие моделей, потому чаще находятся готовые портированные модули типа ТСР стэка и так далее
    чаще модули периферии стандартизованы, а не собственного разлива
    нет распространенных библиотек быстрого старта
  минусы
    обычно дороже
    обычно не хватает таймеров или UARTов или каналов АЦП
    нет распространенных библиотек быстрого старта

По внутренним ощущениям СТМ очень агрессивно рвут рынок, и не успевают за сами же собой по качеству, процессоры выходят каким-то недоделанными что ли, не ощущаю я лично надежности. LPC же как то сделало проц и гонит его таким какой он есть, у меня нет с ними чувства что что-то пойдет не так. Если брать что-то типа LPC1768 - так там вообще все работает как написано в мануале, а если что-то работает не так, то не правильно прочли. Они как-то более предсказуемы, но более скучны с точки зрения периферии и перекидывания ножек.

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

С кубовскими библиотеками я постоянно нарывался на то что идешь по ним шаг за шагом, вроде все хорошо, но потом обнаруживаешь что у них по их логике функция завершения опроса АЦП имеет таймаут 3 секунды сделанный на while, и получается что либо меняй всю идиологию, либо заплатки ставь, и думаешь что быстрее было бы сразу все самому написать, чем тут ковырятся. А так получается пол проекта на кубе, а пол в заплатках и своих функциях не то не се.

[vepex]

Спасибо всем за советы (еще принимаются). Думаю пересяду на STM (честно говорят до сегодняшнего дня не хотел с Atmel уходить).
А что касается физики Ethernet (PHY) - цена я так понял что не сильно отличается, реально нет разницы $2 или $5 (если производство не серийное на 1000 штук).
Поиск на этом форуме показал, что люди нахваливают эти микросхемы: KSZ80XX, LAN87XX, RTL82XX, DP83838, и Micrel (модели не знаю) - что можете посоветовать?

[AlexandrY]

Если бы меня попросили погадать, я бы поставил на то, что LPC сольют в пользу Kinetis.

Правильно мыслите. Freescale дает гарантию на производство своих чипов в течении 10 лет.

Спасибо всем за советы (еще принимаются). Думаю пересяду на STM (честно говорят до сегодняшнего дня не хотел с Atmel уходить).
А что касается физики Ethernet (PHY) - цена я так понял что не сильно отличается, реально нет разницы $2 или $5 (если производство не серийное на 1000 штук).
Поиск на этом форуме показал, что люди нахваливают эти микросхемы: KSZ80XX, LAN87XX, RTL82XX, DP83838, и Micrel (модели не знаю) - что можете посоветовать?

Просто для знакомства с Kinetis можете почитать вот это - http://habrahabr.ru/post/256611/

У Freescale действительно лучшие прикладные открытые библиотеки.
Если вы не чистый схемотехник, то должны понимать их значение.

В последней версии SDK под Kinetis сразу даются порты 4-х RTOS с исходниками самих этих осей: uCOS-II, uCOS-III, FreeRTOS и MQX.
Это еще не считая проект mbed.org где Kinetis играет большую роль.

Кстати MQX в последнее время штатно идет с TCP стеком с SSL (все с исходниками).
Также там скорее всего первым появится и полнофункциональный IPv6

[scifi]

Поиск на этом форуме показал, что люди нахваливают эти микросхемы: KSZ80XX, LAN87XX, RTL82XX, DP83838, и Micrel (модели не знаю) - что можете посоветовать?

У меня KSZ8081. Выбирался самый дешёвый вариант. Работает - а что ещё надо?

[zltigo]

zltigo а почему NXP? Какие у них плюсы по сравнения с контроллерами от STM, TI или Freescale?

На данный момент они не сняли с производства ни один из даже самых первых ARM контроллеров. Это было к вопросу о времени жизни изделия.

[smalcom]

Принцип отсева простой:
1. Начните с обзора того, что вы можете купить у местных поставщиков.
2. тут у вас важное решение: единственный критерий дальнейшего отбора - цена или же некий баланс.
3. Если выбрана цена, то просматриваете по диагонали список ошибок(errata) и переходите к п. 5
4. По списку ошибок и цене смотрите какой из МК слеплен из ...а, а какой приемлемый.
5. Оснащение и порог вхождения. Оцените во сколько обойдётся зажечь светодиодик. Обычно у АРМ'ов есть UART и USB загрузчики, т.е. можно отделаться конвертером.
5а. Если есть деньги на отладочные комплекты, то смотрите во сколько обойдётся оборудование для отладки.

а то обычно кто что использует - то и хвалят

и этот тред не исключение))

и немного оффа

Atmel труднодоступнее и немного дороже чем STM

тут таже ситуация - за цену одного SAM'а ведро не SAM'ов дают.
если бы не список выше, то я бы выбрал архитектуру MIPS - нравится их ассемблер; и продукцию Микрочипа, у которого одни из лучших ценовых предложений по инструментарию(программатор, отладчик).
Но с компиляторами ЯВУ у них был просер да и п.1 имеет место
http://kosmodrom.com.ua/prodlist.php?page=...%EA%EB%E0%E4%F3

[zltigo]

В свете слияния NXP и Freescale непонятно, что там дальше будет. Может случиться, что сольют всю линейку LPC.

Невероятно. Нет смысла "сливать" свою линейку, которую пестовали и по отношению к котрой проводили политику "до последнего потребителя".
Ну купили они кого-то, ну и что? Как жили те, так и будут. Вот я сейчас работаю на купленном ими-же Jennic. Он на самом деле живет своей жизнью в котрой самое отвратительное, через 3-4 года снятие с производства предшественника .

Нет такой проблемы "стабильность работы в сети" на уровне МК.

Практически да.

Как будто не догадываются, что все эти кубы - индусский говнокод.

А вот с говнокодом, котрорый еще не просто говнокод, а еще все чаще и чаще "заменитель" документации - берите говнокод, ибо документации или нет или тоже говно, это реально проблема

Правильно мыслите. Freescale дает гарантию на производство своих чипов в течении 10 лет.

Ну а теперь о NXP расскажите что они сняли из ARM. Короче - будут жить оба.

[scifi]

Невероятно. Нет смысла "сливать" свою линейку, которую пестовали и по отношению к котрой проводили политику "до последнего потребителя".

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

[vepex]

Какие есть варианты с микросхемой (PHY) физического уровня Ethernet? Предпочтение корпусам TQFP/LQFP (48)

Сообщение отредактировал vepex - Jul 30 2015, 09:18

[scifi]

Какие есть варианты с микросхемой (PHY) физического уровня Ethernet? Предпочтение корпусам TQFP/LQFP (48)

Ознакомьтесь

[uuuulala]

Какие есть варианты с микросхемой (PHY) физического уровня Ethernet? Предпочтение корпусам TQFP/LQFP (48)

Wiznet же!
На одном кристалле 8051 + аппаратный стек Ethernet или Cortex + аппаратный стек Ethernet
http://www.wiznet.co.kr/product/
http://www.efo.ru/doc/Wiznet/Wiznet.pl?494#1

англоязычное комюнити неплохое http://wizwiki.net/wiki/doku.php?id=start

[aleksandr-zh]

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

Мои железки простые в плане алгоритмов (на вроде тех же торговых автоматов и мелких наколенных поделок), но вот скорости может когда-то и не хватить
Глянул на AtXmega - как-то не впечатлило, хотя бы из-за доставаемости и отладки.

Приглянулись STM32, но выплывают как технические, так и психологические проблемы после x51, PIC и AVR оные просто "ну ваще другие"

Надо Хорошо учить английский - чтобы читать даташиты в подлиннике, Си - чтобы читать чужие примеры и потом самому писать, надо брать новые программаторы, отладчики...
Вот и почесываю затылок.

[zltigo]

Надеюсь, что даже в случае слива линейки не будут сворачивать производство хотя бы лет 10.

Если не будут сворачивать, как обещано, до последнего потребителя, то что тогда называть "сливом линейки"???

Какие есть варианты с микросхемой (PHY) физического уровня Ethernet? Предпочтение корпусам TQFP/LQFP (48)

Пользовал только однажды - Stellaris 6965. Причина была в том, что встроенный PHY был на удивление экономичен, а требования по питанию были очень жесткиею А так не вижу особого смысла во встроенных.

Wiznet же!

Запихните эту радиолюбительскую поделку для радиолюбитей ... ну в общем подальше.

[scifi]

Если не будут сворачивать, как обещано, до последнего потребителя, то что тогда называть "сливом линейки"???

Это уже спор о значении слов, не очень интересно. Можно придумать разные степени слива:
1) Прекратить развитие линейки
2) Остановить ещё и тех. поддержку (мне по барабану, ни разу не пользовался)
3) Снять с производства
Я не предсказамус, не буду зарекаться. Свои опасения высказал, а там будем посмотреть.

Надо Хорошо учить английский - чтобы читать даташиты в подлиннике, Си - чтобы читать чужие примеры и потом самому писать, надо брать новые программаторы, отладчики...

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

[_3m]

Глянул на AtXmega - как-то не впечатлило, хотя бы из-за доставаемости и отладки.
Приглянулись STM32, но выплывают как технические, так и психологические проблемы после x51, PIC и AVR оные просто "ну ваще другие"

камни stm32 действительно мутноватые. нет, они вполне рабочие но без вникания в индусский говнокод в либах их поднять тяжко.
lpc чуть попроще, начните лучше с них, причем с младших lpc11*
Или kinetis те кторые на cortex-m0. Они в россии непопулярны но судя по дш чипы неплохие.

Это уже спор о значении слов, не очень интересно. Можно придумать разные степени слива:
1) Прекратить развитие линейки
2) Остановить ещё и тех. поддержку (мне по барабану, ни разу не пользовался)
3) Снять с производства

4) Продать маски фирме Holtek (или закрыть глаза на то как они [CENSORED]).

Сообщение отредактировал IgorKossak - Jul 30 2015, 17:20

[aleksandr-zh]

ну, английский может быть разный В даташитах Атмела - сносный (для меня, конечно!), в Микрочип - понятный, а вот корейские и китайские даташиты - %%%!
Да и на Си можно по-разному писать.

начинал с Pic на ассме, потом AVR на асме, наш разработчик невольно подсадил меня на Pascal (на заводе всё на нём писалось: от ПК и спец.станков до МК). На 2006 год Паскали для АВР были голимо говёные. Перешли на FastAVR - нечто между Паскалем и Бейсиком. Потом как-то плавно на Bascom (чистый Бейскик). Крайне редко правил что-то чужое на Си (обычно CodeVision). Си читаю, если простое - понимаю, но ойные черточки и галочки крайне плохо понимаю. По мне проще почти англицкий, чем черточки

ps
щас меня обкидают какашками и начнётся очередной халивар. Придёт Ксения и забанит всех по самый неболуйся ))

Сообщение отредактировал aleksandr-zh - Jul 30 2015, 17:05

[scifi]

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

Как же я их поднимаю, не трогая индусский говнокод совсем и всего лишь читая мануал? Это сейчас не модно?

[jcxz]

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

Если тянет на говнокод, может стоить искать проблему в себе?
По-моему - так даже смотреть в говнокод противно. Только если поржать....
По себе: в последнее время сделал по одному проекту (с параллельным освоением этих новых для меня линеек) на MSP430, STM32F100, Tiva TM4C129, ADuCM360 ни разу не заглянув ни в один пример чужого кода. Исключительно даташиты и юзермануалы.

[kostyan]

По своему опыту: после аврок пересел на атмел САМ7 и САМ3. После них на стм32ф4. Там где раньше в изделии стояло два САМ7, можно обойтись одним САМ3. Где глючил САМ3 - ставишь стм32ф4. У САМ3 плохие часы - батарейный отсек если питать от лития - зависает, если подавать питание по нажатию кнопки - проц запускается порядка двух секунд. Плюс генерация на внешнем часовом кварце АРХИ слабая - от щупа осцила садится и не восстанавливается без перезапуска! После перевыпуска изделия на стм32ф4 - просто не нарадуюсь. Прямо до сих пор балдею - неужели "с таким щастьем и на свободе". Многие хают преднаписанные либы - а я кайфую. Функции хорошо задокументированы. Входные парамерты понятно названы - можно даташит не читать и все понимать что делает та или иная функция. Куб не юзал - руки не доходят. А то что есть в либах - ошибок пока не встречал. Если нужен какой то быстродействующий код - открываю даташит, смотрю чего надо выставить в конкретном регистре, беру код из либы, убеждаюсь что он все делает как написанно в даташите, убираю лишние проверки и макросы, профит. Возможно мне конечно повезло с ерратой - юзаю очень узкий круг стм32ф4 последних ревизий. Критического для себя не ловил.

[Golikov A.]

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

сдается мне что сменив подход
вместо этого

Там где раньше в изделии стояло два САМ7, можно обойтись одним САМ3. Где глючил САМ3 - ставишь стм32ф4

надо будет писать ставишь самый маленький пик и все летает.....


У вас вообще времянки жесткой что ли нет? Или вы гирлянды на СТМ делаете? Там в их библиотеке столько лишних движений и проверок, такие таймауты могучие, да и волатайлов нехватает на оптимизацию выше 0. И как вы с этим всем живете? Переписываете?

[mantech]

сУ вас вообще времянки жесткой что ли нет? Или вы гирлянды на СТМ делаете? Там в их библиотеке столько лишних движений и проверок, такие таймауты могучие, да и волатайлов нехватает на оптимизацию выше 0

А не рассматривали такое применение - инициализачия девайсов их библиотекой, а работа с ними - прямым доступом? Всегда так и делал, и волки...и овцы...ну, понимаете

[Golikov A.]

Была такая версия использования, но при этом в проект затягивается толпа файлов и он уже компилируется не так бодро.

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

[kostyan]

А не рассматривали такое применение - инициализачия девайсов их библиотекой, а работа с ними - прямым доступом? Всегда так и делал, и волки...и овцы...ну, понимаете

Я по сути про тоже.

[Porty]

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

а я делаю так:
задача посылать по скоростному SPI произвольные блоки данных через ДМА:
1. Один раз инициализирую ДМА и SPI при помощи SPL,
2. Запоминаю значения регистов в SPI и ДМА, ПЕРЕД запуском всего этого.
3. При повторном запуске другого блока данных с другим размером - восстанавливаю значения регистров, и меняю только адрес с размером и запускаю при помощи SPL ДМА.

Оформлено это всё в красивую отдельную либу с приятным "сахором" в виде одной функции spi_dma_send(addr, size);
и не знаю проблем ни с досканальным изучением регистров, ни скоростью запуска отправки блока, и написано всё на понятном SPL а не дрочь с битами в регистрах и последующим чтением "а чего это там за EN бит в CR1 записывается". И всё изучение регистров ДМА и SPI сокращается до нахождения адреса и размера посылаемых данных + общий порядок запуска всего этого дела (а по сути всегда это однотипно: настроить всё неважно как и дать отмашку уже важно в какой последовательности)

[Golikov A.]

а я делаю так:
задача посылать по скоростному SPI произвольные блоки данных через ДМА:
1. Один раз инициализирую ДМА и SPI при помощи SPL,
2. Запоминаю значения регистов в SPI и ДМА, ПЕРЕД запуском всего этого.
3. При повторном запуске другого блока данных с другим размером - восстанавливаю значения регистров, и меняю только адрес с размером и запускаю при помощи SPL ДМА.

круто!

[vepex]

Ребят, а что касается микросхем Ethernet (PHY) - что посоветуете? Желательно корпус LQFP.

[scifi]

Ребят, а что касается микросхем Ethernet (PHY) - что посоветуете? Желательно корпус LQFP.

Чукча не читатель?

[vepex]

Чукча не читатель?

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

[scifi]

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

Использовал KSZ8041, KSZ8051, KSZ8081. Никаких проблем не возникает.

[jcxz]

Оформлено это всё в красивую отдельную либу с приятным "сахором" в виде одной функции spi_dma_send(addr, size);
и не знаю проблем ни с досканальным изучением регистров, ни скоростью запуска отправки блока, и написано всё на понятном SPL а не дрочь с битами в регистрах и последующим чтением "а чего это там за EN бит в CR1 записывается". И всё изучение регистров ДМА и SPI сокращается до нахождения адреса и размера посылаемых данных + общий порядок запуска всего этого дела (а по сути всегда это однотипно: настроить всё неважно как и дать отмашку уже важно в какой последовательности)

Из всего многообразия возможностей DMA (работы связным списком, flip-flop, комбинации этих режимов, возможности прямой работы со сложными структурами данных типа кольцевых буферов и N-мерных массивов одной транзакцией и много другого что взбредёт в голову) Вы оставили куцый обрезок в стиле memcpy() и сидите радуетесь этому? Мне Вас жаль....

[Porty]

Из всего многообразия возможностей DMA (работы связным списком, flip-flop, комбинации этих режимов, возможности прямой работы со сложными структурами данных типа кольцевых буферов и N-мерных массивов одной транзакцией и много другого что взбредёт в голову) Вы оставили куцый обрезок в стиле memcpy() и сидите радуетесь этому? Мне Вас жаль....

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

[scifi]

а я в свою очередь жалею перфекционистов и любителей запилить все режимы только потому что они есть

+100500
Ув. товарищ перфекционист в соседней теме изобретает невозможный чудо-макрос на все случаи жизни. Всем понятно, что и без этого макроса хорошо, а всё равно руки чешутся
Решение абстрактных задач - это неплохо и забавно, в том числе в качестве разминки для извилин. Но следует понимать, что с решением насущных задач это, как правило, ничего общего не имеет. Пустая трата рабочего времени.

[jcxz]

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

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

Да и о чём тут (на форуме) ещё общаться? Только чайников учить? Скучно

[zltigo]

А вот насчёт использования всякого рода сторонних библиотек как раз и считаю это пустой тратой рабочего времени... на ловлю багов потом.

Именно так.

[mantech]

А вот насчёт использования всякого рода сторонних библиотек как раз и считаю это пустой тратой рабочего времени... на ловлю багов потом.

Хм... Линуксописатели тихо смеются в сторонке, ибо там-то точно без библиотек не написать ничего

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

[AlexandrY]

Хм... Линуксописатели тихо смеются в сторонке, ибо там-то точно без библиотек не написать ничего

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

Кроме того что вылавливаются еще важно чем вылавливаются.
Важно насколько среда заточена для вылавливания.
Если хотите GUI в исходниках переходите на eGUI под Kinetis-MQX - http://gargy007.github.io/egui_doc/

[zltigo]

А если без шуток, всегда умиляет то, что кто-то там наделал кучу багов в программах, а я-то их уж точно никогда не понаделаю, при написании с чистого листа, читая многотомные даташиты на английском, ерраты и пр...

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

Причем еще не всегда полностью понимая прочитанное...

Ну это Вы за всех не говорите.

А тестирование результата работы никто не отменял, поэтому и вылавливаются все эти глюки...

Умиляет. Типовой дерьмокод содержит такое количество потенциальных ошибок и написан с таким количеством заплаток, на ошибки котрые вылезли при минимальной работе в паркетных условиях, что ловить там уже НЕЧЕГО.

Кроме того что вылавливаются еще важно чем вылавливаются.

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

Хм... Линуксописатели тихо смеются в сторонке, ибо там-то точно без библиотек не написать ничего

Да смеяться-то нечего - способ обеспечения "надежности" в линуксе весьма лобовой - сотни писателей и тысячи латателей за годы дописали и долатали до приемлимого состояния. И продолжают...

[Porty]

А вот насчёт использования всякого рода сторонних библиотек как раз и считаю это пустой тратой рабочего времени... на ловлю багов потом.

чем SPL не угодила? она только перегоняет значения из структуры в регистры простым ленейным кодом в 99% случаях.
Более того производитель наверняка именно ей тестит своё железо, а другой порядок инициализации может дать сюрприз.
И никто не говорит о библиотеках как о панацеи, если разраб в их исходники и документации вообще неразу не глянул и у него не возникли даже сомнения делает ли он всё верно, то это его вина.
А так же распростронённые ошибки есть когда в AHB инициализируются константами APB, всякие не до конца заполненные структуру, переполения стеков, да и тупое игнорирование всяких мелочек.
А потом все ноют "SPL гавно, CMSIS вообще на свалку, WINapi уничтожить, poco примитивна - ООП не используется на всю катушку, а boost вообще дебилы писали - ничего не понятно в ней и это не ООП а гавно".

[brag]

Исползьую STM32. Почему то так исторически сложилось, что почти все проекты на них да и дрова под них понаписывал и ОС(хотя ОС просто под cortex-m3/4)

[Porty]

+100500
Ув. товарищ перфекционист в соседней теме изобретает невозможный чудо-макрос на все случаи жизни. Всем понятно, что и без этого макроса хорошо, а всё равно руки чешутся
Решение абстрактных задач - это неплохо и забавно, в том числе в качестве разминки для извилин. Но следует понимать, что с решением насущных задач это, как правило, ничего общего не имеет. Пустая трата рабочего времени.

Лет десять назад удивлялся откуда берётся столько человек оторванных от реальности.
А потом просто понял что многим везёт что их никогда:
- не заставлял менеджер: "заткнись и напиши этот грёбанный код за неделю, и мы получим годовую прибыль с этого олуха, а тебе дадим месячную ЗП"
- не писали одноразовых проектов
- не горели сроки
- не сталкивались с тем что разработка сделанная кое-как за пол года приносит 90% прибыли и хрен ты это изменишь даже сделав более качественный вариант дешевле, на который потратил пару лет.
- не сталкивались с заказчиками-идиотами которым нужен к швабре обязательно блютуз и ретина-дисплей

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

[Golikov A.]

Сначала длинно написал, а потом понял что вся суть в этом

не сталкивались с тем что разработка сделанная кое-как за пол года приносит 90% прибыли

Те кто получает 90% прибыли на проектах сделанных кое как, по моему мнению подлежат усыплению.
Сначала делаем проекты кое как, а потом говорим а чего это наш ВАЗ так фигов в эксплуатации... Стороны одной монеты!

[Porty]

Те кто получает 90% прибыли на проектах сделанных кое как, по моему мнению подлежат усыплению.
Сначала делаем проекты кое как, а потом говорим а чего это наш ВАЗ так фигов в эксплуатации... Стороны одной монеты!

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

А Вы просто придрались к словам, может автоваз чем то не угодил? Я например доволен, есть и i30 и шестёрка в качестве внедорожника по сёлам и ебеням, на них обоих нормально езжу и не жалуюсь.
Чего и Вам желаю

[zltigo]

А потом просто понял что многим везёт что их никогда:

На везение полагаться не надо. Надо просто творить СВОЕ а не менеджерское. А нежели те-же "разовые проекты", котрые ну очень кому-то надо хоть как-то давай-давай, то от таких ОТКАЗЫВАТЬСЯ без сомнений. Я, например, разовых в свое врнмя делал очень много и ВСЕГДА, без ЕДИНОГО исключения ПОСЛЕ всяких сделавших "быстро". Кстати, благодаря опыту АККУРАТНОЙ работы, медленно тоже не было .

не не не, я просто про баланс, если можно набыдлокодить и у всех оно работает нормально и приемлемо, то почему бы и нет?

Нет, потому, что нет. Потому-же, что не украсть, не убить...

[Porty]

На везение полагаться не надо. Надо просто творить СВОЕ а не менеджерское. А нежели те-же "разовые проекты", котрые ну очень кому-то надо хоть как-то давай-давай, то от таких ОТКАЗЫВАТЬСЯ без сомнений. Я, например, разовых в свое врнмя делал очень много и ВСЕГДА, без ЕДИНОГО исключения ПОСЛЕ всяких сделавших "быстро". Кстати, благодаря опыту АККУРАТНОЙ работы, медленно тоже не было .
Нет, потому, что нет. Потому-же, что не украсть, не убить...

была пара случаев когда сделав очень быстро и по уродски мы получали 1-2 ЗП за несколько дней. А потом ещё по итогам года т.к. оборот фирмы увеличился мы получали повышенные премии (ещё несколько месячных зп).
да обкодившись, да "быдлокодом".

НО

менеджеры были в курсе что этот код надо будет выкинут и его следует заново переписать заложив в десятки раз больше времени.
А тот кто отвечал за поддержку и сопровождение вообще потребовал и получил в 2 раза больше ЗП.
И впредь у нас заложили такое правило - если надо писать быстро - то и надо закладывать полную переделку этих фекалий, и не только в внутренний план фирмы но и предупреждать клиента что в последствии доработки будут СУЩЕСТВЕННО ЗАТЯНУТЫ или вообще откажемся от проекта потому что решить почестному это нельзя. И не стоит бояться говорить правду - находятся те кто платят услышав её.
И естественно не следует о себе забывать:
аврал - плати, МНОГО,
хотите качество - делитесь прибылью или платите бонусы,
оставляйте резерв по времени, авралы допустимы только нештатных ситуаций типа заполучить нового заказчика быстрее конкурентов.

Как вывод: Может Вы не умеете работать с руководством?

[Golikov A.]

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

[zltigo]

...типа заполучить нового заказчика быстрее конкурентов.

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

Как вывод: Может Вы не умеете работать с руководством?

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

Для ускорения я могу писать код жрущий ресурсы....

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

[Golikov A.]

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

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

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

[zltigo]

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

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

[Golikov A.]

Ок

[Corvus]

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

[Golikov A.]

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

[zltigo]

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

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

[jcxz]

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

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

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

- не горели сроки
- не сталкивались с тем что разработка сделанная кое-как за пол года приносит 90% прибыли

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

[Corvus]

Есть же и нормальные решения, в том числе и платные.

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

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

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

[jcxz]

Те кто получает 90% прибыли на проектах сделанных кое как, по моему мнению подлежат усыплению.
Сначала делаем проекты кое как, а потом говорим а чего это наш ВАЗ так фигов в эксплуатации... Стороны одной монеты!

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

не не не, я просто про баланс, если можно набыдлокодить и у всех оно работает нормально и приемлемо, то почему бы и нет?

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

[zltigo]

Платные решения:
а) ничего не гарантируют

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

б) исходники любят скрывать, чего не скажешь о бесплатных.

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

Но где взять на это время, если тратить силы на обсуждение говнокода и изобретение очередного велосипеда с ажурными колёсами?

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

И второй программист не хуже первого или наоборот. Просто у каждого своя специфика.

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

[jcxz]

На везение полагаться не надо. Надо просто творить СВОЕ а не менеджерское. А нежели те-же "разовые проекты", котрые ну очень кому-то надо хоть как-то давай-давай, то от таких ОТКАЗЫВАТЬСЯ без сомнений. Я, например, разовых в свое врнмя делал очень много и ВСЕГДА, без ЕДИНОГО исключения ПОСЛЕ всяких сделавших "быстро". Кстати, благодаря опыту АККУРАТНОЙ работы, медленно тоже не было .

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

[Corvus]

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

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

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

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

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

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

[jcxz]

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

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

[zltigo]

На том опен-соурс и строится. И находят, и исправляют

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

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

Это не совет.

[jcxz]

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

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

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

[Corvus]

я лично про Вас спрашивал.

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

[zltigo]

Кстати - именно из-за этого долго не получалось слезть с LPC17xx

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

[Corvus]

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

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

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

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

[jcxz]

Платные решения: а) ничего не гарантируют

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

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

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

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

[Corvus]

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

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

[zltigo]

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

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

[jcxz]

В своём-то коде граблей не бывает... Или всё же они вылавливются в процессе разработки? А по времени то на то и выходит.

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

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

[zltigo]

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

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

А в чужом ковыряться - на порядки дольше и даже неясно куда копать.

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

[aleksandr-zh]

А как предлагается определять их "нормальность"? ....
Просто у каждого своя специфика.

+5

[jcxz]

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

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