Освоение ARM контроллеров Опции

[maxntf]

Появилась необходимость в освоении ARM контроллеров.
Есть проект реализованный на PIC контроллере, который необходимо портировать на ARM. Это связано с тем, что в него нужно доработать реализацию воспроизведения аудио файлов.
Просьба помочь в выборе контроллера и отладочных средств к нему для изучения ARM, с учетом моих задач. Просто не хочется брать первую попавшеюся отладочную плату с установленным в нее контроллером. А выбрать тот набор оборудования и ПО, который поможет мне в изучении ARM и параллельно реализовать все мои задачи.
Основные параметры основываясь на старый проект:
1) Объем памяти программ не меньше 128kB.
2) Объем памяти данных не меньше 4kB. Учитывая что в старом проекте используется внешняя EEPROM для хранения параметров на 64kB, а в новом проекте еще и нужно хранить аудио треки. И насколько я успел поверхностно ознакомится, в ARM можно использовать внешнюю flash память и для памяти данных контроллера и для хранения треков и параметров. Если я прав, то тогда ARM можно брать вообще без внутреннего ОЗУ.
3) Большое количество портов. В старом проекте был PIC на 80 ног.
4) Нужно 17 АЦП для измерения напряжения, остальные GPIO.
5) 2 порта UART.
6) Желательно USB.
7) И самое главное возможность проиграть аудио ролики (не важно в каком формате хоть в “amr”) в аудио тракт GSM модема. Эти ролики будут подготовлены на ПК и записываться в цифровом формате во внешнюю flash (то есть никаких кодеков для записи аудио не нужно).
Есть под ARM готовые библиотеки для воспроизведения аудио файлов?
В качестве среды разработки хочу взять CooCox CoIDE (GCC Compiler) в виду того что она бесплатная. Вроде неплохие отзывы о ней. Кстати кто знает, в ней есть ОС под ARM.
ARM контроллер и отладочный комплект ST или NuVotone. Лучше ST так как на мой взгляд они наиболее популярны, а по второму производителю маловато информации в сети.
Заранее благодарен за любую помощь.

[Forger]

Появилась необходимость в освоении ARM контроллеров

Примите наши искренние поздравления!

Просто не хочется брать первую попавшеюся отладочную плату с установленным в нее контроллером.

А в чем проблема в данном случае? Ведь под вашу "ресурсоемкую" задачу подойдут 95% отладочных плат, которые делают под ARM

[agregat]

Появилась необходимость в освоении ARM контроллеров.

А зайти на сайт ST и выбрать по параметрическому поиску не пробовали...

[Forger]

А зайти на сайт ST и выбрать по параметрическому поиску не пробовали...

Что вы такое говорите?! Как можно?! Это же, это же ... запрещенный прием!!!
Настоящие джентельмены так не поступают!

[RadiatoR]

Вы путаете назначение ОЗУ и энергонезависимой памяти.
Еще разберитесь - вас сейчас интересует отладочная плата с этими требованиями или чип подходящий к ним?
Если чип, то вариантов много, если отладка, то весь тот набор по крайней мере у ст не стоит. Придется выбирать. Но я бы выбрал обычную STM32F4 Discovery и на ней бы отработал все нужды. Собственно я в свое время так и сделал.

[Tarbal]

Да что вы все такие злые?
Ну не знает человек столько сколько вы -- так расскажите ему где и что читать.

[Forger]

Да что вы все такие злые?

При чем тут злоба? В данном случае по-доброму подтруниваем над откровенным нежеланием самого топикстартера самостоятельно почитать интернеты

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

[maxntf]

Вы путаете назначение ОЗУ и энергонезависимой памяти.

Возможно я и ошибаюсь, просто я бегло просматривал архитектуру МК NUC505 Series от нувотон, и как я понял из этого
Memory
- 128 KB of embedded SRAM
- 2 MB of SPI Flash
То он как раз использует в качестве ОЗУ внешнюю флешь через какую то специальную I2C шину. Может я ошибаюсь?
К сожалению только пару дней как начал заниматься этим вопросом, по этому и интересуют советы понимающих людей.
Допустим дискавери есть с разными МК. Не хочется взять с контроллером которого может не хватить для моего проекта. Допустим на PIC в этом проекте у меня было занято из 128kB около 80%. И если я возьму отладочную плату с ARM на 128kB в котором попробую реализовать свой проект, хватит ли мне его памяти когда нужно еще ауди декодер какой туда впихнуть, а еще хотелось бы какую нибудь ОС (проект не маленький, на pic я использовал OSA) . Просто не зная аппетиты ARM, тяжело выбрать верное решения. А осваивать нужно имея на руках железо, а не только мат. часть.
STM32F4 Discovery это хорошо, но бюджет не резиновый и хотелось бы реализовать проект на МК из серии F0.
Или взять STM32F4 Discovery все сделать, а потом смотреть в какой более дешевый МК все это можно будет засунуть?
Взять заведомо мощнее МК я боюсь напороться на невозможность непереносимости проекта на более простой МК (например с F4 на F0). Потому как пока еще не понимаю разницу между ними. Ну кроме явных параметров, таких как память и быстродействие. Может это как написать проект под PIC32 а потом пытаться его перенести на pic12

Сообщение отредактировал maxntf - Mar 29 2016, 17:53

[Forger]

STM32F4 Discovery это хорошо, но бюджет не резиновый

Это что ж за бюджет такой, раз туда не влазит даже такая довольно простая отладочная плата?

Читайте тут

[maxntf]

Это что ж за бюджет такой, раз туда не влазит даже такая довольно простая отладочная плата?

Читайте тут

Не плата а МК который в ней.

Взять заведомо мощнее МК я боюсь напороться на невозможность непереносимости проекта на более простой МК (например с F4 на F0). Потому как пока еще не понимаю разницу между ними. Ну кроме явных параметров, таких как память и быстродействие. Может это как написать проект под PIC32 а потом пытаться его перенести на pic12

[scifi]

Допустим на PIC в этом проекте у меня было занято из 128kB около 80%. И если я возьму отладочную плату с ARM на 128kB в котором попробую реализовать свой проект, хватит ли мне его памяти когда нужно еще ауди декодер какой туда впихнуть, а еще хотелось бы какую нибудь ОС (проект не маленький, на pic я использовал OSA).

STM имеет интересную особенность: там в одинаковых корпусах часто бывают чипы пожирнее и похудее. Даже миграция между поколениями (STM32F1, STM32F2, STM32F4) есть (см. в даташите "compatible board design" но там заморочки с совместимостью софта). Кстати, 128Кбайт не припомню, у них 64, 256, 512 и т.д. Короче, берите пожирнее, а в серийное изделие можно будет поставить более экономный вариант. Но сначала надо проверить, что такой выбор действительно существует.

[RadiatoR]

Печально, что вы гоняясь за бюджетом и другими вещами до сих пор не сходили на сайт st.com и в продукт калькуляторе не отсеяли необходимые параметры и не убедились, что на F0 ваши требования реализовать в частность 17 ацп нельзя (по крайней мере без спец. приблуд типа аналоговых мультиплексоров и т.д.). До сих пор нет точных данных для помощи например с какой частотой нужно измерять аналоговый сигнал. И прочее...
+ даже базовые знания про SRAM и FLASH вы не удосужились изучить, но уже просите подобрать вам готовое бюджетное решение, прям как 3 основных составляющих

[Forger]

Не плата а МК который в ней.

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

Выбрать проц элементарно - заходите в на сайт производителя МК, находите там "параметрический поиск".
Уж проц тут за вас никто не выберет

[mantech]

Возможно я и ошибаюсь, просто я бегло просматривал архитектуру МК NUC505 Series от нувотон, и как я понял из этого

Рекомендую смотреть в сторону ST или NXP(LPCсерия). Т.к. вы новичек, то по этим мк смогут ответить быстрее и больше...

[maxntf]

+ даже базовые знания про SRAM и FLASH вы не удосужились изучить, но уже просите подобрать вам готовое бюджетное решение, прям как 3 основных составляющих

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

[mantech]

Взять заведомо мощнее МК я боюсь напороться на невозможность непереносимости проекта на более простой МК (например с F4 на F0).

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

[maxntf]

Рекомендую смотреть в сторону ST или NXP(LPCсерия). Т.к. вы новичек, то по этим мк смогут ответить быстрее и больше...

Спасибо! Я собственно на ST пока и остановился, так как по ним много примеров есть.

Сообщение отредактировал maxntf - Mar 29 2016, 18:54

[jcxz]

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

Что странного? Именно так и делают: берут самый жирный МК в линейке, запускают проект на нём. Потом, когда более-менее устаканятся хотелки и решение, смотрят что получилось по ресурсам и в какой более дешёвый МК это можно упаковать. Именно поэтому на отладках чаще всего ставят именно самый жирный МК из линейки.
Но упаковку в меньший МК стоит делать только если нужно серийное производство с достаточно большим объёмом, что в проекте "для себя" не актуально, имхо.

[maxntf]

Во избежание лишних дискуссий буду задавать более конкретные вопросы.
Помогите с выбором платы DISCOVERY в моем случае, для каждого МК я выписал основные критерии которые считаю важны для меня, возможно я что-то упустил:
STM32F401VC:
ROM - 256
RAM - 64
ADC - 16ch
DMA - для загрузки аудио файлов без проца
Комуникация UART, SPI, I2C
SDIO - если флешь будет карта SD
audio PLL - эта штука мне не понятна, нужна ли она мне будет для воспроизведения аудио?
STM32F407VG
ROM - 1024
RAM - 129
ADC - 16ch (вижу что в линейке есть и на 24 ch)
DMA - для загрузки аудио файлов без проца
Комуникация UART, SPI, I2C
SDIO - если флешь будет карта SD
Не вижу audio PLL
STM32F411VE (На мой взгляд наиболее подходящий и цена на проц приемлемая)
ROM - 512
RAM - 128
ADC - 16ch
DMA - для загрузки аудио файлов без проца
Комуникация UART, SPI, I2C
SDIO - если флешь будет карта SD
audio PLL - эта штука мне не понятна, нужна ли она мне будет для воспроизведения аудио?

[jcxz]

ROM - 256

Сомневаюсь, что хотя-бы в одном из означенных МК найдёте столько ROM. Да и нафига она Вам?
Вот размер FLASH - другое дело.

PS: У Вас большие проблемы с терминологией. Вы путаете ОЗУ с FLASH (или чем-то другим), ROM с FLASH, видите указания на некие интерфейсы (I2C) которых нет.
Откройте любой учебник по МК - без знания основ никуда.
Даже помочь Вам сложно, ибо сложно понять, что Вам нужно.

DMA - для загрузки аудио файлов без проца

DMA нужен для разгрузки CPU при работе с периферией. Ни о каких "файлах" он не знает и сделать с ними ничего не сможет. И есть он почти в каждом МК с ядром Cortex-M.

Комуникация UART, SPI, I2C

Коммуникации чего с чем? Аппаратные модули такие есть почти в кажом МК Cortex-M. И даже обычно по неск. шт.
А для АЦП обычно ещё указывают требуемую частоту сэмплирования и разрядность. Кроме того - возможность мультиплексирования входов (или нужны именно отдельные АЦП).

SDIO - если флешь будет карта SD

SD-карта без проблем вешается на SPI.

audio PLL - эта штука мне не понятна, нужна ли она мне будет для воспроизведения аудио?

Полезна, если АЦП и ядро МК по каким-то причинам невозможно тактированть от одного источника. Либо, например, нужно выключать основной PLL для экономии энергии.
Для простого проигрывания звука обычно не нужен.

Для проигрывания звука ещё нужно его как-то вывести наружу. Т.е. - нужен ЦАП. Встроенный или внешний (внешний обычно на I2S или SPI).
Да - и если под "аудио-файлами" понимаете MP3-файлы, то Cortex-M0 будет скорей всего маловат. Хотя всё конечно зависит от требуемого битрейта

PS: Мой совет - возьмите любую отладочную плату и вначале научитесь хоть что-то программировать на ARM МК.

[RadiatoR]

Опять же как я и говорил - нечеткие требования например к аналоговым входам.
Что вы собрались измерять и с какой скоростью? Я не видел отладок с 24 ADC. Если есть - здорово, только так ли нужно?
Может вам есть смысл купить f4 discovery и сделать часть портов через мультиплексор? А уже в итоговом варианте напрямую пустить. А может и не потребуется ставить чип с 17+ ацп входами.. все таки не дешевое удовольствие, тем более вы гонитесь за стоимостью.
По другим интерфейсам и я и другие участники уже отвечали - та же дискавери закроет 95% всего, остальное можно и на костыле подсадить.
На счет звука путнего подсказать не могу - думаю тут есть более грамотные в этом вопросе, но сдается мне выбор по прежнему останется за одной из отладок аля f4disc

[maxntf]

Сомневаюсь, что хотя-бы в одном из означенных МК найдёте столько ROM. Да и нафига она Вам?
Вот размер FLASH - другое дело.

PS: У Вас большие проблемы с терминологией. Вы путаете ОЗУ с FLASH (или чем-то другим), ROM с FLASH, видите указания на некие интерфейсы (I2C) которых нет.
Откройте любой учебник по МК - без знания основ никуда.
Даже помочь Вам сложно, ибо сложно понять, что Вам нужно.

ROM - я имею ввиду память программ.
Да что за люди, уже написал конкретный вопрос, а вместо помощи пытаются отписаться и показать себя умнее всех.
Вы когда объявляете константы вы пишете const rom int x или const flash int x?
Интуитивно можно понять что я имею ввиду.

...
Может вам есть смысл купить f4 discovery и сделать часть портов через мультиплексор? ...

Так я собственно и спрашиваю discovery с каким из этих МК лучше выбрать?

АЦП нужно просто мерить входное напряжение (мультиметр)

Сообщение отредактировал maxntf - Mar 30 2016, 08:09

[Obam]

Цитата(maxntf @ Mar 29 2016, 20:44) *
Взять заведомо мощнее МК я боюсь напороться на невозможность непереносимости проекта на более простой МК (например с F4 на F0). Потому как пока еще не понимаю разницу между ними. Ну кроме явных параметров, таких как память и быстродействие. Может это как написать проект под PIC32 а потом пытаться его перенести на pic12

Характерный пример.
ТС, отметьте себе сразу - F0, F2, F3, F4 (больше того - все доступные ARM) - 32-разрядные со сходной архитектурой; ядра как братья близнецы.
Смело изучайте любое.

Так я собственно и спрашиваю discovery с каким из этих МК лучше выбрать?

Вот любую! Освоите, а к тому времени и свой блок спроектируете.

[jcxz]

ROM - я имею ввиду память программ.

ARM - это не PIC. Здесь единое адресное пространство. Вы этого толком не понимаете, поэтому и не видите многих путей решения Вашей задачи.
Программа в ARM может выполняться хоть из ROM хоть из FLASH хоть из ОЗУ. Также как и данные - могут находиться в любом месте.
Из этого следует например то, что для Ваших "аудио-файлов" возможно и не нужна SD-карта, а их можно просто включить в образ прошивки (вместе с кодом программы) и разместить во FLASH. Всё зависит от их размера.

Вы когда объявляете константы вы пишете const rom int x или const flash int x?
Интуитивно можно понять что я имею ввиду.

Константы я объявляю: int const x;
Интуитивно из Ваших постов можно понять только, что Вам нужен учебник по Cortex-M

[maxntf]

Характерный пример.
ТС, отметьте себе сразу - F0, F2, F3, F4 (больше того - все доступные ARM) - 32-разрядные со сходной архитектурой; ядра как братья близнецы.
Смело изучайте любое.
Вот любую! Освоите, а к тому времени и свой блок спроектируете.

Спасибо, собственно таких ответов я и ожидал!

ARM - это не PIC. Здесь единое адресное пространство. Вы этого толком не понимаете, поэтому и не видите многих путей решения Вашей задачи.
Программа в ARM может выполняться хоть из ROM хоть из FLASH хоть из ОЗУ. Также как и данные - могут находиться в любом месте.
Из этого следует например то, что для Ваших "аудио-файлов" возможно и не нужна SD-карта, а их можно просто включить в образ прошивки (вместе с кодом программы) и разместить во FLASH. Всё зависит от их размера.

И Вам спасибо. И таких ответов хотелось.
Понятно что нужно детально изучать все доки. Но вначале нужно иметь грубое поверхностное представление. Почитать статьи, примеры, а потом получив базовое представление лезть в дебри.

[RadiatoR]

Так я собственно и спрашиваю discovery с каким из этих МК лучше выбрать?
АЦП нужно просто мерить входное напряжение (мультиметр)

Вы путаете мультиплексор и мультиметр.
Мультиплексор вы можете использовать в качестве "тройника" для ваших аналоговых сигналов (если по параметрам проходят) если на плате не будет хватать аналоговых входов. Я лично не видел более 16.

[AVI-crak]

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

Поиграйтесь кубиком от st, там есть все варианты, в том числе и уже готовые проекты для печаток от st - со всеми используемыми ногами (смотрите на свободные - они вам доступны).
http://www.st.com/web/catalog/tools/FM147/...2?sc=stm32cube#

[RadiatoR]

Не имея представления об ARM, в частности о процах от ст рыться в кубе бесполезное занятие. Имхо

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

[den1s]

по требованиям много каналов АЦП, памяти, USB и Cortex-M0 возможно подойдет новый атмеловский SAMC21. Например ATSAMC21J18A

Там 2 АЦП по 12 каналов и одно сигма-дельта АЦП на 3 диф-канала. USB host/device. Правда корпус на 64 ноги максимум.
В качестве бонуса - питание до 5.5В.

Вроде камни эти в продакшен пока не вышли, потому по цене не ясно. Но последнее время Атмелы свои кортексы делают конкурентными с СТМ32 по цене (например М4 оптом от Atmel дешевле STMF4). Камушек конечно навороченный, потому для М0 наверное дорог будет, но уж точно дешевле М4.

Отладку можно купить в России ATSAMC21-XPRO за весьма вменяемые $21

[jcxz]

Отладку можно купить в России ATSAMC21-XPRO за весьма вменяемые $21

Вменяемые? Мне тут на днях отладку на Nuvoton предлагали, который 300МГц и 64МБ внутри и LQFP и на плате куча разъёмов и дип-переключателей - судя по всему удобная плата.
И всего 10$ за отладку.

[den1s]

Вменяемые? Мне тут на днях отладку на Nuvoton предлагали, который 300МГц и 64МБ внутри и LQFP и на плате куча разъёмов и дип-переключателей - судя по всему удобная плата.
И всего 10$ за отладку.

Нувотон трудно по цене перебить и камушки у них интересные встречаются часто. Но работать с ними в России тяжелова-то. Требуются большие объемы заявлять - по мелочи они не размениваются, документация под NDA.

[jcxz]

Документация вроде нормально к ним находится в инете. Глубоко правда не разбирался, но NUC970 Family Programming Guide (типа юзермануал) найти в инете можно.

[den1s]

Документация вроде нормально к ним находится в инете. Глубоко правда не разбирался, но NUC970 Family Programming Guide (типа юзермануал) найти в инете можно.

Возможно, такая ситуация не со всеми семействами. Но, например, для NUC976 даташит распространяется под NDA. Ну и некоторые документы, возможно, можно найти благодаря "добрым людям", которые их выкладывают после получения.

[jcxz]

Возможно, такая ситуация не со всеми семействами. Но, например, для NUC976 даташит распространяется под NDA. Ну и некоторые документы, возможно, можно найти благодаря "добрым людям", которые их выкладывают после получения.

Вы читаете невнимательно. Я же пишу, что NUC970 Family Programming Guide находится за минуту. Это юзермануал с описанием периферии на всё семейство NUC97x.
Описание периферии правда (на поверхностный взгляд) не фонтан - у всяких NXP, STM и т.п. более объёмное описание.

[maxntf]

Продолжаем разбираться. Получил железо, просмотрел несколько уроков, помигал светодиодами, передал в UART. Все вроде не особо сложно, так как сотни примеров есть. Начал разбираться с чего же все начинается. Тут уже инфы меньше и полез смотреть в мануал. Просьба поправить меня если я что то не так понял:
- Все начинается с адреса 0000 0000 (собственно это регистр syscfg_memrmp), который принимает значения состояния штырьков boot;
- У него только младшие 2 байта, которые указывают с какого места продолжить загрузку;
- Есть 3 варианта flash, SRAM и System memory. Во Flash наша основная программа, в System memory заводской бутлоадер, а в SRAM может быть любая временная программа (возможно даже свой бутлоадер, пока еще толком не понял).
- Из Flash мы запускаемся когда мы выполняем основной алгоритм работы.
- Из System memory если хотим обновить прошивку (не совсем понятно зачем это нужно, на сколько я понял у него нет шифрования данных, то есть прошивка должна иметься открытая). Ну возможно для каких то целей отладочных и пригодится.
- Из SRAM мы не можем загрузиться с первого раза, так как в нем будет бяка после подачи питания. Нужно первый раз загрузится нормально, записать в SRAM код программы которую нужно выполнить из SRAM, программно установить syscfg_memrmp для загрузки из SRAM и выполнить программный reset.

Сообщение отредактировал maxntf - Apr 4 2016, 12:53

[RadiatoR]

Адрес 0x00 не принимает никакого значения boot. Туда записывается указатель стека.
Зачем вы лезете в дебри, которые вам не нужны? Отработали переферию - делайте логику.

а вот уже на 2 слове идет адрес старта кода (и скорее всего это не main, а код инициализации тактирования. Создается что в кокосе, что в кейле)

[maxntf]

Адрес 0x00 не принимает никакого значения boot. Туда записывается указатель стека.

Точно, спасибо. Не правильно перевел мануал, регистр SYSCFG как и положено находится в структуре регистров.

а вот уже на 2 слове идет адрес старта кода (и скорее всего это не main, а код инициализации тактирования. Создается что в кокосе, что в кейле)

Этот адрес устанавливается по состоянию регистра SYSCFG (состояние ножки boot)?

[esaulenka]

Нет. Значение SYSCFG определяет, на какую область памяти будет отображаться адрес 0.
Т.е., выставляем в одно значение - и содержимое памяти по адресам 0x00000000 и 0x08000000 будет одинаковое (и так же одинаковым будут следующие N килобайт, цифирку за ненадобностью не помню). Выставляем другое значение - будут одинаковыми 0x00000000 и 0x20000000 и т.д.

Но вот правда - бросайте Вы эти глупости. Мне кажется, этим ремапом никто толком и не пользуется. Разве что штатный загрузчик, да отладчики в режиме "загружать код в RAM" (этакий быстрый режим отладки для маленьких программ, чтобы флеш каждый раз не стирать).

[x893]

Ремапом приходится пользоваться в STM32F0 серии так как нет VTOR
Все загрузчики используют

[AVI-crak]

Но вот правда - бросайте Вы эти глупости. Мне кажется, этим ремапом никто толком и не пользуется.

Ремамп - единственный корректный способ залить код в внешнюю sdram из внешней 25qxx, и запустить ну очень жирную прошивку в нативном режиме - с поддержкой отладки. А на новых чипах от st этот режим уже часть периферии - исполняется самостоятельно, без ручных бутов.

[jcxz]

Нет. Значение SYSCFG определяет, на какую область памяти будет отображаться адрес 0.
Т.е., выставляем в одно значение - и содержимое памяти по адресам 0x00000000 и 0x08000000 будет одинаковое (и так же одинаковым будут следующие N килобайт, цифирку за ненадобностью не помню). Выставляем другое значение - будут одинаковыми 0x00000000 и 0x20000000 и т.д.

Интересно - и как это тут все определили о каком именно МК автор ведёт речь? Что он имеет в виду под "Получил железо ..."?
И уже прямо кучу советов понадавали. И тоже непонятно - по какому именно МК советы.
Прям экстрасенсы одни вокруг......

[maxntf]

STM32F407VG.
Как в программе выполнить reset?
В PIC можно было функцией RESET();

[scifi]

STM32F407VG.
Как в программе выполнить reset?
В PIC можно было функцией RESET();

NVIC_SystemReset();

[jcxz]

STM32F407VG.
Как в программе выполнить reset?
В PIC можно было функцией RESET();

Универсально (для любого МК) - через встроенный WDT.

[scifi]

Универсально (для любого МК) - через встроенный WDT.

А ещё можно соединить GPIO и RESET и дёргать этот сигнал

[jcxz]

А ещё можно соединить GPIO и RESET и дёргать этот сигнал

Хех! Круче - соединить GPIO и ногу EN питающего LDO

[maxntf]

Сейчас разбираюсь с юзерским бутлоадером. Почитал про систему прерываний Cortex, она кардинально от PIC отличается но в принципе все понятно. При старте мы сразу попадаем в прерывание Reset и из него уже выходим в нашу main().
Как все организовать я понял. Только не получается перенести вектор прерываний как в бутлоадере когда переходим к выполнению основной программы, так и в основной программе (ее ведь необходимо сместить выделив место под бутлоадер). Нашел пример бутлоадера, там для этих целей используется функция NVIC_SetVectorTable(). У меня в функциях NVIC файла core_cm4.h такой нет.

Сообщение отредактировал maxntf - Apr 5 2016, 13:34

[scifi]

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

Ну нельзя же так. Правильные пацаны читают мануал на процессор (Cortex-M4, как я понял). Там английским по белому написано, что есть регистр VTOR (в стандартных заголовках обозначается SCB->VTOR). Не нужна функция, чтобы записать значение в регистр, это моветон.

[maxntf]

Вот два кода, первый бутлоадера, а второй моя программа. Так нужно делать?

Код

//В проекте бутлоадера
int main(void)
{
//Здесь код бутлоадера



//здесь переопределение адреса таблицы векторов прерываний
//и переход к выполнению основной программы
__disable_irq ();
__set_MSP( *(uint32_t*)(0x08001000) );
SCB->VTOR = 0x08001000;
(*(void(*)(void))( *(uint32_t*)(0x08001000+4) ))();
}

//В проекте с основной программой
int main(void)
{

SCB->VTOR = 0x08001000;//и в линкере проекта основной программы установить адресацию с 0x08001000

//Дальше код основной программы
}

[scifi]

Вот два кода, первый бутлоадера, а второй моя программа. Так нужно делать?

Кому нужно?
Делать можно по-разному. Мне нравится немного по-другому.
Адрес таблицы векторов не обязательно менять в загрузчике - основная программа сама это может сделать.
Переход на основную программу мне нравится делать вот так:

Код

static const uint16_t jump2fw[] =
{
    0xF850, 0xDB04, /* LDR.W SP, [R0], #4   */
    0x6800,         /* LDR.W R0, [R0]       */
    0x4700,         /* BX R0                */
};
...
((void (*)(int))(1 + (int)jump2fw))(0x08010000);

Причём выполняю это действие сразу после сброса в самом начале Reset_Handler(), если установлен соответствующий флаг (запрос на переход в основную прошивку). При таком способе основная прошивка стартует со сброшенной периферией, что удобно.

[maxntf]

Тогда не верно выразился, нужно так - "Так все правильно будет работать?" . Учитывайте тот факт, что я вообще только начал изучение STM32.
И еще один вопрос в нагрузку:
- когда я ставлю в линкере основного проекта адрес 0x08001000, то после компиляции при переходе в отладку, у меня все весит по адресу 0x00000000. Ну это и понятно, потому что там ничего нет. Тогда как отлаживать? Сначала делаем программу как обычную не под бутлоадер, то есть не меняя в ней адрес таблицы векторов и не трогая линкер. А после того как проект готов, ставим в начало main SCB->VTOR = 0x08001000; и корректируем линкер. Или нужно что то еще?

Сообщение отредактировал IgorKossak - Apr 5 2016, 17:09

Причина редактирования: бездумное цитирование

[scifi]

- когда я ставлю в линкере основного проекта адрес 0x08001000, то после компиляции при переходе в отладку, у меня все весит по адресу 0x00000000. Ну это и понятно, потому что там ничего нет. Тогда как отлаживать?

Я отлаживаю в кейле. Там можно подключить скрипт отладчика. В скрипте пишу

Код

SP = *(int*)0x08001000;
PC = *(int*)0x08001004;

И всё.

[jcxz]

//здесь переопределение адреса таблицы векторов прерываний
//и переход к выполнению основной программы
__disable_irq ();
__set_MSP( *(uint32_t*)(0x08001000) );
SCB->VTOR = 0x08001000;
(*(void(*)(void))( *(uint32_t *)(0x08001000+4) ))();
}

Как-то слишком кудряво и лишнее разименование. Надо быть проще:
((void(*)(void))*(void **)0x08001004)();
И, как тут уже сказали, основная программа должна выставлять VTOR какой ей надо (как и все прочие регистры периферии), а не бутлоадер.
И какое-то у Вас странное содержимое SP. Вы уверены, что по этим адресам у Вас находится ОЗУ? Обычно в МК с ядром Cortex-M по этим адресам находится Flash.
И насчёт __disable_irq () - не уверен, что это будет работать в Cortex-M. Обычно для Cortex-M используют __disable_interrupt().
А __disable_irq() и __disable_fiq() - это для ARM7/9 (и Cortex-A наверное).

Почитал про систему прерываний Cortex, она кардинально от PIC отличается но в принципе все понятно.

Кроме того: система прерываний Cortex-M кардинально отличается от системы прерываний Cortex-A.

- когда я ставлю в линкере основного проекта адрес 0x08001000, то после компиляции при переходе в отладку, у меня все весит по адресу 0x00000000. Ну это и понятно, потому что там ничего нет. Тогда как отлаживать? Сначала делаем программу как обычную не под бутлоадер, то есть не меняя в ней адрес таблицы векторов и не трогая линкер

Это то как раз и непонятно. Что-то у Вас неправильно компилится/линкуется.
Не надо делать "не под бутлоадер". Если правильная конфигурация командного файла линкёра, то после загрузки ПО JTAG-ом, PC устанавливается на точку входа (содержимое вектора сброса или начало функции main()). И это вне зависимости от того, на какие адреса линковали - хоть в FLASH хоть в SRAM хоть во внешнюю SDRAM.

[maxntf]

Это то как раз и непонятно. Что-то у Вас неправильно компилится/линкуется.
Не надо делать "не под бутлоадер". Если правильная конфигурация командного файла линкёра, то после загрузки ПО JTAG-ом, PC устанавливается на точку входа (содержимое вектора сброса или начало функции main()). И это вне зависимости от того, на какие адреса линковали - хоть в FLASH хоть в SRAM хоть во внешнюю SDRAM.

При установке в настройка линкера CooCox старт адреса 0x08001000, после компиляции и запуска отладки у меня во втором слове памяти по адресу 0x00000004 почему весит значение с адресом 0x00010101. Да и вообще я вижу, что в памяти какая то бяка вместо моей программы.

[jcxz]

При установке в настройка линкера CooCox старт адреса 0x08001000, после компиляции и запуска отладки у меня во втором слове памяти по адресу 0x00000004 почему весит значение с адресом 0x00010101. Да и вообще я вижу, что в памяти какая то бяка вместо моей программы.

Так если линкуете с адреса 0x08001000, то зачем смотрите на адрес 0x00000000???
И что такое старт адрес 0x08001000? У Вас там таблица векторов прерываний расположена?

[maxntf]

Так если линкуете с адреса 0x08001000, то зачем смотрите на адрес 0x00000000???
И что такое старт адрес 0x08001000? У Вас там таблица векторов прерываний расположена?

Смотрю на адрес 0x00000004 потому что внем записано 0x00010101 и у меня отладчик висит на этом адресе после старта.
Хотя смотрел бинарник после компиляции, там вроде все верно. (по крайней мере код программы есть)
Наверное я что то делаю не так.
Можете поэтапно указать все изменения проекта под бутлоадер от стандартного проекта, пусть даже который создаем через визар.

[jcxz]

Хотя смотрел бинарник после компиляции, там вроде все верно. (по крайней мере код программы есть)
Наверное я что то делаю не так.

Как Вы смотрите бинарник? Как там видите адреса?
Смотреть надо map-файл. По нему проверяете куда у Вас скомпоновалась таблица векторов прерываний и прочие секции кода и данных.
Также там указана точка входа ПО (в IAR называется "Entry symbol"). Вот с этой точки входа отладчик и стартует.
Я не знаю кокос, пользуюсь IAR.

[zltigo]

Как-то слишком кудряво и лишнее разименование. Надо быть проще:

((void(*)(void))*(void **)0x08001004)();

1. #define ADDR 0x08001004
2. ()ADDR .... Будем явно тип преобразовывать
3. (*)ADDR ....В указатель
4, ((*)())ADDR .................. на функцию
5. ((*)(void))ADDR ........................................без параметров
6. (void(*)(void))ADDR ...... ничего не возвращающую

8. Ну и вызываем:

((void(*)(void))ADDR)();

[jcxz]

1. #define ADDR 0x08001004
...
((void(*)(void))ADDR)();

У ТС адрес 0x08001004 - не адрес функции, а адрес вектора reset в таблице прерываний, который указывает на функцию. Так что там ещё разыменование забыли.
А если-б это был адрес функции, бит0 был бы равен ==1, а не 0.

[zltigo]

У ТС адрес 0x08001004 - не адрес функции, а адрес вектора reset в таблице прерываний, который указывает на функцию.

Поял.

А если-б это был адрес функции, бит0 был бы равен ==1, а не 0.

Это смотря какой режим - не только на кортексах свет клином сошелся.

[maxntf]

Как Вы смотрите бинарник? Как там видите адреса?

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

Сообщение отредактировал maxntf - Apr 5 2016, 17:32

[scifi]

Это смотря какой режим - не только на кортексах свет клином сошелся.

Здесь сошёлся. По некоторым признакам, у него Cortex-M4. Если ему ещё про что-то другое вещать, совсем зависнет

[Kabdim]

Афаик нужно после смены адреса таблицы прерываний надо всадить DSB для повышения кошерности.

[maxntf]

Я отлаживаю в кейле. Там можно подключить скрипт отладчика. В скрипте пишу

Код

SP = *(int*)0x08001000;
PC = *(int*)0x08001004;

И всё.

А где именно это можно сделать, можно подробнее?

[scifi]

А где именно это можно сделать, можно подробнее?

В свойствах проекта во вкладке "отладчик" можно указать файл скрипта инициализации. Можно назвать файл "debug.ini", и в нём всё это написать.
У меня линия RESET от отладчика к МК не подключена, поэтому я вместо загрузчика ставлю заглушку типа "while (1) {}". После сброса МК втыкается в эту заглушку, потом подключается отладчик и принимает дела.

[maxntf]

Подключил FreeRTOS, пока практически пустой проект 3 задачи для теста - 1-я контроль кнопки, 2-я передача строки "Hello World" в UART и 3-я мигание индикаторами.
Хотя в FreeRTOSConfig.h и стоит #define configTOTAL_HEAP_SIZE ( ( size_t ) ( 75 * 1024 ) ) , но в SRAM забрало очень много места, почти 60% всей ОЗУ.

Program Size:
12440 28 79288 91756 1666c main.elf
text data bss dec hex filename

Подскажите почему так? Смотрел в map файле я так понимаю что все жрет heap_2.c

*fill* 0x200001aa 0x6
.bss 0x200001b0 0x12c14 ..\obj\heap_2.o
*(COMMON)
COMMON 0x20012dc4 0xe ..\obj\main.o

[Сергей Борщ]

Подскажите почему так?

75 * 1024 = 76800 = 0x12C00

[maxntf]

Блин сам и напоролся. Смотрел конфиг из чужого проекта, там было #define configTOTAL_HEAP_SIZE ( ( size_t ) ( 17 * 1024 ) ). А то что у меня 75 стоит и не обратил внимания!


Сообщение отредактировал maxntf - Apr 12 2016, 15:43

[zltigo]

Смотрел в map файле я так понимаю что все жрет heap_2.c

Вообще в идеале heap должен занимать ВООБЩЕ ВСЮ свободную память. Посему любые константные дефиниции его размера в корне порочны. Следует слегка постараться и отдавать хипу всю память от конца статически распределенной компилятором до конца памяти контроллера.

[AVI-crak]

Следует слегка постараться и отдавать хипу всю память от конца статически распределенной компилятором до конца памяти контроллера.

Интересно, каким способом???
Я например точно знаю что GCC не умеет считать размер стека прерываний в режиме перепроцессора. Уже потом в отладке, фоновым процессом самого отладчика контролируется нижняя граница, и только в одном режиме ядра - для ос это уже недоступно. Копал долго и упорно, но возможно что-то упустил.

Для себя эту проблему решил простым способом: heap условно растёт в верх, на встречу стеку. Условно, потому-что свой heap, для gcc он нулевой, используется только точка старта. При заполнении всей памяти - новые задачи и новый маллок морозится, пока жирность не спадёт. Очень удобно однако.

[zltigo]

Интересно, каким способом???

Как и любое выделение памяти.

Я например точно знаю что GCC не умеет считать размер стека прерываний в режиме перепроцессора. Уже потом в отладке, фоновым процессом самого отладчика контролируется нижняя граница, и только в одном режиме ядра - для ос это уже недоступно. Копал долго и упорно, но возможно что-то упустил.

Подумате головой и выделите именно стеку фиксированный размер памяти. Отдавать стеку ВСЕ свободное пространство, причем НИКАК его размер не контролировать в надежде, что хватит, это безумие.

Для себя эту проблему решил простым способом: heap условно растёт в верх, на встречу стеку.

Навстречу чему, это уже зависит только от Вас, поскольку где Вы расположите стеки(и) там они они и будут.
У меня системные стеки внизу.

Условно, потому-что свой heap, для gcc он нулевой, используется только точка старта.

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

CODE

define symbol Code_start = 0x00000000;

// Memory Regions -----------------------------------------------------------
// 256K ROM memory
define symbol ROM_start = 0x00000000;
define symbol ROM_end = 0x00007FFF;
// 16K RAM memory
define symbol RAM_start = 0x40000000;
define symbol RAM_end = 0x40001FFF;

// Memory Block Sizes
define symbol SIZE_CSTACK = 0x20; // Dummy System/User Stack Size (Not Used!)
define symbol SIZE_SVCSTACK = 0x180; // Supervisor Mode (Main Work Mode)
define symbol SIZE_IRQSTACK = 0x200;
define symbol SIZE_FIQSTACK = 0x40; //
define symbol SIZE_XXXSTACK = 0x20; // 32bytes Shared Stack for Abort/Undefined Instruction and IAP Buffer
define symbol SIZE_HEAP_RTOS = 0x400; // 1Kb - Dummy _minimal_ space for Memory Manager

define memory mem with size = 4G;
define region ROM = mem:[from ROM_start to ROM_end];
define region RAM = mem:[from RAM_start to RAM_end - SIZE_XXXSTACK];
define region RAM_endblock = mem:[from RAM_end - SIZE_XXXSTACK + 1 to RAM_end];

define block CSTACK with alignment=8, size = SIZE_CSTACK { };
define block SVC_STACK with alignment=8, size = SIZE_SVCSTACK { };
define block IRQ_STACK with alignment=8, size = SIZE_IRQSTACK { };
define block FIQ_STACK with alignment=8, size = SIZE_FIQSTACK { };
define block HEAP_RTOS with alignment=8, size = SIZE_HEAP_RTOS { };
define block XXX_BLOCK with alignment=8, size = SIZE_XXXSTACK { };
define block CHECKSUM { readonly section .checksum };

initialize by copy { readwrite };
do not initialize { section .noinit };

place in ROM { readonly section .intvec };
place in ROM { readonly };
place in ROM { block CHECKSUM };

place in RAM { readwrite,
block CSTACK, block SVC_STACK, block IRQ_STACK, block FIQ_STACK };
place in RAM { block HEAP_RTOS };

place in RAM_endblock {
block XXX_BLOCK };

Сообщение отредактировал IgorKossak - Apr 12 2016, 20:01

Причина редактирования: [codebox] для длинного кода, [code] - для короткого!!!

[AVI-crak]

Как и любое выделение памяти.

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

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

Хотя я надеялся увидеть хитрую трёхэтажную запись мнемониками перепроцесора самого GCC.

[zltigo]

Ну я и вижу как вы мучаетесь, в ручном режиме считая байты.

Это Вы маятесь дурью НЕ задавая размера стека в безосновательной надежде, на то, что он не наедет на кучу.

Хотя я надеялся увидеть хитрую трёхэтажную запись мнемониками перепроцесора самого GCC.

Надежды на чудесные, но нереальные решения и прочие авось, не к лицу инженерам. Размеры стеков придется придется оценивать, указывать и контролировать.

[AVI-crak]

Это Вы маятесь дурью НЕ задавая размера стека в безосновательной надежде, на то, что он не наедет на кучу.

Желаю вам научится читать чужие сообщения.

[zltigo]

Желаю вам научится читать чужие сообщения.

Именно по тому, что не только читал, но и ПОНЯЛ, и написал, что Ваш "метод" не решает ничего. И в примере своем не просто так ARM7 привел с его множеством стеков (то же самое и старшие кортексы) при котрых Ваша идея, что размер стека сам собой устаканитися и думать о его размере не надо, вообще не пригодна в принципе. Собственно все у Вас работает только по причине что У Вас пока явный избыток памяти всегда.

[jcxz]

Вообще в идеале heap должен занимать ВООБЩЕ ВСЮ свободную память. Посему любые константные дефиниции его размера в корне порочны. Следует слегка постараться и отдавать хипу всю память от конца статически распределенной компилятором до конца памяти контроллера.

ЗАЧЕМ??? ...если куча не нужна и не используется нигде в проекте.
Во всех моих проектах размер кучи задан ==0 в конфигурационном файле компоновщика.
У меня везде так (для IAR):

Код

define block CSTACK with alignment = 8, size = 0x000 {};
define block HEAP   with alignment = 8, size = 0x000 {};

А далее:

Код

do not initialize  {section .bssStk};
do not initialize  {section .bssStkMain};
...
place in RAM_regionA {section .BITBAND_RAM, section .dma, section .ethernet};
place in RAM_regionA {rw, first block CSTACK, section .bssMemNoFill, block HEAP};

Стеки задач, основной стек (который указан в reset-векторе) и стек исключений определены подобно:

Код

#pragma data_alignment = 8
__no_init static OS_STK taskADEStk[64 + STK_SIZE_ISR_NFP] @ ".bssStk";

Иногда я объединяю все стеки (задач, основной стек и стек исключений) в единый сплошной блок через define block.
Имхо: определять размеры стеков в си-шных файлах гораздо удобнее, чем в едином конфигурационном файле компоновщика.

PS: Контролировать размер стеков конечно нужно. И выделять под них память, а не надеяться что "что-то не налезет на что-то".

[zltigo]

ЗАЧЕМ??? ...если куча не нужна и не используется нигде в проекте.

Ну вообще-то, совершенно очевидно, речь идет о случае, когда куча используется.

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

Чем? Есть одно место, где описаны все размеры блоков памяти конкретного проекта. Заходишь и смотришь, а не надо ползать искать. Когда пишутся, например, всякие демки на 999 вариантов, тогда в них приходится выносить и размазывать настройки по файлам и ключам. Но для конкретного проекта зачем?

[ViKo]

Как можно контролировать стек (не задач в RTOS), который растет себе и растет, пока не налезет на кучу или переменные??

[zltigo]

Как можно контролировать стек (не задач в RTOS), который растет себе и растет, пока не налезет на кучу или переменные??

Также, как и "задач в RTOS". Какие проблемы? Те стеки тоже "растут себе и растут"... С контролем НЕ в реальном массштабе времени проблем нет. Но вот именно отсутствие контроля в реальном времени как раз и не позволяет на ходу разруливать ситуации со стеком и следовательно по любому под стек нужно выделять гарантированно достаточное место. Потом уже постфактум по результатам контроля, если надо, думать уменьшить его или нет.

[jcxz]

Чем? Есть одно место, где описаны все размеры блоков памяти конкретного проекта. Заходишь и смотришь, а не надо ползать искать. Когда пишутся, например, всякие демки на 999 вариантов, тогда в них приходится выносить и размазывать настройки по файлам и ключам. Но для конкретного проекта зачем?

Есть задача, у неё свой стек. Все переменные, дефайны этой задачи - в её файлах. Проект состоит из множества таких задач. Естественно что данные, нужные локально только данной задаче, должны быть локальны (описаны именно в её файлах, а не вкаком-то едином файле). А стек - это локальная сущность конкретной задачи. И размер его скорее зависит от данной задачи, а не от проекта в целом.
Или Вы и локальные переменные каждой задачи тоже в едином файле определяете?

[zltigo]

Есть задача, у неё свой стек.

Не передергивайте! Речь идет о статически распределяемой памяти.
Но, если-бы я с какого-то бодуна выделял стеки задачам статически, то, да и эти БЛОКИ памяти я бы ТОЖЕ описал под линкер, что-бы видеть общую картину в одном месте и сразу при проектировании, а не тогда, кода линкер выругается при линковке что памяти совсем нет. После чего придется ползать по куче файлов и думать где жертвовать.

А стек - это локальная сущность конкретной задачи.

Содержимое стека - несомненно. Но сам стек, как блок памяти, это уже элемент ВЕРХНЕГО, надзадачного уровня. Вот и его выделением и размещением занимается НЕ задача.

Или Вы и локальные переменные каждой задачи тоже в едином файле определяете?

К чему эта дурацкая фраза и усмешка?

[jcxz]

Также, как и "задач в RTOS". Какие проблемы? Те стеки тоже "растут себе и растут"... С контролем НЕ в реальном массштабе времени проблем нет. Но вот именно отсутствие контроля в реальном времени как раз и не позволяет на ходу разруливать ситуации со стеком и следовательно по любому под стек нужно выделять гарантированно достаточное место. Потом уже постфактум по результатам контроля, если надо, думать уменьшить его или нет.

В принципе - можно и в реальном. И даже под многозадачную ОС.
С MMU конечно вообще проблем нет такое сделать. Но даже с MPU это возможно. Я уже не раз задумывался чтобы внести такую функциональность в свои проекты, всё руки не доходят.
Как:
Вынести все стеки задач в единый сплошной сегмент памяти. Закрыть полностью доступ к этому сегменту через MPU. В ISR PendSV при каждом переключении пользовательского контекста, программировать перекрывающую запись таблицы MPU (более приоритетную чем та запись, которая закрывает доступ ко всему сегменту стека) на новый стек (находящийся внутри общего сегмента стека).
Конечно будут потери памяти на выравнивании, необходимом для MPU. Но сделать вроде можно.
Да - в начале и в конце сегмента стека должны быть небольшие интервалы неиспользуемой памяти.
Конечно, если функция внутри задачи написана так, что выделяет размер массива выходящий за границу сегмента стека, то тогда такая защита может не спасти. Но чаще всего доступ к стеку идёт более-менее последовательно, небольшими шагами.

Если-бы я с какого-то бодуна выделял стеки задачам статически, то, да и эти БЛОКИ памяти я бы ТОЖЕ описал для линкера.

А с какого бодуна Вы выделяете стеки задачам динамически? И зачем такое делать? Задачи создавать/убивать? Это лишнее.

[zltigo]

А с какого бодуна Вы выделяете стеки задачам динамически? И зачем такое делать? Задачи создавать/убивать? Это лишнее.

Без комментариев, ибо рожденный ползать понять "лишнего" не может

[jcxz]

Вот и его выделением и размещением занимается НЕ задача.

Размещением стека, как и любой другой статической переменной у меня занимается компоновщик. Не вижу ни малейшего смысла выделять стек динамически.
Какая разница кто размещает?
Есть разница где эта переменая описана. А описана она должна быть там же, где и прочие локальные переменные задачи.

Без комментариев, ибо рожденный ползать понять "лишнего" не может

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

[KnightIgor]

PS: Контролировать размер стеков конечно нужно. И выделять под них память, а не надеяться что "что-то не налезет на что-то".

Если опустить RTOSы и MMU/MPU.- а такие системы с супер циклом просты и весьма популярны, - то контроль стека организовать затратно, и риск проехать катком стека по переменным есть. Это неизбежно.
На мой взгляд, в системе со стеком И кучей следует именну кучу выделять фиксированного размера, а стек - сколько есть памяти. Почему? Оценить потребность в стеке гораздо сложнее, чем в куче: прерывания, рекурсии, сложно-предсказуемые глубины вызовов... А вот работа с кучей более детерминирована и подконтрольна. Например, в тех немногих местах, где она используется, легко проверить полученный от malloc указатель на NULL и ругнуться, если что не так... Стек же я инициализирую на самый верхний адрес доступной RAM памяти. Как это в .COM программах в DOS делалось (я стар, о я очень стар, я - суперстар!).

[jcxz]

Например, в тех немногих местах, где она используется, легко проверить полученный от malloc указатель на NULL и ругнуться, если что не так...

Если есть куда ругнуться. А если ни LCD ни UART с терминалом? Да и вообще - ближайший человек за тыщу км

[zltigo]

И не убивать их когда работа закончена и создавать заново, а просто....

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

Если есть куда ругнуться. А если ни LCD ни UART с терминалом? Да и вообще - ближайший человек за тыщу км

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

[MrYuran]

Если есть куда ругнуться. А если ни LCD ни UART с терминалом? Да и вообще - ближайший человек за тыщу км

Тогда можно ругнуться в себя.

[zltigo]

Стек же я инициализирую на самый верхний адрес доступной RAM памяти. Как это в .COM программах в DOS делалось (я стар, о я очень стар, я - суперстар!).

Я едва-ли Вас моложе, но так уже не делаю , тем более, что не у x86 этих самых стеков чаще всего не один

[maxntf]

Подскажите во время отладки в CoIDE где можно узнать адреса по которым расположены переменные?