IAR 5.11 LPC2478 (отладка в ОЗУ) - чуть меняю, прогу - отладчик тормозит и улетает Опции

[Student Pupkin]

Прошу, подскажите, в какую сторону копать.
Пытался сделать эффект "циклического" сдвига изображения на ЖКИ (128х32, I2C). Сам ЖКИ считывать данные не позволяет. Поэтому определил массив char video_ram[512] - видеопамять. Сначала меняю содержимое video_ram, потом просто по I2C переписываю его в ОЗУ самого дисплея.

В функции для "циклического сдвига" есть такой фрагмент:

int i,j;
for(j=0;j<=3;j++){ // сдвиг
for(i=1;i<=127;i++){
video_ram[128*j+i] = video_ram[128*j+i-1];
}
}

Под отладкой увидел, что сделал не то совсем, поэтому этот фрагмент поменял:

int i,j;
for(j=0;j<=3;j++){ // сдвиг
for(i=127;i!=0;i--){
video_ram[128*j+i] = video_ram[128*j+i-1];
}
}

Это было единственной изменение. При всех попытках запуска проги под отладчиком (в ОЗУ) было следующее:
1) Отладчик стал запускаться значительно дольше ( IAR повисает секунд на 10-15)
2) При пошаговой отладке переход на следующую команду тоже с тормозами приличными
3) При запуске программы (неважно, до точки останова или без них) проц повисает (на ЖКИ хоть какая-то хрень но выводиться должна, а этого нет), при попытке сделать halt IAR повисает навечно...


Может у кого-то что-то подобное уже было? Где причину искать?

[zltigo]

Под отладкой увидел, что сделал не то совсем, поэтому этот фрагмент поменял:

int i,j;
for(j=0;j<=3;j++){ // сдвиг
for(i=127;i!=0;i--){
video_ram[128*j+i] = video_ram[128*j+i-1];
}
}

Бога ради не сочтите за "наезд", но Вам еше рано отлаживать и писать рано надо учиться. Начните с вдумчивого чтения литературы (чуть было не сказал "любой", но вспомнил "творение" Редькина и вздрогнул ) по 'C' и чуть-чуть по ARM архитектуре. Ибо написанное Вам выглядит дико
- побайтное обращение к памяти, тем более для такого жестко 32bit контроллера, как ARM;
- пара индексов (ну прямо бейсик с паскалем);
- постоянные умножения, сложения и вычитания в цикле;
- про корявость режущую глаз типа "i != 0", i обьявленную высоко - это уже мелочи..
Компиляторы по нышним временам оптимизируют и не такое до приличного состояния, но тем не менее писать надо грамотно!
Но даже если выненаписанное переписать максимально эффективно, то все равно соревнаваться в скорости с приличными (а в IAR 5.11 они уже хорошо писаны) библиотечными функциями придется упорно. В качестве первого, рабочего и портируемого шага вышенаписанное должно смотреться так:

Код

memmove( &videо_ram[0*128+1], &videо_ram[0*128], (128-1) );
memmove( &videо_ram[1*128+1], &videо_ram[1*128], (128-1) );
memmove( &videо_ram[2*128+1], &videо_ram[2*128], (128-1) );
memmove( &videо_ram[3*128+1], &videо_ram[3*128], (128-1) );

Дальше, поскольку массивы имеют тяжелое для memove() вырожденное перекрытие со сдвигом на 1,
можно провать аккуратно уделать memmove() для данного частного случая.

[Student Pupkin]

Нашел, где исправить. Прога заработала. Правда, так и не понял, почему процессор зависал.
Думаю, никому подробности не интересны. Итак все со мной понятно.
Многоуважаемому zltigo - спасибо за критику. Да, наверно я как программист - отстой.
Постараюсь больше в этой теме форума не писать - мое место, как я понял, в теме для новичков.
Если zltigo еще намекнет по поводу рекомендуемой литературы по си (кстати правда - от моего ТВАРЬения попахивает паскалем, си я только начал учить), то буду очень признателен
Еще раз приношу извинения - за то, что сюда залез