Как освободить Стек контроллера??

[ARV]

Нет, ну конечно можно завести generic-указатели, для AVR 3-байтовые

а вот с этого места по-подробнее, пожалуйста какие-такие трехбайтовые generic-указатели? avr-gcc про них что-нибудь знает?

[avreal]

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

Такие указатели были в ком-то для mcs51, у которого вообще дурдом с idata/xdata/code. Не пользовался, ибо то генерило дивный по объёму и тормознутости код, лучше было внимательно раскладывать переменные/буфера и аккуратно вручную работать.
Может, у кого-то и для AVR уже есть, не знаю, не интересовался.

Кстати, у кого-то ещё, кажется, у Avocet C51, забыл за почти пятнадцать лет, была модель памяти, когда на уровне линкера было сказано секцию данных-в-коде не линковать ниже адреса 0x100, в результате 2-байтовый указатель работал с idata+code, ниже - ОЗУ, mov через @R0/@R1, выше - код, movc через DPTR. XDATA в пролёте.

Возвращаясь к нашим пространствам - собственно, само понятие моделей памяти и far/near указателей, которое жило во всех "досовских" (16-битных) компиляторах говорит о том, что языку С все эти заморочки чужды. У PDP-11 было единое 16-битное адресное пространство и, в зависимости от ОС, могло быть что-то, на что потом стал похож EMS, у VAX-11, моторольского 68xxx - единое 32-битное (у младших 68xxx - 24-битное) адресное пространство без всяких там сегментов. "какой такой козырёк?".
Это уже попридумывали те, кому понравился С и они начали его натягиывть на свои заморочки. А уже их последоваели решили, что const-массивы отавляются в ОЗУ для того, чтобы скорость поднять, а не для того, чтобы проще удовлетворить стандарту.

Кстати, на одной из наших плат для "Невроза" ("Нейрон И9.66") мы ставили маленькую ПЗУ-шку с парой подпрограмм для работы с ней именно для того, чтобы ускорить работу, из ОЗУ дольше было

[ARV]

Не-а

вот так всегда...
лично мне бы вот far-модель для указателей не помешала бы, особенно когда юзаешь atmega2560 с ее 256К flash-памятью... я именно о "понимании" компилятором указателей на такую большую память, а не о том, как к ней обратиться при помощи извратов

[O-LED]

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

[ARV]

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

спасение утопающих - дело рук самих утопающих

если у вас данные объявлены как flash char str[] = "123"; то str - это есть указатель на char во flash. отсюда следует, что объявить указатель на байт во flash надо так: flash char *f_ptr;
аналогично и для eeprom: eeprom char *ee_ptr;
если у вас компилятор "интеллектуальный", то он должен верно понять, что надо сделать в случае a = *f_ptr++; или b = *ee_ptr;

[O-LED]

я о другом. Если указатель объявляю как flash unsigned int *указатель и массив flash unsigned int массив[] то все в порядке. как и в случаи если и указатель и массив объявляю eeprom unsigned int *указатель и eeprom unsigned int массив[] .
у меня немного другой случай. есть массивы во флеше, и в еепроме, и есть указатель, который может указывать на массивы размещенные и во флешь и в еепром. И вот тут я их подружить немогу.

вот как это у меня в коде. объявляю массивы с разным расположением

Код: Выделить всё

flash      unsigned int yzor1 []
flash      unsigned int yzor2 []
flash      unsigned int yzor3 []
flash      unsigned int yzor4 []
eeprom     unsigned int yzor5 []
?????  unsigned int  *yzor;

потом в основной программе

Код: Выделить всё

while (1)
{
ля-ля-ля
switch (yzor_nomer)
{
case 0: yzor=yzor1;  break;
case 1: yzor=yzor2;  break;
case 2: yzor=yzor3;  break;
case 3: yzor=yzor4;  break;
case 4: yzor=yzor5;  break;
};               
};

Как мне помирить эти указатель и массивы?

можно конечно завести два разных указателя, а в программе сделать две ветви, но это не наш метод )))

Код: Выделить всё

flash      unsigned int yzor2 []
flash      unsigned int yzor3 []
flash      unsigned int yzor4 []
eeprom     unsigned int yzor5 []
flash     unsigned int  *f_yzor;
eeprom    unsigned int  *ee_yzor;
while (1)
{
ля-ля-ля
switch (yzor_nomer)
{
case 0: f_yzor=yzor1;  break;
case 1: f_yzor=yzor2;  break;
case 2: f_yzor=yzor3;  break;
case 3: f_yzor=yzor4;  break;
case 4: ee_yzor=yzor5;  break;
};
if   (yzor_nomer  <=3)
{
использхуем указатель   f_yzor
}
else
{
использхуем указатель   ee_yzor
}            
};

[Murav]

Так не получится - придётся делать всё вручную:

Код: Выделить всё

flash      unsigned int yzor1 []
flash      unsigned int yzor2 []
flash      unsigned int yzor3 []
flash      unsigned int yzor4 []
eeprom     unsigned int yzor5 []
union {
flash unsigned int  *f;
eeprom unsigned int  *e;
} yzor;
unsigned char isEeprom;

Код: Выделить всё

while (1)
{
ля-ля-ля
switch (yzor_nomer)
{
case 0: yzor.f=yzor1; isEeprom=0; break;
case 1: yzor.f=yzor2; isEeprom=0; break;
case 2: yzor.f=yzor3; isEeprom=0; break;
case 3: yzor.f=yzor4; isEeprom=0; break;
case 4: yzor.e=yzor5; isEeprom=1; break;
};               
};

Код: Выделить всё

a = (isEeprom?*yzor.e:*yzor.f);

Других способов нет. А в avr-gcc вообще нужно ещё и вручную вызывать функцию чтения flash или eeprom.

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

Куда в avr-gcc до таких сложных вещей? Куда важнее было бы сделать нормальную работу оптимизатора на 16-битных числах(которыми в GCC являются все константы, даже если они помещяются в 8 бит) и поддержку обращения к данным во flash без ассемблерных вставок(которые в AVR LibC находятся в pgmspace.h).

[ARV]

Куда в avr-gcc до таких сложных вещей? Куда важнее было бы сделать нормальную работу оптимизатора на 16-битных числах(которыми в GCC являются все константы, даже если они помещяются в 8 бит) и поддержку обращения к данным во flash без ассемблерных вставок(которые в AVR LibC находятся в pgmspace.h).

а в чем проблема с 16-битными числами? если я не ошибаюсь, по стандарту все числа считаются типа int, чтобы они были другого типа. надо объявлять это. так в чем вы видите проблему: в соблюдении стандарта?

а оптимизатор, по-моему, отлично справляется со всеми поставленными задачами... опять же: какие претензии?

и, наконец, последнее: только что тут было рассказано (с уклоном в историю) о том, что Си не имеет и не должен иметь никакого понятия о РАЗНЫХ типах памяти и потому НЕ ОБЯЗАН реализовывать на уровне языка доступ к этим разным памятям... и если какой-то компилятор умеет работать с ячейкой eeprom, как с обычной переменной (без функций) - то это скорее недостаток, чем достоинство! это делает программу непереносимой, но главное, полностью скрывает от программиста контроль за скоростью исполнения. не только скорость, но и просто процесс записи, например, 32-битной переменной long в EEPROM происходит неизвестно как: то ли с использованием прерывания по окончанию записи, то ли нет, то ли с запретом прерываний (атомарно), то ли нет...

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

кстати, по вышеупомянутым причинам avr-gcc-программисты даже не подозревают о наличии каких-то проблем с указателями и т.п. при доступе к разным видам памяти! ибо программист в данном случае сам себе хозяин: какую функцию написал, так она и будет работать. объявил указатель и записал в него адрес FLASH - no problem! потом записал в него адрес ОЗУ - то же самое! напортачил - сам виноват, а не компилятор собственно, как и положено по стандарту - программист пишет, а компилятор исполняет, не допуская отсебятины.

[Murav]

а в чем проблема с 16-битными числами? если я не ошибаюсь, по стандарту все числа считаются типа int, чтобы они были другого типа. надо объявлять это. так в чем вы видите проблему: в соблюдении стандарта?

Главное, что запись типа (a+1)<<2, где a и b имеют тип char вполне может быть преобразована компилятором в сдвиг 16-битного числа, который выполняется в цикле. И естественно скорости это совершенно не добавляет.
Во многих компиляторах(особенно для МК) в таких случаях в качестве типа константы берётся наименьший тип в котором она помещается.

а оптимизатор, по-моему, отлично справляется со всеми поставленными задачами... опять же: какие претензии?

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

и, наконец, последнее: только что тут было рассказано (с уклоном в историю) о том, что Си не имеет и не должен иметь никакого понятия о РАЗНЫХ типах памяти и потому НЕ ОБЯЗАН реализовывать на уровне языка доступ к этим разным памятям... и если какой-то компилятор умеет работать с ячейкой eeprom, как с обычной переменной (без функций) - то это скорее недостаток, чем достоинство!

Хоть компилятор по стандарту и не обязан поддерживать другие типы памяти, но тем не менее поддерживать их нужно. Причём делать такую поддержку крайне желательно на уровне компилятора(а не костылями типа ассемблерных вставок), поскольку в этом случае во-первых оптимизатор может произвести оптимизацию(например, avr-gcc не может использовать инструкцию LPM Rd, Z+) и во-вторых уменьшается число мест где можно сделать ошибку(тот же avr-gcc при обращении к указателю со спецификатором PROGMEM как к обычной памяти даже варнинг не выдаст).
Поддержки прерываний, кстати, в стандарте C тоже нет. И что компилятор для МК может их не поддерживать?

это делает программу непереносимой

Если для указания того, что переменная находится в другом типе памяти требуется только её спецификатор, то программу легко сделать переносимой с помощью обычных #define'ов. А вот если при каждом обращении нужно вызывать функцию, то для переноса кода потребуется переделывать весь код.

но главное, полностью скрывает от программиста контроль за скоростью исполнения. не только скорость, но и просто процесс записи, например, 32-битной переменной long в EEPROM происходит неизвестно как: то ли с использованием прерывания по окончанию записи, то ли нет, то ли с запретом прерываний (атомарно), то ли нет...

Язык высокого уровня и должен скрывать от программиста тонкости реализации. Естественно при этом программисту нельзя забывать, что указав другой тип памяти он может значительно снизить быстродействие и он должен это учитывать. А для возможности доступа по прерываниям можно и дополнительно дать возможность чтения и записи вручную и никаких проблем с таким доступом я не вижу.
А скорость доступа к flash в AVR вообще не сильно меньше, чем к SRAM: всего на 2-6 тактов в зависимости от способа доступа.

кстати, по вышеупомянутым причинам avr-gcc-программисты даже не подозревают о наличии каких-то проблем с указателями и т.п. при доступе к разным видам памяти!

Но им иногда приходится делать конструкции типа pgm_read_word(((PROGMEM struct1 *)pgm_read_word(dataaddr+a))->fld1) .

[O-LED]

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

Код: Выделить всё

eeprom  x;

x=1;
PORTA=x;
x=2;
PORTA=x;
x=3;
PORTA=x;

и в порт А выведится последовательно 1,2,3 и ничего не потеряется и не собьется?

[ARV]

Murav, буквально несколько строк в виде ответа... не хочется холиварить...

конструкция для доступа к экзотической памяти может быть сложной и не очень красивой, но, главное, она понятна всем без исключения программистам.
для портирования кода с обращением к памяти через функцию достаточно переделать эту функцию, а вот когда доступ скрыт внутри компилятора - тут-то и приходится весь код коверкать...
чтобы компилятор сдвиг сделал циклом, да еще при включенной оптимизации - не встречал, может, просто не повезло
язык высокого уровня Си не должен делать того, чего не должен. обращение PORTC.2 хоть и кажется удобным, но вообще ни в какие ворота языка Си не лезет, даже в битовые поля, которые из С++ были притянуты!!! и переносить такую программу гораздо сложнее, чем написанную по стандарту...
GCC выдаст error на *ptr = 123;, если указатель будет описан, как положено const PROGMEM int *ptr;могли бы, конечно, const упрятать внутрь PROGMEM, но не упрятали... мотивация пока мне не ясна (да и не интересует, если честно).

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

[ARV]

и в порт А выведится последовательно 1,2,3 и ничего не потеряется и не собьется?

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

Murav тут доказывал, что такое "незаметное" обращение к EEPROM - хорошо, а вот принесет человек свою программу куда-то специалисту Си и спросит: почему через час все перестает работать? специалист будет смотреть и думать: а и вправду, почему?! все по-стандарту внешне, где собака порылась? а было бы обращение к EEPROM в виде функции - он (специалист) тут же спросил бы - а что эта функция eeprom_write() делает? не в ПЗУ ли какое-то пишет? а не дает ли ПЗУ отказов при частой записи? и решение проблемы будет найдено быстро...

[O-LED]

спасибо. про 100.000 тыс это все понятно. я спрашивал потому, что у меня есть место где массив из ОЗУ перегоняется в еепром. делается это крайне редко, так что вопрос не о количестве циклов записи, а нормально ли запишется в еепром в таком виде, если после записи одного элемента не ждать окончания записи, а сразу приступать к записи второго элемента.

Код: Выделить всё

eeprom unsigned int yzor[64];
unsigned int led[64]

// этот цикл запускается крайне редко!!!
for (x=0;x<64;x++)
{
yzor[x]=led[x]
}

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

Код: Выделить всё

eeprom  int x;

x=0xFFFF;
x=0x0000;

[ARV]

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

Код: Выделить всё

a = 12;
a=12;

возможно он умный и второй раз для этого кода запись не делает... так что с количеством записей лучше думать, что их больше, чем что их меньше.
в третьих, счет надо вести не на весь EEPROM, а только на ячейки, используемые под ваши переменные. нетронутые ячейки EEPROM сохраняют свое качество/количество записей. то есть для пары ячеек под переменную икс будет 2 записи, а для остальной части памяти - 0.

[Murav]

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

Нормально. Перед обращением к EEPROM вставляется ожидание пока он освободится.
А вот из прерываний обращаться к EEPROM нельзя или нужно отключать прерывания на время чтения в основной программе.

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

Здесь важно то, что константы, которые в случае программы для компьютера будут храниться в обычной памяти, в МК окажутся в flash. То есть требуется переделывать способ доступа к константам. А случае констант во flash никаких проблем при переносе нет вообще, достаточно для всех этих констант заменить спецификатор const на flash const, а в случае необходимости доступа к flash функциями придётся переделывать весь код.

GCC выдаст error на *ptr = 123;, если указатель будет описан, как положено const PROGMEM int *ptr;могли бы, конечно, const упрятать внутрь PROGMEM, но не упрятали... мотивация пока мне не ясна (да и не интересует, если честно).

А вот на a = *ptr он не обратит никакого внимания и вставит чтение из SRAM. А записывать в константные переменные и так никто пытаться не будет.

тут доказывал, что такое "незаметное" обращение к EEPROM - хорошо, а вот принесет человек свою программу куда-то специалисту Си и спросит: почему через час все перестает работать? специалист будет смотреть и думать: а и вправду, почему?! все по-стандарту внешне, где собака порылась? а было бы обращение к EEPROM в виде функции - он (специалист) тут же спросил бы - а что эта функция eeprom_write() делает? не в ПЗУ ли какое-то пишет? а не дает ли ПЗУ отказов при частой записи? и решение проблемы будет найдено быстро...

Так программист должен знать что делает спецификатор eeprom, если он его использует.

[mikekehrli]

Я говорю на английском, и я работаю над программой, которая имеет русские комментарии. Можете ли вы сказать мне, что "drebezg" означает? В комментарии он использует "drebezg счетчик". Что значит "drebezg" значит Россия программист? Я не найти его в словаре.

Спасибо.

[GP1]

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

[Jack_A]

Вот почитал я взглядом человека со стороны эту тему и в очередной раз убедился : ну и правильно, что я программлю на АСМе. Создать себе проблему а потом с помощью клуба героически решать ее - как-то не вдохновляет. На АСМе этой проблемы просто нет. Внимание сосредоточено на реализации алгоритма конкретного устройства, а кодинг уже проходит на автомате, как езда на велосипеде.
Прошу не считать мою реплику как очередное развязывание флейма "C vs ASM" - доводы за и против я знаю назубок. Но вот такое мое IMHO

[mikekehrli]

Это имеет смысл. Спасибо.