Ну тогда, если ничего уже не помогает, копайте ассемблерный код, сгенеренный компилером. Возможно прерывание портит что-.... («Телесистемы»: Конференция «Цифровые сигнальные процессоры (DSP) и их применение»)

Разработка, производство и продажа радиоэлектронной аппаратуры

| Карта сайта | Пишите нам | В избранное

Требуется программист в Зеленограде
- обработка данных с датчиков; ColdFire; 40 тыс.
e-mail:jobsmp@pochta.ru

Телесистемы | Электроника | Конференция «Цифровые сигнальные процессоры (DSP) и их применение»

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

Отправлено SM 06 марта 2008 г. 19:50
В ответ на: Ответ(+) отправлено <font color=gray>кэп</font> 06 марта 2008 г. 19:41

Составить ответ | Вернуться на конференцию

Ответы

я уже все закомментировал в обработчике, ничего там портиться больше не может )) — кэп (06.03.2008 19:51:48 82.179.67.254, пустое)
- может, может. Внимательно смотрите ассемблерный текст. Кстати, ничего ассемблерного самодельного нет? — SM (06.03.2008 20:03:16 80.92.255.53, пустое)
  - Ответ(+) — кэп (06.03.2008 20:09:31 82.179.67.254, 192 байт)
    - Поставьте доп. проверку той ячейки на некорректное значение, и повызывайте ее почаще отовсюду. Мож кто ее запарывает. Если нет - то значит портят какой-то регистр, в котором времемнно хранится значение, или стек. — SM (06.03.2008 20:16:6 80.92.255.53, пустое)
      - а как этот глюк может быть связан с кэшем ? при разрешении кэша он появляет...{+} — кэп (06.03.2008 21:27:49 78.37.150.179, 231 байт)
        
        при включении кеша по-разному изменяется скорость выполнения разных частей программы, при том, что внешние события возникают с той же скоростью, и в результате глюк возникает более или менее часто. Я с такими глюками не раз уже воевал. — SM (06.03.2008 23:00:53 80.92.255.53, пустое)