jcxz

Так вроде всё правильно делается - инициализацией переменных занимается не загрузчик, а startup си-программы. А загрузчик только грузит все секции в RAM, а потом запускается startup, который не зависит от того, откуда грузится прога, поэтому сам ничего из флешки грузить не может. У меня была такая же проблема с нехваткой ОЗУ и я перепробовал все ключи компилятора и компоновщика и эти - оптимальные. Сэкономить место можете только Вы сами, например - можно скомпоновать секции .cinit и какие-то части .bss (или своего сегмента неинициализированной памяти) на одни и те же адреса. Ведь, как правило, суммарный размер секций .bss в программе много больше чем .cinit.

Вы меряете не время чтения памяти, а время выполнения GPIO. Не удивлюсь, если один вывод в GPIO дольше чем все 200 чтений внутренней RAM. :) Неверная методика измерений. Надо делать примерно так: дёргаете ногой 1раз, делаете N чтений из DDR, дёргаете ногой 2раз, делаете N+M чтений из DDR, дёргаете ногой 3раз. Вычитаете время (2раз-1раз) из (3раз-2раз), делите на M. Да и программу лучше компилить с полной оптимизацией, объявив указатель чтения как: volatile u32 *p

Вот участок makefile с ключами компиляции/линковки/hex оставшегося ещё с тех времён, когда занимался C5502 (грузилось всё с i2c-флешки): PRJ_NAME = mr04 !if $d(OPC_DEBUG) DIR_OUT = DEBUG.OUT !else DIR_OUT = RELEASE.OUT !endif DIR_CGT = $(TI_DIR)c5500\cgtools\bin DEPEND = *.h makefile DEPEND_ASM = $(DEPEND) *.inc F_CC = "$(DIR_CGT)\cl55" -b -q -s -al -as F_CC = $(F_CC) -fr $(DIR_OUT) -fs $(DIR_OUT) -ft $(DIR_OUT) F_CC = $(F_CC) -fb $(DIR_OUT) -ff $(DIR_OUT) F_CC = $(F_CC) -i"C55X_C_DIR" -i$(DIR_OUT) F_CC = $(F_CC) -d"_DEBUG" -d"CHIP_5502" F_CC = $(F_CC) -mb -ms -v5502 -o1 -oi0 -pdel10 -pdsr69 -pdsr172 $(TAIL_C) F_LNK = -z -abs -c -b -w -ec_int00 F_LNK = $(F_LNK) -m$(DIR_OUT)/$(PRJ_NAME).map F_LNK = $(F_LNK) -o$(DIR_OUT)/$(PRJ_NAME).out F_LNK = $(F_LNK) -x -i"C55X_C_DIR" -l"rts.lib" #F_LNK = $(F_LNK) -xml_link_info=$(DIR_OUT)/$(PRJ_NAME).plc F_HEX = -q -i -memwidth 8 -boot ... Обратите внимание на опции -mb, -mc в ключах компилятора и опцию -c - в ключах линковщика. Инитилось всё загрузчиком. Все константы в исходниках должны быть с const. а то! ;)

Ну если Вам достаточно такой грубой точности как 256 значений на 360 градусов, то наверно. Но если для повышения точности будете пользоваться sin(x+y)=sin(x)*cos(y)+sin(y)*cos(x) то думаю будет значительно медленнее чем полиномом, так как насколько знаю - ROM там очень медленная.

Да, вспомнил - когда я ещё писал на C5502 у меня тоже возникла подобная проблема. Я её решил перекомпилив rts.lib, предварительно выбросив оттуда все ненужные функции типа exit() и пр. Благо в CGTOOLS для 55x она имелась в исходниках (rts.src)

Возможно Вы используете какую-то функцию из стандартной библиотеки, которая вызывает exit() по одной из ветвей (можно попробовать поискать ссылки по map-файлу). Либо: #pragma FUNC_NEVER_RETURNS int main() { ...

А зачем? Чем не устраивает полином?

Скоро получу наконец-то TMDSOSKL137 и тогда будет 2 головы - лучше чем одна :)

Пара дней? Или пара месяцев? USB-device-stack (stand alone), который я использовал (и адаптировал) на ARM7 весил почти 3тыс. строк исходника. + изучение аппаратуры и отладка. Такое написать за пару дней.... Вы оптимист ;) Хочется время тратить на решение основной задачи, а не на изобретение велосипеда. PS: Чувствую - придётся этот стек портировать на C674x :(

Наверно Вы правы - у SPECTRUM DIGITAL нашёл раскладку по ревизиям eval boards - на ревизии D платы стоит XOMAPL137ZKB3 (X = Experimental Device), а на ревизии F платы - OMAPL137AZKB3 (Blank = Production Device). Осталось только понять - какая ревизия платы у TMDSOSKL137, а какая - у TMDXOSKL137BET? Шутите? ;)

В качестве CPU для нового устройства решили выбрать TMS320C6745/OMAP-L137. Ранее с ним дела не имел, но имеется опыт разработки 3-5-летней давности на C5502. Встали такие вопросы: 1. EVM-board - какую лучше использовать и может кто имеет опыт - ваши рекомендации? Нашёл: TMDSOSKL137 у TI, и TMDXOSKL137BET - в Терре. В чём их разница? Не могу найти схем этих плат. Может у кого есть? На плате необходимы след. разъёмы: ОБЯЗАТЕЛЬНО выведенный на разъём или контактное поле McASP1 (или хотя-бы McASP0), USB-device, желательно на разъёме иметь SPI0 или SPI1, I2C, UART1 или UART2. 2. Средства разработки. Думаю использовать CCS3.3 и SAU510. Нужен готовый USB-стек (USB-device). На http://software-dl.ti.com/dsps/dsps_public.../index_FDS.html имеется стек для этого CPU, но судя по описанию, не поддерживает изохронный режим, а именно он мне и нужен :((((( Подскажите - где можно взять USB-стек под DSP-ядро L137 (с поддержкой изохронного режима)? Или надо использовать только L137 и USB-стек запускать придётся на ARM-части? Реально-ли портировать USB-стек от другого кристалла? Устройство должно иметь связь с ПК. Основным интерфейсом связи планируется USB fullspeed. control EP0 и isochronic transfers. Еще не решили, что именно ставить - OMAP-L137 или C6745/C6747.

Я с этим сейчас работаю. Если еще интересно - пиши. ICQ: 311337544 мыло: [email protected]

Спасибо! Из остальных требований - минимальное занимаемое место на плате, и цена. GPIO = 2-3 ноги не больше.

Требования: ОЗУ >= 16кБ, 1/2UART, 1SPI, флеш-программ >= 16кБ, минимальное занимаемое место на плате, не BGA-корпус, диапазон температур от -40, недорогой ;) Быстродействие значения не имеет.