Jump to content

    

Darth Vader

Участник
  • Content Count

    365
  • Joined

Community Reputation

0 Обычный

1 Follower

About Darth Vader

  • Rank
    Местный

Recent Profile Visitors

1356 profile views
  1. Т.е. есть подтвержденный баг, но если его не исправить в течении недели и никто про него ещё раз не напомнил, то считается, что он сам собой исправился и баг-репорт автоматически закрывается? Отличная система!
  2. Это следствие синтаксиса языка. Практического применения не имеет, но не противоречит грамматике языка. Говорит компилятору, чтобы выдавал ошибку при попытке присвоить параметру новое значение в теле функции. Не важно, имеет это какое-то практическое применение или нет. Такое иногда используют, чтобы не плодить лишние локальные переменные. void stupid_delay(int n) { while(n--) __NOP(); } В языке Си нет полноценного встроенного типа данных - массив. Объявление массива: T arr[n]; - это всего лишь описание n последовательно расположенных в памяти объектов типа Т с общим для всех именем arr, обращение к которым возможно через их общее имя и операцию индексирования. В функции массивы всегда передаются по указателю. Объявления void foo(int a[]); void foo(int* a); эквивалентны. В обоих случаях функция принимает аргумент типа int* . И, заметьте, что в обоих случаях она не имеет понятия, что именно ей передают: указатель на начало массива или просто указатель на отдельную переменную. И если это все-таки массив, то количество элементов в нем ёй тоже неизвестно.
  3. Сами придумали? Если нет - приведите ссылку на источник этих знаний. Цитата из стандарта подойдёт.
  4. Не следует использовать динамическое выделение памяти в куче. Вы же утверждали, что Но это всё отступление от темы. А вот это очень показательный ваш код: Вы бы его через компилятор пропустили для начала, ошибки поисправляли. Ничего странного в func1() не видите? Несоответствие между объявлением и использованием?
  5. Если прибор должен быть стоек к РСЭ с оператора напряжением 25 кВ, и испытательным генератом с насадкой-пистолетом непрерывно лупят такими разрядами с частотой 1 Гц в корпус работающего прибора - долго ли он останется работающим? Если есть старый, но работающий комп, который не жалко - можно провести эксперимент на нём. Но, боюсь, что с вероятностью 99,9% результат будет отрицательным. При электропроводном корпусе, гальванически не связанном ни с какими внутренними цепями, обеспечить работоспособность прибора в таком режиме гораздо проще.
  6. По симптомам похоже на неправильный перенос таблицы векторов. Удостоверьтесь, что перенос сделан корректно.
  7. Возьмите тестер в режиме вольтметра переменного напряжения и промерьте им напряжения между всеми корпусами и землями, а также между ними и заземлением в розетке. Может у вас где-то 110 В висит. У меня такое было, когда в сетевом фильтре отпаялось заземление.
  8. Посмотрите тут учебные планы подготовки бакалавров. Там в 1-2 семестрах есть практические занятия на ЭВМ.
  9. Читайте отсюда и далее. Там это обсуждается с разных сторон, как и почему работает загрузчик при записи/стирании флеш-памяти.
  10. Это не страшно. Даже в этом маловероятном случае устройство просто перезагрузится без обновления. При этом и основная программа и загрузчик останутся живы и невредимы. Устройство не превратится в кирпич. Это главное.
  11. Код функции Stm32f0x1Flash::write у вас расположен и исполняется из флеш-памяти или из ОЗУ? Лично я его всегда располагаю в ОЗУ, т.к. вот то, о чем я говорил (суть сразу в первом абзаце, дальше уже не важно, там решение проблемы). Видимо, в STM32 доступ к флеш-памяти организован по-другому и тут такое можно.
  12. Вот. А ведь в это время идет процесс записи или стирания флеш-памяти. Функция записи/стирания пишет в регистры контроллера флеш-памяти, читает оттуда флаги готовности и т.п. Вобщем, формирует некоторую циклограмму. А тут приходит прерывание и исполнение кода прекращается до перевода флеша в основной режим работы. А это должна сделать функция стирания/записи в самом конце. А она зависла где-то в середине циклограммы, где её застало прерывание. Получаем паралич ядра? Патовая ситуация выйти из которой можно только пересбросом?
  13. Для этих случаев предусмотрена возможность переноса таблицы векторов и исполнение кода обработчика из ОЗУ/внешней памяти. Программист должен позаботиться об этом, если предполагает, что такого рода отказы могут случиться. Кстати, а как он ведет себя дальше? Вот перевели мы флеш в режим записи/стирания. Приходит прерывание. Ядро пытается вычитать из флеша адрес обработчика. Шина останавливается, адрес не считан. Что делать дальше ядру? Какую инструкцию выбирать и исполнять? Возвращаться к исполнению прерванного прерыванием кода (запись/стирание флеша), или что-то другое?
  14. Да, остановка. Согласен. Но при попытке ядра считать из флеша по шине инструкцию для исполнения, это приводит к отказу: инструкция не считана, исполнять нечего. То же касается и данных, размещённых во флеше, и адресов обработчиков прерываний. Вобщем, трактовать можно и так и эдак, правильный ответ даст только эксперимент. Например, в Миландровских 1986ВЕ9х такая ситуация однозначно ведет к хардфолту - лично убеждался.
  15. Для примера, для STM32F10x из PM0075 п. 1.2 самый конец (стр. 10): «During a write operation to the Flash memory, any attempt to read the Flash memory will stall the bus. The read operation will proceed correctly once the write operation has completed. This means that code or data fetches cannot be made while a write/erase operation is ongoing. For write and erase operations on the Flash memory (write/erase), the internal RC oscillator (HSI) must be ON» Выделил жирным. Да, про HardFault не сказано. Надо уточнять, что случится при этом. Наверняка какое-то исключение, связанное с отказом доступа к шине (...will stall the bus). Из ARMv7-M Architecture Reference Manual, List of ARMv7-M faults: Т.е. как раз случай отказа доступа к шине при выборке инструкции.