Недавно начал работать с PIC-ми, на мой взгляд такое рваное
распределение памяти неудобно для использования. Решил выстроить
память в непрерывные(линейные) адреса 0x00-0xff следующим образом:
0x60-0x6f банк0 --> 0x00-0x0f
0x20-0x6f банк1 --> 0x10-0x5f
0x20-0x6f банк2 --> 0x60-0xaf
0x20-0x6f банк3 --> 0xb0-0xff


Работаю MPLAB IDE. Пример для PIC16F88.

Чтение из линейного адреса 0xb2 выглядит так:

movlw 0xb2
call read_routine

на выходе в W прочитанный байт


Запись 0xaa в линейный адрес 0Xb2:

banksel 0
movlw 0xaa ;данные, которые
movwf WRITE_BYTE ;надо записать
movlw 0xb2
call write_routine

Копирование из одного участка памяти в другой(непересекающийся)
использую макрос

COPY_MEM read_address,write_address,count

read_address откуда
write_address куда
count сколько байтов

В моем проекте прописывается память своими адресами.
Если закоментарить строку goto Init_0015 то можно
проверить копирование памяти.
 JQ017_L_M.rar ( 14.16 килобайт ) Кол-во скачиваний: 104

Использование С компилятора стирает эти неудобства

Согласен, но у меня предложения для работы в ассемблере, и есть подозрение что бухгалтерия памяти в С компиляторе ведется примерно так же

У человека как раз именно эта проблема в С компиляторе http://electronix.ru/forum/index.php?showtopic=59877
В моей схеме адресации любой буфер(массив) может начинаться в одном банке, а заканчиваться в другом, для меня это прозрачно.
Насчет 'Мечты стареют куда быстрее мечтателей' как показывают форумы многие работают с PIC12,14,16

Да нет, у человека там другая проблема.

Вообще если бы мне за каждым обращением в регистр надо было бы функцию вызывать, я бы удавился. Если у вас код настолько некритичный к скорости, пишите на C. У меня много девайсов на PIC12/16, на ассемблере, но ваш код я бы нигде не смог применить.

В крайнем случае можно не заморачиваясь перед каждым обращением в память banksel ставить.

Например для копирования большого количества байтов из произвольного банка в произвольный такой подход годится

Вообще - то это аппаратное ограничение(14-битовой команды). Pic16 в принципе больше 128 байт ОЗУ не адресует по системе команд (из них 32 SFR). Дальше костыли в виде банков и обращение через banksel (в последних до 1024 байт дошли).

Если необходимо большой массив, то, наверное, лучше в сторону PIC24 - 32 смотреть.
Хотя если подумать - масса задач великолепно решается на этой серии.

По личному опыту могу сказать родная адресация особых препятствий не создает, а обращение к ОЗУ через подпрограммы, по моему, спорное решение. Больше путаници будет и времени на обращение, Хотя это все на любителя.

Уважаемый zelvans!

Вам и на казусе и здесь говорят, что Вы ерунду задумали. Понимаете, в самой идее того, что Вы предлагаете (я пока не говорю про реализацию), есть несколько моментов, которые не позволяют серьезно относиться к предлагаемому Вами решению:

1. Каждая переменная, к которой предполагается обращение по приведенной Вами схеме, должна иметь два адреса: один - для прямого доступа, другой - для доступа через Ваши функции. Очень неудобно.
2. Очень долго выполняются операции доступа к переменным. Тут отчасти причина в Вашей программной реализации (очеь неоптимальной), но в основном - это следствие самой концепции.
3. Ваши функции покрывают не всю область RAM. Понятно, конечно, что прораммист должен это предусматривать и размещать переменные так, чтобы они находились в области видимости линейных адресов, но сам факт того, что об этом придется заботиться, уже отговаривает от использования предлагаемых функций.

И пару слов о реализации. Во-первых, видно, что код написан новичком (по крайней мере - в ПИКах), и предлагать его для всеобщего пользования несколько самонадеянно. А недостатки реализации очевидны:
1. Отъедает слишком много ресурсов:
- несколько ненужных промежуточных переменных (которые, кстати, нужно размещать где-то вне области линейных адресов); при вызове функций можно обойтись регистрами W и FSR (если интересно, как, - могу написать в личку);
- слишком длинные функции (код можно довольно сильно порезать), не говоря уже о теле макроса COPY_MEM (десяток вызовов отъест 250 слов ROM, не многовато ли?)
2. Следствием проверки кучи лишних условий и постоянного использования макросов banksel является увеличение времени работы функции. Сколько времени будет длиться копирование массива из 10 байт? (Я мог бы запустить в симуляторе, но что-то лениво)
3. Следствием использования временных переменных (всякие WRITE_BYTE, READ_BYTE, TEMP_BYTEx) является невозможность обращаться к линейным адресам и в программе и в прерывании. Т.е. при обращении в программе придется запрещать прерывания, а, учитывая большое время выполнения функций, это далеко не всегда преемлемо.

То время, которое Вы тратите на попытки подогнать архитектуру нового для Вас контроллера под Ваши привычки, лучше потратьте на более глубокое изучение самой архитектуры с тем, чтобы максимально эффективно ее использовать, раз уж довелось работать с этим типом контроллеров.

А где такое надо? Не могу представить. Разве только в специфических задачах. Только там этой функции и место. На универсальность она не тянет.

+1!

Сообщение отредактировал Herz - May 12 2010, 07:16

Слова что это универсальный подход сказал не я. Идея применима при копировании из прозвольного в произвольный банк и при расположении обрабатываемого массива в разных банках, например два массива по 100 байт и чтобы было на ассмблере. В остальных случаях, конечно, прямая адресация. Чтобы в последующих проектах не мучиться сделал сразу. Всем спасибо за высказанные мнения. testerplus-у отдельное спасибо за общение в личке.

Не мучайте себя, возьмите другой контроллер, где нет банков, например STM8 или еще какой, на пиках свет клином не сошелся.