Если ваш вопрос не влез ни в одну из вышеперечисленных тем, вам сюда.
Ответить

Re: Вопросы по С/С++ (СИ)

Чт апр 12, 2018 07:09:40

Мурик писал(а):Потому что если несколько задач выполняются друг за другом и
как говорится, дьявол кроется в деталях. в вашей фразе эта деталь - слово ЕСЛИ.

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

просто все эти ЕСЛИ чаще всего надуманные, а не реально существующие. как и бесконечная погоня за "экономией электроэнергии" - зачем МК спать, если он постоянно подключен к сетевому блоку питания, что норма минимум для 50% всех устройств?! это МОЖНО сделать, но отсюда не следует, что это НУЖНО делать. а попытка все-таки сделать порождает излишне "крутые" решения вроде протопотоков и ОС.

сколько сил многие тратят на асинхронный прием по USART команд и разбор их! решение с ОС потребует заметных расходов ОЗУ и FLASH, но это никого не смущает. а в то же самое время scanf и sscanf решили бы 90% проблем, но это "недопустимо", потому что scanf не отпускает цикл до разбора всех данных и отжирает 2К FLASH!!! где логика?! аналогично и с выводом.

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

Re: Вопросы по С/С++ (СИ)

Чт апр 12, 2018 08:07:42

И зачем ломать копья, если всё равно каждый пишет, как пишет?

Как пример, я делаю всё на конечных автоматах. Просто так научился и теперь получается писать именно так. Сложился определённый стереотип мышления.
Так вот, даже в простом проекте на STM8S003F3 с одним энкодером, дисплеем и уартом у меня шесть независтмых задач:
- обработка сигналов энкодера
- обработка длительности нажатия кнопки энкодера
- вывод информации на дисплей с кучей дополнительных режимов
- приём и передача по уарт физического уровня
- обработка протокола передачи логического уровня
- обработка действий пользователя
С ожиданиями у меня бы ничего не заработало. Прерывания применяются везде, где это оправдано.

Тогда о чём спорить? Как программист привык думать, так он и пишет программы.

Re: Вопросы по С/С++ (СИ)

Чт апр 12, 2018 15:00:11

[необходимость в распараллеливании процессов для очень большой части любительских проектов отсутствует в принципе

необходимость много в чем отсутствует. Можно, скажем, проекты не структурировать и даже на .h и .c файлы не делить. И писать в блокнотике, чоуштам.

деление на треды/задачи - просто один из подходов. Зачастую удобный для программиста. Вам он не нравится только потому, что надо еще в ОС вкурить?

Re: Вопросы по С/С++ (СИ)

Чт апр 12, 2018 15:09:28

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

Re: Вопросы по С/С++ (СИ)

Чт апр 12, 2018 15:33:01

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

Re: Вопросы по С/С++ (СИ)

Чт апр 12, 2018 15:44:07

Ivanoff-iv писал(а):...но неумеренное его применение ведёт...

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

Re: Вопросы по С/С++ (СИ)

Чт апр 12, 2018 15:57:34

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

Re: Вопросы по С/С++ (СИ)

Чт апр 12, 2018 16:05:17

Так вот про то и речь ув. коллега. ИМХО, нельзя однозначно утверждать безапелляционно что-то есть запрещенное зло .
Борются тут, понимаешь за каждый такт и бит ресурса, а сами все на ЯВУ, да библиотеки, кое-кто еще ООП пытается :) Неувязочка :)

Re: Вопросы по С/С++ (СИ)

Чт апр 12, 2018 16:27:27

когда с ЯВУ уходишь "вниз" там другие "звери" водятся :) врядли у меня лучше получится математику или ветвление с причудливым условием например развернуть чем у компилятора. да и если я выиграю по скорости выполнения кода, то уж точно проиграю в скорости его создания. :beer:

Re: Вопросы по С/С++ (СИ)

Чт апр 12, 2018 17:30:07

неумеренное его применение ведёт к снижению производительности

ну в вытесняющей ОС - не ведет) Хоть минуту пусть оно ждет в своей задаче, планировщик на это время не забудет про остальные.

Re: Вопросы по С/С++ (СИ)

Чт апр 12, 2018 18:49:00

да, но тогда и сам делай может растянуться на неопределенное время (считает он только пока выполняется)

Re: Вопросы по С/С++ (СИ)

Чт апр 12, 2018 19:00:06

делай может растянуться на неопределенное время (считает он только пока выполняется)

OS как правило предоставляют задачам свои собственные функции ожидания, входя в которые, задача отдаёт ресурсы МК на выполнение других задач. А для временно-критичных участков шедулер можно и остановить. И приоритет таких задач как правило ставится повыше.

Re: Вопросы по С/С++ (СИ)

Чт апр 12, 2018 20:34:38

arkhnchul писал(а):Вам он не нравится только потому, что надо еще в ОС вкурить?
у меня всегда один и тот же принцип в программировании: стоит ли игра свеч?
то есть если я анализирую задачу и прихожу к выводу, что задача решается "тупо" - я тупо её и решаю. если оказывается, что тупое решение не приемлемо - я применяю более "умное". и так далее.

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

до сих пор мне удавалось (или везло?) обходиться без выделения явных параллельных потоков (в том смысле, как это понимает ОСРВ или просто ОС) при разработке проектов на МК. при этом параллельно исполняющиеся задачи, разумеется, были, но делались они без лишних сущностей - прерывания и минимально необходимый автомат состояний. минимально необходимый - подчеркиваю.

попытки перевести мои проекты на OSA приводили меня к мысли, что игра свеч не стоит - т.е. сделать, конечно, можно, но затраты времени на переделку никак не окупаются для меня. вот я и не делал так.

например, мой последний проект - цифровая цветомузыка. не смотря на кажущуюся "многозадачность" (семплирование, FFT-анализ, обсчет алгоритмов "рисунка", вывод на светодиоды, обработка энкодера, вывод на ЖКИ в динамике и прием ИК-сигналов пульта) алгоритм у меня крайне ЛИНЕЙНЫЙ, и только прием ИК-сигналов сделан полностью в прерываниях. все остальные задачи выполняются последовательно, но дискретно, реализуя для себя простейший автомат состояния, как правило, состоящий из двух состояний: ожидание истечения счетчика и собственно выполнения полезной работы.

все в целом реализует принцип ОСРВ, т.е. гарантируется, что любая из задач обязательно получит управление снова ровно через 10 мс (если, конечно, не произойдут какие-то коллизии из-за ошибок программиста). и тем не менее никаких thread-ов, никакого шедулера и т.п. прибамбасов ОС у меня нет.

и неплохо все крутится. так зачем мудрить больше? :)

Re: Вопросы по С/С++ (СИ)

Пт апр 13, 2018 01:35:49

в винде многие вещи отлично делаются без использования многопоточности

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

ARV писал(а):попытки перевести мои проекты на OSA приводили меня к мысли, что игра свеч не стоит
неверная постановка задачи. Перевод "один в один" уже готовой работающей системы на что угодно отличное от нее имеет мало смысла.
Представьте себе другой вариант: вы уже хорошо знакомы с той же OSA и вам вдруг надо сочинить некую систему, логически вполне неплохо представляемую тредами. Так почему бы и нет?
ARV писал(а):все в целом реализует принцип ОСРВ, т.е. гарантируется, что любая из задач обязательно получит управление снова ровно через 10 мс (если, конечно, не произойдут какие-то коллизии из-за ошибок программиста). и тем не менее никаких thread-ов, никакого шедулера и т.п. прибамбасов ОС у меня нет.
если первая часть высказывания верна, то вторая - не верна) Сотни и тысячи плагламистов в своей практике приходят к реализации частных случаев ОС на автоматах, сами о том не ведая.

Re: Вопросы по С/С++ (СИ)

Пт апр 13, 2018 06:32:34

да, но тогда и сам делай может растянуться на неопределенное время (считает он только пока выполняется)


В ОСРВ такого не может быть. delay там совсем не тупым циклом сделан. Однако, задержка будет чуть больше той, что вы ожидали (максимум на две величины системного тика в той же QNX). Также такие ОС предоставляют средства для избегания инверсии приоритетов потоков.

у меня всегда один и тот же принцип в программировании: стоит ли игра свеч?


Это абсолютно разумно. :beer: В 90% задач она только вредит и добавляет головной боли. Вот надо было мне три устройства по CAN опрашивать. Я каждому поток подарил. Потом к этим устройствам ещё по одному в комплекте дали. Сначала как независимое - я и им каждому поток подарил. А потом возжелали связать эти устройства между собой и второе стало зависимо от первого. Появился отдельный поток управления на каждую пару устройств, задающий другим потокам, чем именно занимается устройство в данный момент (те потоки так и работали - им ставили задачу и они её решали). Потом захотели перехват и запись данных от этих же устройств, но когда опрос ведёт третье лицо. Мда. Поэтому в новом приборе с подобными устройствами я уже точно знал, что в данном случае потоков должно быть два - интерфейсный и управляющий. При этом в управляющем нужно делать всё тупо, как в MS-DOS. :) Получилось гораздо более гибкая схема.

Re: Вопросы по С/С++ (СИ)

Пт апр 13, 2018 07:02:18

arkhnchul писал(а):Строго говоря, ни одна вещь в оной винде не делается без многопоточности.
я вел речь не о строгом функционировании программы в винде, а о том, как видит свою программу программист. например, когда надо читать файл, то его в 90% случаев можно читать "тупо", т.е. открыл и давай в буфер качать до конца. и ничего не произойдет такого, что могло бы встревожить... пока не заняться файлами в гигабайты :) а тут окажется, что такой файл читается, мягко говоря, долго, и интерфейс оконный в этот момент тормозит. и приходится думать о вынесении чтения файла в отдельный поток. вот что я имел ввиду, когда говорил, что говорил.
arkhnchul писал(а):Представьте себе другой вариант: вы уже хорошо знакомы с той же OSA и вам вдруг
зачем мне это представлять? последние сообщения в этом топике крутятся вокруг неуёмного желания ЛЮБУЮ задачу подогнать под многопоточное исполнение, при этом знакомства с ОС у автора нет. т.е. многопоточность принимается за некую априори правильную сущность, и уходить от нее нельзя. когда нужда заставляет делить задачу на потоки - это нормально, когда потоки выуждают программиста дробить задачу - это уже странновато. и моё сообщение именно об этом. все-таки не инструмент должен определять решение задачи, а под решение задачи разумно выбрать подходящий инструмент. во всяком случае, мне так кажется.
arkhnchul писал(а):если первая часть высказывания верна, то вторая - не верна)
удивительно, но вы абсолютно правы, и при этом я тоже абсолютно прав :) как вы назовете вот такую программу, многопоточной или однопоточной:
Код:
int main(void){
   init_all();
   while(1){
      workjob_1();
      workjob_2();
      workjob_3();
      synchronize();
   }
}
? ;)
каждая workjob-функция по сути задача, synchronize обеспечивает ТУПУЮ задержку главного цикла, если от момента предыдущего вызова этой функции прошло менее 10 мс, т.е. эта функция подгоняет длительность итерации главного цикла до 10 мс.

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

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

я все время хочу как-то осмысленно применять ОС, и подгоняю постепенно решения своих задач под эту парадигму. но почему-то всегда получается, что мои старания убеждают меня в обратном - не применять ОС :)))

Re: Вопросы по С/С++ (СИ)

Сб апр 14, 2018 12:13:27

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

Re: Вопросы по С/С++ (СИ)

Сб апр 14, 2018 13:46:14

Это происходит из-за того что вы не подключаете заголовочный файлы (include), необходимые во вновь создаваемом файле.
Например, подключили в одном файле #include "test.h", а в следующем забыли или не стали, т.к. и так всё компилируется. Поменяли порядок компиляции файлов и получили ошибку компиляции. Нужно подключать все необходимые для данного файла другие заголовочные файлы. Если файлы используются во всех файлах (например stdint.h), то можно их прописать в файле main.c (компиляция, как правило начинается с него), либо создать отдельный файл с необходимыми #include и подключать его во всех файлах. Только необходимо, чтобы данный заголовочный файл обрабатывался один раз:
#ifndef TEST_H
#define TEST_H

Re: Вопросы по С/С++ (СИ)

Сб апр 14, 2018 14:19:23

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

Изучать выхлоп препроцессора.
Кстати, в С/С++ под библиотеками понимаются уже скомпилированные модули и порядок их подключения задаётся скриптом компоновщика и влияет разве что в том паталогическом случае, когда в разных библиотеках определён одноимённый объект - будет использоваться первый найденный. Т.е. в вашем случае правильнее было сказать "порядок подключения заголовочных файлов", насколько я понял из последующей фразы.
В этот раз потратил несколько часов пока дошел до того, что изменив порядок подключения инклудов программа начала нормально компилироваться.

С-модуль здорового человека первой директивой #include должен подключать свой собственный .h-файл. Это минимизирует зависимость от контекста включения последнего в других модулях проекта.

Добавлено after 18 minutes 42 seconds:
Если файлы используются во всех файлах (например stdint.h), то можно их прописать в файле main.c (компиляция, как правило начинается с него)

Не поможет - всё включённое в main.c будет видно только при компиляции main.c и не видно при компиляции других модулей. Вариант с выделением стандартных заголовков в отдельный .h-файл имеет право на жизнь, более того рекомендуется если компилятор поддерживает т.н. precompiled headers, но для небольших проектов прямое включение в модуле стандартных заголовков позволяет иметь их всегда на виду и корректировать по мере необходимости. Например, заменив при доработке весь printf вывод в отдельном модуле на другие процедуры - идём вверх и сносим #include <stdio.h> нимало не заботясь как на это отреагируют другие модули проекта. Поскольку тенденция такова, что каждый разработчик со временем обрастает набором drop-in модулей для типовых решений, минимизация зависимости таких модулей от чего-то ещё кроме стандартной библиотеки - поможет экономить время.

Re: Вопросы по С/С++ (СИ)

Сб апр 14, 2018 15:40:33

то можно их прописать в файле main.c (компиляция, как правило начинается с него)

Погорячился немного.
Также проверил, IAR компилирует файлы, в алфавитном порядке, причём последовательность скомпилированных файлов, раз от раза, может меняться (видимо многопоточность :) )
Ответить