Адресное пространство ATmega2560 составляет 128х2 КБ, поэтому для адресации свыше 64 КБ используется дополнительный регистр RAMPZ
Вот, загрузите блинк(программатором, без загрузчика), который занимает почти всю память - 261 704 байта.
Мигает на РА0.
Если заработает - значит с памятью у МК всё нормально - это у вас косяки в коде.
:020000020000FC
:0600000000000D94FFFE5C
:020000023000CC
:10FDFE0021E02093210021E02093220018E42CEB37
:10FE0E0034EC3A95F1F72A95D9F71A95C1F712E025
:10FE1E001A95F1F70000000020E02093220018E46C
:10FE2E002CEB34EC3A95F1F72A95D9F71A95C1F7E0
:0CFE3E0012E01A95F1F700000000DDCF83
:00000001FF
С точки зрения программиста достаточно понимать, что там может быть как стандартный короткий адрес, так и длинный адрес, под который следует выделять больше памяти.
особенность костыля, который использует arv-gcc для работы с памятью программ более чем 16 разрядов таковы, что что лучше не писать код, вылезающий за 128к. Там минное поле дальше. Мне лень объяснять. Гуру спросите нашего, он любит про такие тонкости компилятора рассказывать. Я про ЕП.
Если код уже перерос 16 разрядов - возьми другой МК, честно так лучше будет.
То-то и оно. Была атмега128. Написался кода аж на 110кб. Начало вываливаться, что код может работать некорректно. Перешёл на атмегу2560. Всë зря?
А что ты там хранишь столько много в progmem?
Может проще внешнюю память использовать?
Там было немного. Килобайт мож на 5
Обновил Usbasp. Теперь из IDE ошибки верификации нет, но она осталась на avrdude+hex. И всë так же зависает на овер 131кб.
Hex с мигалкой попробую, сейчас дикие ограничения с интернетом в городе.
Если что непонятно написал - спрашивайте
Здравствуйте. Загрузил Ваш hex. Осциллографом считал ежесекундную смену уровня на пине. Значит, работает.
Обновил прошивку программатора, поигрался фьюзами, ответственным за загрузку, позагружал пару видов загрузчиков. Шил из ide, avrdude, avrdudes.
Короче, программа зависает и всë. Причём настолько наглухо, что даже светодиод, работающий от таймера, замирает. Загораются некоторые светодиоды, которые не должны гореть в обычной жизни, даже на Rx-пине. Налицо неадекватное поведение МК с размером скетча в 131кб.
Значит, что камень с “полной” памятью, не “обрезанный”))
Надеюсь, из Mega core?
Если да, и
Значит прав @WladDrakula про avr-gcc, но, мне, всё же, непонятно, зачем делать ядро, спецом заточенное под камни с большой памятью(Mega core),
чтобы потом иметь геморрой?
Я, бы ещё поискал решение, может есть правила написания кода именно для такого случая(большая память) для С++ и gcc…
Да, мегакор. С авр-пинами. Тут вопросов нет. Я в течение месяца писал прошивку, ежедневно заливал. Вопросов не было. Всë работает безупречно. Как только перешагнул рубеж, так всë, приплыли
Мне тоже это непонятно. У всех повально такие проблемы, в основном из-за progmem. Ок, от него я отказался, вопрос 20 минут, переписал. А конфликт остался. Мде…
И всё же , не мешает проверить, что @SAB сказал ( #37)
Program Files\Arduino\hardware\arduino\avr\boards.txt открыть текстовым редактором
От progmem отказались, но константы всё равно на флешь хранятся, так что…
Вообще, большой код, много библиотек, наверное, кто знает, “что у них на уме”))
Может виснет потому, что всё из progmem в ОЗУ перетащил и её тупо не хватает?)
1 лайк
Да там порядка 71% занято озу
Это очень много. Тк. это без локальных, т.е стека.
Это только глобальные переменные!
ИДЕ не может считать локальные и динамические, плюс нужно место под стэк и тп. Так что версия с ОЗУ вполне правдоподобная.
да где там то?
где/как посмотреть, пощупать?
1 лайк
Может не надо? Сразу проблему найдёшь, а ещё только 60 сообщений в теме 
1 лайк