jcxz

Зачем? Чем не устраивает обычный SOF (start-of-frame) событие, которое приходит с частотой 1 или 8 кГц без всяких доп. усилий?

Имеем CGTOOLS v4.6.6 for TMS470. В lst-файлах пишутся имена регистров типа A1, A2,..., V1, V2,... А хотелось-бы видеть обычные имена регистров: R0, R1, ... . куда копать? Кто знает?

Я тоже пробовал (и на 1768 и на 1758), тоже не удалось запустить в 16бит. Пробовал делать перепаковку с помощью разных ширин источника и приёмника (DMACCxControl::SWidth/...DWidth) - тоже не получилось. В результате забил - сделал 8-битную пересылку. PS: Если найдёте решение - стукните мне тоже, пожалуйста

А зачем? Если для ускорения, то гораздо лучше использовать DMA+SSP

Да ужж.... Однако - сколько таких грабель в STM32!... И за что его местный народ так любит? не пойму...

Может просто - по-старинке - переписать критичные места на асме? :)

Макросы - да, классы - нет.

1.Для ядер поддерживающих невыровненный доступ (Cortex-Mx, x86, ...) эти макросы расширяются в обыкновенную операцию чтения/записи соответствующей разрядности. 2.Для ядер не поддерживающих невыровненный доступ (ARM7/9) эти макросы расширяются в набор байтовых операций чтения/записи с последующим объединением в единый результат OR-ами. То же самое делает компилятор для членов u16/u32 внутри #pragma pack(push, 1)...#pragma pack(pop) неявно.

Другой способ я описывал буквально на днях здесь: http://electronix.ru/forum/index.php?showt...15&start=15 Но это имеет смысл только если код надо переносить между разными компиляторами.

Лучше: #pragma pack(push, 1) #pragma pack(pop) Но только это к сожалению не во всех компиляторах работает.

Можно и методы сделать одинаковыми для C++. Я делаю так: struct u16p8 { u8 bytes[2]; operator u16() const { return u16load(&bytes); } u16p8 & operator =(u32 val) { u16save(&bytes, val); return *this; } }; struct u32p8 { u8 bytes[4]; operator u32() const { return u32load(&bytes); } u32p8 & operator =(u32 val) { u32save(&bytes, val); return *this; } }; где: u16load(), u16save(), u32load(), u32save() - макросы, определённые по-разному в соответствии с платформой. Если для Cortex-M3 и x86 к примеру u16load() будет: #define u16load(p) (*(u16 *)p) то для ARM7/9: #define u16load(p) (*(u8 *)(p) | (u16)((u8 *)(p))[1] << 8) Таким образом я совершенно свободно перетаскиваю структуры, описывающие пакованные структуры, между разными платформами. Это очень полезно когда пишешь firmware и тут же пишешь клиентское ПО на PC (для этого устройства) и надо описать протокол взаимодействия - это можно делать в одном файле просто копируя его между двумя проектами.

...а коллективный разум, в лице форума, справился за 2 дня... ;)

ну, если это действительно утечки в стеке, то нужно менять его. Если менять по каким-то причинам не хочется, то остается только ставить костыли. Как-то: значительно увеличить блок памяти для кучи стека (раз у него отдельная куча), это уменьшит частоту сбоев; и переписать функцию аллокатора на свою (в которой сделать контроль оставшейся доступной памяти, с перезагрузкой системы при снижении этой величины ниже некоторого порога).

У Вас есть внешняя память? А если просто попробовать тупо увеличить размер кучи? Проблема пропадет или станет реже проявляться? Возможно у вас проблемы с фрагментацией кучи. В обработчике ошибки mem_alloc можно попробовать вывести карту использования блоков кучи

Написал в личку

И на прием - никакой проблемы. У вас скорость - фиксированная и формат по UART - тоже, это упрощает задачу. Вопрос только - хватит-ли общего быстродействия проца? Заводите DMA с группы ног и спокойно потом разбираете в фоне пришедший блок. Оверсэмплинг можно поставить поменьше - 8 например. Для работы быстрых прерываний в обработчике прерываний DMA разрешаете сразу же на входе прерывания (для быстрых прерываний надо поставить наивысший приоритет). Если все напишите оптимально то по-моему хорошие шансы что хватит 1го процессора, возможно даже М3. А с 2-мя у вас меньше шансов уложиться по потреблению. Непонятно только - зачем 200кбод при таком малом траффике. если у вас 2 байта в неск. мсек, то лучше снизьте скорость раз в 10-100 и будет легче и потребление меньше.

Может вы просто неправильно выбрали процессор? Ставить для этого 2 процессора - по-моему избыточно. Если процессор не загружен на 100%, то может проще сделать программную эмуляцию UARTов? Если загружен - взять более мощный и сделать программную эмуляцию на нем. ;)

...или возьмите процессор с ядром ARM7/9 - там есть переключение контекста (на один из теневых наборов регистров) и можно ничего не сохранять (особенно для FIQ) :laugh: В LR грузится не старый PC, а спец. значение (ссылка на вектор прерывания). Адрес возврата сохраняется на стеке как вам уже сказали.

Между разрядностью полинома и разрядностью данных нет никакой связи.

Т.е. - при старте по включению, он проверяет наличие валидной прошивки во флеш выше себя и передаёт управление на неё автоматом? Тогда это подойдёт. Уже и забыл когда последний раз имел дело с 8-битниками.. ;) Речь идёт о замене хорошо знакомых LPC17x, на что-то более экономичное.

Спасибо за оперативный отзыв. Какие могли-бы порекомендовать отладочные платы и где купить? I2C - скорей всего не будет в данном проекте, будут SPI и UART точно, и будет использован DMA. Что-то слышал что DMA там кривоват, это правда? Загрузчик по UART позволяет прошивать флеш или только в ОЗУ грузит? То, что энергопотребляющие режимы очень популярны в еррата - это настораживает. Рассматриваю EFM32 как альтернативу LPC1758. Сейчас проект скорей всего будет делаться на LPC1758 как хорошо освоенном и соответственно - быстром в разработке. Но потом возможна миграция на EFM. В EFM32 (EFM32GG232) привлекают два плюса по сравнению с LPC1758: более низкое потребление (даже без режимов сна) и ОЗУ=128кБ.

Для нового проекта присматриваюсь к семейству EFM32. Но какой-то он малопопулярный. Использовал кто EFM32 в своих разработках? Если да - поделитесь своими впечатлениями? Как он вам? Какие были трудности, какие подводные камни? В первую очередь будет интересовать: низкое потребление, SPI, UART, DMA (должно работать в sleep с SPI и UART).

...и теперь (если они всё-таки не исправились и опять накосячат) виноваты перед начальством будете Вы в их косяках :smile3009:

Это что-то мало у вас... У меня в каком-то режиме до полукилобайта занимал. Как она может быть побайтовой (или вообще привязанной к адресам) если там нигде адрес не указывается? Если логически подумать, то там скорее всего определяется факт срабатывания прерывания внутри секции эксклюзивного доступа (по LDREX взводится флаг в CPU, который сбрасывается если возникло прерывание, а потом он проверяется STREX). Когда у меня была аналогичная проблема с расходованием стека в RTOS sprintf-ом, я просто сделал переключение стека, на стек для sprintf (с семафором ессно).

Неправда. Сторожевик - очень полезная вещь. Всегда использую в своих разработках, причём внешний и неотключаемый и работающий ВСЕГДА. Баги в ПО есть всегда - это неизбежная реальность, даже у самых опытных программистов. Кроме того - наверное вы не сталкивались с испытаниями на помехоустойчивость. И помеха может вогнать проц в совершенно неожиданное состояние на самом прямом ПО. И тут поможет только сторожевик.