Форум разработчиков электроники ELECTRONIX.ru

torik

Dec 9 2005, 12:50

Привет всем опять. Задача такая - надо очень максимально быстро

читать из памяти программ данные.
На ассемблере так решал эту проблему:

movlw 0x08 ;старший байт адреса в памяти программ
movwf PCLATH
movlw 0x01 ;младший байт символа 0 в памяти программ
call PCL
movwf s0
movlw 0x09 ;младший байт символа 1 в памяти программ
call PCL
movwf s1
......
PCL: ;переходим на таблицу с адресом PCLATH:PCL
movwf PCL
......
ORG 0x800h
retlw 0x33
retlw 0x36
......

В результате один символ считывается за вроде 7 тактов.
НАДО СДЕЛАТЬ ТОЖЕ САМОЕ НА HITECH C!!! Никак не добиться результата.

Проблема №1:
- для таблицы в памяти программ не задать адрес размещения. Пишу
#pragma psect const=videorom
const unsigned char video [] = {
0b00111001,
..........
и ключ для линкера -L-Pvideorom=0x0800, т.е в целом -L-Pvideorom=0x0800 -PSECTMAP -M"$(TARGETBASE).map" -O"$(TARGETBASE).cof" -O"$(TARGETBASE).hex"
Компилятор ругается unknown psect: videorom
В чем тут проблема не пойму. Вроде все по инструкции.

Проблема №2:
Функция вместо PCL такая
extern unsigned char video_call_pcl(unsigned char n) {
PCL = n;
return 0; //чтобы не ругался компиллер.
}
В ней добавляются лишние команды после компиляции:
CLRF 0x3 - очистка статуса
7C0 00A4 MOVWF 0x24 - сохранение передаваемого парамаметра
Как их убрать кроме как вручную?

Спасибо всем.

Old1

Dec 10 2005, 18:21

Цитата(torik @ Dec 9 2005, 15:50)

Привет всем опять. Задача такая - надо очень максимально быстро

читать из памяти программ данные.
На ассемблере так решал эту проблему:

movlw 0x08 ;старший байт адреса в памяти программ
movwf PCLATH
movlw 0x01 ;младший байт символа 0 в памяти программ
call PCL
movwf s0
movlw 0x09 ;младший байт символа 1 в памяти программ
call PCL
movwf s1
......
PCL: ;переходим на таблицу с адресом PCLATH:PCL
movwf PCL
......
ORG 0x800h
retlw 0x33
retlw 0x36
......

В результате один символ считывается за вроде 7 тактов.
НАДО СДЕЛАТЬ ТОЖЕ САМОЕ НА HITECH C!!! Никак не добиться результата.

Проблема №1:
- для таблицы в памяти программ не задать адрес размещения. Пишу
#pragma psect const=videorom
const unsigned char video [] = {
0b00111001,
..........
и ключ для линкера -L-Pvideorom=0x0800, т.е в целом -L-Pvideorom=0x0800 -PSECTMAP -M"$(TARGETBASE).map" -O"$(TARGETBASE).cof" -O"$(TARGETBASE).hex"
Компилятор ругается unknown psect: videorom
В чем тут проблема не пойму. Вроде все по инструкции.

Проблема №2:
Функция вместо PCL такая
extern unsigned char video_call_pcl(unsigned char n) {
PCL = n;
return 0; //чтобы не ругался компиллер.
}
В ней добавляются лишние команды после компиляции:
CLRF 0x3 - очистка статуса
7C0 00A4 MOVWF 0x24 - сохранение передаваемого парамаметра
Как их убрать кроме как вручную?

Спасибо всем.

Сколько циклов у вас занимет чтение символа из таблицы при выполнении кода на С?

torik

Dec 12 2005, 05:59

На СИ - в лучшем случае 9 (если использовать в константах retlw) - но опять не могу массив запихать по нужному адресу в памяти программ. На асме - 7 циклов.

Old1

Dec 12 2005, 07:36

Цитата(torik @ Dec 12 2005, 09:59)

На СИ - в лучшем случае 9 (если использовать в константах retlw) - но опять не могу массив запихать по нужному адресу в памяти программ. На асме - 7 циклов.

У меня на picc получилось 10 циклов, а вот на IARе - 6 циклов! Я тут на досуге сравнивал работу двух компиляторов и пока сравнение в пользу IAR, кстати запихнуть таблицу по определенному адресу там плевое дело (только вопрос зачем?

) перед объявлением массива (таблицы) нужно вставить директиву, например

Код

#pragmа location=0x800

. Не хочу гнать на хайтековский компилер, возможно и в нем можно получить то, что вам нужно, поигравшись с оптимизацией... Да, код который компилировал при тестировании обоих компиляторов:

Код

const unsigned char TABLE[5]={1,2,3,4,5};
volatile unsigned char A1,A2,A3,A4,A5;
void main(void)
{
    for(;;)
    {
        A1=TABLE[0];
        A2=TABLE[1];
        A3=TABLE[2];
        A4=TABLE[3];
        A5=TABLE[4];
    }
}

torik

Dec 12 2005, 11:30

Колво циклов для ПИКА в лучшем случае такое (решение то зависит от задачи):

movf adres,w (1 цикл)
call mpcl (2)
mpcl:
movwf PCL (1) число циклов еще под вопросом - ща не помню
retlw 0xYY (2)
movwf poluchatel (1)

Такчто 7, а не шесть

Виктория

Dec 12 2005, 15:41

Цитата(Old1 @ Dec 12 2005, 11:36)

Цитата(torik @ Dec 12 2005, 09:59)

На СИ - в лучшем случае 9 (если использовать в константах retlw) - но опять не могу массив запихать по нужному адресу в памяти программ. На асме - 7 циклов.

...
Да, код который компилировал при тестировании обоих компиляторов:

Код

const unsigned char TABLE[5]={1,2,3,4,5};
volatile unsigned char A1,A2,A3,A4,A5;
void main(void)
{
    for(;;)
    {
        A1=TABLE[0];
        A2=TABLE[1];
        A3=TABLE[2];
        A4=TABLE[3];
        A5=TABLE[4];
    }
}

b0b

Dec 14 2005, 19:34

Цитата(Old1 @ Dec 12 2005, 10:36)

У меня на picc получилось 10 циклов, а вот на IARе - 6 циклов! Я тут на досуге сравнивал работу двух компиляторов и пока сравнение в пользу IAR

ерунда какая-то, шутка что ли?
иар мог не читать из памяти программ (а положить таблицу в ОЗУ), это раз.
профайлер считает такты неправильно, это два.
ну и хотелось бы увидеть на код (листинг).

на данный момент (и скорее всего навсегда) для пик16 другой нормальной
(по качеству кода) альтернативы ht-picc нет.

по сравнению, немного в тему, пара ссылок:
http://www.telesys.ru/wwwboards/mcontrol/2...es/126213.shtml
http://www.telesys.ru/wwwboards/mcontrol/2...es/129898.shtml

Old1

Dec 15 2005, 07:51

Цитата(b0b @ Dec 14 2005, 22:34)

ерунда какая-то, шутка что ли?
иар мог не читать из памяти программ (а положить таблицу в ОЗУ), это раз.
профайлер считает такты неправильно, это два.
ну и хотелось бы увидеть на код (листинг).

на данный момент (и скорее всего навсегда) для пик16 другой нормальной
(по качеству кода) альтернативы ht-picc нет.

То что IAR лучше это лично мое менение (и я не собираюсь его никому навязывать)... Вывод такой (для себя и на тот момент) я сделал после компиляции С-кода см. пост №4. Прилагаю list file в котором видно, что таблица находится в памяти программ, и что IAR вообще накомпилировал... Кстати если код усложнить, то результаты уже другие... не в пользу IAR

b0b

Dec 15 2005, 15:36

Цитата(Old1 @ Dec 15 2005, 10:51)

Кстати если код усложнить, то результаты уже другие... не в пользу IAR

но всеравно он лучше, т.к. это Ваше личное мнение

ok, понятно. вопросов больше нет.