Как программист я не очень сильный, как электронщик еще ничего... Посему не судите строго за может быть и дурацкий вопрос. Суть проблемы в следующем: Писал программу на С используя MPLAB v8 в cвязке с HI-TECH v9.60 для микроконтроллера PIC16F876A. Схема хорошо работает и я постепенно добавляю в нее новые сервисные возможности. И теперь компилятор выдает окно, что использовал я Program DATA на 99% в BANK 0 и при введении новых переменных естественно выдает ошибку. Господа, а как же другие банки? Ведь они вообще пустые, судя по отчету компилятора. Вот я и хотел бы знать как заставить HI-TECH размещать переменные в других банках, например в BANK1 ? Еще раз извините за каламбур.

1. вообще-то не совсем понятно - Program DATA - это память программ, а не RAM. Уже программа не лезет? все таки приведите полностью что выдает компилятор, что бы не было недопонимания.
2. если все таки не хватает озу, то возможны следующие причины:

2.1 версия 9.60 глючит (используйте 9.50пл3. у меня был случай когда программа нормальнл компилирующаяся в 9.50 отказалась компилироваться в 9.60 с сообщением о нехватке памяти).
2.2 по умолчанию, если не указвать квалификатор "near" или "bank0" компилятор распологает переменные во всех свободных банках, кроме банка 0. в банк 0 ложатся переменные только c вышеуказанными квалификаторами.
пример

Я извиняюсь, не Program data a Space Data смотрим прилогающийся рисунок, Нажмите для просмотра прикрепленного файла как видно из последнего использовано 99% данных BANK 0 При попытке добавить ещеодну переменную типа int (я уже не говорю про long), получаем следующий рисунок Нажмите для просмотра прикрепленного файла Вот я и спрашиваю как заставить компилятор размещать мои переменные в других банках? За ранее спасибо.

См выше п 2.2
если нужно положить в какой-то конкретный банк попробуй так:
static bank1 int b;

На самом деле все с точностью до наоборот. По умолчанию - bank0, остальные банки нужно объявлять явно.

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

Из manual.pdf от picc 9.60 PL2 STD

Из manual.pdf от picc 9.60 PL0 PRO

Для picc18 аналогично. (но он тоже не знает про квалификатор bank0:))
Могу предположить, что tarasik пользуется STD версией компилятора, которая требует рукопашного разведения переменных по банкам.
2tarasik: обратите внимание на "All auto objects are positioned into bank0, along with function parameters.", и, соответственно, не вводите лишних локальных переменных и аргументов функций.

т.е. пишите как рекомендуется новичкам - просто глобальные переменный.

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

одного не пойму, уж 5 лет как ПИКами 18 занимаюсь (ипсользуется RAM до 90%), не было вопросов с банками под С. вот когда в память быстрого доступа не лезут (near) это да, но вот остальное...

да и с 16ми в свое время тоже вопросов не возникало. в крайнем случае просто необходимо было указать bank1 bank2 и т.д. и то, если память не изменяет, скорее для оптимизации, чтоб нужные одновременно переменные в одном банке лежали

может все таки поставить 9.50пл3 и не мучиться человеку?

Лучше наоборот. При использовании указанного компилятора (STD) лучше свои переменные вручную размещать по банкам с квалификаторами, отдав 0-й банк на откуп компилятору под его системные дела. Потому что "лишнии локальные переменные и аргументы функций" имеют класс auto и будут размещаться на стеке, уничтожаясь при выходе из функции. Стек же компилер, в свою очередь, сможет сделать поболе в 0-м банке. Получаем недурственную экономию ОЗУ за счет повторного использования памяти стека на всякие промежуточные дела.

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

Аппаратный стек пика определяет возможную глубину вложения, а софтовый стек picc строит, для размещения в нем передаваемых аргументов и локальных переменных функций. При вложении функций софтовый стек тоже растет само собой. Вот под это память и нужно ему отдать в 0-м банке. Или вы под каждую temp'овую мелочь внутри функции глобальную переменную заводите? А я предпочитаю пользовать одну и ту же область стековой памяти для всех функций.

И при чем здесь куча?

Да, Вы правы я пользуюсь именно этой версией, что ж будем вручную разводить. За помощь всем простое человеческое СПАСИБО!

На досуге пробегитесь по листингу и мапу - пары минут хватит, чтобы понять, что picc не строит софтовый стек (на всякий случай: под стеком обычно понимают одностороннюю очередь с организацией LIFO). Автопеременные размещаются линкером жестко без каких-либо возможностей для телодвижений и при наличии возможности попадают на те же адреса, что и btemp? (но это уже проделки оптимизатора). Закос под стек у picc состоит только в распределении памяти под автопеременные и btemp?, начиная со старших адресов bank0.

Уф-ф... Давайте лучше порадуемся за автора треда, что ему пригодилась информацию, которой мы смогли с ним поделиться.