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

    

jcxz

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

    5 530
  • Зарегистрирован

  • Посещение

Репутация

0 Обычный

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

  • Звание
    Гуру
  • День рождения 01.12.1974

Контакты

  • ICQ
    311337544

Информация

  • Город
    Омск

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

13 633 просмотра профиля
  1. Из чего это очевидно? memcpy в IAR проверяет - выровнены ли на 4 оба адреса и если да, то копирует (size & -16) байт (где size - размер из аргумента функции) инструкциями LDM/STM; если адреса не выровнены или (4 <= size < 16) - копирует пословно (по 4 байта LDR/STR); и только остальное - побайтно. Ну вначале ещё немного копирует побайтно, пытаясь выровнять адреса. То же самое возможно и в M0, имхо. "Приведение к упакованной структуре" ничего не порождает, так как анализ указателей и размера происходит внутри memcpy() в runtime и memcpy ничего не знает о типе копируемых данных. И вообще не знает - структура это, или её часть или просто произвольная область памяти. Конечно некоторые компиляторы, имея данные о выравнивании или о размере копирования, могут вместо memcpy() общего вида подставлять специализированные memcpy, оптимизированные под данный случай вызова (не нужны проверки и выравнивания внутри в runtime). Для пользователя (пишущего в коде memcpy()) всё это прозрачно и копирование он может считать побайтным. Если конечно он не сделал глупостей с приведением типа аргументов memcpy() (если такие глупости могут иметь место быть, то компилятор, будучи введён в заблуждение кривым приведением типов, может подставить оптимизированные функции memcpy() вместо memcpy() общего вида - тогда и будут проблемы с выравниванием).
  2. А какой декодер нашли?
  3. Нет. Много лет назад сделал обработку fault-ов. С тех пор просто перетаскиваю её из проекта в проект. Сделал по даташиту на ядро. Там всего ничего регистров. С M0 не работал, только M3/M4.
  4. Архив с шифрованием обычно помогает. В особо тяжких случаях можно дополнительно .exe переименовать во что-то другое.
  5. Под "точкой фаулта (PC)" я имел в виду адрес PC, на котором произошёл fault. haker_fox писал, что у него уже анализируются регистры. По-моему под анализом надо понимать выдачу пользователю содержимого всех регистров CPU + кадра активного стека + расшифровки регистров HF. Типа как в синем окне смерти винды. По-крайней мере у меня во всех проектах сделано именно так.
  6. Так вроде Вы написали, что анализируете:
  7. Зачем? Точку фаулта (PC) знаете? Смотрите в окно дизасма на команды в этом месте и в окно регистров на их значения, и определяете причину.
  8. Когда я писал про то, как сделать FatFS устойчивой к сбоям, я имел в виду подобный метод. Вроде в нём нет никакого ноу хау - всё само собой очевидно. Не раз реализовывал системы хранения подобным образом. Главное правило тут: любая небезопасная операция модификации носителя, должна быть журналируемой (перед её началом должна быть сделана в журнале запись о её начале, содержимое и последовательность планируемых операций, в процессе операции в журнале должно бэкапиться всё содержимое перезаписываемых поверх областей, а после завершения - запись удалена). Небезопасные операции модификации - все операции, которые, будучи прерваны, приведут к нарушению логической структуры хранения на носителе. Примерно так.
  9. Нет конечно. Причём тут невыровненный доступ, если аргументы-указатели функции (memcpy()) могут быть произвольными (байтовыми)? Скорее похоже на то, что Ваш memcpy() лезет в несуществующую память (нарушение границ). Смотрите код в точке fault-а и значение регистров в этой точке. Как вариант: один из ваших new не может выделить память и возвращает NULL, который Вы затем передаёте в memcpy(). Отсюда и доступ в несуществующую память. Почему после new не проверяете возвращаемое ею значение? Это грубая ошибка. Вообще эта ошибка находится за 5 минут, после взгляда в окна дизасма и состояния регистров отладчика.
  10. Ну можно изменить мой метод, добавив перед записью блока, запись в тот маркерный байт отдельного значения "старт записи" например == 0xFE, а после завершения записи блока - записывать в этот байт "завершение записи" == 0xFC. Тогда достаточно только этот байт прочитать. Но выигрыш от этого не велик, так как блоки всё равно лучше проверять на валидность при старте ПО (CRC, ...), а значит их нужно читать полностью по любому. А вот при записи 3 шага вместо 2-х - это уменьшение скорости записи. И чтение блока - операция очень быстрая, я в своих устройствах читал их с внешней флешь по dual-SPI на SCLK == 30МГц - время очень малое.
  11. А что сложного? Выделить один байт в заголовке записываемого блока. При записи блока выставить ему значение == значению стёртой ячейки флешь (предположим это 0xFF). После завершения записи блока выполнить запись поверх этого байта со значением != 0xFF (предположим это 0xFE). Теперь при старте ПО проверяем блок: 1) Если все байты блока имеют значение == 0xFF - блок чистый (не писался); 2) Если в блоке есть байты со значением != 0xFF и наш байт == 0xFE - блок записан полностью; 3) Если в блоке есть байты со значением != 0xFF и наш байт == 0xFF - был рестарт в процессе записи блока.
  12. Дык - на местном FTP вся история этих версий есть.
  13. Зайдите в любой магазин или отдел для вейперов и обнаружите большой выбор 18650. Причём и большетоковых и большой ёмкости.
  14. Неоднократно в обычных магазинах возле дома видел фонарики, которые могут работать от 18650. Даже хотел купить. Но потом заказал на али