jcxz

Из чего вы сделали такой вывод? Что же там по вашему в LR??? Каким образом интересно вы вычислили время выполнения и размер функции??? И причём это тут вообще? И что? С чего вы решили что до перехода там содержался адрес возврата??? PS: Блин - вместо того чтобы тут нести чушь, почитайте лучше описание системы команд! Большего количества чуши в одном сообщении трудно найти....

Функции как вызываются? Правильно: обычно через BL. BL что делает с LR?

Адрес возврата в LR внутри функции хранится только если в функции нет вложенных вызовов других функций. Подумайте почему. Как работает инструкция BL я прекрасно знаю. Но не она возвращает управление из функции some_func. Управление возвращается обычно или BX LR или чем-то вроде POP {...,PC} (если в той функции было сохранение LR на стеке (были вложенные вызовы других функций)). Во втором случае в LR будет не то что вы ожидаете. То что вы этого не встречали, говорит о том, что вы никогда не заглядывали в листинги компилятора. После того как LR был сохранён на стеке, содержимое LR больше не нужно и при необходимости может использоваться для временных переменных компилятором. Если угодно, вот пример из моего проекта (IAR6.50): static void KeyboardScan() { _Z12KeyboardScanv: 0xE92D 0x41F0 PUSH {R4-R8,LR} static u8 m[ncell(kbdKeyPins)] = {0, 0 Depend3Keys(, 0)}; static u16 tLight; int c = 0, c1, n = ncell(kbdKeyPins) - 1; 0x.... 0x.... LDR.W R2,??DataTable28_5 0x.... 0x.... ADR.W R4,kbdKeyPins+0x4 0x.... 0x.... LDR.W R6,??DataTable28_1 0x.... 0x.... LDR.W R7,??DataTable28_4 0x2000 MOVS R0,#+0 0x2102 MOVS R1,#+2 0xF202 0x0306 ADDW R3,R2,#+6 0xF44F 0x5500 MOV R5,#+8192 do { if (Pdat2(kbdKeyPins[n].port, kbdKeyPins[n].pin)) { ??KeyboardScan_0: 0xF894 0xE000 LDRB LR,[R4, #+0] 0xF893 0xC000 LDRB R12,[R3, #+0] 0xEB07 0x1E4E ADD LR,R7,LR, LSL #+5 0xF8DE 0xE014 LDR LR,[LR, #+20] 0xF894 0x8001 LDRB R8,[R4, #+1] 0xFA2E 0xFE08 LSR LR,LR,R8 0xEA5F 0x7ECE LSLS LR,LR,#+31 0xD50D BPL.N ??KeyboardScan_1 Разговор не о LR в CPU, а о LR из фрейма, сохранённом на стеке при стекинге перед входом в ISR.

Почему Вы решили, что в LR - адрес возврата из функции, в которой произошло исключение? Имхо - там может быть что угодно. Пример: PUSH {...,LR} ;стандартный вход в функцию, вызывающую другие функции ... BL some_func С этого места в LR - может быть, что угодно, может адрес этой инструкции, а может и что-то другое если возврат из some_func осуществлялся чем-то вроде POP {..., PC}, а не BX LR. А ещё - оптимизатор может использовать LR как обычный РОН. После улёта исполнения кода в произвольное место в ОЗУ, определить можно только адрес (PC), где произошло исключение. Об остальном - только гадать. Когда я боролся с подобной проблемой, я сделал монитор регистров CPU, повесил его на высокочастотное IRQ от таймера (такое чтобы давало >90% загрузки CPU). В ISR просто писал дамп регистров CPU (и ближайшего стека) в FIFO таких дампов в ОЗУ. При наступлении сбоя - смотрел последовательность этих дампов и определял где было последнее валидное состояние. Расстояние между такими дампами получалось всего несколько десятков команд - место сбоя ловилось довольно точно. Ну или нужен какой-то аппаратный трэйсер с запоминанием потока команд и возможностью отмотать назад.

Возникает подозрение что CaDILO и octobus - суть две ипостаси одной и той же сущности :rolleyes:

Во-во! меня тоже раздирает... А всё непонятное пугает потенциальных разработчиков. Автор-то сам как - дружит с программированием под винду хотя-бы?

Я думаю - можно. А как - изучать Вам :)

Можно явно указать сегмент для переменной: int q @ ".X_RAM"; Далее в командном файле линкёра объявить его инициализируемым или нет, по желанию.

Если в нём (LMX9838) есть какие-либо GPIO, доступные удалённо (как в WT12), или хотя-бы сигналы CTS/DSR, которыми можно удалённо рулить по BT, цепляете сдвиговый регистр на них, а параллельные выводы регистра - на ноги OP3,OP4,OP5.

Интересно - как вы это себе представляете? Ваш коммуникатор удалённо через BT меняет baudrate локального UART BT-модуля и ваш контроллер на плате, общающийся через данный UART с BT-модулем, теряет с ним связь. Он-то откуда узнает, что ему надо теперь поменять скорость UART???? Чушь полная. Через UART с модулем работает тока ваш МК на плате, он и должен рулить скоростью этого UART. Для того собственно и предназначены AT-команды установки baudrate UART в модуле.

Всё-таки решили отказаться от WT12? Если не секрет - почему?

Внутрь корпуса - геркон на размыкание контактов батарейки. И ложите на хранение в ящичек с мощным магнитом :)

Интересно вот почему это так: ембеддед - от 50, а под винду - от 80 ??? По-моему у работодателя, что-то в голове перекошено :) Писать под винду гораздо проще и гораздо больше народу умеет это делать, чем ембеддед.

Его ставят когда разработчики не умеют работать на голом железе и с ограниченными ресурсами. Прочие причины (всякие ЖК, сети и т.п.) - вторичны. Имхо B)

А ничего что в R15 - программный счётчик? Ну если без R14 ещё как-то можно вообразить выполнение программы (без вызовов функций ;), то без PC.... затрудняюсь... Или у вас тут AVR, а не ARM? Тогда - ФИ..... :)))

Надо-ж!... И Вы прям вот так вот запросто золочиваете R15??...

Таймауты у меня ставятся какие-то при открытии порта. Таймауты зависят от вашего протокола. Думаю дело в буферизации - внутри терминалок как-то криво видно сделано, то-ли приём завязан с отображением, то-ли какие-то статусы порта опрашивает, сказать сложно. У меня-же приём выполняется в отдельном потоке ОС (trhread) в большой буфер (16кБ) и без блокировок с основным trhread. Все опросы статусов порта в другом потоке, тоже не основном потоке приложения.

Компилятор не узнаёт, узнаёт линкер. Компилятор при создании obj-файлов к ним цеплят таблицы экспорта/импорта для внешних ссылок. А линкёр потом, используя эти таблицы, связывает модули и подставляет реальные адреса. Либо не реальные адреса, а например, может формировать таблицу перемещений, по которой потом загрузчик подставит реальные адреса. Но этот вариант не для выполнения проги из флеш CPU определённо.

Может и тут. Я когда тестировал терминалками, даже проверенными вроде и уважаемыми, были тормоза и скорости выше ~115200 не мог получить, хотя все настройки WT12 крутил. Потом написал свою, с приёмом через WinAPI и всё начало летать.

Без разницы. А скорость у вас какая по UART? Не 115200 случаем? :laughing: И чем на стороне PC принимаете?

Придумать :rolleyes: Это получается: таймер+DMA и ещё + 48 байт(слов?) в ОЗУ. ТС-у ведь нужен цифровой сигнал: 0, 1, 0, 1, .... как я понял. Не знаком с периферией STM32, но думаю проще сделать по-другому: SPI(master)+DMA. Если не понятно, поясню: Настраиваем SPI на битовую частоту 48*2 кГц. DMA настраиваем в flip-flop режиме (первый буфер - передача 6 раз байта 0x55, второй буфер - передача 6 раз байта 0 (или 0xFF по желанию)). Сигнал получаем с MOSI. Пересылок по шине в 8 раз меньше, а так как у ТС CPU и так загружен (>80%) то это важно. Если использовать 16-битный режим SPI, то можно ещё в 2 раза уменьшить кол-во пересылок. К тому-же - при связке таймер+DMA, так как состояние пина должно быть изменено в тот момент, когда таймер формирует событие, то любые задержки из-за загрузки шины будут также приводить к дрожанию фронтов сигнала. В связке-же SPI+DMA, в SPI имеется буферизация, поэтому такая связка гораздо устойчивее к загрузке шины. Всё

SPP в радиусе 2-3 метра: 50-60кБ/сек

Хм... Это что-ж за вызовы такие?? Если задача без ОС и нужно контролировать только один стек, то можно стек расположить в самых младших доступных адресах ОЗУ и обработчик Bus Faults настропалить на точную или неточную ошибку доступа к памяти. А если в вашем ARM-е имеется MPU, то очевидно можно и его для этого задействовать. Непонятно только какой именно ARM имеется в виду....

Возможно проблемы из-за того, что JLink-и разных версий. Попробуйте обновить их прошивки до последней. Я уж давно так работаю с 2-мя JLink параллельно (подключаясь отладчиком то к одному то к другому не перетыкая кабелей) - под IAR нет проблем. Но у меня оба 8-е.

Ядро стоит правильное (Cortex-M3), я это первым делом проверил. Я это знаю. THUMB было пропущено по недогляду при редактировании. Но весь вопрос в том - почему IAR это съел без всяких претензий и накомпилил чушь??? Причём в lst-файле на этом месте указано: BL <метка> :smile3046: