jcxz 241 27 апреля, 2017 Опубликовано 27 апреля, 2017 · Жалоба Если это нарушить, то возникает аппаратное исключение. Это всё описано в документации. Поэтому у вас проц и виснет. Виснет не поэтому. Виснет потому, что нет обработки этого исключения. :laughing: Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dxp 65 1 мая, 2017 Опубликовано 1 мая, 2017 · Жалоба Виснет не поэтому. Виснет потому, что нет обработки этого исключения. :laughing: Обработчик исключения там есть - обработчик по умолчанию. В нём процессор и сидит, а основная программа при этом висит. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 241 6 мая, 2017 Опубликовано 6 мая, 2017 · Жалоба Обработчик исключения там есть - обработчик по умолчанию. В нём процессор и сидит, а основная программа при этом висит. Наличие обработчика не говорит о наличии обработки исключения. Обработчик может быть пустой. Или только осуществляющий индикацию. Обработка исключения - это набор некоторых действий после исключения, позволяющих вернуть ход выполнения в штатное русло. В данном случае например: выполнить операцию побайтно в обработчике и вернуться в основной поток выполнения. Ну или нечто иное. Раз у Вас там "сидит", значит никакой обработки у Вас нет. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dxp 65 9 мая, 2017 Опубликовано 9 мая, 2017 · Жалоба Наличие обработчика не говорит о наличии обработки исключения. Обработчик может быть пустой. Или только осуществляющий индикацию. Обработка исключения - это набор некоторых действий после исключения, позволяющих вернуть ход выполнения в штатное русло. В данном случае например: выполнить операцию побайтно в обработчике и вернуться в основной поток выполнения. Ну или нечто иное. Раз у Вас там "сидит", значит никакой обработки у Вас нет. Это после любого исключения можно вернуть "в штатное русло"? Наверное поэтому каждый видел сообщения ОС "Приложение выполнило недопустимую операцию и будет завершено". Невыровненный доступ на Blackfin - невыполнимая операция. И выполнить её "побайтно" вы не сможете. Там просто нет никакой дополнительной информации - какой был доступ. Кроме того, чаще всего такая ошибка возникает ни из-за того, что программист ошибся и выполнил такой доступ (на том же Си не так просто это сделать, т.к. компилятор правильно организует доступ). А возникает это из-за как правило из-за ошибок работы с памятью - порчи стека, ошибок адресной арифметики и т.д. - вот тут-то и лезет обращение по невыровненному адресу. И как тут прикажете исправлять? Поэтому никто там ничего не исправляет - возникло такое исключение - прибили задачу, если это взрослая ОС. А в bare-metal - просто индикация и больше никакой дополнительной обработки. Автор программы должен исправить причину (порчу памяти), тогда и следствий (невыровненного доступа) не будет. Т.ч. у каждого свои понятия, что есть обработка. Какая-то она есть. А другую там и применить. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 241 11 мая, 2017 Опубликовано 11 мая, 2017 · Жалоба Это после любого исключения можно вернуть "в штатное русло"? В зависимости от алгоритма работы ПО - возможно. Наверное поэтому каждый видел сообщения ОС "Приложение выполнило недопустимую операцию и будет завершено". Вот это и есть - один из вариантов реализации такого Обработчика исключений. Не тупо зависнуть на заглушке, а собрать необходимую информацию об исключении. И выдать её пользователю. Либо сохранить её куда-то и перегрузиться. Это всё и есть - "штатные русла выполнения ПО после исключения". У меня исключения как правило именно так и обрабатываются. Если нет каких-то спец. требований. И выполнить её "побайтно" вы не сможете. Там просто нет никакой дополнительной информации - какой был доступ. Да ладно? Все могут, а я не смогу? А значение PC при возникновении этого исключения разве не известно? Даже с учётом конвеера DSP я думаю возможно будет определить команду вызвавшую его. А дальше всё штатно, как и для других архитектур, где есть такие же ограничения: декодируем код команды, режимы адресации, регистр, вычисляем результирующий адрес доступа и операцию, и выполняем её. А возникает это из-за как правило из-за ошибок работы с памятью - порчи стека, ошибок адресной арифметики и т.д. - вот тут-то и лезет обращение по невыровненному адресу. И как тут прикажете исправлять? Как правило такая ошибка чаще всего возникает при некорректной работе с указателями. Конечно - при разработке ПО её лучше исправить. Но в каких-то редких случаях может быть полезной и программная эмуляция невыровненного доступа. Например - в Cortex-M я видел рекомендации по использованию исключения невыровненного доступа именно для программной эмуляции этой операции и возвращения выполнения в штатное русло. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dxp 65 12 мая, 2017 Опубликовано 12 мая, 2017 · Жалоба Вот это и есть - один из вариантов реализации такого Обработчика исключений. Не тупо зависнуть на заглушке, а собрать необходимую информацию об исключении. И выдать её пользователю. Либо сохранить её куда-то и перегрузиться. Это всё и есть - "штатные русла выполнения ПО после исключения". У меня исключения как правило именно так и обрабатываются. Если нет каких-то спец. требований. И что это даёт? Ну, перезагрузилсь - и что? Проблема-то не решена. В программе баг, ваши перезагрузки его не исправят. Да ладно? Все могут, а я не смогу? А значение PC при возникновении этого исключения разве не известно? Даже с учётом конвеера DSP я думаю возможно будет определить команду вызвавшую его. А дальше всё штатно, как и для других архитектур, где есть такие же ограничения: декодируем код команды, режимы адресации, регистр, вычисляем результирующий адрес доступа и операцию, и выполняем её. Насчёт PC не знаю. Но даже если это известно, это не поможет. При возникновении исключения из-за невыровненного доступа у Blackfin в регистре SEQSTAT лежит код 0х24 (Data access misaligned address violation), всё, больше никакой информации нет. Вы не можете определить, был ли 32-разрядный доступ по адресу, кратному 8 бит или по адресу 16 бит, или это был 16-разрядный доступ ко нечётному адресу. И как вы будете тут что-то исправлять? А самое главное - в 99% (если) случаев это исключение возникает из-за "прострелов" памяти, т.е. тут даже если знать всё о точке возникновения исключения и о размерах выравнивания, это всё равно абсолютно ничего не даёт - бессмысленно исправлять доступ, когда ошибка совсем в другом. На ARMv7 тут и исключения не возникнет, т.к. эта ISA поддерживает невыровненный доступ, но это лишь отсрочивает обнаружение проблемы. А на Blackfin обнаруживается в том числе и по этому признаку, т.к. его аппаратура не поддерживает невыровненный доступ. Только и всего. И такие ошибки в программе на РС всегда заканчиваются выдачей Segmentation Fault и аварийным завершением программы. И лучшее, что тут можно сделать - это организовать какую-то выдачу информации о коде ошибки. Но мне и это было не надо - если программа зависла, я делаю останов эмулятором и смотрю, что там произошло. Если висит в обработчике исключения, то смотрю код исключения. Если он указывает на невыровненный доступ, то даже не сомневаюсь, что где-то "прострелило" память. И в подобной ситуации практически на любом МК ничего принципиально иного - т.е. возможности исправить ход выполнения программы, - сделать нельзя. А ваши доводы - это теоретизирование. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 241 12 мая, 2017 Опубликовано 12 мая, 2017 · Жалоба И что это даёт? Ну, перезагрузилсь - и что? Проблема-то не решена. В программе баг, ваши перезагрузки его не исправят. Вы что-то не догоняете... ;) Причём тут баг? Баги надо исправлять, а не костыли для них делать - это несомненно. Речь не о багах, а когда по каким-то причинам необходимо изредка обращаться к памяти невыровненно. Именно штатно, а не при баге. При чём тут все эти разрушения памяти и переполнения стека?? Речь вообще не об этом. Я же писал о штатном русле выполнения, в котором такие исключения - вполне стандартный путь поведения ПО. Это во-первых. Во-вторых - даже если это нештатное поведение программы, баг, то как раз запись точки события (со всем контекстом) в энергонезависимую память - это очень помогает в нахождении этого бага. Похоже у Вас мало опыта в разработки сложных систем, работающих у заказчика круглые сутки. Иначе бы понимали, что возможны ситуации когда твоё устройство работает скажем месяц у заказчика не выключаясь без сбоев, а потом происходит внезапный сбой (например - неожиданное исключение). Т.е. - очень редкий. Воспроизвести это "на столе" практически невозможно, так как происходит оно при редком стечении множества факторов в определённой последовательности. Сколько не отлаживай на столе - не получается воспроизвести. И визуально не найти - объём ПО - десятки тысяч строк, а то и сотни. Вот тут как раз очень помогает запись таких событий. В опытной эксплуатации на объекте заказчика работает множество таких устройств, скажем месяц. Набирается статистика таких сбоев (если есть). И потом по ней уже можно искать причину. Я много раз сталкивался с такими случаями. Насчёт PC не знаю. Но даже если это известно, это не поможет. При возникновении исключения из-за невыровненного доступа у Blackfin в регистре SEQSTAT лежит код 0х24 (Data access misaligned address violation), всё, больше никакой информации нет. Вы не можете определить, был ли 32-разрядный доступ по адресу, кратному 8 бит или по адресу 16 бит, или это был 16-разрядный доступ ко нечётному адресу. И как вы будете тут что-то исправлять? Опять-же - это Вы не можете, а у меня всегда почему-то получалось :laughing: Я ещё ни на одной архитектуре (где есть исключения/прерывания) не видел такого, чтобы не возможно было определить точку, где оно произошло. Адрес возврата всегда есть. А для тех исключений, где по адресу возврата не определить адрес исключения (в Cortex например такие есть), адрес сохраняется в спец. регистре. А как именно определить какой доступ и скольки-разрядный и прочее - я писал выше. Если не понятно, разжую: Скажем по адресу возврата минус одна команда увидели команду: LDR R0, [R1] - попробуйте догадаться скольки-разрядный доступ был и по какому адресу? :laughing: И как именно программно сэмулировать это невыровненное чтение? Имхо - даже начинающий должен догадаться.... :laughing: На ARMv7 тут и исключения не возникнет, т.к. эта ISA поддерживает невыровненный доступ, но это лишь отсрочивает обнаружение проблемы. А на Blackfin обнаруживается в том числе и по этому признаку, т.к. его аппаратура не поддерживает невыровненный доступ. Очевидно, что Вы не знаете не только архитектуру Blackfin, но и в архитектуре Cortex-M тоже не разбираетесь. В Cortex-M только некоторые команды поддерживают невыровненный доступ. Да и то - опционально. Большинство команд обращения к памяти его не поддерживают. И лучшее, что тут можно сделать - это организовать какую-то выдачу информации о коде ошибки. Но мне и это было не надо - если программа зависла, я делаю останов эмулятором и смотрю, что там произошло. Ну да - теперь попробуйте это сделать когда это произошло на объекте заказчика за несколько тысяч км в ночь с 31-го декабря на 1-е января. И с учётом того, что работу объекта остановить нельзя ни на час. У Вас совсем нет практического опыта работы как видно - не представляете как реально происходят такие сбои. Ваш настольный опыт тут не поможет. А ваши доводы - это теоретизирование. "Давайте не спорить о вкусе устриц с теми кто их ел" (С) ... :laughing: Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dxp 65 12 мая, 2017 Опубликовано 12 мая, 2017 · Жалоба <флуд поскипан> Окей, давайте докажите на практике, а то ваша пустая болтовня уже поднадоела. Вот возникло исключение - в регистре SEQSTAT код 0х24. Ваши действия? Причину вы не знаете - может память испорчена, а может программист на ассемблере что-то писал и накосячил с доступом. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 241 12 мая, 2017 Опубликовано 12 мая, 2017 · Жалоба Окей, давайте докажите на практике, а то ваша пустая болтовня уже поднадоела. Вот возникло исключение - в регистре SEQSTAT код 0х24. Ваши действия? Причину вы не знаете - может память испорчена, а может программист на ассемблере что-то писал и накосячил с доступом. Доказываю я работодателю своей работой. Моё время дорого стоит. Хотите чтобы сделал за Вас работу? Докажите, что способны оплатить моё время! А то Ваш пустой трёп поднадоел - как видно предмета обсуждения Вы не знаете, а пытаетесь что-то советовать.... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dxp 65 12 мая, 2017 Опубликовано 12 мая, 2017 · Жалоба Доказываю я работодателю своей работой. Моё время дорого стоит. Хотите чтобы сделал за Вас работу? Докажите, что способны оплатить моё время! А то Ваш пустой трёп поднадоел - как видно предмета обсуждения Вы не знаете, а пытаетесь что-то советовать.... Не сомневался в таком ответе. Вы не знаете, как это сделать, вот и юлите. Я утверждаю, что из исключения, возникающего на Blackfin из-за невыровненного доступа, невозможно вернуть программу в рабочее русло корректно. Вы же в своей манере менторским тоном как обычно порите чушь, что это можно. Раз утверждаете - докажите. Ваше словоблудие, на которое вы тут тратите ваше "драгоценное" время, - это не доказательство. Не можете показать, не надо выступать. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 241 13 мая, 2017 Опубликовано 13 мая, 2017 · Жалоба Я утверждаю, что из исключения, возникающего на Blackfin из-за невыровненного доступа, невозможно вернуть программу в рабочее русло корректно. Вы "знаете"??? Ха! Вы даже не знаете как узнать значение PC при котором произошло исключение. Значит Вы не знаете даже базовых основ работы системы исключений в том процессоре, о котором что-то "утверждаете". А значит всё что Вы тут понаплели - как раз и есть словоблудие. И я нигде не утверждал, что знаю Blakfin. Я с ним не работал. Но много работал с другими DSP и Cortex-M, про которые Вы тут тоже несли чушь не владея предметом. И по аналогии с ними, могу предположить, что на Blakfin-е дела обстоят точно так же. И то что Вы этого не знаете - ни о чём не говорит. Так что это уж скорее к Вам пожалуйста не тратьте драгоценное время всех читателей этой темя на чтение Вашего словоблудия. :laughing: ЗЫ: И так: Раз утверждаете что "невозможно вернуть программу в рабочее русло " - докажите. Не можете показать, не надо выступать. Вот именно. B) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dxp 65 14 мая, 2017 Опубликовано 14 мая, 2017 · Жалоба Ответа по существу так и нет. Ok, слив засчитан. Впрочем, ничего иного от вас ожидать и не приходится - только постоянные попытки давать оценку личностям оппонентов и расчёсывание собственного ЧСВ. Видно что искусство чтения Вам недоступно. Вот это похоже на правду - что не умеете читать. Похоже у Вас мало опыта в разработки сложных систем Очевидно, что Вы не знаете не только архитектуру Blackfin У Вас совсем нет практического опыта работы как видно Вы читать умеете? А понимать смысл прочитанного? Очевидно Вы не имели опыта работы с SDRAM, а у меня ... Прочитайте выделенное несколько раз, пока не поймёте. Моё время дорого стоит. По двору разнёсся слух, Что сильнее всех петух, Что вчера в ужасной драке Оторвал он хвост собаке, Гусаку намял бока - Покалечил гусака... А распускает этот слух... Сам петух Оставайтесь колотить понты. Всего вам хорошего. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 241 15 мая, 2017 Опубликовано 15 мая, 2017 · Жалоба Так всё-таки - как узнать значение PC прерванного процесса в прерывании/исключении на Blackfin? :rolleyes: Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться