У 407VE две области оперативки: IRAM1 0x20000000 длиной 0x20000 (128К) и IRAM2 0x10000000 длиной 0x10000 (64К).
Вопрос 1. Они же равнозначны, кроме размера? Скорость доступа к ним одинакова, 1 такт, да?
Вопрос 2. Кейл дефолтно ставит галочку на IRAM1. Если я ее сниму и поставлю поставлю на IRAM2, все облпсти (статическая часть, куча и стек) лягут в нее, это понятно. А вот правильно ли я понимаю, что IRAM1 при этом я смогу распределить самостоятельно, указав начало константой 0x2000000 и далее вычисляя адреса нужных мне областей и заполняя соответствующие указатели?

1) IRAM2 висит только на D-bus ядра и к ней нет доступа от остальных мастеров (DMA например)
2) Лучше определить секции в линкере и указывать их переменным (что-то типо http://www.keil.com/support/man/docs/ar ... 000009.htm)

Afz, смотри AN4296. Там для F3, на нем еще можно из CCM код запускать, в остальном то же самое.

PCBWay - всего $5 за 10 печатных плат, первый заказ для новых клиентов БЕСПЛАТЕН

Сборка печатных плат от $30 + БЕСПЛАТНАЯ доставка по всему миру + трафарет

Онлайн просмотровщик Gerber-файлов от PCBWay + Услуги 3D печати

Так и из 0x20000000 можно запускать код. А из каких областей нельзя его запускать?
По-крайней мере на F429....

Добавлено after 2 minutes 20 seconds:

А зачем так делать? Зачем забирать работу у компоновщика???

Выбираем схему BMS для заряда литий-железофосфатных (LiFePO4) аккумуляторов

Обязательным условием долгой и стабильной работы Li-FePO4-аккумуляторов, в том числе и производства EVE Energy, является применение специализированных BMS-микросхем. Литий-железофосфатные АКБ отличаются такими характеристиками, как высокая многократность циклов заряда-разряда, безопасность, возможность быстрой зарядки, устойчивость к буферному режиму работы и приемлемая стоимость. Но для этих АКБ очень важен контроль процесса заряда и разряда для избегания воздействия внешнего зарядного напряжения после достижения 100% заряда. Инженеры КОМПЭЛ подготовили список таких решений от разных производителей.

Подробнее>>

Нельзя запускать код из CCM RAM(0x10000000), в том числе и на F429. Можно на более новых F3 и G4.

Новый аккумулятор EVE серии PLM для GSM-трекеров, работающих в жёстких условиях (до -40°С)

Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре. Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.

Подробнее>>

Это я неспешно размышляю на тему дискового кэша. Вернее, кэша для микро-SD. Там нужно будет неопределенное количество памяти, которой надо будет рулить динамически. Альтернативой, как я понимаю, будет куча, но, ИМХО, лучше уж я сам все распланирую, чем полагаться на run-time систему, исполняющую действия с кучей. Еще что-нибудь недопойму в ней, и появится какая-нибудь ерунда типа утечки памяти.

Собственно, я раньше так и делал - брал в куче максимальный объем, оставив на всякое-разное чуть больше необходимого минимума, а потом в этом взятом куске распоряжался собственными средствами. Ну, а тут оно сразу физически разделено, две области, одна 128К, вторая 64К. Вторую отдать стандартным средствам Си, а первую занять под собственные нужды, имея твёрдую уверенность, что никто, кроме моих средств туда не залезет - ни стек не наедет, ни возможные ошибки.

Это, как раз, меня пока не беспокоит - я не пользуюсь ДМА. Впрочем, спасибо, учту.

Тут другой вопрос возник. Истолкуйте мне, плз, пункт 2.1.2 документа RM0090 (стр. 62). Как истолковать "This bus is used by the core for literal load and debug access." ? Это что, запись данных по D-bus невозможна, только чтение?

Зачем эти кучи или вообще динамически распределять? Какой толк?
Просто выделить статически массив и в нём сделать кеш. Так будет и проще и экономнее по памяти.

Подскажите по usart в stm32f4 когда данные из Transmit dataregister (TDR) попадут в в Transmit Shift Register ?

В общем я хотел в прерывании по TC сначала закинуть 1 байт в регистр DR и тут же настроить DMA на передачу массива.
И от этого ожидал сначала передачу 1 байта, так как думал что Transmit Shift Register уже занят, а потом запуск DMA по событию TXE.
Но такой финт не заработал(сразу выдается массив через DMA), возможно из за того что данные из Transmit dataregister попадают в Transmit Shift Register после КЛОК usart (в от скорости передачи?) и DMA просто перезаписало первый байт который я туда закинул.

Я конечно сделаю это нормально сначала передам 1 байт и в прерывании по завершению его вызову DMA. Но все же интересно почему такой финт не сработал.

PS: Запихать этот 1 байт в массив сложно да и он всего 0, по этому решил сделать так.

Попадёт он тогда, когда TXE выставится. Через сколько конкретно тактов: раз это не оговорено даташитом - значит поведение не гарантируется. Возможно, что копирование в сдвиговый регистр производится в момент завершения передачи стартового бита. Как версия. Но закладываться на это не надо, даже если и так в данном конкретном чипе. Потому что выйдет новая ревизия - и может измениться.


Не обязательно. Можно использовать DMA с двойным буфером: в первый как раз и положить этот байт. Тогда прерывания не нужно.

Добрый день, забираю данные у АЦП с помощью DMA, все работает правильно. Если начинаю забирать данные по прерыванию значение которое измеряет АЦП уменьшается на 200 отсчетов. ПОдскажите пожалуйста возможные причины такого поведения?

Вангую, что меряете через АЦП напряжение питания МК. С появлением высокочастотных прерываний от АЦП загрузка CPU увеличивается => увеличивается потребление МК => проседает питание.
Но скорее всего - что-то с синхронизацией работы АЦП и забора данных с него. Заочно поставить диагноз вряд-ли возможно.

Думаю Вы правы, надо проверить!!! Спасибо!!!

200 это очень много (если идет речь о 12-ти битном АЦП).

Лично я бы смотрел в сторону аналоговой части. Например если подключить если поставить делитель из пары резисторов по 10 КОм (и не поставить конденчсатора) то легко может быть такая разница в зависимости от частоты работы ADC.

Проверил с питанием все ок!!!



Судя по тому, что с питанием все хорошо факт на лицо.

возможно, глупость спрошу, да и не специалист, но
по факту разрядность забираемых данных одинаковая?
и как изменится ошибка, если скажем уменьшить в 2 раза потенциал источника?

Частота сэмплирования одинаковая? У СТМ32 входное сопротивление АЦП падает с повышением частоты.

Тоже есть вопрос по ADC / DMA. Пока не могу понять, в чём дело.

Речь о проекте анализатора спектра. Используется два канала АЦП в режиме "MultiChannel single conversion".

Суть следующая. Раз в 50 мкс (или с частотой 20 кГц) от таймера приходит прерывание. В этом прерывании "дёргается" АЦП. Сначала АЦП снимает данные с левого канала, затем с правого, и на этом всё заканчивается, вплоть до следующего запроса от таймера через 50 мкс.

Данные, которые получает АЦП (два 16-битных числа), кладутся в "длинный" DMA буфер. Таким образом, через некоторое время в этом буфере появляются снятые с двух каналов значения (L-R-L-R-L...-L-R). Дальше уже эти данные подвергаются анализу Фурье, выводятся на экран и всё такое. Но это пока не важно.

На STM32F103CB всё работает отлично. В качестве входов АЦП выбраны PA0 и PA1, которые в этом случае являются простыми каналами АЦП 0 и 1.

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

А проблема в том, что данные с PA0 (левый канал) аккуратно ложатся в "свои" ячейки в DMA буфере. То есть, например, если подать синусоиду в левый канал, а в правом оставить тишину, то в DMA буфере будет что-то типа:
То есть, данные в "левых" ячейках постоянно меняются, а данные в "правых" равны половине разрешения АЦП (половина питания).

Но вот если на левый канал ничего не подавать, а синусоиду завести в правый канал, то в DMA буфере получается уже другая картина:
. То есть, левый канал не "стоит" в половине питания 2048, а меняется в противофазе с правым. Так, что их сумма почти одинакова всё время.

То есть, данные со входа PA0 попадают в канал ADC_channel 1 правильно.
А вот данные со входа PA1 попадаются не только в ADC_channel 2, но, почему-то, и в ADC_channel1, но "в противофазе".

Такое ощущение, что где-то не отключена "дифференциальность" для входа PA2. Но не могу понять точно.

Код с инициализацие АЦП, если кто хочет взглянуть: https://github.com/WiseLord/ampcontrol- ... trum.c#L90 Там же чуть выше настройка DMA.

P.S. Так... вопрос, похоже, снимается. Похоже, в библиотеке LL функция LL_ADC_SetChannelSingleDiff имеет баг, из-за которого какой бы режим канала ни устанавливался (single_ended или differential), он всегда устанавливается в differential. Канал 1 работает нормально (так как у него "пары" нет), а вот канал 2 работает не относительно земли, а относительно канала 1.



Вот упоминание о баге с ответом недельной давности, что пофиксят в будущих версиях LL.

P.P.S. Для справки, обошёлся обычным CMSIS-овским

WiseLord, а зачем дергать АЦП в прерывании ? Таймеры умеют аппаратно запускать преобразование. Можно также настроить одновременное измерение двух каналов.

Да, я знаю. Пока сделал как попроще (через прерывание), но потом, когда буду "вылизывать" код, посмотрю на предмет срабатывания по триггеру от таймера. Правда, не уверен, что конкретно от этого таймера можно дёрнуть АЦП, но, если и нет, можно посмотреть на другие таймеры.

А вот по поводу одновременности - это как? ADC1 и ADC2 запускать параллельно?

Просто сейчас это работает как-то так:

То есть, в прерывании таймера не делается ничего длительного. Он просто запускает быструю серию измерений, и они идут "в фоне" - через DMA. При необходимости в серию легко добавить и другие каналы АЦП.

Параллельная работа двух АЦП особых преимуществ не даст. Или что-то другое имеется в виду?

Да, параллельный запуск подразумевался.