Jump to content

    

johnshadow

Участник
  • Content Count

    32
  • Joined

  • Last visited

Community Reputation

0 Обычный

About johnshadow

  • Rank
    Участник
  1. Согласен. Я когда-то на gps трекерах автомобильных так и делал - в рабочем приложении скачивалась прошивка на внешнюю spi-flash, а затем перезагрузка. Дальше бутлоадер проверяет наличие прошивки и ее корректность на внешней флешке. Если все в порядке - расшифровывает и заливает в основную флеш. И еще - реализация скачивания\докачки по http оказалась проще (реализовывал и ftp, и http).
  2. Согласен. Нужно что-то с функционалом ala ArtMoney, но не ясно как отслеживать если в одном CAN сообщении приходят разные SPN.
  3. Да, в свободном доступе их нет. Т.к. там не FMS, а проприетарщина. :( Можно попробовать такую методику поиска - тыц (сам не проверял).
  4. Если нет стойкой ненависти к паскалю - ниже прилагаю честно подсмотренный где-то модуль, которым пользуюсь в одном проекте. Им определяю подключение\отключение последовательных портов U_Usb.rar
  5. Вот где у нас идеологическая разница - у меня в master попадает только проверенный код, который прошел тестирование в том числе и на группе реальных устройств у клиентов (которые согласились стать бета-тестерами). Таким образом в любой момент из master всегда можно собрать "стабильный" релиз. И как у релизов, так и у бета-сборок однотипный вывод версии - типа "XX.YY дата коммита и короткий hash". Где XX.YY это мажорные и минорные значения версии, которые правятся руками (может быть и тэгом и git). В вашем же случае, если возникает необходимость проверить бету на оборудовании клиента, но клиент столкнется с двумя разными стилями указания версии: 1) Релизная, вида: "XX.YY.buil_num" 2) Бета, вида: "commit_hash" или что-то подобное Т.е. имеем две сущности (два вида), хотя фактически можно обойтись одной: только второй, так как первая не может быть универсальной, ведь она поддерживается только в master ветке. Стоит ли плодить сущности без их необходимости? Предлагаю закончить обсуждение, т.к. оба подхода имеют право на жизнь (и реально применяются) и с обеих сторон было приведено достаточно аргументов, для принятия решения, какой из них более подходящий в конкретном случае.
  6. Так ведь в распределенных СКВ нет возможности проводить сквозную нумерацию билдов\коммитов. Допустим я создал ветку от вашего проекта и работаю с ней, параллельно с вами. У меня свои номера билдов теперь, у вас свои. И как их дальше сравнивать? На mercurial пытались прикрутить сквозную нумерацию, но по моему это отход от идеологии распределенных СКВ. А так как есть дата коммита, то полный hash для однозначного определения конкретного коммита и не нужен.
  7. Вы с этим проектом один работаете? Как без систем контроля версии выполняете модификацию кода? Т.е. каким образом разделяете релизную копию и копию в которой сейчас вносите изменения? По поводу билдов. Зайдите в FireFox в about:buildconfig и обнаружите: Built from https://hg.mozilla.org/releases/mozilla-beta/rev/d171c36d484800b1bb00db1612460a7120dd2fdf Аналогично для Хрома в about:version: Версия 0e9a9a6f3676ae439b78cd9b3f62b4193c3ac7d5-refs/branch-heads/2924@{#895}
  8. А как вы в оффлайне определяете такое написание? Например на сроке годности продуктов? в readme проекта можно указать формат интерпретации даты yyyy-dd-mm или yyyy-mm-dd - для новых участников проекта. Там же можно указать и стили оформления кода и т.п. Уверяю вас - это возможно. Вы же не думаете, что короткий hash создатели git придумали just for fun? И еще момент - "db74878" это первые символы полного hash. Два варианта: 1) выводить в переменную и время. для избегания разночтений - в UTC. 2) в логе git посмотреть полную дату-время коммитов. Контроль версий, как и баэкапы можно не любить, но жизнь вынуждает их применять... рано или поздно. :rolleyes:
  9. У меня из git обычно забирается такой командной, которая выполняется автоматом перед компиляцией: git log --pretty=format:"(%ad %h)" --abbrev-commit --date=short -1 результат потом попадает в h-файл. Получается в итоге: #define GITHASH "(2017-02-03 db74878)" в итоге и дату видно и не нужен длинючий hash. По дате можно определить "новизну" билда, а по hash найти конкретный коммит
  10. Вполне. Есть пару предложений: malloc возвращает void* - т.е. приведение к типу "указатель на Element" не нужно тип переменной на которую указывает tmpElement может в дальнейшем поменяться, я в таких случаях предпочитаю в sizeof использовать сам указатель: Element *tmpElement = malloc(sizeof(*tmpElement)); memset (tmpElement, 0, sizeof(*tmpElement)); проверку на выделение памяти из кучи добавляю так (хотя возможно это и не совсем правильный метод): Element *tmpElement; if ((tmpElement = malloc(sizeof(*tmpElement)))) { memset (tmpElement, 0, sizeof(*tmpElement)); ... free(tmpElement); //если этот кусок памяти больше не нужен }
  11. Возможно. Мне тяжело сейчас предоставить "живой" пример - дело было два-три года назад. Помню, что ошибка проявлялась при совместном использовании оптимизации по размеру и LinkTimeOptimization (Os и flto). Проект был по CooCox и они только добавили опцию LTO у себя в настройках компиляции. Обошел ее используя не библиотечную реализацию: __attribute__((used)) void * memcpy(void * d1, const void * s1, size_t n) { char * d; const char * s; volatile size_t n1 = n; s = s1; d = d1; while (n1--) *d++ = *s++; return d1; } "помогало" именно создание volatile'ной переменной и дальнейшая работа с ней. в противном случае (при использовании аргументной переменной n) бесконечно висел в while - уменьшение переменной не происходило. причем висело не в моем коде, а внутри функций freertos (тогда то ли 6, то ли 7 версии). понимаю, что это все выглядит как рассказ про йети, но... :laughing:
  12. Я просто думал, что для cortex-m0 компилятор генерирует безопасный код в тех случаях когда адрес переменной на момент компиляции не известен. Тогда мне не ясно назначение опции -mno-unaligned-access. Ладно бы hardfault возникал при оптимизациях Os или O3, где побайтовый доступ потенциально приводил бы к раздутию кода или снижению производительности. 2Allregia: Нет, на IAR\KEil не проверял. memcpy при оптимизациях Os\O3 меня уже пару раз подводила. решение со структурой действительно потенциально быстрее, но не будет ли генерироваться ассемблерный код, который будет вылетать при невыровненном доступе?
  13. Пример CDC для F072 можно подсмотреть в форке kuldeepdhaka/libopencm3-examples в ветке example/pwm/stm32f07. под stm32f0xx пришлось в паре мест слегка поправить, т.к. получал hardfault по доступу к невыравненным данным. типа такого: diff --git a/libopencm3/usb/usb_standard.c b/libopencm3/usb/usb_standard.c index d94ceed..da47391 100644 --- a/libopencm3/usb/usb_standard.c +++ b/libopencm3/usb/usb_standard.c @@ -130,7 +130,9 @@ static uint16_t build_config_descriptor(usbd_device *usbd_dev, } /* Fill in wTotalLength. */ - *(uint16_t *)(tmpbuf + 2) = totallen; + //*(uint16_t *)(tmpbuf + 2) = totallen; + *(tmpbuf + 2) = totallen & 0xFF; + *(tmpbuf + 3) = totallen >> 8; return total; } я так и не понял почему компилятор не обрабатывает такие ситуации сам (gcc-arm-embedded 5.4 2016q2). может кто из местных объяснит.
  14. Всегда пожалуйста.
  15. использую libopencm3 на stm32f072 - CDC (для основной проги) и MassStorage (для бутлоадера).