Для написания программ подходит любой из вариантов. Но в большинстве случаев предпочитаем использовать собственные и/или чужие-доработанные под свое понимание программные модули (библиотеки или еще как их можно называть)... При повторном использовании только копируем с небольшой доработкой. То же самое касается и схемотехнических решений. Тем более сегодня - когда сложность начинки микросхем и сопровождающего программного обеспечения кратно нарастает с каждым годом (а то и чаще).
Речь идёт о простой Ардуино. Ардуино не меняется уже много лет...
Аналогично с простым радио модулем.
На самом деле возможностей радио модуля как правило больше... Но на практике ими никто не пользуется. Тогда зачем писать целую библиотеку если можно написать несколько простых функций... Скопировать в любой проект и пользоваться себе на здоровье)).
Итого:
NRF_init(250, 4, 2400); // скорость 250, мощность 4, частота 2400 мгц. NRF_on(1); //1- on, 0 - off. NRF_TX(String); // передача данных (текста). NRF_RX(String); // приём данных (текста).
Все)) Этих функций достаточно для простых поделок на Ардуино. Термометры... Тахометры... Вольтметры... и т.д.
А кому мало могут дописать дополнительные функции. Но как правило никому не надо.
И вот мы уже передаём/принимаем данные и выводим на экран))
lcd_init(127); // яркость экрана - 0...255. lcd_on(1); // 1- on, 0 - off. NRF_init(250, 4, 2400); // скорость 250, мощность 4, частота 2400 мгц. NRF_on(1); // 1- on, 0 - off.
NRF_RX(String); // приём данных (текста). lcd_data(String); // вывод данных (текста) на экран.
Все)) библиотеки не нужны.
При этом читаемость кода не страдает. Так как все функции тупо копируются в начало кода программы (вместо библиотек). Их можно не читать. Никто не заставляет)) И там же объявляются все переменные. Или не объявляются)) Переменные могут быть локальные внутри функций.
Не понятно в чём вклад разработчика в оптимизацию. Если какие-либо функции библиотеки не используются (не вызываются), компилятор сам их просто не включит в загрузочный файл. Зато достаточно будет добавить в проект один файл библиотеки, может ещё соответствующий файл заголовков и всё.
как же всё предсказуемо... уже наперёд знаешь кто что ответит... даже скучно... ладно... пойду дальше заниматься "ламерством")) p.s. настоящие профи пишут на уровне процессоров... но это уже следующий уровень))
Просто потребность в многофайловых проектах возникает по мере роста их объёма. Да и вносить корректировки/редактировать под что-либо друго из набора уже выполненных и проверенных решений заметно проще. Та же котуинка со сменными аппаратными модулями и их программным обеспечением как пример. Но там вроде ж не Си а ассемблер и МК на базе AT89S52... Ну тогда посмотрим чего получиться в исходнике тех же просточасиков (проект К145/К145М), ежли его одним файлом оформить... Да и, к примеру, просто поменять управление и индикацию с той К145
там вроде просто "многофайловики"... Да и насчет "просто атмега328"... Относительно "простенькой" разве что про аттини13 аттини 2313, АТ89С2051 да PIC10F200 так сказать можно ...и то ... смотря как их использовать.
об этом я и говорю... чтоб посмотреть весь проект... надо открывать все файлы... отдельно. а это всего то простенькие часики))
Ну тогда посмотрим чего получится в исходнике тех же просто пультиков, ежли его одним файлом оформить... Спойлер Спойлер всё одним файлом... открыл и сразу видно весь проект. потребность в многофайловых проектах по мере роста их объёма не возникает. возникает потребность в дополнительных МК... потому что один МК уже не справляется)) и вот тут уже возникает потребность в многофайловых проектах... потому что для каждого МК надо писать отдельный файл...
Можно и так - делаются дополнительные спецкристаллы обработчиков на отдельных "универсальных кирпичиках". Обычная история. К примеру те же прикладные программаторы в котуинке... Только вот зачем такие картинки рисовать, когда и обыкновенных схемных обозначений достаточно? Напоминает старые схемы к автоэлектрике - сплошные рисунки с весьма сложным восприятием сути простейших решений. Лучше уж стандартную блок-схему начертить для общего восприятия. У Вас каждый модуль комплекта - готовое изделие при центральном модуле обработчика данных, выполняющего всего лишь одну функцию обработки В моих "часиках" иной вариант - единый аппаратный модуль с несколькими вариантами программной реализации разных по функциям устройств (каждое со своей программой обслуживания). Приоткрыл Ваши исходники... от 1000 до 5000 строк кода одним файлом... Я думал только мои проекты ЖУТЬ, оказалось я не одинок... Помимо прочего... не все компиляторы допускают "безгранично растущие" размеры исходников (к примеру те же "ранние ассемблеры"). Да и выискивать нужный участок текстовки проще с двумя отдельно открытыми окнами редактора (еще приятнее на двух мониторах).
Так и я пока котуинку забросил... Хорошо хоть архивы вроде не растерял со всеми заменами компов... Там только базовый блок да три программатора в железе и программах выполнены (ассемблер mcs51). Леньки однако, да "местные особенности"...
А на кой такой дурдом то? Для простейших бытовых устройств или того же расширителя СОМ порта компа? Не хош влияния ИИ - не подключайся к интернету, не используй мобильную связь. Обычных проводков что ли мало? Остальное (ежли не радиоканал) от помех весьма мало зависит. Относительно "искрового разряда в шины питания" - так то же пройденный этап. Не вижу в том смысла кухонный таймер от РЭБа защищать.
во первых в моём компе нет СОМ порта... только виртуальный для прогера)) во вторых речь про устройство на видео...
устройство на видео... предназначено для перевозки грузов... гражданских грузов в мирное время и военных грузов в военное время.
с учётом сложившейся обстановки... программу устройства надо переписать... под новые требования)) кухонный таймер от РЭБа защищать не надо.)) кухонный таймер работает по проводам. поэтому антиспуфинг... ППРЧ... отпадает... а шифрование остаётся... потому что кухонный таймер подключен к интернету.
Котуинке как раз все равно какой тип СОМ порта - аппаратный или виртуальный (USB-COM переходник). Насчет тырнета для простого таймера на кухню - это уже из разряда избыточного дурнодома... Правда кому что удобнее - или простота применения или "только при работе через глобальные (интернет) сети". В то же время наиболее удачным вариантом является конструкция, которая при полностью автономной работе имеет еще и опционно дополнительный сервисный модуль связи с удаленным контрольным пультом (который всегда можно и исключить). Варианты интернет (сетевых) приложений частично снимают вопросы интерактива с оператором ("лампочки/кнопочки"). Но то уж за собой и минусы потянет - "несанкционированный доступ" (соответственно необходимость кодирования/шифрования и прочее к функционированию самой конструкции напрямую отношения не имеющее, а вот на затраты средств и времени избыточно кусючее). Выбор конечно за автором конструкции (ежли заказчик своего требования не выставит - а в качестве заказчика частенько домашнее окружение выступает ).
сейчас у меня простейшие бытовые устройства работают так... Спойлер и опять же...
всё одним файлом... открыл и сразу видно весь проект. и вот тут уже возникает потребность в многофайловых проектах... потому что для каждого МК надо писать отдельный файл...
BOB51 писал(а):
(соответственно необходимость кодирования/шифрования и прочее к функционированию самой конструкции напрямую отношения не имеющее, а вот на затраты средств и времени избыточно кусючее).
вовсе нет. всё уже написано. осталось только скопировать кусок кода в свой проект. а вот собственно кусок кода отвечающего за шифрование... Спойлер
x_raund = 0; InvShiftRows(); InvSubBytes(); AddRoundKey(); }; //////////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////gamma TX: unsigned char TX_gamma_st = 0; //счёт gamma TX //////////////////////////////////////////////////////////////////шифрование TX: void AES_TX(void) { //выбор ключей: //b_Key_N_ = 0,1 -Буфер Номер Key if (b_Key_N_ != Key_N_){ /////////////////////////////////// b_Key_N_ != Key_N_ : //////////////////////////Key_N == 0 if (Key_N_ == 0){ Key_0_Key(); // Key_0 > KeySchedule }; //////////////////////////Key_N == 1 if (Key_N_ == 1){ Key_1_Key(); //Key_1 > KeySchedule }; ////////////////////////////////// Key_N_ > b_Key_N_ b_Key_N_ = Key_N_; }; /////////////////////////////////////////////////////// //////////////////////////////////vektor: //TX_int[0] = ID_Source; //TX_int[1]...TX_int[15] = vektor[1]...vektor[15]; /////////////////////////////////////////////////////// //vektor > state for (xAES=0; xAES<16; xAES++) { state[xAES] = TX_int[xAES]; // TX_int > state }; //Блок простой замены: encrypt(); // encrypt //vektor > TX_int for (xAES=0; xAES<16; xAES++) { TX_int[xAES] = state[xAES]; // state > TX_int }; /////////////////////////////////////////////////////// for (TX_gamma_st = 16; TX_gamma_st < TX_len; TX_gamma_st = TX_gamma_st + 16) { /////////////////////////////////////////////////////// //Блок гаммы: ///////////////////////////////////////////////////////TX: vektor > state: //////////////////////////Key_N == 0 if (Key_N_ == 0){ /////////////////////////RX: флаг error_vektor: //vektor_TX_0 ++ vektor_0(); // счёт vektor_0 //vektor > state for (xAES=0; xAES<16; xAES++) { state[xAES] = K_int[xAES]; // vektor_0 > state }; }; //////////////////////////Key_N == 1 if (Key_N_ == 1){ /////////////////////////RX: флаг error_vektor: //vektor_TX_1 ++ vektor_1(); // счёт vektor_1 //vektor > state for (xAES=0; xAES<16; xAES++) { state[xAES] = K_int[xAES+48]; // vektor_1 > state }; }; /////////////////////////////////////////////////////// //Блок простой замены: encrypt(); // encrypt //цикл шифрования: for (xAES=0; xAES<16; xAES++) { TX_int[xAES+TX_gamma_st] ^= state[xAES]; // state ^ TX_int }; };//TX_gamma_st + 16 /////////////////////////////////////////////////////// };//AES_TX //////////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////gamma RX: unsigned char RX_gamma_st = 0; //счёт gamma RX //////////////////////////////////////////////////////////////////////vektor_RX: unsigned char vektor_RX[] = {0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0}; //16 байт ///////////////////////////////////////////////////////////////расшифрование RX: void AES_RX(void) { /////////////////////////////////////////////////////// //////////////////////////////////vektor: //TX_int[0] = ID_Source; //TX_int[1]...TX_int[15] = vektor[1]...vektor[15]; /////////////////////////////////////////////////////// //Входной блок > state for (xAES=0; xAES<16; xAES++) { state[xAES] = TX_int[xAES]; // TX_int > state }; //Блок простой замены: decrypt(); // decrypt //vektor > vektor_RX for (xAES=0; xAES<16; xAES++) { vektor_RX[xAES] = state[xAES]; // state > vektor_RX }; //vektor > RX_int for (xAES=0; xAES<16; xAES++) { TX_int[xAES] = vektor_RX[xAES]; // vektor_RX > TX_int }; /////////////////////////////////////////////////////// for (RX_gamma_st = 16; RX_gamma_st < RX_len; RX_gamma_st = RX_gamma_st + 16) { /////////////////////////////////////////////////////// //Блок гаммы: //////////////////////////////////////////////////////// //vektor_RX ++ for (xAES=15; xAES>7; xAES--) { if (vektor_RX[xAES] == 0xFF) {vektor_RX[xAES]=0;} else {vektor_RX[xAES]++; xAES=1;}; }; //vektor_RX > state for (xAES=0; xAES<16; xAES++) { state[xAES] = vektor_RX[xAES]; // vektor_RX > state }; //////////////////////////////////////////////////////// //Блок простой замены: encrypt(); // encrypt //цикл расшифрования: for (xAES=0; xAES<16; xAES++) { TX_int[xAES+RX_gamma_st] ^= state[xAES]; // TX_int ^ state }; }; }; ////////////////////////////////////////////////////////////////////////////////
как видим ничего сложного нет. обычный AES256. и затраты... и времени... совсем небольшие)) из плюсов: -отпадает необходимость в блоке точного времени. т.к. время синхронизируется по компьютеру. -отпадает необходимость постоянно бегать на кухню и смотреть показания кухонного таймера. т.к. время кухонного таймера можно посмотреть в компьютере. -отпадает необходимость вручную устанавливать время кухонного таймера. т.к. время кухонного таймера можно установить в компьютере. -отпадает необходимость в блоке питания кухонного таймера. т.к. питание кухонный таймер получает по проводам. -если таймер находится на кухне а мы в комнате... то мы можем не услышать звук кухонного таймера. в этом случае кухонный таймер отправляет пакет на сервер который находится в комнате и в котором установлен бузер. так мы гарантированно услышим кухонный таймер. -и т.д.
короче... одни плюсы))
из минусов: -надо тянуть провода по всему дому. но это не очень большая плата за удобства.))
У каждого свои предпочтения. Однако городить полноценную внутри домовую/внутриквартирную сеть ради пары простых приборчиков для домашнего хозяйства это не слишком оправдано. Но и не исключается, если такая сеть уже ранее сделана и самоделка является дополнением к уже ранее созданному. Я ж сетевыми вариантами не занимаюсь - разве что небольшие проекты с вынесенными датчиками и/или функциональными блоками. Касательно "единого массива текста" - все же значительно более удобен вариант из нескольких файлов. Редактирование "выкусь - копировать - вставить" или вставка целым блоком "библиотеки" похожи, но не совсем одно и то же.
многие говорят что это всё просто игрушки... а я говорю что это на самом деле реально удобно. удобно когда лёжа на диване можно управлять всеми бытовыми приборами в доме. Спойлер и для этого не требуется больших затрат. достаточно несколько МК. Касательно "единого массива текста" - все же значительно более удобен вариант из одного файла. Удобно когда всё под рукой. В отличии от бибилиотек (которые написаны отдельный файлом) в одном файле проще и быстрей что-то отредактировать. Достаточно просто переместиться в начало файла и внести изменения. Чем просматривать каждую отдельную библиотеку. мы же говорим о простеньких МК и простеньких программках для простеньких МК... а не о сложных многоядерных процессорах с кучей машинных инструкций... для простеньких МК проще, быстрей и удобней писать всё одним файлом.
У каждого свои предпочтения. Однако система выноса в отдельный файл текста обработчика алгоритма и/или аппаратного модуля достаточно удобна. Помимо прочего такой подход приучает выделять задачу, а не размешивать по всей программе в разных местах (если таковое не вынужденная мера).
roman.com, если кто-то захочет продолжить ваш файл с конструкцией позже во времени, даже вы через год-два например, несмотря на столько комментариев, будет сложно, почти невозможно.
Вы написали код для себя, и вряд ли кто-то попытается понять, что код делает. Вряд ли кто-то позаимствует у вас кусок кода. Предпочтут написать прогр, коду самостоятельно, напр. используя если есть алгоритм и описание. (Напр. если вижу в C-файлы goto..., их сразу закрываю . Личное мнение).
Многое зависит и от сложности как самой основной программы, так и ее составлящих. То же обслуживание интерактива может быть как простейшим, так и весьма навороченным, обработчики вывода на дисплей также различны. что касается коммуникационных модулей - то их порой вообще в разных участках программы можно встретить. Постепенно от подпрограммы (функции) и до отдельного файла (или класса) переход будет происходить. Всему свое время. А вот насчет "вспомнить прошлый код"... Это таки весьма жутковатая история/перспектива... Особо ежли больше года прошло да распечаток с хорошим описанием нету... Зато пару раз вспомнил и отметил забытое описание понятнее сделаешшш!
Последний раз редактировалось BOB51 Пт окт 10, 2025 16:02:15, всего редактировалось 1 раз.
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 14
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения
Вход
Регистрация
Правила
FAQ
Поиск
. Личное мнение).
