Jump to content
    

Leaderboard

Popular Content

Showing content with the highest reputation since 04/26/2024 in all areas

  1. Нет, скрам -- это методология ведения работы. А система следующий, более низкий уровень иерархии, система управления строится на основе методологии. Что не делает методологию системой. Конечно. Логистика, закупки, отлаженные производственные процессы -- да. Где всё более-менее предсказуемо и поддаётся адекватному прогнозированию. Но не в разработке нового. Серьёзно? 🙂 Ещё как даёт -- просто методы лодыри применяют другие. Например ИБД (имитация бурной деятельности). А в совокупности к хорошо подвешенным языком бездельник вообще может казаться самым деятельным -- скрам предоставляет как раз возможность демонстрировать (дейлики и прочие регулярные митинги). Не даёт лодырничать никакой не скрам. Вообще, никакая методология или система управления не решает сама по себе эту задачу. Её решает конкретный человек -- руководитель. Если он на своём месте, он прекрасно видит, кто что стоит, кто чем занимается, где есть толк, а где пустота (имитация). Потому что принцип "Кадры решают всё!" применим не только к исполнителям, но и (в первую очередь!) к руководителям. Управление -- живой процесс. И всё зависит от квалификации, умений, опыта и адекватности человека, который осуществляет это управление. Никаких других вариантов нет. Полагать, что скрам что-то там кому-то не даёт или наоборот обеспечивает результат -- есть вредная иллюзия. Далее по пунктам. Ещё одна иллюзия. То, что скрам-методология предполагает ежедневные митинги наряду с планированием спринтов и ретрами, никакой вовлечённости не повышает и не обеспечивает: сидят люди на митинге, слушают бубнение очередного выступающего, ждут своей очереди отчитаться и того, когда это бесполезное и бессмысленное мероприятие закончится. Только и всего. Много раз лично участвовал в этих митингах и наблюдал оную картину. Вовлечённость в проект может поднять тот же самый человек, который руководит процессом, применяя три рычага (это известная тема из психологии): поднять интерес подчинённого сотрудника-коллеги, правильно выбирая для него задачи -- далеко не все задачи интересны всем, поэтому тут надо внимательно и чутко подходить. Будет интерес -- будет результат. Интерес -- это самый главный мотиватор; помочь с пониманием трудных моментов (сам или привлекая других, более квалифицированных в вопросе людей). Когда человек имеет хорошее понимание того, что он делает, это тоже прилично мотивирует (повышает вовлечённость), позволяет работать эффективнее, что поощряет исполнителя, который видит позитивный результат своей работы; довести важность дела до сотрудника-коллеги: нужность результата, ответственность перед заказчиком, уважение товарищей и т.п. Всё это -- живая работа с людьми. Только она и даёт результат. А пустая говорильня на дейликах -- просто трата времени и сил. За счёт чего? Что такого уникального даёт скрам для этого? Что собрались и поговорили? Ну, собрались и поговорили. Наговорились, устали, ничего не решили -- это сколько угодно. Даже более того -- это обычный результат, когда толпа пытается что-то решить. "Лебедь, рак и щука". И эта говорильня продолжается из раза в раз без всякого результата. Решение менять курс (адаптироваться) должен принимать тот, кто отвечает за результат. Его ответственность, его и решение. Как правило, это тот же самый руководитель работы. Он может собрать людей, спросить их экспертное мнение, выслушать каждого, и на основании этого, а также своего опыта и знания своих людей (к чьему мнению в какой ситуации нужно прислушиваться больше, а чьё умножать на 0.1) принять решение, за результат которого ему потом отвечать. Никакие общие собрания и пустопорожная болтовня на них не нужны. Соблюдение сроков обеспечивается грамотным разбиением работы на этапы и контролем выполнения работы по этим этапам. А коллективная ответственность -- это миф! За исключением крайних случаев: типа, все мегасознательные и ответственные как главный герой из советского фильма "Коммунист", или когда в случае неуспеха всех расстреляют (лишат премии, уволят и т.п.). Во всех других случаях коллективная ответственность проявляет себя как коллективная безответственность. Всегда в группе (статистически) находятся раздолбаи, тормоза, рукожопы, эгоисты-индивидуалисты и т.п. И без присмотра и персональной ответственности всё это приводит к тому, что результат провальный, с спросить не с кого. Итого, опять всё сводится к компетенции и квалификации управляющего процессом конкретного человека. Работает только в случае простых задач. Проходили не раз. Когда задачи сложные, требующие серьёзного вникания, всё это не работает от слова совсем. Пример из реальности: пилим командой ПЛИСовый проект, я занимаюсь PCIe DMA (на TLP), а коллега -- поиск паттернов в потоке сетевого трафика. У нас задачи не пересекаются вообще никак! И каждая из них требует глубокого погружения. В итоге, все скучают, когда я что-то бубню запросы чтения памяти хоста, проблемы негарантированного порядка прихода CplD от разных запросов, про кредиты non-posted запросов и подобное, а когда коллега говорит про свою работу, я из его рассказов понимаю только, что у него там какие-то блум-фильтры, перфектные таблицы кукбука и ещё какая-то хрень, названия которой я не запомнил. Чтобы мне понимать, о чём он говорит, мне нужно серьёзно погружаться в тематику его работы, но я не могу этого делать -- у меня своей выше крыши. И у него ровно та же ситуация. И у всех в группе. Получается, что все сидят и тупо ждут, чтобы отчитаться, и когда это пустое мероприятие закончится. Скрам-мастер не понимает вообще ничего из того, что там говорят, т.к. он не специалист ни в ПЛИС, ни в тематике проекта. Ну, по скраму он и не должен. Его задача -- быть секретарём заседания. И вот в итоге проектом занимается 8 человек, но задачи у всех перпендикулярные, какие-то общие места есть только на стыковках, а это очень небольшая часть проекта. В итоге, на общие темы мы можем поговорить только про какое-нить CDC FIFO, проблемы с STA, нюансами использования общего инструментария (симулятор, синтезатор и т.п.) и другими общими вопросами, которые к непосредственно проекту имеют опосредованное отношение. Итого, эффективно задачи решаются при правильно организованной иерархии управления, когда все люди -- и специалисты, и руководители (от крупных до тимлидов) на своих местах. Иерархия -- это естественный способ решения сложности в человеческой коллективной деятельности.. Да, тут важно не скатиться в раздувание иерархии на пустом месте, не допустить возникновения и роста бюрократии и формализации. Поддерживать процесс живым -- это достигается только правильным подбором кадров и никак иначе. Скрам же тут не помогает совсем никак. А мешает изрядно. Он размывает ответственность, распыляет цели, место чётко выверенного курса получается "рыскание". На локальном уровне хорошо работает самоорганизация, когда подбираются (или подбирают) люди ответственные, мотивированные, знающие и умеющие -- она сами между собой наладят и взаимодействие, и рабочий процесс. Но это происходит самодвижущимся образом у них без всяких скрамов. Скрам и тут только мешает, пытаясь формализовать этот естественно сложившийся процесс. Когда задача совсем новая и непонятная, то, конечно, никакого внятного ТЗ быть не может. Поэтому ведётся предварительная работа -- например, как вы правильно назвали, выполняется НИР. А потом при выполнении ОКР ещё эскизный проект (ЭП), на входе которого присутствует проект ТЗ, и цель ЭП -- создать технический облик объекта разработки и разработать уже нормальное ТЗ, с которым можно смело идти в технический проект (ТП), коий уже и есть собственно разработка. Где тут рулящая роль скрама? Да без него это сто лет делалось и делается. Он сюда вообще не вписывается. Что же касается корректировки ТЗ по ходу дела, то и это возможно, но не так огульно как это делается со скрамом. Если заказчик предлагает (просит) что-то поменять, это рассматривается, и если принимается, то выпускается специальные документ: дополнение к ТЗ. Все эти доп. хотелки отражаются там. И всегда видно, что было исходно, а что изменилось по ходу дела. Отдельный документ позволяет хорошо видеть, сколько чего, когда и как изменилось. И это позволяет эффективно пресекать излишнюю тягу заказчика к фантазиям . При разработке софта эти изменения реализуются ещё как-то более-менее безболезненно. При разработке железа -- это как правило боль, и часто оказывается неприемлемым. Иначе разработка затягивается на годы. Это проблема, когда софтовая контора берётся делать железо: тематика и средства радикально другие, а подходы те же самые. Я работал в софтовой IT комании, которая взялась разрабатывать железо (для себя, для своего продукта), в итоге 6 лет хардварному отделу, объём работы проделан колоссальный, сами разработки технически очень достойные (специалисты высокого уровня там трудятся -- контора может себе таких позволить), но в серии и у клиентов по истечении этого срока нет ни одного из полудюжины разрабатываемых изделий. Это происходит именно по причине постоянных корректировок хотелок, отрицания ТЗ как такового, отсутствия этапности в работе, зато есть скрам во всей его красе с коллективной ответственностью безответственностью и прочим. Да и странно предъявлять ответственность исполнителям, если от них тут мало что зависит -- каждый из них на своём месте свою работу сделал хорошо. Подводя итог Скрам, возможно, неплохо себя проявляет при разработке, например, веб-приложений, когда результат работы можно сразу предъявить, и заказчик видит его, может попросить что-то поменять или откорректировать -- вот тут спринты, как контрольные точки, помогают. Но когда ведётся разработка материнской платы сервера (со 128-ядерным процессором и 16 планками DDR4), где работа схемотехника и конструктора ПП занимает по полгода, какие нафиг спринты?! То же самое и с ПЛИС: тот же PCIe DMA я пилил несколько месяцев, и эта работа почти никак не пересекалась с другими -- она несмотря на известную сложность, является локальной, законченной в себе -- ни вводные никакие снаружи тут не нужны, ни результат показать в конце спринта невозможно (вряд ли кому будет интересно смотреть на очередной добавившийся тест того или иного модуля). По итогу пристального наблюдения за этой темой и невольного участия в ней, для себя я сделал следующий вывод: скрам -- это вредная иллюзия управляемости процесса, которая проникла глубоко в сфере IT. Секрет успеха этого внедрения состоит из двух частей: Потребность руководства IT компаний в инструментах управления, которые оное руководство само создать не смогло, но тут ему предложили готовое "решение". Агрессивная реклама этой методологии со стороны консалтинговых агентств и лавок вроде AgileLab, желающих рубить немалые деньги на некомпетентности, доверчивости и легковерности руководителей IT контор. Ну, почему руководители контор ведутся на это -- это Даннинг-Крюгер в полный рост: уровень управленческой компетентности не позволяет ни организовать процесс эффективно, ни понять, что предлагаемое тоже не решение. Процесс разработки и продвижения софта сам по себе прощает многие косяки -- цена ошибки невелика, стоимость производства ноль, сроки производства -- тоже почти нулевые (сколько на пересборку требуется), возможность отлаживаться на клиентах и т.п. Всего этого нет в теме разработки железа, там всё эти ошибки стоят дорого. Поэтому там этот подход не работает совсем. Если в какой-то конторе ввели Scrum, это по факту и по сути является ничем иным как росписью руководства этой конторы в собственной управленческой несостоятельности. Не больше, не меньше.
    5 points
  2. народ токсичный пошел. внимательно вчитывается. объясняет, что за написанным стоит. предупреждает невнимательных коллег, что что означает. нет, чтобы схватить не глядя, как при совке : сыр или туфли черные мужские - главное, что схватили.
    3 points
  3. Коллеги, я решил проблему с ошибкой верификации битстрима. Что было изначально: - битстрим собран в Vivado с использованием патча от Fudan версии 5.2.0, итог: успешная верификация на всех чипах 2022 года и на 41% чипов 2023 года. Что я сделал чтобы решить проблему: - ранее собранный битстрим прогнал через инкрементальный патч в Platform Tools из Procise, дабы посмотреть, что будет меняться в зависимости от установленных галочек, итог: с дефолтными настройками получил битстрим, который успешно проходит верификацию на всех чипах 2023 года выпуска. *.msk файл при этом от исходного битстрима. Похоже, что патч для Vivado либо не до конца отрабатывает, либо не учитывает какие-то особенности более новых чипов. При этом я также получил Warning от Platform Tools, что у меня в битстриме есть SDP RAM, хотя патч должен был поправить SDP на TDP. Более того в логах самого патча нет никакой ругани на SDP. В общем проект спасён, вроде есть путь, по которому можно получить рабочее решение, но, как говорится, осадочек остался... Буду пробовать PangoMicro - со дня на день должны приехать 🙂
    3 points
  4. Это что за ТЗ такое, когда через месяц оказалось, что оно не про то? ТЗ -- серьёзный документ, от него зависит результат чуть не на все 100%. ТЗ -- это отправная точка в разработке. Из него формируются этапы работы. Если через месяц выясняется, что ТЗ не про то, что надо, разработчика ТЗ (или того, кто ему задачу ставил) гнать за профнепригодность. Меняет и дополняет по ходу дела?!!! Серьёзно?! Вот это и корень проблем при использовании IT'шных подходов в разработке железа! Это в софте можно быстро перех..якать, с железом это не прокатывает. Да и с софтом эта практика порочна и является источником массы проблем, просто там последствия ощущаются не так больно. Вместо того, чтобы сразу подумать и спланировать процесс, там доминирует метод "х.як, х..як и в продакшн". Единственный сценарий, где такое оправдано -- это когда задача (что нужно конкретно сделать) недостаточно ясна на старте, и пока не начнёшь, невозможно понять, как конкретно это надо сделать. Поэтому применяется этот метод "тыка" -- сделали что-то, увидели, то или не то. Тут, конечно, нужно всем участвовать -- и заказчику, и разработчику, и периодичность этих контрольных точек должна быть достаточно короткой (1-4 недели) -- те самые спринты. Это как-то работает при разработке софта, но с железом это полный провал. Там нужно всё заранее тщательно проектировать и планировать, потому что перефигачить по ходу дела не получится, т.к. стоимость производства в отличие от софта далеко не ноль. Что знают? Что мешает это знать без скрама? А нужно ли всем участникам это знать? Не будет ли это "знание" отвлекать их от своей конкретной и сложной работы? Это нужно знать всем участникам команды? Зачем? Об этом нужно знать тем, кто к этому причастен. Это узнаётся адресно без всяких скрамов. При правильной организации работы есть её руководитель, который всё аспекты курирует (или назначает ответственных, если задач много). И для этого скрам нужен? А как же без него-то обходились десятки лет и продолжают обходиться? Когда приступать к выпуску КД -- очевидно на этапе РКД. Ну да, тут никак не обойтись без планирования спринта, дейликов, ретры. Ведь все разработчики должны быть в курсе, когда же надо отдать корпус в покраску. И уж стопроцентно это должны знать скрам-мастер и продукт овнер. Ну, если потеря кучи времени и отвлечение на посторонние процессы, зачастую искусственные и бесполезные, как натягивание работы на сторипоинты, никого не расстраивает, то пожалуй поверю. 🙂 Ну, о чём и речь -- годится только для простых и понятных задач, которые ясно, как делать, можно достоверно спрогнозировать трудозатраты и т.п. Словом -- не про разработку. Логистика, снабжение, какие-то уже более-менее отлаженные производственные процессы, когда есть опыт, на который можно опереться. В разработке нового такого опыта как правило нет, поэтому всё это скрам-планирование идёт лесом. Ну, удачи вам
    3 points
  5. 3 points
  6. посмотрите библиотеки из этой коллекции: https://github.com/iDoka/awesome-embedded-software (там есть прям раздел "Сжатие")
    3 points
  7. Аналоговнет? Я какую мысль хотел донести: любая деятельность, создающая рабочие места здесь, полезна. Деятельность, направленная на создание интеллектуальной собственности, полезна. А что до аппетитов, так такой же европейский оверпрайс никого раньше не смущал?
    3 points
  8. написать дерьмо можно и на си, на %ПОДСТАВЬ_ИМЯ_ЯЗЫКА%. Этот код борланд-стаил. Борланд славится тем, что не придерживается строгому стандарту, а пытается стандарт под себя прогнуть. Даже в народе ходит выражение "Есть язык С++, а есть язык Borland-C++". На с++ такой код classA.size = 100; Очевидно, что у classA есть публичный член size. В Borland-C++ Tlabel label; label.text = "Hello word" с точки зрения c++ text - это публичный указатель. Но в борланде за text через __property cпрятан сеттер типа Tlabel::setText(consr char *str). Школата и неокрепшие умы начинают пробовать свои силы в с++ и пробуют писать форточки на народном Borland-C++. Программисты МК, закоренелые сишники, пишут утилитки для отладки своего железа с ПК (до сих пор многие сидят на Borland-C++ 6). борланд предлагает class.text = "hello". Они видят, что text в паблике и приучаются к этому и потом пишут свой код на с++, без сетеров/гетеров, всё в паблике и не парятся.
    2 points
  9. что вас так буквы ТЗ взбудоражили... компания имеет денег, готова платить (хбз будет или нет :)), работает по стандартной (но не новой) схеме... на то и придумали спринты, чтобы править требования по мере движения жизни вперед и появления новых условий. Спринты удобная штука можно легко корректировать курс, вычислять лоботрясов и бездарей
    2 points
  10. Давайте откроем отдельную тему по поводу управления разработкой.
    2 points
  11. Начиная с ATmega128 и ATmega8, ЕМНИП, бит SPIEN недоступен при программировании через SPI. Что-то другое вмешалось, например - RSTDIS.
    2 points
  12. Самая вишенка на этом торте. Это не просто подготовка проектов, заправка питателей и оператор, но и диагностика неисправностей и их устранение. Значит специалист по точной механике, приводам, пневматике, опыту юстировки конкретного оборудования и все в одном флаконе. Помимо всего прочего имеющий инженерные коды доступа к этим станкам и сервис мануалы, которые просто так никто не дает, ибо имеющий их, может очень неплохо зарабатывать выездным сервисменом. Говорю так, потому что немного знаком со всей этой кухней изнутри.
    2 points
  13. Работа периодическая, не на полную занятось, те больше в режиме подработки. География - чтобы можно было иногда доехать в офис, но в целом дистанционная. Работаем в основном над своими идеями, заказного мало. Производим, в основном, диктофоны Edic-mini ( www.telesys.ru ). Идеологически они несложные (по сути микрофон, контроллер (STM32 сейчас) и память) и похожие, но мы выжимаем максимум из параметров (минимальный размер и тд) те оптимизация - это основное. Суть работы сводится к сборке проектов в кучу, их проверке, наведению лоска, отладке технологии сборки, доделке ничейных мелочей и тд. Как правило, схему, прошивку у нас делает один человек, плату разводит другой, корпусные детали делает третий. Все это нужно в кучу собрать чтобы получился диктофон, потестить, собрать обратку от продажников, истории ремонтов, дать рекомендации что надо изменить, где поправить (или сделать это самому, если есть навыки - получится быстрее), описать (или видео) технологию сборки и контроля для серийной сборки (сборку плат мы заказываем на стороне, а у себя делаем финальную сборку) и тд. Какие навыки полезны: тестер, осциллограф, паяльник, лазерный гравер/резак, 3D принтер. Ну и общее понимание техники. Все мелкое, поэтому хороошее зрение важно. Если можете делать какую-то работу на уровне разработчика/конструктора, то можем озадачить и ею. Оплата - ну, наверное, попроектно. Договоримся. Раньше у нас был человек для этой работы, но у нас случился большой перерыв во внедрении новых изделий, поэтому ищем нового. С предложениями пишите в личку, плиз.
    2 points
  14. Грамотным является хотя бы прочитать то, что пишут оппоненты. А вы видимо даже не читали то, что я предложил. Если бы прочитали, то уяснили бы что: Т.е. - период 4,3•106001 (о котором я писал) - это не константа. И можно выбрать свой период, наиболее удобный. Из ряда простых чисел Мерсенна. Ряд этот имеется по приведённой мною ссылке. Например в нём есть число = 170141183460469231731687303715884105727. (что даёт разрядность = ln(170141183460469231731687303715884105727)/ln(2) = ~127 бит). Т.е. - реализуем Вихрь Мерсенна с базой = 170141183460469231731687303715884105727 и получаем период = ~2^127. И этот период математически обоснован, а не голословное утверждение. ТСу 2^127 вроде как - вполне достаточно.
    2 points
  15. Профсоюзный Лечебный Комплекс
    2 points
  16. Минимально по компонентам - микроконтроллер.
    2 points
  17. Ура, с Днём Победы в 1945 !!!
    2 points
  18. Есть libpng для работы с .png: http://www.libpng.org/pub/png/libpng.html В исходниках. Которая внутри для сжатия использует zlib: https://www.zlib.net/ Лучше передавать .png, а внутри распаковывать с помощью libpng. .png ничем сжимать не нужно, оно внутри уже сжатое будет (особенно если поставить максимальный уровень сжатия = 9). Не знаю её требований по ОЗУ, но скорее всего надо быть готовым, что потребует довольно много его. Впрочем - уровень сжатия можно настроить в диапазоне: 0...9. Также есть какие-то настройки (дефайнами) разных параметров. Вроде и размер словаря там можно было настроить.
    2 points
  19. Вместо SIM800C закладывайте A7682E. Загуглите аппнот A7682E_SIM800C_SIM868_ SIM7080G Compatible Design
    2 points
  20. У них, грубо говоря, свой синхронизатор, т.е. они накапливают данные в буфер синхронно, а потом передают винде с метками времени.
    2 points
  21. Только не клон, а просто китайский МК. У них ведь всё лицензионное. Последние года 2-3 встретить на "голубой таблетке" настоящий STM32F103 сродни встрече с девственницей в борделе.
    1 point
  22. Уточнил с производителем - у них нет errata отдельно. Максимум что есть - список багов которые публикуются в описании релиза PDS Даташит на Titan 2 версии 1.5. Изменения не критичные. DS05001 Titan2 Series FPGA Device Data Sheet 1.5_microterra.ru.pdf
    1 point
  23. внизу же кнопки Импорт-Экспорт. но лучше сохранить PCB шаблон и его использовать уже со слоями. но как показывает практика, еще проще открыть последний проект и удалить в нем всю графику и использовать в новом проекте. т.к. PCB все равно обрастает новыми слоями, правилами и т.д.... Можно, нужно разлочить компонент. Но крайне порочная практика. Я б за это схемотехникам своим руки бы по отрывал. Железно рано или поздно будет ошибка. Лучше однажды исправить в библиотеке. По опыту могу посоветовать не стесняться в размере промежутка между пинами. Т.е. тупо ставим пины подальше друг от друга, а не лепим на расстоянии 2.5 мм при пересечениях провожу проводники под 45 градусов. вполне симпатично получается
    1 point
  24. на плате и настраиваются. а так Default/ В любом случае это на плате нужно. Только там видно свободное место, где можно расположить текст и подобрать его размер
    1 point
  25. https://www.google.ru/search?q=nanocrystalline+common+mode+choke
    1 point
  26. 1- скорее всего это каркас, чтобы провод не перетирался об сердечник, т.к. судя по всему, дроссель рассчитан на большие токи, раз один контакт состоит из четырех проводов, и он может сильно вибрировать во время работы Вот вид классического дросселя на 2-3А
    1 point
  27. Согласно данному выше ГОСТ, оно всегда нечистое, и описаны все подробности.
    1 point
  28. Это какой-то косяк в модели дросселя. Если заменить дроссель на две связанные выражением К индуктивности, то всё правильно показывает +6 и -6. Резонанс Щёлкнув правой кнопкой мыши на оси углов (справа от графика), можно выключить отображение ФЧХ. Аналогично с АЧХ (слева).
    1 point
  29. Ну, тогда уже и все остальное заказывайте по образцу и подобию. Дешевле будет.
    1 point
  30. Расшифрую немного. Сейчас вы видите в отчете что-то, чего сами не задумывали в дизайне. Значит, IDE собирает какой-то другой проект, НЕ ВАШ. И собирает его неправильно. Вам нужно детально проанализировать каждую строчку репорта - посмотреть код, посмотреть схему, проверить тактирование всех участвующих сигналов. Если IDE говорит, что есть пересечение клоков - то так оно и есть. По крайней мере, в "её" проекте. Вопрос только "где?" и "как это исправить?". В одной и предыдущих ваших тем на форуме мы уже обсуждали этот момент. С помощью констрейнов можно легко заглушить все нарушения. Но вам-то, наверное, не отчеты нужны, а работающий дизайн. Поэтому, скорее всего, каждая красная строчка отчета потребует некоторых доработок по коду. Где-то нужно будет добавить синхронизаторы, а где-то - констрейны. Каждый случай потребуется разбирать отдельно, и на форуме это сделать сложно. Почитайте книжки, которые я прикрепил, это самая лучшая литература по теме.
    1 point
  31. Не подобрать, а рассчитать, читаем документацию АкейГугла
    1 point
  32. Возьмем на оплачиваемую стажировку студентов технических ВУЗов с минимальным опытом разработки под STM32&ESP. Оплата до 100 тысяч, возможность совмещения с учебой.
    1 point
  33. золотые слова. когда речь идет о разработке (хотя, повторюсь, эта задача наверняка решена, ну правда, а связкой контроллер - компьютер и подавно) ни о каких 3 и 5 речь даже не идет. вообще не считаем. ибо делая с 0 получаем ниокр. и по срокам и по цене. а делая одну две три штуки получаем цену настоящую. у меня платка с простеньким процем и 5 операми в количестве 3 шт, для очень своих, одно железо, просто поддержать науку, это 50. еле со скрипом. вот мысль такая. в этой теме много народу приходит. и начинают со схемотехники и со своего видения, сколько стоит. вот просто 90 % постов такие. есть посты без единого вопроса. там все в порядке. а есть напрашивающиеся на простую зеркалку : приходим в магазин: я считаю что должно стоить столько , а это столько. и в разработке начало разработки должно начинаться не со схемотехники , а с экономики. и этот пост будут читать будущие возможные работодатели. затевая приборчик, исходите из стартовой стоимости ниокра в миллион (на производстве умножаем это на 10). если вам эта цифра не нравится, у вас ничего не получится. природу можно попробовать обмануть , только обмануть не получится. если вы начнете с калькулятором умножать стоимость 10 резисторов на 3 рубля и исходить из этого , вы просто обманываете себя. вы могли бы так считать покупая под себя. но, почему то идете к другим, при этом рассказывая, как все должно быть.
    1 point
  34. Всё это описано в стандарте, но в разных его частях. Поэтому могу предложить вам почитать книгу, которая есть на местном FTP в /pub/DOC/STANDARDS/PCI/Whitepapers/Budruk R., Anderson D., Shanley T., PCI Express System Architecture(2003).pdf Начните с главы 21. Такой опыт есть, правда не на Zynq, а на Artix. Но в целом разницы нет, и там, и там Root Complex. Вы управляете ресетом, даёте ресет, IP поднимает линк, далее вы сами должны сформировать конфигурационные транзакции для поиска устройств (endpoint) на шине, записывает параметры в их регистры (назначает адреса, разрешает работу MEM/IO) и выполняет транзакции чтения/записи. В целом там нет ничего сложного, звучит это страшнее, чем есть на самом деле.
    1 point
  35. Очень просто. Дело в том, что у линковщика тоже есть переменные, которые он на этапе связывания может передать в программу пользователя. Оставил только то, что относится к сути вопроса. Скрипт линкёра, в котором создаётся переменная _estack. /** ****************************************************************************** * @file LinkerScript.ld .... /* Highest address of the user mode stack */ _estack = ORIGIN(RAM) + LENGTH(RAM); /* end of "RAM" Ram type memory */ Далее в стартап-файле (у меня он свой) описываем эту переменную: //////////////////////////////////////////////////////////////////////////////// // // startup_stm32f446xx.cpp // //////////////////////////////////////////////////////////////////////////////// // GCC ARM compatible .... extern void *_sidata, *_sdata, *_edata; extern void *_sbss, *_ebss; extern void *_estack; // вот описание этой переменная из линковщика .... const intfunc __vector_table[] __attribute__ ( ( section (".isr_vector_FLASH" ), used ) ) = { (intfunc)&_estack , // значение этой переменной вычислит и подставит линковщик &Reset_Handler, &NMI_Handler, &HardFault_Handler, &MemManage_Handler, &BusFault_Handler, ... Значения переменных _Min_Heap_Size = 0x800; /* required amount of heap */ _Min_Stack_Size = 2K; /* required amount of stack */ используются точно также. Мне в стартапе они не нужны, поэтому прмер привёл для _estack.
    1 point
  36. Не знаю, я лично с JBC NET не работал, попалось на глаза, когда картриджи заказывал. У нас так. Правда и монтажниц не очень много. Единственная проблема с JBC, это дороговизна и долгий срок поставки картриджей.
    1 point
  37. А самое смешное, что задача с УАРТом, И2Ц, АЦП и таймером решается без каких-либо РТОС 🙂 По крайней мере, мы раньше на такие темы даже и не заморачивались. Это вот сейчас стало модно крутить РТОС даже в светомигалку. Использование ДМА и прерываний, вкупе с системным таймером позволит устаканить указанные четыре вещи без РТОС как за нефик делать. Перечисленные модули все равно же будут работать примерно поочередно, типа пока не будет готов результат АЦП, УАРТ не будет начинать передачу. И наоборот, пока по УАРТу не придет команда запуска АЦП, он не будет запускать процесс измерения. И2С - это наверно какой-нить OLED 128х64. В лучшем случае 🙂 Ну это так, для справки, примерно плюс-минус както так.
    1 point
  38. Большое Всем спасибо! Уже пишу код с этими расчетами. Мне понравилось по старинке через двоичный код. Как раз будет два массива, один в виде 0b другой с соответствующими сопротивлениями.
    1 point
  39. Да не стабилитрон это, PESD5V2
    1 point
  40. Pango_BSDL.7z Попробуйте поискать в этом архиве.
    1 point
  41. Разумнее снять S-параметры с входного и выходного каналов микросхемы и с учётом топологии п/п покрутить в CADе согласующие цепи.
    1 point
  42. Для управления делителем APB/APB1/APB2, как и делителем AHB, никаких дополнительных манипуляций не требуется. Никаких переключений на HSI и всего прочего не требуется. Кстати, ваш код работает совсем немного не так, как вы хотели (но это вряд ли на что-то ощутимо повлияет для вас). Вы сначала сбрасываете поле PPRE в регистре периферии, устанавливая делитель /1, а лишь затем ставите свой делитель. Лучше сделать через одно read-modify-write, так: RCC->CFGR = (RCC->CFGR & ~(RCC_CFGR_PPRE_Msk)) | RCC_CFGR_PPRE_DIV4; Так вы избежите кратковременного переключения на "левый" делитель. В целом, всё выглядит работоспособным. А как вы это проверяете? Не здесь ли проблема?
    1 point
  43. Можно использовать слово не из 8 бит, а из 16 STCP повесить на аппаратный NSS SPI - данные защёлкнутся сами по фронту, не нужно ничего софтом делать
    1 point
  44. Волшебная микросхема называется сдвиговый регистр.
    1 point
×
×
  • Create New...