Всем доброго времени.
Необходимо в PROGMEM хранить здоровенный кусок графики для дисплея. Навешивать для этого отдельную флешку не хочется, потому как объем кристалла позволяет все это добро упаковать прямо в прошивку и не есть мозг. Но тут, сопесна, возникла проблема. Зашить то в прошивку можно и черта лысого, а вот получить доступ к памяти выше 64кб хренушки. Видел где-то на забугорных форумах один и тот же лисапед, где обращение к нужному адресу памяти просиходит через ассемблерный макрос с использованием недокументированной комманды того самого asm. Но помню, что свое время так и не получилось прокатиться на том дивном велике... что-то упорно не компилилось.
Задача, сопсна, проста. Нужно рабочее решение, которым можно будет просто заменить pgm_read_byte(*) / pgm_read_word(*)
Подскажите метод обращения к 64kb+ flash памяти в atmega2560
- ARV
- Ум, честь и совесть. И скромность.
- Сообщения: 18544
- Зарегистрирован: Чт дек 28, 2006 08:19:56
- Откуда: Новочеркасск
- Контактная информация:
Re: Подскажите метод обращения к 64kb+ flash памяти в atmega
вроде как avr-gcc (точнее, компоновщик ld) генерирует прошивку, в которой в младших адресах размещаются константы PROGMEM, а собственно код идет в старших адресах, т.е. pgm_read_xxx будет работать без всяких ухищрений.
но если у вас данных больше 64К - таки да, проблемка имеет место быть... но решается она элементарно: использованием макроса pgm_read_byte_far(address_long) или других аналогичных. единственное неудобство заключается в том, что в качестве аргумента макроса нельзя использовать обычный указатель Си... т.е. надо извращаться именно с адресами блоков памяти, а не с доступом.
я могу порекомендовать размещать такие блоки в отдельных секциях памяти, задавая при компиляции (линковке) адреса этих секций принудительно. т.е. вы заранее знаете, что такой-то массив у вас будет по такому-то адресу и используете это значение для доступа, а не при помощи &prog_mem_variable, как обычно...
да, кстати, имейте ввиду, что функции из avr-libc, работающие с константами во flash, не будут работать корректно, если упомянутые константы будут расположены в адресном пространстве выше 64К. т.е. вместо strcpy_P и подобным вам придется использовать что-то самописное.
но если у вас данных больше 64К - таки да, проблемка имеет место быть... но решается она элементарно: использованием макроса pgm_read_byte_far(address_long) или других аналогичных. единственное неудобство заключается в том, что в качестве аргумента макроса нельзя использовать обычный указатель Си... т.е. надо извращаться именно с адресами блоков памяти, а не с доступом.
я могу порекомендовать размещать такие блоки в отдельных секциях памяти, задавая при компиляции (линковке) адреса этих секций принудительно. т.е. вы заранее знаете, что такой-то массив у вас будет по такому-то адресу и используете это значение для доступа, а не при помощи &prog_mem_variable, как обычно...
да, кстати, имейте ввиду, что функции из avr-libc, работающие с константами во flash, не будут работать корректно, если упомянутые константы будут расположены в адресном пространстве выше 64К. т.е. вместо strcpy_P и подобным вам придется использовать что-то самописное.
если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе
при взгляде на многих сверху ничего не меняется...
Мой уютный бложик... заходите!
при взгляде на многих сверху ничего не меняется...
Мой уютный бложик... заходите!
Re: Подскажите метод обращения к 64kb+ flash памяти в atmega
То, что через указатель не будет (может и можно как-то извратиться, тут я увы не знаю) - я знаю. И это грусть и печаль.
Мысль с раскидкой блоков имеет право на жизнь, но гибкость кодинга просто улетучивается. Это ж каждый раз, когда в сл. прошивке нужно изменить какой-то блок, ручками править адресацию. Ленивый я до жути, хочется автоматизации.
Но за ответ спасибо тем не менее.
Мысль с раскидкой блоков имеет право на жизнь, но гибкость кодинга просто улетучивается. Это ж каждый раз, когда в сл. прошивке нужно изменить какой-то блок, ручками править адресацию. Ленивый я до жути, хочется автоматизации.
Но за ответ спасибо тем не менее.
Бложу помаленьку обо всем подряд