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 повисает навечно...


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

[wangan]

попробуйте со флеши, поотрубайте плагины в Options->Debugger, закройте все watch и подобные, уменьшите скорость джитага, ну пересоздайте проект наконец, закоментируйте main и напишите его элементарным и пошагайте

[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 еще намекнет по поводу рекомендуемой литературы по си (кстати правда - от моего ТВАРЬения попахивает паскалем, си я только начал учить), то буду очень признателен
Еще раз приношу извинения - за то, что сюда залез

[zltigo]

...по поводу рекомендуемой литературы по си

Собственно для всех времен и народов база одна - K&R то издание которое уже ANSI С. Только читать внимательно и не стремиться сразу чего-либо написать. Дальше уже чего-нибудь акцентирующее внимание уже на стиле и отсутствии оного, ну, например, "Практику программирования" Пайка и того-же Ритчи...

[defunct]

i обьявленную высоко - это уже мелочи..

Давайте про "i объявленную высоко" не будем вообще, потому как это стандарт

А как бы красиво
for (int i = 0; ...)
не смотрелось, не везде оно откомпилица. RVDS / CA такого не знают, даже если не включать режим strict ANSI C.

[zltigo]

потому как это стандарт

каша никакого отношения к поминанию стандартов всуе не имеет.

не везде оно откомпилица.

А компиляторы, которые спустя 11 лет все еще не знают, что наступил 1999 год и есть ISO/IEC 9899 использовать просто не надо.

[defunct]

А компиляторы, которые спустя 11 лет все еще не знают, что наступил 1999 год и есть ISO/IEC 9899 использовать просто не надо.

Расширение есть расширение, никто его не обязан поддерживать.
Да и никчемное оно по своей сути, от объявления переменных где попало код становится только хуже читаемым.
Менять RVDS на что-то ради C99 - акститесь, много ли альтернатив для Cortex-A9?

наступил 1999 год

Есть C в лице ANSI C и есть C++, все остальное от лукавого - и есть такое же дерьмецо как Object Pascal, который между Pascal и Delphi.

[zltigo]

..от объявления переменных где попало код становится только хуже читаемым.

Пытаетесь перевернуть с ног на голову? Неуклюже, ибо for( int i,... это именно там, где надо, а не там, где попало.

много ли альтернатив для Cortex-A9

. Там, где на данный момент реально используются A9, RVDS ни нафиг ни сдался, ибо там уже люди и операционки написали и API c либами.

[defunct]

Неуклюже, ибо for( int i,... это именно там, где надо, а не там, где попало.

Нет уж, это ANSI C позволяет объявлять там где надо - в начале каждого блока {}.
А вот C99 кроме этого позволяет объявлять еще и где попало, после круглой скобки, просто где ни попадя по тексту...

. Там, где на данный момент реально используются A9, RVDS ни нафиг ни сдался, ибо там уже люди и операционки написали и API c либами.

Смею уверить, что далеко не всем нужны тяжеловесные ОС и GUI на A9.

[zltigo]

Смею уверить, что далеко не всем нужны тяжеловесные ОС и GUI на A9.

Может быть. Только они мне неведомы. А вот нынешние реальные проекты A9 сделаны не RVDS. Вот такая реальность оказалась. Ну лично Вы можете хоть кодах писать.

[defunct]

Может быть. Только вот нынешние реальные проекты A9 сделаны не RVDS. Вот такая реальность оказалась.

Если Вы не сталкивались с нынешними реальными проектами A9 на RVDS это не дает повода так категорично судить о реальности.
Хотя думаю что Вы сталкивались просто не придавали значения (у Вас же есть мобильник), думаете GSM/3G/4G/WiMax / LTE базовые станции строятся на Linux или VхWorks или еще какой толстой ОС? Нет, там RVDS.

[zltigo]

думаете..

Знаю. Так уж вышло.