Забрать FSR у PICC-18

Здравствуй, All!

Подскажите способ "отобрать" у PICC-18 один из FSR'ов. Хочется организовать в прерывании указатель на буфер без постоянного сохранения/восстановления (ISR - в asm-файле). Пробовал ключ -RESRAMFD9-FDF - не помогло :(

С уважением, Игорь Хавторин (aka Gary) E-mail: gary_fido {ГАВ} gfm {тчк} ru

Reply to
Igor Havtorin
Loading thread data ...

Привет!

Thu Mar 31 2005 21:42, Igor Havtorin wrote to All:

IH> Подскажите способ "отобрать" у PICC-18 один из FSR'ов. Хочется IH> организовать IH> в прерывании указатель на буфер без постоянного сохранения/восстановления IH> (ISR - в asm-файле). Пробовал ключ -RESRAMFD9-FDF - не помогло :(

Маловероятно, что такое возможно, хотя бы потому, что библиотеки уже скомпилированы с использованием этого FSR'а. Да и использует он эти FSR'ы, PROD'ы и т.п. под временные переменные налево и направо.

А из-за чего такое острое желание? Неужели 8 циклов на сохранение/восстановление это так много?

Александр Голов, Москва, snipped-for-privacy@mail.ru

Reply to
Alexander Golov

Здравствуй, Alexander! апреля месяца первого дня ты писал(а):

[...]

AG> Маловероятно, что такое возможно, хотя бы потому, что библиотеки уже AG> скомпилированы с использованием этого FSR'а. Да и использует он эти AG> FSR'ы, PROD'ы и т.п. под временные переменные налево и направо.

Ну из библиотек у меня максимум целочисленные '*' и '/', а там в основном BTEMP, а для компилятора - FSR'ом больше, FSR'ом меньше (PICC вообще одним FSR обходился :-).

AG> А из-за чего такое острое желание? Неужели 8 циклов на AG> сохранение/восстановление это так много?

Когда принимаешь пачки данных с LPT (а надо еще заголовки искать/байты подсчитавать и т.п.), то до слёз жалко тех машинных циклов, которые были "сожраны" группой из 6-8 movff на входе/выходе прерывания. Из прерываний практически не вылезаешь, да и диаграмма LPT получается "вялой" (и это на PIC18F6620 24Mhz).

Хочется "содержательную" часть ISR написать вроде:

psect intcode

btfss _LPT_flags,BLK_RCV bra header_search

bsf _LPT_busy

movff _PORTD,POSTINC1 dcfsnz _ByteCnt bsf _LPT_flags,BLK_END

btfsc _LPT_flags,BLK_END bcf _LPT_busy

bcf int_request retfie

при этом мы не портим никаких регистров - только время воруем :-).

С уважением, Игорь Хавторин (aka Gary) E-mail: gary_fido {ГАВ} gfm {тчк} ru

Reply to
Igor Havtorin

Привет!

Fri Apr 01 2005 12:55, Igor Havtorin wrote to Alexander Golov:

...

AG>> А из-за чего такое острое желание? Hеужели 8 циклов на AG>> сохранение/восстановление это так много?

IH> Когда принимаешь пачки данных с LPT (а надо еще заголовки искать/байты IH> подсчитавать и т.п.), то до слёз жалко тех машинных циклов, которые были IH> "сожраны" группой из 6-8 movff на входе/выходе прерывания. Из прерываний IH> практически не вылезаешь, да и диаграмма LPT получается "вялой" IH> (и это на PIC18F6620 24Mhz).

IH> Хочется "содержательную" часть ISR написать вроде:

...

IH> при этом мы не портим никаких регистров - только время воруем :-).

Похоже на тот случай, когда переписать на асме только критическую часть кода без существенной потери эффективности не удастся. Может с другим компилятором?

А здесь по времени мы имеем:

interrupt 3 bra intcode 2

intcode: btfss _LPT_flags,BLK_RCV 2 bra header_search bsf _LPT_busy 1 movff _PORTD,POSTINC1 2 dcfsnz _ByteCnt 1 bsf _LPT_flags,BLK_END 1 btfsc _LPT_flags,BLK_END 1 bcf _LPT_busy 1 bcf int_request 1 retfie 2 ------ 17

При 24 МГц время выполнения обработчика будет 2,8 мкс. Если засунуть сохранение/восстановление FSR то добавятся 16 циклов, что займёт уже 5,5 мкс. Можно поднять частоту МК до 40 МГц, тогда получится 3,3 мкс. Другой вариант использовать более производительный МК, например на dsPIC30F без резервирования регистров при 30 MIPS получается 0,74 мкс (а с резервированием двух регистров 0,5 мкс):

interrupt 4 push.d w0 2 mov PtrBuf,w0 1 btfss _LPT_flags,BLK_RCV 2 bra header_search bset _LPT_busy 1 mov #_PORTx,w1 1 mov.b [w1],[w0++] 1 dec _ByteCnt 1 bra NZ,L1 2 bsf _LPT_flags,BLK_END bcf _LPT_busy L1 mov w0,PtrBuf 1 pop.d w0 2 bclr int_request 1 retfie 3 ---- 22

Александр Голов, Москва, snipped-for-privacy@mail.ru

Reply to
Alexander Golov

Здравствуй, Alexander! апреля месяца третьего дня ты писал(а):

[...]

AG> Похоже на тот случай, когда переписать на асме только критическую часть AG> кода без существенной потери эффективности не удастся. Может с другим AG> компилятором?

Трафик по LPT небольшой (около 25 Кбайт/сек) Собственно 18F6620 нужен, в основном, по количеству выводов. Разумеется все было написано на С, и даже испытана кооперативная OS Salvo. "Внутренняя" функциональность была отлажена на встроенном тесте, осталось дописать LPT, и вот с его _времянками_ и возникли вопросы. По найденным мною данным по LPT минимальная длительность Strobe - 1мкс, по диаграме Центроникса за эту микросекунду надо успеть забрать данные и поднять Busy. Данные аппаратно защелкнутся в PSP, а вот Busy я смогу поднять только после 3-х циклов на вход в прерывание 3-х movff, и, собственно, bsf _LPT_busy. Итого - более 1.6 мкс. Возможно, для основной массы компьютеров Strobe гораздо длинней, но вдруг попадется тот "единственный"... Есть вариант: по входу в прерывание поднять Busy, а уже затем выполнить все сохранения и пользовать любой FSR, но возникла идея закрепить один FSR за прерыванием и вообще ничего не сохранять, может действительно - какой-нибудь другой компилятор.

[...]

AG> При 24 МГц время выполнения обработчика будет 2,8 мкс. Если засунуть AG> сохранение/восстановление FSR то добавятся 16 циклов, что займёт уже AG> 5,5 мкс. Можно поднять частоту МК до 40 МГц, тогда получится 3,3 мкс. AG> Другой вариант использовать более производительный МК, например на AG> dsPIC30F без резервирования регистров при 30 MIPS получается 0,74 мкс AG> (а с резервированием двух регистров 0,5 мкс):

Частоту 6620 выше 25 не поднимешь, разве что поставить 6621 - там действительно до 40, но это решение "в лоб", а хотелось сделать красиво, и чтобы грелось поменьше. Производительность dsPIC зесь явно лишняя, в будущем мне предстоит с ним работать, я уже ищу средства разработки, но пока с ним знаком весьма повехностно, а сроки сдачи - вот они, так что будем сдавать на PIC18.

С уважением, Игорь Хавторин (aka Gary) E-mail: gary_fido {ГАВ} gfm {тчк} ru /Такой вот анти-спам/

Reply to
Igor Havtorin

Привет!

Sun Apr 03 2005 16:05, Igor Havtorin wrote to Alexander Golov:

...

AG>> Похоже на тот случай, когда переписать на асме только критическую часть AG>> кода без существенной потери эффективности не удастся. Может с другим AG>> компилятором?

IH> Трафик по LPT небольшой (около 25 Кбайт/сек) Собственно 18F6620 нужен, в IH> основном, по количеству выводов. Разумеется все было написано на С, и IH> даже испытана кооперативная OS Salvo.

...

IH> Есть вариант: по входу в прерывание поднять Busy, а уже затем выполнить IH> все сохранения и пользовать любой FSR,

Самое очевидное решение. Нужно поставить захват Busy прямо на точку входа (0x0008), тогда при отсутствии запретов прерывания ты гарантировано уложишься в 1 мкс при 20 МГц (1 цикл на фиксацию запроса, 3 цикла на вход, 1 цикл за команду захвата Busy). Потом, действительно, гоняй себе контекст не напрягаясь.

IH> но возникла идея закрепить один FSR за прерыванием и вообще ничего не IH> сохранять, может действительно - какой-нибудь другой компилятор.

В такой постановке не вижу особого смысла. Для 24 МГц PIC18 25 кБ/с -- сущая ерунда. Зачем вообще дёргаться?

...

IH> Частоту 6620 выше 25 не поднимешь, разве что поставить 6621 - там IH> действительно до 40, но это решение "в лоб", а хотелось сделать красиво, IH> и чтобы грелось поменьше.

По большому счёту частоту можно и опустить до 20 МГц (если уж нужно питание экономить), но эту глюкаву (6620) всё равно лучше заменить (на 6621) от греха подальше.

Александр Голов, Москва, snipped-for-privacy@mail.ru

Reply to
Alexander Golov

Здравствуй, Alexander! апреля месяца шестого дня ты писал:

[...]

IH>> но возникла идея закрепить один FSR за прерыванием и вообще ничего не IH>> сохранять, может действительно - какой-нибудь другой компилятор.

AG> В такой постановке не вижу особого смысла. Для 24 МГц PIC18 25 кБ/с -- AG> сущая ерунда. Зачем вообще дёргаться?

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

IH>> Частоту 6620 выше 25 не поднимешь, разве что поставить 6621 - там IH>> действительно до 40, но это решение "в лоб", а хотелось сделать IH>> красиво, и чтобы грелось поменьше.

AG> По большому счёту частоту можно и опустить до 20 МГц (если уж нужно AG> питание экономить), но эту глюкаву (6620) всё равно лучше заменить (на AG> 6621) от греха подальше.

А что в 6620 кроме 25МГц вместо обещаных 40 и здорово перелопаченных фьюзов еще что-то "недоделано"? У меня в разных приборах и тот и другой применяются и пока не было необходимости ерраты читать.

С уважением, Игорь Хавторин (aka Gary) E-mail: gary_fido {ГАВ} gfm {тчк} ru /Такой вот анти-спам/

Reply to
Igor Havtorin

Привет!

Thu Apr 07 2005 12:11, Igor Havtorin wrote to Alexander Golov:

...

AG>> По большому счёту частоту можно и опустить до 20 МГц (если уж нужно AG>> питание экономить), но эту глюкаву (6620) всё равно лучше заменить (на AG>> 6621) от греха подальше.

IH> А что в 6620 кроме 25МГц вместо обещаных 40 и здорово перелопаченных IH> фьюзов еще что-то "недоделано"? У меня в разных приборах и тот и другой IH> применяются и пока не было необходимости ерраты читать.

Там столько еррат было на несколько версий "силикона", в конце концов они вообще отказались гарантировать работу табличного чтения при низких температурах уже абстрактно от тактовой частоты.

Лучше забыть.

Александр Голов, Москва, snipped-for-privacy@mail.ru

Reply to
Alexander Golov

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.