Перейти к содержанию

    

haker_fox

Свой
  • Публикаций

    3 020
  • Зарегистрирован

  • Посещение

Репутация

0 Обычный

Информация о haker_fox

  • Звание
    Познающий...
  • День рождения 18.01.1986

Контакты

  • Сайт
    http://
  • ICQ
    339085018

Информация

  • Город
    г. Иркутск

Посетители профиля

Блок последних пользователей отключён и не показывается другим пользователям.

  1. STM32L0 HardFault: заморочки с выравниванием

    Простите, это я код некорректно привёл. Указатель на null проверяется. Там всё ок. А на счёт выравнивания меня эта статья смутила. Там написано, что __aeabi_memcpy4 ожидает выровненных указателей.
  2. А не поделитесь?)))) Если в электронном виде доступна... А за описание алгоритма - спасибо!!!! Интересный подход!
  3. STM32L0 HardFault: заморочки с выравниванием

    Это же указатель на массив из байт. Я вот и не могу понять, нужно ли массиву указывать это слово.
  4. STM32L0 HardFault: заморочки с выравниванием

    Поторопился с выводом. Даже с __packed падает(((
  5. STM32L0 HardFault: заморочки с выравниванием

    Извините за подъйм старой темы. Но что-то я запутался. Вот фрагмент кода из функции для Cortex=M4F uint8_t * ptr1 = new uin8_t[128]; uint8_t * ptr2 = new uint8_t[128]; memcpy( ptr1, ptr2, 128); Периодически схватываю HF, в окне Call Sack отладчика точка вылета __aeabi_memcpy4 + 0x5. В отладчике HF у меня есть анализ регистров, и причина указан "A data bus error has occurred". Я так понимаю, это невыровненный доступ. Значит надо писать так? __packed uint8_t * ptr1 = new uin8_t[128]; __packed uint8_t * ptr2 = new uint8_t[128]; memcpy( ptr1, ptr2, 128); Ошибка, вроде, ушла. А для uint32_t * ключевое слово __packed выходит не требуется?!
  6. Ну, во-первых, не нужно троллить в ветке, отличной от "Общения". Тогда наш разговор уже давно бы стал конструктивным. Во-вторых, вы сделали заявление, что Я понимаю, что это не мне адресовано. Но! Ответить я на это был вправе. Хорошо, отбросим проблемы с ерратами микросхем. Но безбажную прошивку для более-менее сложного объекта написать всё равно проблематично. Хотя бы по причине, указанной iosifk. И вы просто не будете в курсе как правильно расставить эти базовые основные команды для неполностью изученного физического объекта.
  7. А сколько каналов (я имею в виду вычислительных) принимает решение? Если один, то можно ли ему верить?
  8. Угу. Это только у теоретиков, всё гладко. У них программы без багов. А то, что баг, по-сути может содержаться в алгоритме, хотя бы по причине не полностью ислледованного и смоделированного (и то и другое иногда сделать невозможно) физического объекта им невдомёк.
  9. И всё-таки, вы, полагаю, именно такие программы и пишите? Или это потаённое желание души?
  10. Не надо штамов, пожалуйста. Причины багов я уже описал. Кстати, в случае сварного соединения... их тоже дублируют, троируют, другими словами закладывают запас прочности. На один шов будет надеяться только не очень... практичный человек. Если шов может быть только один (трубопровод), то после сварки его дефектуют. И никто не положится на мастерство сварщика в таком случае. Но шов задефектовать - это одно, а оттестировать вновь созданное ПО - другое. Вы как-то забываете, что только компьютер довольно отлично отлаженная железка в силу его распространённости (на каждгом столе стоит). А железо прибора, которое каждый раз уникальное - может содержать новые, ранее неприменяемые, компоненты, недокументированные errata, особенности микросхем и т.п. В общем, вы, либо троллите, либо действительно ещё не очень опытный разрботчик. Приведите, пожалуйста, примеры своих разработок.
  11. Тут всё нормально, ибо мой вопрос был относительно системы, которая работает в условиях подстанции. И здесь экономить на компонентах - самому себе пилить сук) Вы меня простите за прямоту, но так будет понятнее. Итак, говорить, что код писать грешно может человек с небольшим опытом разработки. Без обид. Который не занимался написанием кода для реальных приборов, которые должны выполнять широкий спектр функций: измерять что-то с датчиков, иметь USB Host/Device, MMC/SD, Ethernet (на нём modbus, web, ftp, ssh, telnet и мн. другое), возможно GUI, вести логи, расчёты. Иметь повторяемость при сборке на производстве. И т.д. и т.п. Предвидя справедливый такой же прямой ответ я поясню свою позицию. Современные компоненты довольно сложны. Возьмите теже АЦП ADS1247, ADS131E08. Описания только на на "банальные" АЦП превышает 100 стр. За всеми нюансами порою уследить невозможно. Когда вы начинаете реализовывать функции, о которых я сказал выше, вы начнёт задействовать такие модули микроконтроллера, как DMA, MAC, MMCSD, различные матрицы и коммутаторы внутренних событий, блоки делителей и умножителей. Некоторая периферия относительно подробно описана в документации, и тем не менее имеет особенности, которые вылазят не сразу, а спустя недели эксплуатации. И это не баг в коде напрямую, а недокументированная особенность периферии. И сразу вы её не отловите, а приборы уже стоят на объектах. Потом - сложность и нетривиальность некоторых измерительных алгоритмов. Вы их отладили в лаборатории, на паре объектов. А на одном из них - раз и вылезла мелкая особенность. И - поездка на объект, сбор данных, разбор в чём дело - правка софта. Мой любимый пример: Airbus A321 летает более 20 лет, а ПО авионики обновляется до сих пор. И это не карты навигации. А уровень тестирования такого ПО - это не уровень пилорамы. Может быть я в вашем случае ошибаюсь, и вы пишете ПО без ошибок. Я могу в это поверить. Но, скорее всего, вы почти единственный такой, либо выпускаете относительно несложные приборы. Если я не прав, добавьте свой ответ) Такое случается, но не в этом дело. Обычно ПО такого уровня должно писаться независимыми командами, а блоки управления - троироваться. Либо ПО нужно прогонять через анализаторы кода, и... тестировать, тестировать и тестировать. Другими словами отказ таких систем не должен быть результатом ошибки одного человека, и даже не только одного. Не верю))) Глючат. Сам наблюдал. Siemens S7-300. Но дело не в этом. Надёжность системы управления обеспечивается не только вылизанным кодом, но и резервированием. См. fault-tolerant системы. Здесь и ветка есть интересная. Мы правда там авионику обсуждали)
  12. jcxz, в очередной раз от всего сердца благодарю вас за такой развёрнутый ответ! Вот бы поработать с вами в одной команде, мог бы многому научиться)))) Но... до Омска мне далековато)))) В общем мне всё стало понятно!!!! Этот вариант мы рассматривали тоже. Но, вариант от уважаемого jcxz мне нравится больше, т.к. он устойчив ко многим типам сбоев, и не требует усложнения системы электропитания прибора, дополнительного ПО для безопасного останова проца. А в этом ПО тоже могут быть ошибки, соответственно, ещё не известно, сохранятся данные или нет...
  13. Простите, но я тогда не понимаю, как писать по кольцу? Допустим, я накапливаю на флешке файлы лога, длина которых варьируется от 50 до 150 кБ. Логов допустимо хранить 20, затем они переписываются, начиная со старшего. Т.е. сами логи пишутся в большом кольце, а внутри логи писать тоже по кольцу? Но как? Я понимаю, могу задавать тривиальные вопросы, но мне действительно не очень понятно. Буду премного благодарен, если "разъжуёте")))) И можно ли при таком подходе писать файлы вперемешку, как на "настоящей" ФС? Например, файл лога + текстовый файл и т.п.
  14. Ну всё-таки в момент выключения питания потеряется минимум одна страница флеши. Спасибо, изучу её. На всякий случай вопросы: она поддерживает несколько разделов? Совместима с FAT (полностью)? Есть ли какие ограничения, прямо не указанные на сайте?
  15. Добрый день, коллеги! В приборе, которому могут неожиданно отключить питание, необходимо сохранять логи (файлы длиной 50 - 150 кб). Допускается потеря лога в момент отключения питания (либо другого сбоя), но не разрушение ФС вместе с остальными данными. Прибор сделан на базе Cortex-M4F. Используем FreeRTOS. Из журналируемых "свободных" решений нашёл только uc/FS. Может быть есть какие-либо ещё доступные ФС с такими возможностями, пригодными для применения в embedded? В целом, не требуется совместимости с FAT, хотя и желательно. Посоветуйте, пожалуйста, что-нибудь! Очень заранее благодарен!)))