Jump to content

    

johnshadow

Участник
  • Content Count

    32
  • Joined

  • Last visited

Community Reputation

0 Обычный

About johnshadow

  • Rank
    Участник
  1. Согласен. Я когда-то на gps трекерах автомобильных так и делал - в рабочем приложении скачивалась прошивка на внешнюю spi-flash, а затем перезагрузка. Дальше бутлоадер проверяет наличие прошивки и ее корректность на внешней флешке. Если все в порядке - расшифровывает и заливает в основную флеш. И еще - реализация скачивания\докачки по http оказалась проще (реализовывал и ftp, и http).
  2. Цитата(alig517 @ May 15 2017, 15:03) геморно это все. Согласен. Нужно что-то с функционалом ala ArtMoney, но не ясно как отслеживать если в одном CAN сообщении приходят разные SPN.
  3. Цитата(alig517 @ May 14 2017, 20:07) Здравствуйте! Друзья, я правильно понимаю, что описание 11 битных идентификаторов по аналогии с описанием протокола FMS(FMS-Standard description) не найти свободно? Нужно либо методом долгих тестов вычислять, либо покупать/выпрашивать у производителя? ... Необходимо найти идентификаторы отвечающие за топливо. Да, в свободном доступе их нет. Т.к. там не FMS, а проприетарщина. Можно попробовать такую методику поиска - тыц (сам не проверял).
  4. Если нет стойкой ненависти к паскалю - ниже прилагаю честно подсмотренный где-то модуль, которым пользуюсь в одном проекте. Им определяю подключение\отключение последовательных портов [attachment=105528:U_Usb.rar]
  5. Вопрос по лицензированию

    Цитата(juvf @ Feb 8 2017, 06:38) все сливается в основной ствол, тестится в основном стволе. Вот где у нас идеологическая разница - у меня в master попадает только проверенный код, который прошел тестирование в том числе и на группе реальных устройств у клиентов (которые согласились стать бета-тестерами). Таким образом в любой момент из master всегда можно собрать "стабильный" релиз. И как у релизов, так и у бета-сборок однотипный вывод версии - типа "XX.YY дата коммита и короткий hash". Где XX.YY это мажорные и минорные значения версии, которые правятся руками (может быть и тэгом и git). В вашем же случае, если возникает необходимость проверить бету на оборудовании клиента, но клиент столкнется с двумя разными стилями указания версии: 1) Релизная, вида: "XX.YY.buil_num" 2) Бета, вида: "commit_hash" или что-то подобное Т.е. имеем две сущности (два вида), хотя фактически можно обойтись одной: только второй, так как первая не может быть универсальной, ведь она поддерживается только в master ветке. Стоит ли плодить сущности без их необходимости? Предлагаю закончить обсуждение, т.к. оба подхода имеют право на жизнь (и реально применяются) и с обеих сторон было приведено достаточно аргументов, для принятия решения, какой из них более подходящий в конкретном случае.
  6. Вопрос по лицензированию

    Цитата(juvf @ Feb 7 2017, 14:19) Как говориться: в чем профит? Так ведь в распределенных СКВ нет возможности проводить сквозную нумерацию билдов\коммитов. Допустим я создал ветку от вашего проекта и работаю с ней, параллельно с вами. У меня свои номера билдов теперь, у вас свои. И как их дальше сравнивать? На mercurial пытались прикрутить сквозную нумерацию, но по моему это отход от идеологии распределенных СКВ. А так как есть дата коммита, то полный hash для однозначного определения конкретного коммита и не нужен.
  7. Вопрос по лицензированию

    Цитата(juvf @ Feb 7 2017, 11:12) просто мне удобней автобилдом контролировать номера релизов. Вы с этим проектом один работаете? Как без систем контроля версии выполняете модификацию кода? Т.е. каким образом разделяете релизную копию и копию в которой сейчас вносите изменения? Цитата(juvf @ Feb 7 2017, 11:12) Нету ни каких диких хэшей из гита, нет даты... По поводу билдов. Зайдите в FireFox в about:buildconfig и обнаружите: КодBuilt from https://hg.mozilla.org/releases/mozilla-beta/rev/d171c36d484800b1bb00db1612460a7120dd2fdf Аналогично для Хрома в about:version: КодВерсия    0e9a9a6f3676ae439b78cd9b3f62b4193c3ac7d5-refs/branch-heads/2924@{#895}
  8. Вопрос по лицензированию

    Цитата(juvf @ Feb 6 2017, 14:20) ps ну вот мне не понятно что было раньше... например 2017-02-03 или 2017-03-02? А как вы в оффлайне определяете такое написание? Например на сроке годности продуктов? в readme проекта можно указать формат интерпретации даты yyyy-dd-mm или yyyy-mm-dd - для новых участников проекта. Там же можно указать и стили оформления кода и т.п. Цитата(juvf @ Feb 6 2017, 14:20) И во вторых.... как по db74878 найти в гите 734713bc047d87bf7eac9674765ae793478c50d3? Уверяю вас - это возможно. Вы же не думаете, что короткий hash создатели git придумали just for fun? И еще момент - "db74878" это первые символы полного hash. Цитата(juvf @ Feb 6 2017, 14:20) в 3-их: у пользователя (или у наладчика на флешке) есть две сборки "(2017-02-03 db74878)" и "(2017-02-03 df56a87)" - какая свежея? я пробовал прикрутить контроль версий.... не вкатило.... не понравилось. Два варианта: 1) выводить в переменную и время. для избегания разночтений - в UTC. 2) в логе git посмотреть полную дату-время коммитов. Контроль версий, как и баэкапы можно не любить, но жизнь вынуждает их применять... рано или поздно.
  9. Вопрос по лицензированию

    Цитата(juvf @ Feb 6 2017, 10:19) да и в гите или в меркуле номер ревизии такой вроде 734713bc047d87bf7eac9674765ae793478c50d3, а у пользователя такой d921970aadf03b3cf0e71becdaab3147ba71cdef. какой из них раньше? ещё есть ветки... как ревизия с разных веток будет приходить.... может какнить можно это приготовить и я его готовить не умею... У меня из git обычно забирается такой командной, которая выполняется автоматом перед компиляцией: Кодgit log --pretty=format:"(%ad %h)" --abbrev-commit --date=short -1 результат потом попадает в h-файл. Получается в итоге: Код#define GITHASH "(2017-02-03 db74878)" в итоге и дату видно и не нужен длинючий hash. По дате можно определить "новизну" билда, а по hash найти конкретный коммит
  10. Цитата(Метценгерштейн @ Dec 12 2016, 19:11) Корректно? Вполне. Есть пару предложений: 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. STM32F0xxx USB без HAL

    Цитата(Сергей Борщ @ Oct 25 2016, 13:26) Интересно. Когда подведет еще раз - выложите сюда, вероятнее всего вы просто не умеете ее готовить. Возможно. Мне тяжело сейчас предоставить "живой" пример - дело было два-три года назад. Помню, что ошибка проявлялась при совместном использовании оптимизации по размеру и 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 версии). понимаю, что это все выглядит как рассказ про йети, но...
  12. STM32F0xxx USB без HAL

    Цитата(Сергей Борщ @ Oct 25 2016, 10:41) Потому что не обязан. Вы же хотите, чтобы ваши программы были маленькими и быстрыми. Используете явное приведение типов - вся ответственность на вас. Я просто думал, что для cortex-m0 компилятор генерирует безопасный код в тех случаях когда адрес переменной на момент компиляции не известен. Тогда мне не ясно назначение опции -mno-unaligned-access. Ладно бы hardfault возникал при оптимизациях Os или O3, где побайтовый доступ потенциально приводил бы к раздутию кода или снижению производительности. 2Allregia: Нет, на IAR\KEil не проверял. Цитата(Kabdim @ Oct 25 2016, 11:10) Кстати патч на мой вкус не очень. В таких случая лучше либо использовать memcpy (в релизе его соптимизируют в инлайн), либо код вроде такого: ... В вашем решении много битовых операций на ровном месте. memcpy при оптимизациях Os\O3 меня уже пару раз подводила. решение со структурой действительно потенциально быстрее, но не будет ли генерироваться ассемблерный код, который будет вылетать при невыровненном доступе?
  13. STM32F0xxx USB без HAL

    Пример 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. STM32F0xxx USB без HAL

    Цитата(Сергей Борщ @ Oct 24 2016, 13:01) Мы рады за вас. Всегда пожалуйста.
  15. STM32F0xxx USB без HAL

    использую libopencm3 на stm32f072 - CDC (для основной проги) и MassStorage (для бутлоадера).