Ищу учебник по (системному) программированию

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

Сообщение **stesl** » 30 янв 2021, 10:25

Меня, во время учебы, спасала Побегайло А.В. "Системное программирование в Windows". В свободном доступе не нашел, покупал в Google
Рулил потоками в Free Pascal )))

Системное программирование, наверное, не совсем корректная формулировка того, что ищется. Системное программирование - это программирование на уровне операционной системы.

Я бы посоветовал привязаться к языку javascript или на крайняк к python. Это два довольно современных кроссплатформенных языка, где есть многое, чего нет в с++. С javascript в нагрузку еще два друга - html и css - лучше прокачать.

А так, думаю, в с++ вы много интересного тоже найдете.

Хотя, если честно, непонятно, что хочется изучить. Указатели и ссылки (абсолютная и символьная адресация) известны? Сильная/слабая типизация? Глобальные и локальные переменные? Структуры? Объекты/классы?

Михайло писал(а): ↑30 янв 2021, 11:21 Хотя, если честно, непонятно, что хочется изучить. Указатели и ссылки (абсолютная и символьная адресация) известны? Сильная/слабая типизация? Глобальные и локальные переменные? Структуры? Объекты/классы?

Структуры-объекты-классы известны давно. Хочется даже не изучить, а увязать теорию с кодом. Вот довелось столкнуться с cc2530 от texas и известным stm32. И заметил, что как работает код из примеров - вроде понятно, если под рукой талмуд по api есть, а вот терминология, которая в документации и на форумах используется - уже не совсем. Ну точнее, на уровне портов, памяти и помигать светодиодом вопросов нет (хотя на stm для этого куча способов и библиотек и все разные) а вот когда приходится иметь несколько задач в параллель, да ещё прерывания ловить - приходится лезть в теорию.
А для начала надо разобраться где вообще сейчас проходит граница между системным и прикладным программированием. В случае с микроконтроллерами с огрызками ОС она кажется весьма условной. С никсами вроде понятнее, но тем не менее тоже пока четкого представления нет.

Я смотрю, вы уклоняетесь в сторону многопоточного программирования, при чем на stm32.

По многопоточности я смотрел видеолекции Евгения Калишенко. Не сказать, что идеальный лектор, но он компетентен в вопросе и наиболее системно преподает. Надо только понять такую вещь: иногда кажется, что ты написал потокобезопасный код, но на самом деле это скорее всего не так. И запуск кода не всегда обнаруживает нарушение потокобезопасности (по случайному обстоятельству не нарушается). Но и он не теоретик, а практик. Типа "вот вам набор инструментов, используйте".

Stm32 на столе лежит, а изучать удобнее то что есть.
Просто при ковырянии с stm столкнулся с тем, что в мир микроконтроллеров пришли технологии и приемы программирования из "взрослых" операционок. А тут пробел в знаниях, нас немного другому учили.

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

Сообщение **Sergey_P** » 30 янв 2021, 15:07

Когда я работал с Windows API еще не было замечательного сайта StackOverflow и мне очень помогала вот эта книжка:
Джонсон Харт "Системное программирование в среде Microsoft Windows"
http://www.williamspublishing.com/Books ... 879-5.html

Сейчас я бы не стал разрабатывать приложение на уровне WinAPI. Десктопные приложения под Windows вроде-как сейчас модно писать на C#. Для своих задач я выбрал Java и не могу нарадоваться.

В прошлом году я начал плотно заниматься программированием STM32. Среда STM2CudeIDE + CubeMX - замечательный инструмент. Всю информацию по всем вопросам нахожу в Гугле (лучше искать на английском). Я принципиально отказался от RTOS и тоже рад этому решению. Работа с UART, USB и Ethernet не вызвала никаких проблем.
По моему опыту могу однозначно посоветовать одно: операционную систему и многопоточность в микроконтроллере лучше применять только если четко понятно - зачем это вам надо. Иначе больше времени потратите на борьбу с библиотеками и системой. Например, та-же LWIP отлично работает без RTOS и, как по мне - гораздо проще работать с ней на "низком уровне".

Sergey_P писал(а): ↑30 янв 2021, 15:07 операционную систему и многопоточность в микроконтроллере лучше применять только если четко понятно - зачем это вам надо

Ноги растут не из STM, а из CC2530. Кристалл вроде простой, на ядре 8051. Но работать с протоколом Zigbee, радиоканалом и шифрованием не используя поставляемый API - это будет работа ради работы, результат в далекой перспективе. А в родном Z-Stack от TexasInstruments HAL и OSAL так перекручены, что хрен разберешь, да и от операционки там в общем-то только менеджер задач.
Насчет StackOverflow и гугла - так собственно и ищу умную книгу, дабы общаться на одном языке... А то получается как у Ильфа и Петрова - "На третьем ходу выяснилось, что гроссмейстер играет восемнадцать испанских партий. В остальных двенадцати черные применили хотя и устаревшую, но довольно верную защиту Филидора. Если б Остап узнал, что он играет такие мудреные партии и сталкивается с такой испытанной защитой, он крайне бы удивился."
Десктопными под Win давно не увлекаюсь, да и не в моде они сейчас, все на веб переходят). Но вот Raspberry под спецдистрибутивом Debian иногда требует ручного программирования, и питона уже не всегда хватает. И опять же почти всегда задачи сводятся к процессам, взаимодействующим с чужими API.
За совет спасибо, книгу посмотрю.

Сообщение **Sergey_P** » 30 янв 2021, 23:18

Никита писал(а): ↑30 янв 2021, 16:22 работать с протоколом Zigbee, радиоканалом и шифрованием не используя поставляемый API - это будет работа ради работы

Я как раз и не предлагаю делать все "с нуля" и руками. Считаю, что HAL от разработчика процессора и те библиотеки, которые он включает в свою среду разработки - это то, что нужно по максимуму использовать.
Просто не нужно подниматься на слишком высокий уровень абстракции.
Я не работал с другими процессорами, кроме STM32, поэтому в качестве примера приведу работу с TCP/IP через библиотеку LWIP. Она включена в дистрибутив STM32CubeIDE и может работать как под RTOS, так и на "голом железе". Программисту, который привык работать с сокетами в Windows или Linux, будет проще реализовать все под RTOS, т.к. там эти-же сокеты. Однако, потратив совсем немного усилий, можно сделать все то-же при помощи низкоуровневых функций. Объем исходного кода, который придется написать, кстати, не намного больше. Но в этом случае в программе будет гораздо меньше мест, где могут возникнуть ошибки.
В общем, нормальный HAL упрощает работу с железом, а все последующие надстройки над ним - обычно усложняют.
Но если уж разработчик процессора не дает возможности легко обойтись без ОС, то тут вариантов нет - придется изучать.

По поводу абстракций есть хорошая (хоть и старая) "философская" статья:
https://habr.com/ru/company/selectel/blog/512796/

В данном конкретном случае все не так просто.
Zigbee представляет из себя Mesh-сеть и устройство, кроме моих прикладных задач, обязано регистрироватся в сети, обмениваться ключами, слать маяки, а в случае стационарного питания - еще и выполнять функции роутера - оценивать стоимость маршрутов, пересылать чужой трафик, подключать новые endpointы и т.д.
Смысл как раз в том, чтобы взять готовые шаблоны от изготовителя для решения этих задач. А там, увы, возможность только прицепить свои прикладные функции в менеджер. Так что на уровне HAL не получится.

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

Сообщение **stesl** » 31 янв 2021, 09:30

Михайло писал(а): ↑30 янв 2021, 11:21 Системное программирование, наверное, не совсем корректная формулировка

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

Михайло писал(а): ↑31 янв 2021, 06:55 Многопоточные заморочки типа семафоров, мьютексов, очередей требуются только в том случае, когда у вас два или более потоков выполняются параллельно и могут читать и изменять общие ячейки памяти.

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

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

Михайло писал(а): ↑01 фев 2021, 07:17 У каждого ядра своя копия регистров, скорее всего, и стек тоже. То есть с точки зрения программиста каждый поток - это обычная однопоточная программа, иначе был бы кошмар.

И опять возвращаемcя к вопросу о практической реализации межпоточного и межпроцессного взаимодействия :)
Причем, в случае с микроконтроллерами все еше интереснее, пока непонятно где разница между процессом и потоком)

Сообщение **Sergey_P** » 01 фев 2021, 12:05

Никита писал(а): ↑01 фев 2021, 09:16 И опять возвращаемcя к вопросу о практической реализации межпоточного и межпроцессного взаимодействия :)
Причем, в случае с микроконтроллерами все еше интереснее, пока непонятно где разница между процессом и потоком)

Насколько я понимаю, терминология и подходы могут слегка отличаться в зависимости от системы. Например, в книге Харта (я давал ссылку выше) сравнивается, как это сделано в Windows и Linux/Unix. Критическая секция, мьютекс, семафор - это вроде как стандартные понятия, но последнее слово - за компилятором и API.

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

Вот, кстати, нагуглил статью по поводу терминологии:
https://www.feabhas.com/sites/default/f ... cesses.pdf

Сообщение **Jackson** » 01 фев 2021, 14:08

Никита писал(а): ↑30 янв 2021, 14:16 Видеоколлекции не очень люблю.

Никита писал(а): ↑29 янв 2021, 20:13 появилось время (по дороге на работу и обратно)

И личный водитель? :)

Jackson писал(а): ↑01 фев 2021, 14:08 И личный водитель? :)

Служебный автобус. Ибо гонять каждый день по 40 км на стройплощадку и столько же обратно на своей машине невыгодно.
А автобус, надо отдать должное работодателю, достаточно комфортный чтобы книгу почитать или просто отоспаться).
Бонус - забирает недалеко от дома, т.е. руль крутить по городу тоже не надо, это еще плюсом минимум полчаса свободного времени в том же автобусе.
А видео - планшета у меня нет, ноутбук таскать только ради этого лень, а на телефоне мелко. Читалка на e-ink в этом плане компромисс, правда упоминал уже - для технической литературы не всегда пригодна.

Отправлено спустя 11 минут 57 секунд:

Sergey_P писал(а): ↑01 фев 2021, 12:05 поэтому там каждый производитель делает по-своему

И не только делает, но и описывает. И разработчики, один из которых пишет на C++ под API ОС, а другой - на ассемблере под железо микроконтроллера, естественно будут пользоваться той терминологией, которая привычна им. А если еще сам не понимаешь толком о чем речь - разобраться с этой путаницей та еще задача.

Сообщение **stesl** » 03 фев 2021, 02:24

Никита писал(а): ↑01 фев 2021, 16:31 А если еще сам не понимаешь толком о чем речь - разобраться с этой путаницей та еще задача.

Вполне привычная для АСУшника ) Возьмите его, полжизни работавшего с Овном и киньте на амбразуру Сименса ) Всё у Вас, Никита, получится. Вопросы, а соответственно размышления в голове - уже обладают нужным набором терминов. А сленг дело такое - с опытом придёт.

Сообщение **Andreywys** » 03 фев 2021, 10:37

Я бы сам почитал что-нибудь по многопоточному программированию. Иногда требуется, например, для отправки http запроса, но дальше async await не лезу.

Михайло писал(а): ↑30 янв 2021, 11:21 Я бы посоветовал привязаться к языку javascript или на крайняк к python. Это два довольно современных кроссплатформенных языка, где есть многое, чего нет в с++. С javascript в нагрузку еще два друга - html и css - лучше прокачать.

Для windows, имхо, с# + visual studio + msdn - идеальный вариант. А для embedded - плюсы и среда разработки (IAR, KEIL и т.п.).

stesl писал(а): ↑03 фев 2021, 02:24 Возьмите его, полжизни работавшего с Овном и киньте на амбразуру Сименса

Ну если полжизни - то соглашусь. Хотя если моей - то у Овеновцев ПЛК еще не было, были ТРМ и подобные железяки. Но работать довелось и с Codesys и со step7 и немного с TIAPortal. Тяжело при разадресовке незнакомого железа, а дальше - МЭК он и есть мэк, а справочник по библиотечным блоками все равно под рукой держать приходится.

stesl писал(а): ↑03 фев 2021, 02:24 Всё у Вас, Никита, получится

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

Andreywys писал(а): ↑03 фев 2021, 10:37 Для windows, имхо, с# + visual studio + msdn - идеальный вариант. А для embedded - плюсы и среда разработки (IAR, KEIL и т.п.).

Windows как раз не особо интересен. Линух + MK. Плюсы (даже еще просто TurboC, плюсы пришли позже) изучать начинал четверть века назад, тут проблемы нет.
Проблема не с языком, а с тем, что на нем написано)

Сообщение **kirik** » 06 фев 2021, 18:34

Мануал к ОСРВ SCM RTOS http://scmrtos.sourceforge.net/files/do ... _v4.ru.pdf

Сообщение **Степа** » 17 фев 2021, 23:06

Учебники:
Дж. Харт, Системное программирование в среде Windows
М. Руссинович и Д. Соломон, Внутреннее устройство Windows /эта есть и в формате FB2, в общем-то в неплохом качестве/
Попадалась еще более общая, с примерами из мира Unix /как бы не Эндрю Таненбаума/ - принципы одни и те же. Написание команд разве что иное...

Никита писал(а): ↑31 янв 2021, 19:51 как накладывается эта многопоточность на архитектуру процессора,как происходит переклчение межу потоками, что при этом в каких регистрах и в стеке

Вкратце: многопоточность бывает кооперативной и вытесняющей. В первом случае поток отрабатывает цикл и отдает управление операционке. Реализуется легко и непринужденно, на чем угодно и под чем угодно. Хоть на ПЛК /вот прямо сегодня смотрел проект с кооперативной многозадачностью на S7-300/.
Во втором - операционка сама определяет длительность кванта времени и по истечении его /или по желанию потока/ передает управление следующему потоку. В этом случае работа строится примерно так: по таймеру происходит прерывание, обработчик сгружает содержимое всех регистров процессора и сопроцессора в память, выделенную для хранения контекста потока, определяет следующий поток и загружает его контекст в регистры, выходит из прерывания. Не на каждом процессоре такое реализуемо. И не то, чтобы легко и непринужденно.
Стек - на обычных процессорах это область обычного ОЗУ, на которую ссылается пара SS:ESP. На микроконтроллерах - тут смотреть надо. Какие сам полапать успел - там жестко заданный стек, никак не изменяемый.
При кооперативной многозадачности всякие семафоры-мьютексы и ты ды нужны примерно так же, как рыбе сапоги. Потому как что бы поток ни делал, он отдаст управление тогда и только тогда, когда сам посчитает нужным. При вытесняющей - без средств синхронизации любая попытка обменяться данными между потоками чревата случайными ошибками. Вообще любая. Особенно, если процессор многоядерный - т.е. потоки реально могут работать параллельно. Хотя и одноядерность не гарантирует от таких ошибок. Работаю с мьютексами и критическими секциями. Разницы: если мьютекс не создан - можно не продолжать попытки, обойти критическое место и поделать что-то еще; вход в критическую секцию остановит поток, если секция занята.
Скажем, задачу об обедающих философах надо решать с помощью мьютексов: если левая или правая вилка заняты - философ бросает уже захваченную вилку и начинает цикл размышлений, по окончании которого опять попробует взять вилки /которые вполне уже могли освободиться, полежать и снова быть захвачены оголодавшим соседом/. С критическими секциями если одна из вилок занята, философ впадет в ступор до освобождения вилки, но схватит ее как только она освободится.
Кстати, это и есть пример кооперативной многозадачности: философ схватил вилки и кушает, пока душа просит.
Процесс - грубо говоря, описание программы. Поток - то, что исполняется на процессоре. В любой программе один и только один процесс, потоков может быть не менее одного.

Вот как-то так в общих чертах, без деталей и подробностей...