Вобщем есть такой вопросик:
Есть подпрограмма(функция или процедура-не важно).
В ней таблица вида

почему asm,dw 0x... спросите вы: для того, что бы я мог использовать все 14 бит flash памяти. можно задать как массив во флэш,но при реализации компилятор сделает таблицу вида:

и т.д.

собственно, сам вопрос: как можно считать эти данные внутри функции Table1 и если не вызывается данная функция, как заставить компилятор её не исключать при сборке.

Считать флэш у меня получается, а присвоить присвоить переменной адрес функции-не получается.
Да, проц = PIC16F876A и(или) PIC16F886

Сообщение отредактировал DenisIV - Apr 12 2009, 11:11

если это просто данные, зачем их описывать как функцию ? нужно делать массив констант

Объясняю: данные размером 8 килобайт. в памяти FLASH контроллера 14 килобайт (8 килослов размером 14 бит)
если я задам массив из 8 килобайт, компилятор сгенерит код типа retlw 0xFF и т.д. т.е. будет использовано 8 бит из 14-и.
этот код будет весить 8 килослов(14-битных, а не 8!!!), т.е. 100% FLASH памяти контроллера.

мне же мужно считать 14-битные данные из FLASH, выровнять на границу в 8 бит и т.д (дальше не вопрос)
я думаю, в 6 килобайт оставшихся точно помещу распаковку(выравнивание) =))

ваш совет полезен только в случае, если массив менее 8кб (8192-длина программы)
а здесь другое...

Объявление:


Считывание адреса:


P.S. А вариант со сжатием данных по подойдет? Т.е. сделать обычный массив через const char Table[]={...}, и добавить функцию-распаковщик.

Сообщение отредактировал testerplus - Apr 12 2009, 20:39

Огромное вам сапасибо, testerplus , я более ёмкого и конкретного ответа даже не ожидал.
Буду тестировать на проекте как проснусь, сразу отпишусь.
Алгоритм со сжатием не подойдёт, так как данные уже упаковны не хуже GSM упаковки... Но всё равно биг спс !!!
Я думаю, считывание типа Temp=FLASH_READ(MyTable+OffSet) должно пройти...
Есть ещё пара мелких локальных вопросов, которые я хотел бы задать, но это потом...
Адреналин, оказывается, вырабатывается не только в случае опасности, а так же в случае удачной компиляци...

Такой фокус не пройдет (пройдет только на STD-версии компилятора и для ПИКа с ROM < 2k, да и то, если переобъявить метки "MyTable" -> "_MyTable" и в начале файла добавить объявление прототипа: void MyTable(void)).

Метка, объявленная в asm из Си не будет видна. Так что только через асм. Удобно будет организовать в виде функции, но это уже Вам решать:

У меня прошло так:

Только вот указатель на функцию компилируется неправильно. Либо я его неправильно описал.
Как я понимаю:
Temp - прямая адресация к ячейке.
*Teмp - адресация к данным через указатель (как к регистру INDF)
&Temp - адресация к самому указателю (как к регистру FSR)
в итоге у меня почему-то значение в Temp не совпадает с адресом самой функции.
А так строчка
мне очень помогла.
Не хотелось бы прибегать к асму, т.к. программа планируется быть носимой на другие платформы.
предыдущий рабочий вариант был таков:

но в начале функции команды asm не дадут перейти на другую платформу... =((

Я выше описывал, что так не получится. HTPICC (и STD, и PRO) при объеме ROM > 2K будут строить таблицы переходов для всех функций, к адресам которых есть обращения в программе. Т.е. Ваша операция &MyArray вернет не адрес самой функции, а адрес вызова через таблицу переходов
для STD-версии или номер элемента в таблице переходов для PRO-версии (кстати, у Вас каккая?)

Кроме того, HTPICC легко первыми инструкциями в функции вставит:

Если они будут добавлены, то вся таблица сместится, поэтому обращение может быть только через внутреннюю метку.

на какие платформы планируется перенос? dw не везде задается одинаково.

Можно поподробнее? Есть ли доступ к таблице переходов?
PRO 9.65

даже если сместится, можно хоть как-нибудь не прибегая к асму вытащить адрес функции и засунуть в какую-нибудь переменную?

на AVR и x51.
ну в AVR с dw нормально, только точка перед ней нужна, с 51 проблем никаких вроде.
dw не самая большая проблема.

Тут все не очень просто. В ПРО-версиях (кажется с версии 9.60pl4) есть внутренняя константа fpbase (не доступная через Си, по крайней мере, я не добрался до нее). К ней можно обратиться только через asm:


Переменная существует и доступна только тогда, когда в программе есть обращение к адресу функции. Сами понимаете, что это не выход, т.к., во-первых, по-любому получается использование асма, а во-вторых, это всего лишь адрес таблицы переходов.

Но также доступой становится константа с префиксом fp__ (опять же через ассемблер). Если функция называется MyArray, то адрес перехода на эту функцию в таблице переходов будет доступен через константу fp__MyArray.


Я пока не находил таких механизмов.


Я про разные платформы спросил вот к чему: учитывая, что в трех перечисленных платформах dw описывается по-разному, то все равно придется делать какие-то платформозависимые куски кода и выбирать их директивами препроцессора #ifdef. А раз так, то совершенно спокойно можно использовать встроенный asm по той схеме, которую я привел в функции GetMyTable() (тремя-четырьмя постами выше). Вот эту функцию и нужно будет сделать платформозависимой. Весь остальной код будет переносимым, т.к. будет содержать только вызов этой функции.

Ясно. ну в этом случае мне выгоднее использовать конструкцию, которую я ранее приводил, когда я вызываю функцию, а в теле функции асмом отдаётся собственный код адреса и далее dw 0x.. и т.д.

Да, позвольте дать совет не использовать конструкции вида

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

Это хоть какая-то гарантия будет от перемешивания команд... (IAR для AVR точно очень любит такие фокусы, я насмотрелся...)
Ну тема с доступом к массиву полагаю,закрыта...
Хотелось бы ещё спросить про аппаратный I2C мастер. У меня ну никак не получилось заставить его работать. Может какие тонкости есть в этом деле?
Я попытался повторить эту демку на PIC16F886 и сколько не бился, так и не смог запустить аппаратно I2C. Пришлось программно симулировать.
В даташите вроде не отличаются I2C у 876A и 886.

Спасибо, хотя я с этим никогда не сталкивался.


Если честно, никогда не работал с аппаратным i2c в ПИКах