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

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

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

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

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

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

Отправлено кэп 06 марта 2008 г. 19:51
В ответ на: Ну тогда, если ничего уже не помогает, копайте ассемблерный код, сгенеренный компилером. Возможно прерывание портит что-то такое, о чем Вы не подозреваете, но что нужно между вычитыванием переменной и проверкой условия case. отправлено SM 06 марта 2008 г. 19:50

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

Ответы

может, может. Внимательно смотрите ассемблерный текст. Кстати, ничего ассемблерного самодельного нет? — 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, пустое)