Forger

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

Можно хоть 100 и больше, тут все зависит от типа драйверов скорости, топологии (терминаторы не на всех "концах"), длины проводов и т. п. В реальности системы массой датчиков всегда имеют сильно развитую топологию со своими маршрутизаторами, повторителями, преобразователями. Только абсолютному чайнику придет в голову соединять сотню датчиков одной шиной и уже тем более разнесенных на десятки и сотни метров. Поэтому реальные работоспособные шины RS-485 и подобные содержат в себе от силы пару десятков узлов. Может быть, где-то и существуют функционирующие шины на гораздо большее число узлов, объединенных одной физической шиной, но они наверняка работают лишь благодаря принципу "не пердеть и не дышать". А как что тронешь, все валится разом со всеми вытекающими... Одно дело придумать велосипед, другое дело его собрать, а уж третье - сопровождать и обслуживать. Так вот про третье дело горе-разработчики зачастую просто не знают или упорно игнорируют по принципу "и так сойдет".

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

Отечественные МК - самый передовые: аппаратный USART им ни к чему, поскольку способны легко держать программный USART на сотни К/М/Г бит в сек и даже остается чуть-чуть на полезную работу )) По крайней мере в этом уверены некоторые разработчики

Пробовал как-то перейти на компилятор V6 вместо V5 (под uVisiion 5), дабы сравнить размер кода и в надежде потом пользоваться новомодный C++14. Проект был под freeRTOS. Проц STM32L1. Объем кода вырос, заметно вырос (игрался разными ключами оптимизации). Меня это удивило и конечно же не устроило, поэтому вернулся назад на V5... Подозреваю, что дело в очень толстых стандартных библиотеках, но не уверен. Возможно, под DS ситуация будет лучше, но пока не пробовал. А он и сейчас уже обновляется заметно реже (последняя была аж в июле). Тоже чую, что придется рано или поздно переходить на DS.

Напишите свое видение этой "проблемы" в компанию ARM ;)

Здесь под словом reentrant имеется ввиду возможность обработчика прервать самого себя. Наподобие вызова функции внутри самой себя. А вытесняющие прерывания называются иначе - nesting interrupts, т.е. вложенные прерывания (в некоторой литературе может встречаться другое название - preemptive). Они подразумевают вытеснение одного обработчика прерываний ДРУГИМ обработчиком. Если же прерывание от того же самого источника произойдет в то время, пока обрабатывается прерывание от этого же источника (скажем, байты по USART сыпятся быстрее, чем успеваем их обрабатывать), то новое прерывание станет отложенным (pending) и вызовется сразу же после обработки текущего (если конечно никто более приоритетный его не прервет). Другими словами, встанет в очередь. Это если объяснять грубо и на пальцах, на деле там полно своих нюансов.

Дык, это вполне логично, и касается не только для ARM )) В ARM (не во всех) реализована поддержка вложенных прерываний. Почитайте про PendSV и заодно про SVC вызовы. Про это уже давно исписаны все заборы интернеты. Это если желаете толстые фунции вызывать в фоне прерываний (кстати, за подобные "дела" в некоторых конторах очень сурово карают). Это вы сейчас так говорите, в данный момент. А в перспективе? ;) Но, если же проект такой примитивный, то все можно сделать на паре/тройке аппаратных таймеров. В самом убогом ARM как минимум два-три штуки найдутся (помимо стандартного SysTimer). Такое решение простое, наглядное и железобетонное. Если правильно назначить приоритеты этим таймерам, то получится относительно работоспособный "шедулер" с поддержкой приоритетов. Еще еще вариант - простейший супер-луп, использующий лишь один таймер (systimer), где код из фона прерываний переносится в фон задач. Фактически пишете шедулер RTOS самостоятельно руками (со всеми вытекающими). зы. В любом проекте в фоне прерываний не должны вызываться никакие толстые функции! Иначе другие толстые функции поплывут и в итоге поплывет времянка всего проектика. Кто пытался писать сложные проекты в супер-лупе (продвинутые ардуинщики), то понимает, что я имею ввиду )))

Именно так и нужно делать, изменяются лишь свойства этого нового файла (см. мой первый пост в этой теме). Вообще, все это есть в мануале на Keil - см. RAM function. Не ленитесь читать ))

А в чем собственно проблема? Речь про некий академический тест (курсач)? ;) Существуют плиски со встроенными ARM ядром, флэшью и ОЗУ, т. е. по сути обычный МК ARM, но с плюшками. Такой вариант не подошел?

Лютое решение ((( Конечно, уже поздно переделывать железо, но почему решили все это чисто на MCU, а не поставили хотя бы FPGA в связке с практически любым МК? если 2/3 кода требуют работы из ОЗУ, так разместите этот код в отдельный файл, разместите его в секции ОЗУ, а все остальное оставьте во флэш. Таблицу векторов желательно скопировать в ОЗУ с перенастройкой NVIC, причем кидать в TCM ОЗУ. Судя по размеру проекта, хватит всей TCM на весь код )))

Если не секрет, то о какому чудо-проекте идет речь? Любопытно ))

Чисто праздный интерес: каким способом вы пришли к тому, что перенос кода в ОЗУ решит проблему?

Каких ресурсов? Разметите критический важный кусок кода внутри отдельных функций, размещенных в отдельном С/CPP файле, поместите весь файл в секцию RAM (как это сделать, см. мануал на Keil). Тогда не придется городить загрузчик лишь для того, чтобы весь код засунуть в ОЗУ. Вы действительно полагаете, что перемещение ВСЕГО кода в ОЗУ поможет решить эту проблему? ;)

Создаете ДВА проекта - проект А - для формирования финальной прошивки (бинарник берем из проекта B ) вместе с простым загрузчиком. проект B - для целевого кода, в сборке DEBUG выполняется и отлаживается как обычно из флэш, в RELEASE сборке - финальная прошивка с размещением всего кода в ОЗУ. А почему не хотите переместить в ОЗУ лишь части проекта, которым это действительно необходимо?

Может есть смысл размещать в ОЗУ не весь код, а только тот, который этого требует? Особенно выгодно по скорости выполнения размещать код в области ОЗУ, которая напрямую подключена к ядру (в STM32 она называется TCM RAM). В KEIL это делается очень просто, почитайте мануал. Если нужно весь код, то я бы сделал так: пишем простейший загрузчик (стартуемый из FLASH), который копирует и возможно даже на ходу распаковывает сжатый код из FLASH в ОЗУ. Делает ремап векторов (в NVIC поправить всего один регистр) и запускает загруженный код. А сам код для исполнения в ОЗУ собирается уже с другими параметрами линкера (в скрипте линкера нужно лишь поправить несколько строчек кода). После чего его (BIN файл) можно упаковать (при желании) и добавить в прошивку загрузчика как внешний файл. KEIL это умеет. Т. е. можно так настроить, что нужный HEХ при компиляции будет формироваться автоматически, для этого лишь нужно выбрать нужный режим (у меня обычно DEBUG/RELEASE) в выпадающем списке.

Ну, да, а влезать в чужую беседу, особенно если сам в ней "не в зуб ногой" - это по-Вашему норм :01: А у вас-то есть что добавить по теме - SST ("каруселька" и т. п.)? Или тоже можно "открывать счет"?

Паттерна "склетон" не существует, но вангую, что речь шла про синглтон. Опиской это не назовешь, поэтому очевидно вы даже не пользовались им ни разу ... Короче, счет 3:0 К слову: по-началу, по неопытности я использовал синглтон слишком активно где надо и не надо ... но это было давным-давно и больше так не делаю )) Суперлуп (или "карусельки") проходят у подавляющего большинства настоящих программеров (не ардуинщиков или куберов) еще в "ясельном" возрасте. Но, судя по всему, еще попадаются редкие уникальные исключения.... Расслабьтесь, никто не собирается менять ваш образ мышления: "поздно пить боржоми ..." :) Однако, ваших "пары постов" вполне для этого хватило - что не пост, то "пук в лужу" :laughing: Да, что вы говорите?! Ну, засуньте в обычный МК (не распберри) хотя бы что-то напоминающее эту "моду". Покажите пример...

Суть от этого не меняется - лаконичный код под классической RTOS после переписывания под SST превращается в банальный говнокод (см. посты #31 и #33). Отсюда мораль: если вы видите перед собой говнокод, то смотрите на тип шедулера. Если стоит SST, "карусельку" или "супер-мега-гипер-луп", то шансы для этого кода все еще есть ... Если этот говонокод умудрились соорудить даже под классической RTOS, то код - в помойку, автора кода - за кассу в "магнит" :)

Аналогичная ситуация! Но только мне удалось наваять свою простейшую ось относительно быстро, после "наиграться" с ней и в итоге поставил готовую чужую и больше этот вопрос не поднимал. С другой стороны, до сих пор вот мне очень интересно познавать новые фишки в мире эмбедед ПО, в частности, относительно недавно "изучал" .netmicro, недавно чуть "по-тискал" micro java (или как там она зовется) .... Короче, удалил их к чертовой бабушке - рано еще, времена еще не пришли, нынешние МК пока еще слишком ватные для таких "вещей". Кстати, в данный момент уперся в необходимость применения такой вещи (пишу под плюсами) - паттерн "фабрика объектов", а совсем недавно освоил паттерн "делегатов" . Удивительно, но теперь они реально мне понадобились, хотя в свое время хихикал над другими: "гы-гы, плюсы, шаблоны, паттерны" ... Но, ребяты, изобретать самодельный колхозный шедулер = городить "велосипед с квадратными колесами" "из говна и палок" - это уже, прям, лютая дикость :01:

Хм, удобная функция, спасибо за подсказку! Пригодится ;)

Но, выходит, что не все об этом знают ... ;)

ОК, слив опять защитан. Счет 2:0 :) Для тех, кто не в теме: в ARM Cortex есть такой механизм - BitBanging (вроде правильно написал). Он позволяет упростить работу с обращениями типа чтение-модификация-запись. В частности, изменение состояния пинов не требует создания критических секций и т. п, как это было необходимо в более архаичных ARM. В молодости я тоже страдал всякой херней наподобие SST ("каруселек") и т. п. подобной дребедени лишь чисто ради "академического" интереса (в ту пору на Microchip процах). Кстати, на Microchip только так и можно было использовать RTOS - кооперативная с вагоном соотв. костылей. Но это было давно и осталось в далеком прошлом (к счастью)... Но времена меняются, и, чтобы не отстать от поезда, нужно осваивать новые решения.

Можно, но в данном случае - в этом нет нужды. Это - главное отличие RTOS от самодельных "каруселек" - не делать то, что не нужно делать. Нет, все в точности наоборот. Именно поэтому везде, где возможно, ставлю RTOS. Это сильно упрощает код и делает его легко переносимым из одного проекта в другой. Во-первых, чтобы зажечь светодиод, не нужно как выговорите "захватывать шину GPIO". Читайте матчасть по ARM Cortex. Не позорьтесь )) Во-вторых, тут не указана реализация методов класса led - on и off. Да и не имеет это отношения к делу. Читайте матчасть. Хрипит он скорее всего по другой причине - меандр сделан средствами RTOS, без использования аппаратных таймеров. Бывшие ардуинщики именно так и делают. Правильно будет - реализовывать разные задачи разными инструменты, а не городить все одним. Вот: // создаем семафор OS::Semaphore semaphore; // гипотетическая задача: while(true) { semaphore.waitForever(); // что-нить делаем } // обработчик прерываний или другая задача { semaphore.signal(); } Для примера, ожидание семафора бесконечное, но есть другие методы у этого класса OS::Semaphore, в частности позволяющие ждать его не более указанного времени. Ваша очередь ... Такая реакция говорит о том, что "про песочницу" я попал в самую точку Кстати, кто такие "гастролеры" с некого "хабра"?

Ну-ну, песочница оживилась :)