а что здесь "лучше"....... volatile? - это никак не влияет. Что касается следующих строк...... речь же не шла о содержимом....

Ну это ладно ..... я же в принципе обратился, думал что с таким давно уже народ сталкивался ....... и есть какое-то объяснение такого поведения, но ......


А что касается результатов моих исследований, почему именно так себя ведет 1.33 с 16f88x (с 12F1572 например все нормально в аналогичной ситуации) я не знаю, да и честно говоря не хочу тратить слишком много времени выясняя это, поскольку эта "проблема" легко обходится - достаточно просто чтобы была хоть одна константа с абсолютным размещением, скажем по последнему адресу (для 886) и тогда феномен исчезает.

volatile влияет на то, что если ты не используешь данный регистр, то при оптимизации 3, и при НЕиспользовании - ХС8 его просто проигнорирует не включит в проект.

Для остальных оптимизаций - это не имеет значения.

Так а в чём проблема ?

До сих пор значения адреса EEPROM не соответствуют той константе ?

Вообще то в ADRESH грузится старший байт АДРЕСА константы, а не константа... Ты в курсе что означает в Си амперсанд?

@ и __at ничем друг от друга не отличаются. Символ @ по английски звучит как at.

Не надоело писать пургу?

Вообще то он его использует.

__at ... вообще-то у Микрочип -это : "attribute", и можно посмотреть это в справочнике по MPLABX, а значёк @ по системе ASCII = 0x40.

Это твоя разнузданная фантазия. Спецификатор attribute никакого отношения к at не имеет.

И что из этого следует? Причем тут ASCII код символа?
ЗЫ. В русском языке слово "значок" пишется через "о". Учи русский язык, прежде чем писать всякую пургу...

скажем так, прошлые страницы тоже нехило так позабавили, но нынче прям до слёз......

Ну что? вдоволь позабавились по поводу "Ё" и "о" ?
Ну тогда давайте разберём - что такое в пик16 - программная память
Адресация команд урезанная, всего 14 бит из 16-ти, полноценного перехода (линейного) по адресу нету
Табличного чтения НЕТ, а значит - можно уйти по некоему адресу, и вернуться оттуда - только если там будет команда "RETLW".
Обычно - это и выполняется в этих процах.
Естестевенно - ни ПИСАТЬ, ни ЧИТАТЬ таблично FLASH - этих процев невозможно!

Теперь давай посмотрим на запись:

//xc8
const uint8_t R1 @0x18D0=0xAA;
EEADR=(uint8_t)&R1;
EEADRH=((uint16_t)&R1)>>8;

константа адреса, которая равна 0xAA, ну ладно, с этим можно смириться, как и с тем, что САМ указав константу адреса - после (во второй строке) хочет её считать ...
Но третья строка: от значения 8 бит - сделать 16-надцать бит (ДОЛБНЮ понятно - что это НОЛЬ). что бы потом разместить в старший адрес

Здесь на форуме есть кто-нибудь, кто скажет - что такое пишут только после третьего тазика водки? или всем всё нравится ?

Ну и наконец последнее: а стесняюсь спросить - а что эти действия дают в плане прошивки?
ПОЛНОЕ значение из ПЗУ не считаешь - возможности данной серии камней не позволяют, записать тоже нельзя ...
Зачем знать адрес той ячейки, в которой разместил команду:
RETLW 0xxx ???
Ты её и так сохранил в качестве:
const uint8_t R1 &(0x18D0) = 0xAA;

Сам говорил что предпочитаешь правду, но ведёшься на другие правды

В других компиляторах (CCS), в другом языке (C) есть доступ для чтения и записи в память программы. Не знаю как делает, но функции есть и за рассматриваемого МК.

Из Help:

---
Если поможет, фрагмент из файла .lst:
(для меня ASM: незнакомая часть)

Я чувствую, что тебе не надоело быть клоуном...
Открываем даташит и внезапно видим:

Давайте по порядку по поводу "правды" (лично для ALEKS1102X-а)

Повторим суть вопроса - "Родэрик" указал что при команде

const uint8_t R1 = 0xAA;

неправильно вычисляется адрес константы на PIC16F886 !

EEADR=(uint8_t)&R1;
EEADRH=((uint16_t)&R1)>>8;

// в данном случае &R1 - адрес R1 ( !! 16 бит )
// загружаем младший и старший байт адреса
// в переменные EEADR , EEADRH

скорее всего планируется работа с данной "константой"
// а почему нет? если знаем адрес, то можно и изменить!


в случае PIC12F1572 - работает - адрес вычисляется правильно


в случае когда задаём адрес напрямую - то всё работает

const uint8_t R1 @0x18D0=0xAA;

а также работает комбинация

const uint8_t R1 = 0xAA;
const uint8_t R2 @0x1FFF;

----------

смоделировал данную ситуацию
MPLABX 6.05 + XC8 2.41
pic16f690 ( как аналог по коду pic16f886 )
pic16f1827 ( как аналог по коду pic12f1572 )
// пустая программа и

1) const uint8_t R1 = 0xAA;

2) const uint8_t R1 __at(0x800) = 0xAA;

3) const uint8_t R1 = 0xAA;
const uint8_t R2 __at(0x800);


EEADR=(uint8_t)&R1;
EEADRH=((uint16_t)&R1)>>8;

// xc8 2.41 - не знает @

----------
и удивительно - проблема есть для pic16f690!
в листинге всё прекрасно видно что делает компилятор

для записи в память программ константы всегда используется RETLW

1. для pic16f690 получилось что R1
разместился по адресу 0x0007
а адрес назначается 0x8001

для pic16f1827 получилось что R1
разместился по адресу 0x0800
а адрес назначается 0x8800

2. для pic16f690 получилось что R1
разместился по адресу 0x0800
а адрес назначается 0x0800

для pic16f1827 получилось что R1
разместился по адресу 0x0800
а адрес назначается 0x0800

3. для pic16f690 получилось что R1
разместился по адресу 0x0908
а адрес назначается 0x8908
R2 разместился по адресу 0x0800

для pic16f1827 получилось что R1
разместился по адресу 0x0801
а адрес назначается 0x8801
R2 разместился по адресу 0x0800


для расширенной серии pic12f1xxx - pic16f1xxx
есть мапирование памяти программ на память озу с адреса 0x8000
(только младшие байты памяти программ)

используя указатели можно читать таблицы очень быстро
поэтому назначаемый адрес и входит в диапазон 0x8xxx
и сегмент stringX - организуется правильно

для обычных pic16 - xc8 переклинивает и адрес неверно расчитывается

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

старший бит15 в данном случае - неважен,
так как при записи в EEADRH - отбрасывается

данные манипуляции нужны только для изменения константы
// вычисляем адрес и записываем стандартным алгоритмом
// новые данные по этому адресу


---------- дополнительно ----------

для pic16f1xxx команда
EEADR = &R1
правильно запишет 16 бит адрес в старший и младший байт
команда
EEADR=(uint8_t)&R1;
также пишет 16 бит адрес, игнорируя приведение типа

забавно. куча приведений типов... наверное, надо. но почему-то если
тоне

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

EEADRH=((uint16_t)&R1)>>8;
старший байт отбрасывается и так
и да можно сократить ещё
EEADRH=(&R1)>>8;


для
EEADR=(uint8_t)&R1;
также будет верно
EEADR=&R1;
тоже отбрасывается старший байт

// просто копировал код который указали ранее

Добавлено after 2 minutes 52 seconds:
для pic16f1xxx
EEADR - 16 бит объявлен

а старший и младший байты
EEADRL
EEADRH

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

А что он должен использовать для чипа, в котором нет другого доступа к программному флешу?
Спешу напомнить, что В ЛЮБОМ контроллере доступ к программному флешу не является нативной для Си процедурой. Поэтому в компиляторах используются костыльные для Си спецификаторы, а результат компиляции глубоко аппаратно зависим.
Кстати, спецификатор @ - это от IAR. О чем совершенно определенно сказано в мануале на XC8.
Но вопрос Родэрика был СОВЕРШЕННО О ДРУГОМ. Речь шла о неявном размещении константы линкером.

Добавлено after 2 minutes 36 seconds:

А я не парюсь по этому поводу и просто всегда привожу явно. Ведь я не профессиональный программист и откровенно не помню нюансов неявного приведения.

Добавлено after 3 minutes 9 seconds:

Вообще то нельзя. В нормальном компиляторе это вызывает варнинг. EEADRH - это не указатель, а простой регистр и потому константу-указатель нужно привести к простой константе.

КРАМ, именно поэтому пугаюсь, когда вижу лишь частичное приведение, начинаю подозревать, что так и задумано, а я просто не знаю нюансов.

Zikon, попробовал write_program_memory() (в CCS) для 16f690. Функция недоступна.
16F886, 12f1572 - ОК.
Спасибо за инфо.

А ты (Вы) напиши это на АСМ
А потом будешь выкладывать вырезки из даташита на пик16

PS: я уже давно пик16 использую только для чего-то мелкого, ну типа иммо для авто
Серьёзного там ничего не напишешь
https://drive.google.com/file/d/1y0nTqb ... drive_link

Что "это"? Обращение к флешу через контроллер флеша? Так я привел скрин даташита с текстом на АСМе.
Ты изъясняйся конкретно, а не междометиями...

У тебя есть возражения к даташиту?

Поздравляю. Возьми с полки пирожок.
Понятия мелкий/крупный зависят от соотношения ресурсов контроллера и решаемой задачи. Судя по твоим местным эпистолиям, работать с 8-битным Микрочипом ты можешь на очень начальном уровне. Что не сообщение, то какая то глупость...

Ты что считаешь "серьезным"?

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

Добрый день!

Написать на "АСМ" я имел ввиду, что если СИ запрещает кому-то пользоваться ВСЕМИ хотелками микроконтроллера, то АСМ все запреты снимает.

Нет, возражений к даташиту нету, просто он рассчитан наверное на расширение функционала этой линейки процев. Они это и сделали в процах, в которых после "16F" стало больше ТРЁХ цифр.
Только ЗАСАДА - она и осталась Куча переключений банков ОЗУ, из-за которых, если нужно написать ЧЁТКИЙ-ТОЧНЫЙ тайминг - то не получиться нужны вставки на АСМ.
Да ладно вставки, память читать всё равно нет возможности, да и как она появится, если прямой доступ к памяти - это регистры TBLPTRx и TABLAT, а это уже серия пик18.
Да и 14-ти битный адрес к памяти флешь - это тоже "энтузязизма" не добавляет ... когда старший адрес может быть только до 0x3F ...
Вот поэтому, и нет смысла читать старший адрес программной памяти

Спасибо конечно за пирожок, но я его почему-то не нашёл на той полке, которую Вы не указали
В моём понятии - мелкий, это частота не более 8-ми МИпс, памячти почти НОЛЬ, но есть несколько аппаратных модулей, которые можно использовать, к примеру, для связи с иммо от WV
Ну можно ещё взять м/с типа DS1307, DS1338, MCP7941x и сделать добротные часики - прицепить ещё солнечную панель, аккум типа 16850, и можно сказать - почти на всю жизнь
Главное - правильно программу написать, чтобы аккум не всё время заряжался, а по мере необходимости.

Я не могу закинуть на Яндекс диск, он требует купить диск !?! Накой мне их диск? Я что? ЛОХ свою инфу разбрасывать по всей интернетовской помойке? Да она завтра будет доступна последнему бомжу.
Поэтому, я пользуюсь этой помойкой только для раздачи неких своих данных, которые я считаю - что можно выложить в помойку.
А что? здесь есть файлообменник, который вкурит от 700 МГбайт и выше ? Чёт я сумневаюсь

А кто хочет, тот и нерасшаренный скачает