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

    

jcxz

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

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

  • Посещение

Репутация

0 Обычный

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

Контакты

  • ICQ
    311337544

Информация

  • Город
    Омск

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

13 723 просмотра профиля
  1. Странный HARDFAULT

    С такими симптомами - значит проблема уже очень запущена, баг видимо плавающий. Найти будет трудно. Я бы сделал монитор выполнения: запустил прерывание от таймера на максимально возможной частоте, такой, чтобы прерывание случалось не реже чем каждые десяток команд кода. В ISR его сделал сохранение регистров и верхушки стека в кольцевой журнал. А потом, по факту попадания в HF, проанализировал содержимое журнала: в каком месте находилось выполнение непосредственно перед HF, какое состояние регистров, стека и т.п. Если причина HF-ов единственная, то вполне возможно как раз перед HF выполнение будет проходить по проблемному коду. Но конечно не обязательно. В таких случаях очень помогает ETB (обратная отладка). Но этого в МК STM32 вроде как нет, к сожалению.
  2. Cosmic IdeaSTM8 и тип INT

    Есть такой тип? Никогда не использовал...
  3. Странный HARDFAULT

    Почему? Это обычное поведение для ARM-компилятора. Загляните в любой .lst-файл и поищите. LR сохраняется потому что есть вложенные вызовы других функций (команды BL), а R3 - для выравнивания стека на 8.
  4. Cosmic IdeaSTM8 и тип INT

    "Cадись - два!..." В указанных случаях, например на ARM (и на других архитектурах) следует использовать int (или unsigned int). всякие uint8_t будут приводить к неоптимальному коду. PS: Может перестанем хамить и лучше чему-нить поучимся?
  5. Cosmic IdeaSTM8 и тип INT

    По делу есть что сказать? По заданным конкретным вопросам?
  6. Cosmic IdeaSTM8 и тип INT

    Очень сомнительное утверждение. Тем более так категорично. Никогда не говори "никогда". Если скажем имеется цикл for, то какого типа переменную цикла позволите определять, при условии что количество итераций должно быть == 10? А если аргумент функции имеет диапазон 0...100 - какого типа его следует делать?
  7. Почитали, но не поняли... Двоичный, двоично-десятичный и пр. - это форматы текстового представления чисел, а не форматы чисел. А формат хранения (и обработки) чисел в МК это - либо обычное целое (частный случай Q-формата), либо Q-формат (общий случай для чисел с фиксированной точкой), либо плавающая точка. Парсер переводит числа из формата текстового представления в один из форматов хранения чисел. Для представления угловых данных удобно использовать например Q31, получается он из плавающей точки умножением на (1u<<31)/180 с насыщением. Так как диапазон углов -180....+180, то умножаем на (1u<<31)/180, затем выполняем насыщение по диапазону -2^31...+2^31-1 и получаем угол в формате Q31 с полным диапазоном значений: -1.0 соответствует -180, +0.99999999 соответствует +180. Насыщение не обязательно, так как без него +180 автоматом станет -180, а ведь это - одно и то же. Только изредка оно важно. Как можно заметить - для Q31 легко выполняется суммирование углов - просто сумма без всяких последующих проверок (результат автоматом будет в том же диапазоне -180...+180). Ну и т.д. Аналогично можно использовать не Q31, а Q15 если хватает его разрядности и если он удобнее. Или другие разрядности Q. При необходимости - легко конвертировать один Q-формат в другой, простым сдвигом. Точнее сказать: это нормализованное представление угловых значений. Нормализованное по значению 180. И представленное в Q-формате. PS: Вообще советую почитать литературу про цифровую обработку сигналов. В части целочисленной обработки. Там почти вся она на Q-форматах. В систему команд DSP даже команды и регистры входят для аппаратной поддержки Q-формата. В системе команд ARM есть только лёгкие потуги в сторону аппаратной поддержки Q-формата.
  8. гугл в помощь. Википедия хотя-бы. PS: Для угловых данных Q-форматы наиболее оптимальны для обработки/хранения. имхо.
  9. Так запоминайте уже распарсенные значения. У меня так и делается. И их размер никак не зависит от исходной строки, он всегда - Q31. Тем более что строковое представление - совершенно неудобно для последующей обработки (дальнейших целей). Ждать любого количества в разумных пределах. Например - подумать, что для внутренней обработки там используется double и, соответственно, длина строкового представления числа может быть любой до максимального разрешения double. Ну или ещё больше. И вообще - парсер должен быть гибким и как можно менее зависимым от мелких вариаций формата. по возможности. имхо.
  10. А почему Вы решили что формат "другой"? Это цифры - незначащие. Так что - формат тот же самый. Ожидать надо любого положения точки. И по-моему Вы не полностью прочитали мой пост. Я думаю, что количество знаков может зависеть от получаемой сейчас точности определения положения. И меняться в реальном времени. А значат эти цифры - что в данный момент SIM868 определяет положение с бОльшей точностью. А зачем вообще выделять что-то там под строку? Не знаю как Вы там парсите ответы SIM868, но у меня ничего "под строку" не выделяется. Ответы SIM868 парсятся прямо в приёмном FIFO-буфере драйвера SIM868. А он, естественно, много больше, чем место под одну строку, потому что кроме строки GPS, могут приходить и другие URC или ответы на команды. В произвольное время.
  11. А какая разница? И почему у Вас ПО зависит от количества знаков после точки? Вы же, когда на экране нового калькулятора видите больше знаков после запятой, чем было раньше, не впадаете в ступор. Почему тогда это делает Ваше ПО? Такое ПО - неправильное. Вот у меня в одном проекте есть SIM868 и используется GPS, но я даже не обращал внимания сколько там знаков. Какая разница? И мне кажется очевидным, что при развитии firmware SIM868 и выпуском новых версий, SIMCOM вполне вправе изменять количество этих знаков, лишь бы оно было >= чем указано в доке. И я думаю, что в доке указали минимальное разрешение, которое может обеспечить модуль, а при захвате бОльшего числа спутников, точность определения положения увеличивается и количество знаков, естественно, должно увеличиваться (производитель может или передавать там мусор (пока спутников маловато) или не передавать эти знаки (что он и делает получается)).
  12. Имхо - пользователи скажут ещё большее Фи, при тормозящем интерфейсе. По-моему задержки визуального интерфейса гораздо сильнее раздражают, чем какие-то там ступеньки.
  13. Не знаю, вот мой девайс: https://yadi.sk/i/sX7VBDNBiivrMw Фото сделано с расстояния ~30 см, зум - почти максимальный. Как видите - если развернуть фото на весь экран (т.е. - смотреть в упор), то дискретность да - видна. Но попробуйте уменьшить картинку на экране до реального размера LCD (а реальный размер этого LCD = 73 мм по диагонали) и посмотреть с расстояния скажем 20-30 см - тогда дискретность уже становится не заметна.
  14. Может Вы не тот шрифт выбираете? Не знаю - вот передо мной работает мой девайс, шрифты в него я брал виндовые, стандартные, рисую сам - собственные функции рисования, 4bpp, внутренняя CCM память. Ну да - ступенчатость шрифта заметна, но только если в упор разглядывать. С расстояния ~20 см уже ничего не видно. И это у меня 320x240, а если у Вас экран большего размера, то там скорее всего и точки мельче - дискретность ещё менее заметна должна быть. Ну только если не совсем большая диагональ экрана. PS: Ну так и скажите работодателю - нужно сглаживание? Тогда нужен DSP (ну или другое ядро, быстрее работающее с памятью). Но это будет стоить дороже (в плане скорости перехода на него, изучения его). Если он согласен - вперёд.