zhek

Довольно близкая для меня тема, вот только с андроидом не дружу пока.

Имею в серии несколько вариантов схем и программ ЗУ мощностью до 30 Вт, новые решения внедряю постоянно. Думаю, что не будет особых проблем модифицировать под вашу задачу. ЗУ универсальное - может заряжать LiIon, NiMh и VRLA аккумуляторы. Вывод графиков и логов в ПК.

Давно занимаюсь разработкой медицинской техники. Правда с ЭХВЧ работал только в обратном направлении - защищался от него в каналах ЭКГ, ЭЭГ, SpO2 и других :) Но думаю, что смогу быть полезен вам. Есть опыт разработки разнообразных аппаратных и программных решений.

Спасибо scifi за ответ, пока решил проблему извращённо: забрал последний сектор. Нездоровая ситуация - для хранения 40 байт резервировать 128 кБайт, зато всё работает ;) А flash и наполовину ещё не потрачена. Со временем попытаюсь забрать первый сектор, но чувствую, это будет сложнее.

Эх, если бы знать, где смотреть)

Может кто знает, никак не могу найти отгадку. Надо освободить нулевой сектор для записи данных, поэтому указываю линкеру, что flash начинается с первого сектора, соответственно меняю размер: в диалоге Target изначально было IROM1: 0x8000000 (start) и 0x100000 (size) делаю IROM1: 0x8004000 (start) и 0xFC000 (size) линкер вроде слушается, в map-е видно это, RESET находится по адресу 0x08004000, но после прошивки камень прыгает на адрес 0x8000000...

Поизучал оптимизацию. Косяк возникает только если выбрана High оптимизация по Speed или Balance независимо от выбора галочек. Сделал High по Size. Все вроде нормально стало. Общая производительность упала процентов на 5-6. Устраивает.

Похоже, косяк был связан все-таки не с компилятором. Обнаружилось, что размеры стеков были заданы не кратными 4. Из-за этого в прерываниях указатель стека тоже не был кратен 4. Если команда использовала указатель стека при адресации, 32-битные данные переписывались неправильно. Это сразу выявилось, когда локальные переменные в прерываниях стали типа int. Раньше использовались char и short. Разбираться, чтоб однозначно определиться с причиной, уже некогда. Т. к. в стеке может применяться выравнивание по 8 байт, теперь делаю размеры кратными 8 или 16. Но вот сегодня столкнулся с другой проблемой - уже в IAR 5.40 Делаем расчет КИХ-фильтра, т. е. считаем свертку буфера сигнала с массивом коэффициентов. Без оптимизации все работает. Делаю оптимизацию High, Speed. Убираю галочки Function inlining и Static clustering. Получаю глюк. Ошибку видно в ассемблерном коде. Исходники на С и ассемблерный код прикладываю. Суть ошибки в следующем. Буфер входного сигнала - кольцевой. Т. к. фильтр симметричный, умножений можно делать в два раза меньше. При расчете свертки движемся по буферу, используя два индекса, двигающихся в разных направлениях. Длина буфера 256 значений. На индексы надо накладывать маску 0xFF, чтобы "закольцеваться". Я для этого объявил индексы типом unsigned char. Имеем цикл на С for (i = 0; i < 128; i++) { x = f->buf[k1] + f->buf[k2]; sum += (long long)x*k2120v2; k1++; k2--; } И ассемблерный код // 66 x = f->buf[k1] + f->buf[k2]; // 67 sum += (long long)x*k2120v2; ??Lpf2120v2_1: LDR R5,[LR, #+8] ADD R6,R2,R3, LSL #+2 LDR R6,[R6, #+8] ADD R5,R6,R5 LDR R6,[R12], #+4 SMLAL R0,R1,R5,R6 // 68 k1++; k2--; SUB R3,R3,#+1 AND R3,R3,#0xFF // 69 } ADD LR,LR,#+4 SUBS R4,R4,#+1 BNE ??Lpf2120v2_1 в качестве переменной k2 используется R3 и с ним происходит все правильно k1 в коде нет, вместо этого применяется указатель, который лежит в LR, и вот он-то выходит за пределы буфера и мы имеем глюк Теперь надо пробовать новую версию IARа? Или сразу другой компилятор? У нас некоторые разработчики используют Keil. Кто-нибудь про него знает чего-нибудь плохого? filters_dbg.txt filters_dbg_h.txt filters_dbg.s.txt

Тяжело дается ассемблер, но вроде как BCS - переход, если больше или равно, т. е. цикл выполнится 1 раз. Иначе вообще бы ничего не работало :) Это соответствует исходному коду функции wbCalcDA short wbCalcDA(UBYTE beg, UBYTE end, UBYTE minus, ecgWAVE_BUILD *wseg) { UBYTE i; short da; for (i = beg, da = 0; i <= end; i++) da += wseg->segs[i].da; if (minus) da = -da; return da; } Думаю, что это и есть самая вероятная причина. Но, глядя на листинг обработчиков прерываний, ничего подозрительного не нахожу. Правда, смотрел только на использование R8. Все смотреть тяжеловато, проект очень болшьой, а я с ассемблером на "Вы". fiq в проекте не используется, вложенные прерывания - тоже IAR показывает, что стеков хватает с запасом. Проверял (считал сам и смотрел на содержимое ОЗУ) - не врет.

прикрепляю файлик, сменил расширение с .s на .txt, а то не позволяли прикрепить строка 6922 Только код работает, смотреть его, наверное, неинтересно. Исходник не менялся полтора года, прошивка столько же работает в серийных изделиях. Я три дня по этому коду хожу. При одних и тех же начальных условиях функция может работать по-разному. А тот фрагмент, который написан выше, вроде как однозначно определяет содержимое R8. ecg_sel.txt

Начал подглючивать девайс при работе. Долго искал причины, пока не убедился, что это косяк IAR ARM 5.30. Делал оптимизацию High по Speed. Были установлены все птички, кроме Static clustering. Окончательно убедился, что это не ошибка в коде, когда стал регулярно ловить такую ситуацию. Ассемблерный код: ... MOVNE R8,R8, LSL #+16 MOVNE R8,R8, ASR #+16 // 1740 if (a >= wbNOISE_PARTS)//фиксируем начало зубца CMP R8,#+12 ... Команды MOVNE выполняют преобразование типа short->long. После этих операций в старших 16 битах может быть только знак, т. е. нули или единицы. Когда я ходил по ассемблерному коду, поймать не удавалось. А если идти по С-шному, то после очередного шага я сразу попадаю на строку CMP и вижу чудеса: например, в R8 вместо числа 58, лежат нули в младших 16 битах и число 25 в старших. Посмотрел, как используется R8 в прерываниях, но криминала не обнаружил. Так и не выяснил, что же именно происходит. Но поскольку использованием регистров рулит компилятор, то видимо из-за него когда-то что-то происходит не так. После снятия галочки Function inlining в настройках оптимизатора все стало работать нормально.

Спасибо, я действительно делал не так, как написал)) Теперь все работает.

Господа, знает кто-нибудь, как заставить компилятор (IAR) использовать команду SMULL? Пример такой: long x, y; long long z; z = x*y;//генерится команда MUL, умножение делается в long, старшие 32 бита отбрасываются, потом дополняются до long long знаком, результат неправильный z=(long long)x*y;//генерится набор команд для выполнения 64-битного умножения, результат правильный, но вычисления занимают большое время А как бы использовать SMULL, тогда получим long*long = long long. И результат правильный, и время небольшое. Можно написать свою ассемблерную функцию, но в ней нужно будет сохранять регистры в стеке, а это опять потери времени. Компилятор мог бы это сделать лучше, т. к. переменные уже лежат в регистрах.

Главная проблема-то в том, что частота ШИМ требуется 72 кГц. Чтобы устанавливать и сбрасывать пин, нужно дергаться в прерывания 2 раза за период, т. е. каждые 7 мкс. Для АРМа это напряжно, да еще и считать нужно много, иначе зачем он. А при маленьких значениях коэффициента заполнения вообще не успеть перенастроить. А вот насчет того, что LPC2103 более новые - я этого не знал. Надо поглядеть в их сторону. Спасибо всем ответившим.

Спасибо за ссылочку. Но там применен LPC2103. Почитал даташиты. В LPC210x есть режимы PWM в таймерах и про это явно написано. А в последующих камнях этой возможности нет. Видимо, в этом и ответ на мой вопрос. Хочешь много ШИМов - применяй другие камни. Но все-таки паскудство. 100 ног - и всего один PWM.