Специально пересмотрел твои примеры и твои алгоритмы. Недоуменно пожал плечами. Неинтересно. А теперь слушай меня внимательно. Сидишь, плюешься на промышленность. Я внимательно пересмотрел твои примеры. Твой уровень не очень. Каша. В голове тоже. Так что закройся и тем более не смей хулить нашу промышленность. "Профессионал" штопаный.
Да нет, сейчас конкретно о ваших примерах. Вы ведь собирались тут всех учить правильно жить и творить, говорили, что вы прям супер-мега крут, так ведь? Ну так вот как раз мы и разбираемся с вашей супер-пуперностью Вот и скажите, господин учитель, почему вы написали в файле proc_inputs.h включение его же самого в себя #include "proc_inputs.h"? Нет, на самом деле, почему и для чего? Можете объяснить это? Вы хоть пользуетесь какими-нибудь инструментами анализа написанного? Потому как просмотр иерархии четко и однозначно покажет, что в файле proc_inputs.h отклонено подключение #include "proc_inputs.h" по причине написанного "защитного" дефайна #ifndef PROC_INPUTS_H #define PROC_INPUTS_H. Уберите этот защитный механизм, и у вас вылезет ошибка повторного подключения того же файла.
Ну и второй момент: по какому принципу вы включаете в заголовочные файлы всё что нипопадя, смешивая "мухи и котлеты", "люди и кони"? Почему у вас нет деления на модуль и интерфейс модуля, и почему там, где положено быть интерфейсу модуля, у вас смешано "люди, кони, мухи, котлеты"? Кто вас этому научил? Снова бездумное копирование ранних ошибок?
Да, вот к чему приводит бездумное шаблонное мышление. Ошибки, не проработанные на ранних этапах, так и кочуют из проекта в проект, без понимания причин и следствий. Вот такой вот итог. Как говорится, "и он еще нас учить собрался!" Я ж говорил - не показывайте эти писульки АРМ-щикам - засмеют и закидают тапками. Нееет, с такими "учителями" нам не построить свой CTX Gamma 2000 Будет получаться только коловорот ручной с кнопкой "назад".
Тест. Ты там алгоритм выкладывал. За такой алгоритм тебя любой вменяемый эмбеддер тапками закидает. Это не алгоритм, а каша. Слишком много нагромоздил. Так что утрись и иди себе... Например, Паронджанова почитай, как нужно правильно составлять алгоритмы.
Нет, погодите, мы сейчас о вас говорим, "учитель". Вы нас учить собрались. Мы посмотрели, послушали и задаем вопросы. Будьте добры, поясните, почему ваш "учебные пособия" содержат вот такие вот нелогичности и запутанности в заголовочных файлах модулей. Поясните, по какому принципу вы вписываете в интерфейс модуля всё то, что там не должно быть по определению интерфейса модуля? Нет, вы поясните, почему в интерфейсе модуля вы пишите #define check_in_1() (check_bit (IN_1_PIN, IN_1)) // High level. , то что используется ТОЛЬКО в этом модуле и не выходит за его пределы? Или вы просто не знаете, что такое интерфейс модуля и что он содержит? Печально, печально. Мда. А вы то обещали "модульность, инкапсуляция"... А оказалось... "мухи и котлеты, люди и кони". Вы хоть знаете, что инкапсуляция относится к С++ языку, а в Си она не реализована. Я уж не спрашиваю, понимаете ли, что это вообще такое. Вы бы еще про полиморфизм завернули бы
Последний раз редактировалось MLX90640 Сб окт 08, 2022 21:44:53, всего редактировалось 1 раз.
Ну и чего цапаться то? Ничего неожиданного в том, что у каждого имеется свой "слэнг" или излюбленный стиль написания текстов. Это вполне закономерно - и начальная подготовка и специфика практического приложения различны. Варианты применяемых сред разработки также имеют свою специфику. Да и цели порой весьма разные - кому простое любительство, кому работа. Кстати у Корабельникова также можно кой-чего взять... Интересно бы в обсуждении поконкретнее поучаствовать - да это не ассемблер, а в Си у меня только на адуринке варианты(и проекты и макеты) там с одной стороны проще с другой и посложнее ( в проекте могут использоваться файлы как в СИ стиле так и в С++ стиле, да еще и Сишный ассемблер для оченно подготовленных пользователей -благо хоть для АВРок на основе GCC). Насчет расхода памяти - на то и ЯВУ, чтоб память кушать. Альтернатива дотошное изучение документации изделия (микроконтроллера) и работа под ассемблером.
Последний раз редактировалось BOB51 Сб окт 08, 2022 21:50:09, всего редактировалось 1 раз.
Да нет, можно всё списать на "я художник, я так вижу". Но тогда не зачем других учить. Потому что уровень нелогичностей и элементарных ошибок - просто зашкаливает. Ну ладно, допустим, наплевать, пусть делает как хочет. Но поучать других, не зная самому и не умея объяснить, почему он сделал именно так, а не иначе - это уж... Вот это как раз и не следует делать. Именно поэтому наша промышленность такая убого-деревянная и отстала лет на 40. Потому что ошибки таких вот "разработчиков" накапливаются и не дают развития.
Насчет Корабельникова - ну это как раз вот как у господина Demiurg-а. Что-то можно взять, но только пропустив через фильтр правильного написания. Напрямую использовать - будет как и у Корабельникова, фигня и чушь, ошибки в самых базовых понятиях. Вот тут такие ошибки и есть - нет понимания "интерфейс модуля", нет понимания логики работы и логики связей и зависимостей.
Последний раз редактировалось MLX90640 Сб окт 08, 2022 21:52:51, всего редактировалось 1 раз.
1 - материал был не тебе. ТС-у. 2 - пересмотри внимательно мой пример. ВНИМАТЕЛЬНО. Задай себе один вопрос. Почему я написал именно так.
Если я написал так, значит был резон. Макросы для оптимизации выхлопа компиляции. Чтобы компилятор сделал одной командой. Я прибил гвоздями компилятор, чтобы он сделал так, как нужно мне, а не как посчитает нужным компилятор. sbic или sbis pinb, 0.
Макрос я завернул в функцию, для табличных методов. Пример я собрал из одного своего проекта.
Да нет, можно всё списать на "я художник, я так вижу". Но тогда не зачем других учить...
В данном поцарапсе я вижу не попытку "учить" , а скорее вопрос утверждения "своего видения" проектописания. И не более. Так что не стоит царапки в ход пускать.
Да никто и не царапается. Просто констатация фактов. Demiurg заявил, что щас он всех научит, как детей делать. Ну, сидим, смотрим. Дождались - а получается - что его метода детеделания - через опу. Во как. Но там же не вход, а выход.
Нет, ну конечно топикстартер волен делать так как хочет, никто его не заставляет. Благо, он сам еще не очень то может отделять зерна от плевел, то бишь общепринятую практику от ошибочных "уроков". Вот именно так и распространяются ошибки и заблуждения.
Ну и раз Demiurg не может ответить, то значит, он просто бездумно копирует раз за разом свои "детские" ошибки от малограмотных "учителей". Именно поэтому наша промышленность сейчас и ушла в каменный век. Отечественный CTX gamma 2000? Неее, кнопка "пуск/стоп" на ардуине - вот наше всё
Так, Demiurg снова не понял, о чем его спрашивают. Повторяю: Зачем #define check_in_1() написан в заголовочном файле proc_inputs.h (интерфейс модуля), если этот макрос используется ТОЛЬКО в файле proc_inputs.с (функционал модуля) в функции void scan_inputs (void) ? Согласно общепринятой практике и нормам языка Си (книга "Язык программирования Си" от авторов языка Си Ритчи и Кернигана), в интерфейс модуля не должно помещаться то, что используется лишь локально в самом модуле. Это и есть та самая модульность, про которую твердил ранее наш "учитель". Но, к сожалению, наш "учитель" сам не понимает того, чему хотел нас учить.
Нет, я серьезно. Учителя, как минимум, должны хотябы сами понимать то, чему они собрались учить остальных. А если учитель не понимает, что такое интерфейс модуля, то как же он собрался нас учить модульности написания? Это ведь ошибочное учение получается. Вот я против чего. Не надо учить ошибкам.
Последний раз редактировалось MLX90640 Сб окт 08, 2022 22:14:11, всего редактировалось 1 раз.
Это - ошибка. Плохая практика. Почитайте книжку "Язык программирования Си" от авторов этого языка Ритчи и Кернигана. Там они дают пояснения, как и для чего используются те или иные файлы. Не по принципу "лишнее", а по принципу той самой модульности, которой вы решили нас учить. Вобщем, сначала исправьте свои давние заблуждения, а потом уж принимайтесь поучать отстальных.
У каждого есть много действующих проектов. И вполне естественно использование собственных наработок из старых проектов в новых. Насчет "отставания" - стандартная детская болезнь "фанатизма" по отношению к новой элементной базе или к определенным типам сред разработки. Более рациональный подход - использование лучших приемов из разных, ХОРОШО ПРОРАБОТАННЫХ ранее материалов (включая элементную базу, компиляторы, среды разработки). Часто бывает еще не исчерпав ресурсов имеющегося лезем в изучение нового. Второе - расчет только на единственного и неповторимого производителя как деталюшек, так и софта разработки. Касательно "инклудов"... Честно говоря там не так все просто, как кажется... В вышевыложенном проекте " игрушки" как раз пара вариантов сложностей решалась в порядке изучения материала. В какрй-то мере удалось найти компромисс, правда совсем не "в академическом стиле".
MLX90640. Мне достаточно было увидеть твой алгоритм. Где ты пытаешься опросить кнопку, управлять выходами. Чтобы составить мнение о твоей несостоятельности. Не указывай, как мне делать свою работу. Говоришь о профессионализме, правилах. Лично я не вижу в тебе грамотного специалиста. Достаточно глянуть на твой алгоритм. На этом все. Разговор с тобой закончен. Хочешь что то сказать? Напиши и покажи свой пример. Ответь ТС-у на заданный вопрос.
естественно использование собственных наработок из старых проектов в новых.
Нет, для себя - пожалста, как хотите, хоть задом наперед и всё в одном файле, и со всеми "детскими" ошибками, никто вам ничего не скажет. Но вот когда вдруг один такой гражданин заявляет, что щас он нас всех тут учить будет, а сам выдает такие вот перлы, за которые еще 15 лет назад тапками били - ну это уж извините, ну как вот так то? Чисто для себя - делайте как хотите. Но распространять заблуждения под видом учения - не следует.
Вот как раз про использование ЛУЧШИХ приемов - это верно. Лучших, но не худших. Надо просто уметь учиться, а не зашориваться ошибочными шаблонами 15-летней давности этапа освоения.
Ты 5 страниц тут нафлудил. Показал никуда не годный пример и алгоритм. И сидишь, тычешь себя пяткой в грудь. Какой ты типа профессионал. Я не вижу в тебе профессионала. В упор не вижу. Поверь. Мне есть с чем сравнивать.
Ответь ТС-у на вопрос. Показывай свое видение вопроса или иди на хер.
Условия задачи. Опрос кнопок. Подавление дребезга. Управление выходами в соответствии с ТЗ тс-а.
Demiurg, если вы не умеете читать функциональные блок-схемы и графы переходов КА, то это ваша личная беда, а не моя. Свое видение вопроса я показал. Вам оно не понравилось, в силу того что вы просто не разбираетесь и ваше шаблонное мышление не переваривает иное. Но это ведь вы, Demiurg, решили всех тут научить, но выдали такой перл, что уши на лоб полезли. Вот конкретно к вам и вопросы все. На которые вы не можете ответить по причине того, что даже не понимаете, о чем спрашивают вас, как "учителя". Вот такой вот итог, господин "учитель". Как говорится, "не зная броду - не лезь в воду".
Повторяю. Ты нафлудил на 5 страниц. Показал отвратительный пример. Отвратительный алгоритм. Ты не справился с задачей. Поэтому все сказанное тобой не имеет никакого смысла. Даже твое умение чтения графов. Тебе самому не смешно себя читать? О каком профессионализме ты нам тут втираешь?
Задача простейшая. Элементарная. 3 кнопки, 3 выхода.
Так, ну давайте не переводить стрелки и не переваливать с больной головы на здоровую. Если вы не разобрались и у вас случился разрыв вашего шаблона, то это сугубо ваша проблема. У вас просто шаблонное зашоренное мышление. Рамочное. Рамки. Детские ошибки, не исправленные на начальном этапе. И всё, что не соответствует вашему рамочному шаблону, вызывает в вас столь эмоциональное отторжение, что вы даже перестаете понимать суть диалога и переходите на личности.
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 520
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения