Forger

Это такой подход принят у профи - писать ТЗ, составлять бизнес-планы и т.п. Но мне что-то подсказывает, что ТС сам себе "начальник", а речь идет про саморазвитие на базе какой-нибудь платки ардуино :)

Буферизировать данные, как предложил Harvester, но вместе с данными присылать еще и номер сэмпла в качестве временнОй метки, на случай, если какой-то из замеров потерялся по пути. Т.е. проектирвоать некий, пусть и простой, но протокол. ВременнЫе метки должен формировать контроллер, он это сможет сделать гораздо точнее винды.

Нужно найти программиста, готового взяться за эту работу. Предложения о работе находятся в другом разделе: ТЫЦ

Такие вопросы следует задавать разработчику программы. Сформулируйте свой вопрос более конкретно. А еще лучше распишите задачу, которую пытаетесь решить.

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

Создавать глобальный const объект для такой примитивной задачи вовсе не обязательно. Достаточно лишь добавить эту строку в некий h-файл, а сам этот файл добавлять во нужные c/cpp исходники (через соотв. include). У меня такой файл называется GlobalSettings.h Если же вам принципиально нужно разместить некую переменную (или константу) по некому адресу, то задача эта весьма обсосанная и есть в мануале на keil. Способы реализации зависят от версии компилятора.

В этом плане вы не одиноки ;) См. последний пост на первой странице этой темы.

У меня как раз никакой "перестройки" нет, проект сразу проектируется как надо, а потом уже кодится. А не наоборот, как принято у многих "программеров" ;) Поэтому переделка и развитие такого кода (если приходится это делать) по крайне мере у меня происходит очень гуманно, т. к. "перестройка" уже не требуется. Я не призываю переделывать проект, который уже набит критическими секциями. Это - бессмысленно. Код как раз проще и понятнее. По крайней мере для меня. Я уже в который раз повторюсь, что тупо заменить критические секции сервисами RTOS нельзя, иначе как раз и получим монстроподобный код. Короче, я не настаиваю, тут уж ваше дело - использовать совать критические секции или нет. Но для меня они - в чистом виде костыль, пройденный этап. Однако, бывает, что использую их, но лишь в очень редких случаях, когда нужно например что-то по-быстрому отладить, не вдаваясь в подробности. Особенно, если работа с чужим кодом. В настоящее время стараюсь вместо них использовать ldrex/strex, как на мой взгляд более "гуманную" версию критических секций. В принципе, вполне рабочее решение, особенно, если нужно просто защитить всего один указатель или переменную. Но тоже - по особой нужде. Ну, это вы уж очень жирные МК называете, их использую редко. В такие можно напихать "черта дикого" и еще останется огромный запас места и производительности. Секрет! Но проекты коммерческие, к распилу госбюджета отношения не имеют, по крайней мере прямого. Но больше ничего не могу сказать. Типа NDA ;)

А я вам в который раз пытаюсь донести, что нельзя тупо заменить критическую секцию на сервис ОС. Нужна перестройка кода, чтобы обойтись БЕЗ конкуррентного доступа к одним и тем же данным. В моих проектах себестоимость копеешного МК в рамках всего изделия составлять крохи. Однако, я уже упоминал, что в критичных случаях годны любые средства - и костыли критические секции, и голый С и даже ... ASM С таким проектами работал (чистый ширпотреб). Там совсем другой мир. Экономить приходится практически на всем. Но это - совсем другой мир. Смотрю, моя персона не дает вам покоя )) Я ничего не могу поделать с тем, что вам все-таки приходится использовать критические секции и даже вложенные (!). Однако, мне, к счастью или увы (тут вам виднее), прекрасно удается избежать этого. Хотя такой цели я не ставлю, просто, это получается как-то само собой ;) Проекты серийные (не более тысячи в год), изделия не для ширпотреба, но и не оборонка, где цена комплектующих вообще не имеет значения (там с комплектовкой вообще свой цирк, вдаваться не в детали не буду). Стоимость МК от всего изделия в моих проектах составляет 1..2%. Поэтому экономия на ОЗУ и памяти всегда оборачивается весьма недешевым геморроем. Пройденный этап. Конкуренция - почти нет, по крайней мере, в настоящее время. Если припрет, "отрезать" есть что, но уж точно не МК.

Все очень просто: пока запрещены прерывания, все другие прерывания ждут своей очереди. Также в этим моменты напрочь теряется вся прелесть вытесняемых прерываний. Вот поэтому и костыль :) Правда все в той же Freertos можно указать границу (для кортекс М3 и выше), выше которой в критических секциях прерывания не запрещаются, но и в тех прерываниях нельзя использовать сервисы rtos. Конечно же, когда уже никак нельзя без этого или где подобные ограничения не имеют значения, то этот костыль - вполне рабочее решение. И отказывать от него полностью также неразумно, как и его сувать в каждую дырку )) Никаких вместо, выше я об этом написал. Мьютекс в прерывании не использую, он нужен только в фоне задач. В прерываниях использую счетные или простые бинарные семафоры, ну и флаги по нужде. Тут кто как привык )) Во freertos есть даже непосредственные уведомления конкретной задачи task notify - вроде даже как самое легкое решение из всех межзадачных синхронизаций. Вроде бы в ucos-3 тоже появилась такая штука. Просто - не обращаться в прерывании к тем данным, которые используются напрямую в фоне задач. Кольцевой буфер (без проверок на исчерпание/переполнение) тут будет в самый раз в купе с одним счетным семафором. Если не годится, то существуют сообщения, очереди сообщений, Также существуют механизмы непосредственного уведомления задач - notify. Короче, все решаемо и очень даже просто )) Оверхед? Незначительный. Если, конечно, он есть. Как раз про серию и говорю ;) Конечно, бывают проекты, где приходится писать на самом-самом голом С с ASM вставками, но там RTOS, плюсы с их "наворотами" и т. п - вообще как собаке пятая нога. Там уже совсем другая история, где главное - результат, а костыли - по боку ))

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

Но судя по всему, далеко не все об этом знают ;) Я указал, что использую критические секции крайне редко и всегда оооочень аккуратно, а вложенные никогда не использую. Ибо мне нафик не нужны грабли на ровном месте. По мне, любая критическая секция - костыль и явно говорит о том, что в моем проекте есть проблемы с проектированием. В RTOS для защиты важных кусков кода существуют более безопасные механизмы вместо критических секций. Например, все, что связано с обращению к некому порту (в частности та же PRINTF), я использую отдельную задачу/модуль. А все остальные задачи/модули обращаются к этому порту не напрямую, а через эту задачу/модуль через соотв. механизмы синхронизации (мьютекс). Ранее использовал критические секции более сложные - запоминалось состояние флагов прерываний и на выходе восстанавливалось, но в процессе набора опыта нужда в таких вещах напрочь пропала, причины я указал выше.

ТС выложил часть исходников, в частности в его файле MKL27Z64xxx4_RTOS_test.c все нужное есть. Код действительной примитивный, за исключением скрытых граблей в ввиде PRINTF, который тут врядли полностью reentrant. Да и стек жрет он весьма непредсказуемо. И не исключено, что тут он даже обращается к куче ... А я уже давно использую такие критические секции (саму идею "стырил" из scmRTOS): class CriticalSection { public: inline CriticalSection() __attribute__((always_inline)) { __asm volatile ("CPSID i"); } inline ~CriticalSection() __attribute__((always_inline)) { __asm volatile ("CPSIE i"); } }; Это - простейшая реализация, без запоминания предыдущего состояния флажков разрешения прерываний. Но если используется RTOS, то она как раз самое то. Работает просто: достаточно лишь создать объект CriticalSection внутри например функции и при выходе из нее автоматом будут разрешены прерывания (вызывается деструктор). Также его можно объявлять внутри любой группы фигурных скобок { }, даже внутри циклов, если конечно пишем на плюсах. Весьма удобно: for (...) { CriticalSection cs; ... } или так: if (condition) { CriticalSection cs; ... } else .... Однако, стараюсь использовать ее очень редко и только там, где без нее ну вообще никак ))

При чем тут некий ProcessorExpert??? Вы почему-то вбили себе в голову, что проблема кроется лишь в настройках freertos. Попробуйте перечитать второй пост в этой теме еще раз. Там на мой взгляд я указал наиболее вероятную причину. Пройдите по шагам в отладчике. Убедитесь, что происходит вызов прерывания SysTick и соотв. вход в SysTick_Handler, реализованный freertos, а не какую-то постороннюю функцию. Для упрощения оставьте только одну задачу с задержкой, уберите для начала нафик PRINTF, ибо его тупое применение где можно и где нельзя может наплодить кучу проблем на ровном месте. Добейтесь, чтобы такой код работал не "зависая", а уже ПОТОМ суйте туда свой код, ЧАСТЯМИ, поэтапно: static void sec_task(void *pvParameters) { for (;;) { vTaskDelay(1); } }

Увы, мой телепатический шлем на днях сломался - после подачи питания все задачи по разу запускает и виснет на последней, перепробовал все настройки, разумеется "PREEMPTION, systickinterrupt, time slicing и др. включены.", пробовал даже самый козырный вариант - вслепую тыкая разные настройки. Тщетно! Крайняя меря (что категорически запретил делать производитель шлема) - гугль, но и тут чуда не произло - ну, нету связи и все тут (( Видать, придется нести в ремонт ...