Внешняя SRAM, Выбор скорости Опции

[zorromen]

Вапрос таков...Какая должно Быть время доступа к внешней SRAM...чтобы без проблемм работать на 16Mhz...

[defunct]

Вапрос таков...Какая должно Быть время доступа к внешней SRAM...чтобы без проблемм работать на 16Mhz...

Если речь о настройках задержки шины памяти, то
для 55ns и более быстрой памяти, задержка любая.
для 70ns памяти - +1 холостой такт.

[=GM=]

Вопрос таков...Какое должно быть время доступа к внешней SRAM...чтобы без проблем работать на 16Mhz...

Основной параметр - время доступа к памяти, он не должен быть больше времени доступа МК к внешней памяти, отсюда и исходите. Например, время доступа к внешней памяти для атмеги128 составляет 3 машинных цикла, т.е. 62.5*3=187.5 нс без дополнительных циклов ожидания.

Однако многое зависит от временных характеристик отдельных сигналов как МК, так и статической памяти. Нужно более внимательно смотреть на соответствующие временные формы конкретной памяти.

Если речь о настройках задержки шины памяти, то для 55ns и более быстрой памяти, задержка любая.
для 70ns памяти - +1 холостой такт.

Зачем нужен холостой такт, там же и так чтение/запись делается за 3 МЦ, вроде бы все проходит и так, скажем, для памяти HM62256B-7 (время доступа 70 нс) или HM62256B-8 (время доступа 85 нс)

[defunct]

Зачем нужен холостой такт, там же и так чтение/запись делается за 3 МЦ, вроде бы все проходит и так, скажем, для памяти HM62256B-7 (время доступа 70 нс) или HM62256B-8 (время доступа 85 нс)

На свой в очередной раз веселый вопрос, Вы сможете ответить себе самостоятельно после того как заглянете в даташит и посмотрите на длительности сигналов RD/WR.

Веселый термин МЦ применяйте относительно к Ц51, у AVR все меряется тактами.

[singlskv]

Свой веселый термин МЦ применяйте относительно к Ц51, у AVR все меряется тактами.

+1
Еще Microchip любит МЦ, что бы было непонятно, что реальная
производительность =20МГц/4такта.

[zorromen]

Тогда ставим более конкретный вапрос ... мега 162 16 мегагерц + HM62256B-7 (время доступа 70 нс) ... Будет нормально работать без потерь в некоторых битах?... в JTAG ведь все видно ...

[=GM=]

Зачем нужен холостой такт, там же и так чтение/запись делается за 3 МЦ, вроде бы все проходит и так, скажем, для памяти HM62256B-7 (время доступа 70 нс) или HM62256B-8 (время доступа 85 нс)

На свой в очередной раз веселый вопрос, Вы сможете ответить себе самостоятельно после того, как заглянете в даташит и посмотрите на длительности сигналов RD/WR.
Веселый термин МЦ применяйте относительно к Ц51, у AVR все меряется тактами.

Минимальная длительность сигналов RD/WR у атмеги128 равна 52,125 нс (документ 2467n, с.331).
Максимальная длительность сигналов ОЕ/WR для HM62256B-7(8) составляет 40(45)/50(55) нс (дейташит на HM62256B, с.7-8). Давайте посмеемся вместе. Где тут надо смеяться(:-)?

Насчет МЦ. Привык использовать в DSP, слишком много понятий связано с понятием такт, да и тактов разных в процессоре немеряно, поэтому иногда проще поискать эквивалентное понятие, машинный цикл неплохо звучит, не хуже других. Например, у меня два DMACа выполняются за один МС 10нс (machine cycle), как мне говорить, за полтакта? На самом деле, если копнуть чуток поглубже, эта команда размазывается на 8 клоков (тактов) процессора(:-(. Конвейер, понимаете ли, а вы говорите такты! Да и в самих аврках есть одноуровневый конвейер, так что и там такты, как мера выполнения команды сомнительна. Хотя на бытовом уровне, пожалуй, использовать можно(:-).

Свой веселый термин МЦ применяйте относительно к Ц51, у AVR все меряется тактами.

+1
Еще Microchip любит МЦ, чтобы было непонятно, что реальная производительность =20МГц/4такта.

-2
Вроде еще не пятница, неплохо бы и по делу что-нибудь сказать? Поближе к теме ветки(:-).

[zorromen]

Я сандалил W24257-70L но он не шел на 16мгц а только на 4 мгц шел...но когда писа например нули в память некоторые биты записывальсь всеже с ошибками....боп импульсы непомогают... все перепробывал...поэтому и спрашиваю про скорость...получается 70 нс тока на 4 мегагерца идет и то с глюками...

[Nanobyte]

... на 4 мегагерца идет и то с глюками...

Почти наверняка битая SRAM или AVR. Мне ни разу не удалось поймать сбои при работе на 16 мГц и 70нс. Кстати, конденсатор по питанию около памяти очень даже желателен. Ещё посмотреть бы осциллографом сигналы адреса и управления прямо на выводах SRAM. Если проводники тонкие и длинные тогда, возможно, звон портит вам всю картину.

[defunct]

Минимальная длительность сигналов RD/WR у атмеги128 равна 52,125 нс (документ 2467n, с.331).
Максимальная длительность сигналов ОЕ/WR для HM62256B-7(8) составляет 40(45)/50(55) нс (дейташит на HM62256B, с.7-8). Давайте посмеемся вместе. Где тут надо смеяться(:-)?

что ж, давайте посмеемся.
В даташитах на SRAM обычно не приводят такой параметр как макс. длительность WE строба, следовательно цифры 50(55) приведенные вами есть ни что иное как мин. длительность WE строба.

Получается с одной стороны мин. длительность WE строба (70ns памяти) = 55ns, с другой стороны мин. длительность WE меги 52.125. 55 несколько больше чем 52.125 не так ли? Тут и начинаются глюки. Как они проявляются - можете поэкспеременитировать.
Мне даже не нужно приводить данные из даташитов других производителей памяти (хотя я запросто могу это сделать), достаточно цифр из вашего.

Например, у меня два DMACа выполняются за один МС 10нс (machine cycle), как мне говорить, за полтакта?

простите, чего у вас выполняется? Вы постоянно сорите какими-то аббревиатурами которые слабо вяжутся со смыслом.

[zorromen]

Ура...нарыл память с 35нс доступом...думаю теперь проблем небудет)))

[=GM=]

Минимальная длительность сигналов RD/WR у атмеги128 равна 52,125 нс (документ 2467n, с.331).
Максимальная длительность сигналов ОЕ/WR для HM62256B-7(8) составляет 40(45)/50(55) нс (дейташит на HM62256B, с.7-8). Давайте посмеемся вместе. Где тут надо смеяться(:-)?

что ж, давайте посмеемся.
В даташитах на SRAM обычно не приводят такой параметр как макс. длительность WE строба, следовательно цифры 50(55) приведенные вами есть ни что иное как мин. длительность WE строба.

Не, смешнее не стало, но к счастью, разобрался. Всё не так работает. Для конкретности будем говорить о 70-ти наносекундной памяти. Начнем с самого начала. При появлении строба OE статическая память должна выдать данные и как можно быстрее. Максимальное время выдачи для нашей памяти достигает 40 нс, т.е. гарантированно через 40 нс после начала строба чтения появятся достоверные данные. В то же время минимальная длительность строба чтения от атмеги128 составляет 52 нс. Казалось бы все хорошо, ан нет! Судя по временным графикам на МК, необходимо обеспечить наличие достоверных данных за 40 нс до конца строба чтения.

Вывод такой. Для 55-, 70- и 85-наносекундной памяти необходим один дополнительный такт ожидания. Иными словами, для соответствия спецификации чтение SRAM должно осуществляться не менее, чем за 4 такта МК.

Получается с одной стороны мин. длительность WE строба (70ns памяти) = 55ns, с другой стороны мин. длительность WE меги 52.125. 55 несколько больше чем 52.125 не так ли? Тут и начинаются глюки. Как они проявляются - можете поэкспеременитировать.
Мне даже не нужно приводить данные из даташитов других производителей памяти (хотя я запросто могу это сделать), достаточно цифр из вашего.

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

Например, у меня два DMACа выполняются за один МС 10нс (machine cycle), как мне говорить, за полтакта?

простите, чего у вас выполняется? Вы постоянно сорите какими-то аббревиатурами которые слабо вяжутся со смыслом.

Прошу прощения за непонятки. Как всегда предполагается, что все люди делают примерно тоже самое, и нет нужды повторяться. Поясню смысл аббревиатуры. DMAC это команда цифрового сигнального процессора TMS320F2812. D-double, т.е. двойной, MAC-multiply and accumulate. То есть берется два 16-битных операнда из разных участков памяти, перемножаются, получается 32-битный результат, который складывается с содержимым аккумулятора. За один такт (10 нс !) выполняется два таких MACа, отсюда DMAC. Не знаю как вас, но меня такой результат впечатляет. Чтобы добиться подобного результата, применяют конвейерную обработку, каждая команда разбивается на 8 частей и в процессоре одновременно выполняются 8 команд на разной стадии выполнения. Для стороннего наблюдателя процесс выглядит как если бы одна команда выполнялась за ОДИН такт, хотя на самом деле она выполняется за 8 тактов. Вот тот ОДИН такт и называют машинным циклом, возможно неправомерно, но так уж сложилось. Надеюсь, теперь вам стало более понятно, что я имел в виду?

Упоминая о DMAC, я просто хотел показать, что имеет смысл применять понятие машинный цикл (МЦ) вместо слова "такт".

[ps1x]

Я конечно не очень разбираюсь в памяти для АВР, но может сделать двухканальную, типа РЕЙД массива, пишется попеременно то в одну то в другую, и читается также... Если уж быстродействия МС памяти не хватает...

[defunct]

Не, смешнее не стало, но к счастью, разобрался. Всё не так работает. Для конкретности будем говорить о 70-ти наносекундной памяти. Начнем с самого начала. При появлении строба OE статическая память должна выдать данные и как можно быстрее. Максимальное время выдачи для нашей памяти достигает 40 нс, т.е. гарантированно через 40 нс после начала строба чтения появятся достоверные данные. В то же время минимальная длительность строба чтения от атмеги128 составляет 52 нс. Казалось бы все хорошо, ан нет! Судя по временным графикам на МК, необходимо обеспечить наличие достоверных данных за 40 нс до конца строба чтения.

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

Вывод такой. Для 55-, 70- и 85-наносекундной памяти необходим один дополнительный такт ожидания. Иными словами, для соответствия спецификации чтение SRAM должно осуществляться не менее, чем за 4 такта МК.

Согласен с выводом, тем более он не противоречит рекомендациям от Atmel.

[=GM=]

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

Что вы так прицепились к этим смайликам(:-)? На мой взгляд они добавляют немного живости к обсуждаемым темам и показывают эмоции автора. "Суха теория, мой друг, но древо жизни вечно зеленеет" (С)Гейне. Вы что, всегда по жизни такой мрачный? Меняйтесь пока не поздно, а то не доживете до пенсии(:-).

И, позвольте, какие амбиции? Я ж ВАС спрашивал, почему нельзя использовать три такта, а не утверждал, что можно их использовать (см. пост №3). Высказывал, так сказать, сомнения.

Последнее, пожалуйста, отвечайте адекватнее по поводу веселых вопросов и смайликов, поскольку ничего веселого в моем изначальном посте (№3) не было и смайликов тоже, формулировка "веселые вопросы" появилась в вашем посте.

Вывод такой. Для 55-, 70- и 85-наносекундной памяти необходим один дополнительный такт ожидания. Иными словами, для соответствия спецификации чтение SRAM должно осуществляться не менее, чем за 4 такта МК.

Согласен с выводом, тем более он не противоречит рекомендациям от Atmel.

Зато он противоречит вашей рекомендации для 55-ти нс памяти (см. пост №2).

[defunct]

Зато он противоречит вашей рекомендации для 55-ти нс памяти (см. пост №2).

Да, потому что тайминг Tdvrh = 40ns, который вы взяли из даташита соответствует частоте тактирования 8Mhz. Мы же речь ведем о 16Mhz, т.о. длительность Tdvrh будет в два раза меньше, т.е. 20ns, что годится для 55ns памяти.

[=GM=]

Зато он противоречит вашей рекомендации для 55-ти нс памяти (см. пост №2).

Да, потому что тайминг Tdvrh = 40ns, который вы взяли из даташита соответствует частоте тактирования 8Mhz. Мы же речь ведем о 16Mhz, т.о. длительность Tdvrh будет в два раза меньше, т.е. 20ns, что годится для 55ns памяти.

Странно, но в дейташите Tdvrh = 40ns как для 8 МГц, так и для 16 МГц, возможно вы посмотрели не в ту графу таблицы. Но даже если бы Tdvrh=20 нс, то это не поможет, поскольку минимальная длительность импульса записи RD равна 52.5 нс, а 55-ти наносекундная память обеспечивает выдачу стабильных данных через 35 нс, т.е. минимальная длительность RD должна быть 35+20=55 нс.
Возможно, что отдельные экземпляры памяти и МК как-то будут работать, но мы же говорим о соответствии спецификации (по-нашему - техническим условиям) на МК и SRAM, чтобы обеспечить работу системы в любых допустимых условиях эксплуатации.

[defunct]

Но даже если бы Tdvrh=20 нс, то это не поможет, поскольку минимальная длительность импульса записи RD равна 52.5 нс, а 55-ти наносекундная память обеспечивает выдачу стабильных данных через 35 нс, т.е. минимальная длительность RD должна быть 35+20=55 нс.
Возможно, что отдельные экземпляры памяти и МК как-то будут работать, но мы же говорим о соответствии спецификации (по-нашему - техническим условиям) на МК и SRAM, чтобы обеспечить работу системы в любых допустимых условиях эксплуатации.

Output Enable to Output Valid 35ns это опять же время для 70ns памяти.

У 55ns памяти это время чуть-чуть меньше. Например у памяти Winbond W24258-55LL парамер Output Enable to Output Valid = 27ns,

27ns+20ns = 47ns

итого имеем даже запас:
52.125ns-47ns = 5.125ns

[=GM=]

Но даже если бы Tdvrh=20 нс, то это не поможет, поскольку минимальная длительность импульса записи RD равна 52.5 нс, а 55-ти наносекундная память обеспечивает выдачу стабильных данных через 35 нс, т.е. минимальная длительность RD должна быть 35+20=55 нс.
Возможно, что отдельные экземпляры памяти и МК как-то будут работать, но мы же говорим о соответствии спецификации (по-нашему - техническим условиям) на МК и SRAM, чтобы обеспечить работу системы в любых допустимых условиях эксплуатации.

Output Enable to Output Valid 35ns это опять же время для 70ns памяти.
У 55ns памяти это время чуть-чуть меньше. Например у памяти Winbond W24258-55LL парамер Output Enable to Output Valid = 27ns, 27ns+20ns = 47ns
итого имеем даже запас: 52.125ns-47ns = 5.125ns

Насчет 27 нс понятно, вначале вроде упоминалась W24257, а не W24258.

Тем не менее, запаса нет, вы принимаете Tdvrh равным 20 нс, а на самом деле Tdvrh=40 нс, следовательно, импульс чтения не может быть меньше, чем 27+40=67 нс.
Не поленился, скачал свежий документ doc2467.pdf (10/06, ver.O). Проверьте сами, Tdvrh=40 нс для 16 МГц, с.331, таблица 137, строка 9.

[Spider]

ребят, не пинайте больно если что не так, но у меня ничего не работает Есть ATMega128 и есть 2 диповых памяти выколупанных из старой i386 мамки, в частности MOSEL MS62256H-20NC. Всё это дело я присобачил к меге через защёлку 74ACT573PC и транзистор RK7002 в качестве ивертора CS второй "страницы" памяти.
Пробую писать в память и ничего не пишеться - JTAGом смотрю что там в памяти с помощью той же меги.
Инициализирую работу пробовал так:

Код

MCUCR |= _BV(SRE) | _BV(SRW10);    // enable external memory (xram)
    XMCRA |= _BV(SRW01) | _BV(SRW00) | _BV(SRW11) | _BV(SRW10);
    XMCRB &= ~(_BV(XMM2) | _BV(XMM1) | _BV(XMM0));

дабы увеличить все задержки, но так же пробовал и максимально быстро, короче как тока не пробовал. Что я не так сдела можете подсказать? Ах да. Мега работает с кварцем 18.432MHz

[defunct]

Есть ATMega128 и есть 2 диповых памяти выколупанных из старой i386 мамки, в частности MOSEL MS62256H-20NC.

Задержек определенно не надо.

Наиболее вероятно - ошибка в разводке..
Проверить наличие сигналов RD/WR
Проверить также сигнал ALE на входе LE защелки.
CS защелки - на землю.

Ах да. Мега работает с кварцем 18.432MHz

не расчитана она на такую частоту.

74ACT573PC

ACT серия часом не 3V? Mega с кварцем 18.432 на 3V будет сбоить.

[Spider]

Есть ATMega128 и есть 2 диповых памяти выколупанных из старой i386 мамки, в частности MOSEL MS62256H-20NC.

Задержек определенно не надо.

Наиболее вероятно - ошибка в разводке..
Проверить наличие сигналов RD/WR
Проверить также сигнал ALE на входе LE защелки.
CS защелки - на землю.

Ах да. Мега работает с кварцем 18.432MHz

не расчитана она на такую частоту.

74ACT573PC

ACT серия часом не 3V? Mega с кварцем 18.432 на 3V будет сбоить.

Всё решено, спасибо за помощь. Защёлка оказалась дохлой. Купил новую всё заработало.

[I_AM_WINER]

Реально пользуем память 55 нс с полным временем 3 цикла (16/3 = 5,33 Мгц)
По datasheet рассчитывать временные параметры далеко не подарок.
Даже Samsung 55 нс память со скрипом пролазит по временным характеристикам.


А 20МГц ATMEGA с внешней памятью в природе существуют?

Сообщение отредактировал I_AM_WINER - Jan 31 2007, 22:58

[Spider]

А 20МГц ATMEGA с внешней памятью в природе существуют?

Ну у меня и АТМЕга128-16 на ура с 20Мгц пашет. Да это не правильно, но пашет ведь

[Spider]

В общем проблема у меня. Ресетится устройство. Понятно что из-за переполнения. Вот что у меня после компилдяции:

Код

AVR Memory Usage
----------------
Device: atmega128

Program:   42940 bytes (32.8% Full)
(.text + .data + .bootloader)

Data:       5282 bytes (129.0% Full)
(.data + .bss + .noinit)

EEPROM:       66 bytes (1.6% Full)
(.eeprom)

Build succeeded with 0 Warnings...

Линкуется вот так:

Код

avr-gcc.exe -mmcu=atmega128 -Wl,-u,vfprintf -Wl,-Tdata=0x801100,--defsym=__heap_end=0x80ffff  -Wl,-Map=ppp.map at.o common.o fcs.o icmp.o ip.o main.o ppp.o tcp.o udp.o mmc.o logger.o time.o lcd.o ff.o    -lprintf_flt -lm  -o ppp.elf

имею внешнюю оперативку в размере 64к.
Делаю тест вот так:

Код

u16 SRAM_Test(void)
{
    unsigned short j;

    Reset_WD();

    for (j = 0; j < RAM_SIZE; j++) {
        _SFR_MEM8(j + EXT_MEM_START) = (unsigned char)(j);
        Reset_WD();
    }
    for (j = 0; j < RAM_SIZE; j++)
    {
        if (_SFR_MEM8(j + EXT_MEM_START) != (unsigned char)(j)) return j;
        Reset_WD();
    }

   return 0xffff;            // past it's test
}

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

Код

T_PPP            PPP;
....
memcpy_P((char*)&PPP.OUR_IP.ip32, OurIP, 4);
....

рано или поздно оно ресетится.
Помогите победить! ХЕЛП!

[aesok]

Линкуется вот так:

Код

avr-gcc.exe -mmcu=atmega128 -Wl,-u,vfprintf -Wl,-Tdata=0x801100,--defsym=__heap_end=0x80ffff  -Wl,-Map=ppp.map at.o common.o fcs.o icmp.o ip.o main.o ppp.o tcp.o udp.o mmc.o logger.o time.o lcd.o ff.o    -lprintf_flt -lm  -o ppp.elf

Какая версия avr-ld? Или WinAVR?

Вместо "-Tdata=0x801100" попробуйте использовать "--section-start,.data=0x801100". И проверте в .map файле в каких адресах расположена секция .data

Анатолий.

[zorromen]

Привет...Вот собрал макет на меге162 16 МГц ... память взял с матери ... кеш бывший .. мне эти микросхемы отпаяли феном ... защелка 74НС573В1 ... память UM61256CK-20 ... короче 20 нс ... Это я уже 3 раз собираю этот макет ... раньше собирал на 70 нс ... Ни разу нормально неработала ни тада ни сейчас ... написал тестер памяти так постоянно вылетают ошибки ... причем каждый раз в разных местах ... уже все перепробывал всякие параметры использовал ...нехочет работать без ошибок ... Прозвонил все ... и смотрел осцилографом ... нормальные фронта ...
Сразу напрашивается пара вопросов...
1) Мож битая мега ...
2) Почему в студии в окошке мемори не показывает, то что я пишу во внешнее ОЗУ ...
3) Почему в студии не отображаются Static переменные ...

[zorromen]

Вчера решил проверить осциллографом сигналы ... выдрал буфер с памятью ... смотрюю сигналы есть там где они быть немогут 12..19 ноги буфера ... сигнал але там ... аказалось я позавчера все перепаял с флюсом БЛИЦ 18 рублей ... такой как мед и пахнет также))) ... Он аказывается токопроводящим ... зараза ... мне все и портил ... пришлось все смывать получше ... А ваще какой флюс брать нетокопроводящий?

[SasaVitebsk]

Вчера решил проверить осциллографом сигналы ... выдрал буфер с памятью ... смотрюю сигналы есть там где они быть немогут 12..19 ноги буфера ... сигнал але там ... аказалось я позавчера все перепаял с флюсом БЛИЦ 18 рублей ... такой как мед и пахнет также))) ... Он аказывается токопроводящим ... зараза ... мне все и портил ... пришлось все смывать получше ... А ваще какой флюс брать нетокопроводящий?

На точке опоры была такая ветка. Обсуждалось всё. Мы тоже "новым флюсом" воспользовались. Потом переделывали. И, что характерно этим флюсом меги8 паялись только в путь уже год. А как применили м2560 с ногами 0.5мм, то - не работает. Используем обычный канифольный. Там вообще по требованиям специальный нужен, - 20$ за 50г. Но, понятно, таких денег жалко.

[Spider]

Вот что видно в мапе:

Код

Memory Configuration

Name             Origin             Length             Attributes
text             0x00000000         0x00020000         xr
data             0x00800060         0x0000ffa0         rw !x
eeprom           0x00810000         0x00010000         rw !x
*default*        0x00000000         0xffffffff

Linker script and memory map

Address of section .data set to 0x800100
LOAD C:/WinAVR/bin/../lib/gcc/avr/3.4.6/../../../../avr/lib/avr5/crtm128.o
                0x0080ffff                __heap_end = 0x80ffff

И ещё далее по тексту вот так:

Код

.data           0x00800100       0xcc load address 0x0000a6f0
                0x00800100                PROVIDE (__data_start, .)
*(.data)
.data          0x00800100        0xc at.o
.data          0x0080010c       0x1a common.o
                0x00800110                MainBufferWr_Rx
                0x0080010c                rtc
.data          0x00800126       0x48 main.o
.data          0x0080016e       0x20 ppp.o
.data          0x0080018e        0x2 tcp.o
                0x0080018e                TCP_Socket
.data          0x00800190        0x1 mmc.o
.data          0x00800191       0x2d logger.o
.data          0x008001be        0xa ff.o
.data          0x008001c8        0x4 C:/WinAVR/bin/../lib/gcc/avr/3.4.6/../../../../avr/lib/avr5\libc.a(rand.o)
*(.gnu.linkonce.d*)
                0x008001cc                . = ALIGN (0x2)
                0x008001cc                _edata = .
                0x008001cc                PROVIDE (__data_end, .)

.bss            0x008001cc     0x13d6
                0x008001cc                PROVIDE (__bss_start, .)
*(.bss)
.bss           0x008001cc        0xc common.o
                0x008001d5                TimerIntCounter
                0x008001cd                UART0_RxBufferRd
                0x008001cf                UART1_RxBufferRd
                0x008001ce                UART0_RxBufferWr
                0x008001d7                LastResetReason
                0x008001d1                MainBufferWr_Tx
                0x008001d3                MainBufferRd_Rx
                0x008001cc                GPSModeSet
                0x008001d0                UART1_RxBufferWr
                0x008001d6                WatchdogCounter
.bss           0x008001d8        0x2 icmp.o
                0x008001d8                ICMP_Header
.bss           0x008001da        0x4 ppp.o
                0x008001da                CodeHeader
                0x008001dc                PPPHeader
.bss           0x008001de        0x4 tcp.o
                0x008001e0                TCP_TmpPort
                0x008001de                TCP_Header
.bss           0x008001e2        0x2 udp.o
                0x008001e2                UDP_Header
.bss           0x008001e4        0x2 mmc.o
.bss           0x008001e6      0x899 logger.o
.bss           0x00800a7f        0xc time.o
.bss           0x00800a8b        0x4 ff.o
*(COMMON)
COMMON         0x00800a8f        0x5 at.o
                0x00800a8f                AT
COMMON         0x00800a94      0x642 common.o
....

Что скажете? ХЕЛП!

[aesok]

Код

И ещё далее по тексту вот так:[code]
.data           0x00800100       0xcc load address 0x0000a6f0
                0x00800100                PROVIDE (__data_start, .)
*(.data)
.data          0x00800100        0xc at.o
.data          0x0080010c       0x1a common.o
    ....

Секция дата расположена по адресу 0x00800100, а не нужном вам 0x00801100. Опция линкера "-Tdata" работает только для контроллеров, у которых внутренняя RAM начинается с адреса 0x60 (AT90S8515), и не работает для тех у которых начинается с 0x100 (ATmega128, ...) или 0x200(ATmega1280, ...). Для них используйте в опцию "--section-start .data=..." - она делает тоже самое и работает всегда.

В LDFLAG вам нужно заменить "-Tdata=0x801100" на "--section-start,.data=0x801100".



Анатолий.

[Spider]

Код

И ещё далее по тексту вот так:[code]
.data           0x00800100       0xcc load address 0x0000a6f0
                0x00800100                PROVIDE (__data_start, .)
*(.data)
.data          0x00800100        0xc at.o
.data          0x0080010c       0x1a common.o
    ....

Секция дата расположена по адресу 0x00800100, а не нужном вам 0x00801100. Опция линкера "-Tdata" работает только для контроллеров, у которых внутренняя RAM начинается с адреса 0x60 (AT90S8515), и не работает для тех у которых начинается с 0x100 (ATmega128, ...) или 0x200(ATmega1280, ...). Для них используйте в опцию "--section-start .data=..." - она делает тоже самое и работает всегда.

В LDFLAG вам нужно заменить "-Tdata=0x801100" на "--section-start,.data=0x801100".
Анатолий.

Кусочек мэйк файла:

Код

## Linker flags
LDFLAGS = $(COMMON)
LDFLAGS += -Wl,-u,vfprintf -Wl,-Map=ppp.map
LDFLAGS += -Wl,-section-start=.data=0x801100,--defsym=__heap_end=0x80ffff

Кусочек мапа:

Код

Linker script and memory map

Address of section .data set to 0x800100
LOAD C:/WinAVR/bin/../lib/gcc/avr/3.4.6/../../../../avr/lib/avr5/crtm128.o
Address of section .data set to 0x801100
                0x0080ffff                __heap_end = 0x80ffff

....

.data           0x00801100       0xd0 load address 0x0000abb0
                0x00801100                PROVIDE (__data_start, .)
*(.data)
.data          0x00801100        0xc at.o
.data          0x0080110c       0x1a common.o

Ща буду пробовать что получилось.

[Spider]

Получилась полная фигня.
Берём и начинаем отлаживать JTAG'ом. Видим, что все переменные лежат >=0x1100 адресах, но в то же время их начальные значения:

Код

unsigned char str[]="Test";

JTAG'ом видны во внутреней памяти. Если же обратиться к переменной, то возвращается значение из внешней памяти, где конечно же помойка. Запись опять же идёт во внешнюю память. Короче прикольно как-то. Это я что-то не так делаю? Кстати. Если эмулировать AVRStudio Emulator'ом, то всё как надо.

[zorromen]

Привет ... я заметил интересную весч ... что ноги на JTAG которые должны еще и служить ногами для старших адресов ... во время зариси или чтения на 32 кб памяти ваще ничего неделают ... JTAG отсоединен ... тоесть контроллер должен махать ими ... но немашет ... я думаю может во фьюзах надо отключить jtag ? А в окне мемори ваще чушь ...

[aesok]

Получилась полная фигня.
Берём и начинаем отлаживать JTAG'ом. Видим, что все переменные лежат >=0x1100 адресах, но в то же время их начальные значения:

Код

unsigned char str[]="Test";

JTAG'ом видны во внутреней памяти.

В какой внутреней памяти: в RAM или FLASH? По каким адресам?

[zorromen]

Ахтунг ...
Ша я обнаружил интересный факт ... Ноги которые идут на JTAG ... это 4 старших разряда памяти ... так они не дают работать со всей памятью ... т.е 8к мах ... Я тока отрубил фьюз JTAG и о чудо ноги стали работать ... Тока кать теперь отлаживать прогу? ерунда какаято со стороны разработчиков ...
Смотрю осцилографом...

[=GM=]

Ахтунг ...
Ша я обнаружил интересный факт ... Ноги которые идут на JTAG ... это 4 старших разряда памяти ... так они не дают работать со всей памятью ... т.е 8к мах ... Я тока отрубил фьюз JTAG и о чудо ноги стали работать ... Тока кать теперь отлаживать прогу? ерунда какаято со стороны разработчиков ...
Смотрю осцилографом...

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

По поводу отладки в описании говорится - ВСЁ, ЧТО НА КРИСТАЛЛЕ (extensive on-chip debug support) + программирование внешней памяти, еепром, фьюзов...

Размещайте отлаженные куски выше по памяти, а нижние 8К - для отладки...

[Spider]

В какой внутреней памяти: в RAM или FLASH? По каким адресам?

B RAM. Ну адреса как и положено для переменных внутренней РАМ от 0 и выше по порядку.
В общем сделал я так: во внешку разместил только кучу, и все "громозкие" переменные объявил указателями и аллочу память на них. Пока работает.

[Handler]

Извените за ламерские вопросы, но все таки хочеться узнать.
1. К каким атмегам можно подрубить внешнию паметь, например к atmega32 можно?
2.Где бы прочитать, желательно на русском, про реализацию этого процесса?

[Nanobyte]

... 1. К каким атмегам можно подрубить внешнию паметь, например к atmega32 можно?
2.Где бы прочитать, желательно на русском, про реализацию этого процесса?

1) ATmega8515, ATmega162, ATmega64, ATmega128
2) http://www.gaw.ru/html.cgi/txt/doc/micros/avr/arh128/2_1.htm

[Spider]

А можно вернуться к моим папугаям? В смысле могу ли я использовать всю ОЗУ как одно целое, а не как "внутреняя" и "внешняя"? Точнее могу ли я сказать об этом компилятору?
Напоминаю, что пока у меня мега128и 32к внешней СОЗУ. Внутреня адресуется как обычно, а во нешнюю перенесена куча (хип).

ЗЫ. А можно, как-нить узнать объём и кол-во занятой памяти в результате работы программы? ну там переменные, их расположение и размер в куче?

[IgorKossak]

А можно вернуться к моим папугаям? В смысле могу ли я использовать всю ОЗУ как одно целое, а не как "внутреняя" и "внешняя"? Точнее могу ли я сказать об этом компилятору?
Напоминаю, что пока у меня мега128и 32к внешней СОЗУ. Внутреня адресуется как обычно, а во нешнюю перенесена куча (хип).

Всё можно. Это нужно сказать линкеру, подкорректировав соответствующий командный файл или скрипт в зависимости от среды разработки.

ЗЫ. А можно, как-нить узнать объём и кол-во занятой памяти в результате работы программы? ну там переменные, их расположение и размер в куче?

Это можно увидеть в map файле, выдаваемом линкером, включив соответствующую опцию.
Размер кучи постоянен (как и размер стека) и также задаётся скриптом линкера, а вот её занятость определить также сложно как и занятость стека.

[Spider]

Всё можно. Это нужно сказать линкеру, подкорректировав соответствующий командный файл или скрипт в зависимости от среды разработки.

Это можно увидеть в map файле, выдаваемом линкером, включив соответствующую опцию.
Размер кучи постоянен (как и размер стека) и также задаётся скриптом линкера, а вот её занятость определить также сложно как и занятость стека.

А по подробнее в случае с WinAVR можно?

[aesok]

А по подробнее в случае с WinAVR можно?

Кое какая информация есть в avr-libc-user-manual в разделе 8.5 Using malloc().

Анатолий.

[IgorKossak]

А по подробнее в случае с WinAVR можно?

WinAVR не использую уже давно.