rusefi.com

russian wrote:Текущая версия была последней в тот момент, а сейчас она уже не последняя.

Не-ет, что-то тут не так... И проблема, возможно, посерьёзнее, чем кажется на первый взгляд...
Вы же всего несколько месяцев назад портировались на новый ChibiOS, верно? Но дело в том, что в этот ваш форк почему-то попали файлы годичной давности вместо свежих (на тот момент) файлов!..
Смотрим. Вот первый ваш коммит за 22-е марта ("[rusefi] First batch of changes"): https://github.com/rusefi/ChibiOS/commit/3f25f7b5e9e81dd6135c7df7c82782a685acf648.
Отлично. Сразу перед ним в списке идёт обычный авторский коммит Джованни от 3-го марта ("Fixed bug #818.") - казалось бы, свежий на тот момент: https://github.com/rusefi/ChibiOS/commit/7cac0e4b0889b9f22fb998e48ac2a5e3f06e0b93.
Идём по этой ссылке и видим там файлы годичной давности: release_note_16.1.0.txt (a year ago). И приписку "Read only mirror of SVN ChibiOS repository."...
А теперь фокус! Идём на текущий репозиторий ChibiOS и находим там этот же коммит Джованни от 3-го марта! Вот он: https://github.com/ChibiOS/ChibiOS/commit/8e47415958cd7ca27a36e0ab926bc437950b975e.
И смотрим там файлы. Они другие! Тут уже, например, сидит release_note_next.txt 3-месячной давности, как и положено, и остальные файлы соответствуют датам.

В общем, не знаю, что произошло, но, похоже, вы портировали отнюдь не последнюю на тот момент версию, а какое-то старое зеркало с svn-репозитория...
Я не спец по этим модульным штукам гита. Я могу только предполагать, что примерно в то время переезжали с sourceforge на гит, и то ли у Джованни, то ли у вас что-то не заладилось немножко...

В моём понимании вопроса git толжен показать нам полную историю https://github.com/rusefi/ChibiOS/tree/stable_rusefi

Делал этот бранч @

Например https://github.com/rusefi/ChibiOS/tree/stable_rusefi/os/hal показывает нам какие-то коммиты 3 месяца назад в стиле "Fixed bug #817."

Подробнее знает @, который в slack обещал завтра попробовать накатить свежее из свежего 3.1 бранча.

Один из спорных нюансов https://github.com/rusefi/ChibiOS/tree/stable_rusefi - я там папки удалял, то ли зря, то ли не зря.

Можно читать от https://www.atlassian.com/git/articles/git-forks-and-upstreams и до забора. По уму можно родить правильную команду для git diff между https://github.com/rusefi/ChibiOS/tree/stable_rusefi и https://github.com/ChibiOS/ChibiOS/tree/stable_16.1.x

Возможно мне стоит вернуть удалённые папки. Возможно @ нам наколдует, если его хорошо попросить

russian wrote:показывает нам какие-то коммиты 3 месяца назад в стиле "Fixed bug #817."

Отличный пример. Сравни:
https://github.com/rusefi/ChibiOS/tree/024738d265bd3ef20dff3bb2809feabe3e24fb32/os/hal/include
и
https://github.com/ChibiOS/ChibiOS/tree/47a8438f5b7e146294a666a3e3ed3151fba8e9b9/os/hal/include
Под одним и тем же "Fixed bug #817." числятся разные файлы. В одном есть hal_dac.h ((с) 2016), в другой - dac.h ((с) 2015).
Файлы едва-едва отличаются, но в каждом действительно присутствует фикс #817!..
Такое ощущение, что Джованни ведёт параллельно несколько версий, и умудряется фиксить баги сразу во всех...

Не смогу сейчас хорошо в это вникннуть Нужно пинать @

rusEfi патч chibios очень небольшой, пара килобайт. Нужно этот патч в какой-то момент всё-таки куда-нить заново записать.

Джованни может фиксить в нескольких ветках руками, может заголовки master отличаются от заголовков 16.1?

А может вообще нагло спросить на ChibiOS forum-е?

Выложил маленький, но полезный pull request!

В настройках есть "Firing Order", которая задаёт последовательность зажигания цилиндров (1-3-4-2 у нас). И есть подозрение, что подключать катушки нужно напрямую: 1-й выход на 1-ю катушку, 2-й - на 2-ю, 3-3, 4-4. А порядок работы задаёт сама прошивка по этой вот настройке. Так ли это?
2) А форсунки используют firingOrder? или их нужно подключать по иной схеме?
Речь идёт о фазированном впрыске, где порядок впрыска имеет значение. Или же нужно задавать самим фазы впрыска и порядок работы.

и форсунки, и катушки конечно же используют firing order - так что катушки и форсунки нужно подключать по расположению на двигателе, и потом задавать порядок зажигания.

А как задать пароль и имя для блютус модуля? В консоли или в студии?

Отправлено с моего PRO 6 через Tapatalk

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

puff wrote:а с чего бы оно в консоли или в студии задается?
читай внимательно мануал к модулю - там всё подробно разжевано. понадобится только переходник усб-сериал.

Ну например в секу для настройки блютус соединения используется стандартный менеджер, там задается имя сети и пароль

Отправлено с моего PRO 6 через Tapatalk

сеть блютус?
в rusefi, насколько я знаю, такого нету. просто цепляешь свой модуль к пинам tx/rx и получаешь блютус интерфейс.

Как puff говорит - rusefi просто использует uart, не зная что это bluetooth. может речь про wifi?

russian wrote:может речь про wifi?

Нет, речь именно о bluetooth-модуле. На плате frankenso, как я видел, тоже предусмотрена возможность его запаять. И легко себе представить ситуацию, когда юзер запаяет непроинициализированный модуль. Как его после этого проинитить? Легче всего, для юзера - через консоль. Дык вот, в СЕКУ была как раз удобная фича - по команде из менеджера прошивка временно переключалась на 9800 бод и посылала по UART AT-команды (в модуль) для задания имени, пинкода и битрейта. Вот, думаю, и нам можно бы сделать подобное и подцепить это на соответствующую команду rusEFIconsole. Тогда не нужен будет внешний шнурок UART..

принимаю вкусные PR

выдаёт ли triggerSimulatorPins только сигнал ДПКВ, или для распредвала тоже?
Вообще, стоит ли подавать сигнал датчика фаз (1 зуб) как CamInput или лучше как primary/secondary trigger в режиме 1+60-2

про BT - тогда надо смотреть разводку места под модуль - для перепрогрммирования, если память не изменяет, надо какие-то пины куда-то закорачивать. а после этого - возвращть в нормальный режим.
плюс для разных модулей (HC05?HC06?) разные инструкции. как по мне - лишняя головная боль. проще в инструкции по сборке указать, как оно должно быть проинициализировано, прежде чем запаивать в плату. впрочем, это не означает, что пользователю не захочется менять натсройки позднее.

так что опять, смотреть в разводку платы...


кстати, хз как оно будет вести себя внутри корпуса. вроде бы meXanicus имел опыт работы с блютусом в живом авто, но вот не уверен, что он помещал его в металлический корпус...

puff wrote: но вот не уверен, что он помещал его в металлический корпус...

а кто говорил про металлический корпус?

в самом деле, ой.
а почему bluetooth, не вайфай?

puff wrote:в самом деле, ой.
а почему bluetooth, не вайфай?

Модуль блютус уже имеется, да и с wifi не работали

Отправлено с моего PRO 6 через Tapatalk

darxfame wrote:выдаёт ли triggerSimulatorPins только сигнал ДПКВ, или для распредвала тоже?
Вообще, стоит ли подавать сигнал датчика фаз (1 зуб) как CamInput или лучше как primary/secondary trigger в режиме 1+60-2

давай для простоты стараться меньше смешивать вопросы, а то вероятность запутаться повышается?

Нет разделения ДПКВ или распред в rusEfi - есть многоканальный сигнал с точными углами. И есть отдельно сверху определение фаз, совмещённое с переменными фазами.

http://rusefi.com/wiki/index.php?title=Manual:Software:Trigger#Trigger_Simulation

rusEfi has a feature of trigger signal emulation on Trigger Simulator Pins. All channels of trigger input would be simulated on corresponding channels of Trigger Simlator.

At the moment rusEfi has no means for VVT/camInput simulation.

Для случаев 1+60-2 я думаю твой точно позиции "1" в списке известных форм нет, так что единственный вариант - это camInput. camInput не умеет симулироваться сейчас.

Dron_Gus wrote:Хотел поинтересоваться, есть ли какие-то причины (кроме отсутствия времени/желающих), почему сейчас используется два шнурка для получения двух сериальников (usb + uart)? Может есть какие-то ограничение и композитному устройству на этом проце не хватает ресурсов?
Есть желание поковырять это, но не хочется зря потратить время и натснуться на какие-то известные грабли.

https://github.com/rusefi/rusefi/issues/52

Looks like there are some issue with using both ports as serial-over-USB at the same time: http://forum.chibios.org/phpbb/viewtopic.php?f=3&t=1687

http://forum.chibios.org/phpbb/viewtopic.php?f=2&t=1118&start=20

russian wrote:Looks like there are some issue...

Вот черт. Есть какая-то линия партии по использованию другого USB?

Dron_Gus wrote:Вот черт. Есть какая-то линия партии по использованию другого USB?

в 407 всё-таки дискавери рулит, так что выбора USB нет. нужно смотреть, как будет вести себя STM32F427VG - будет ли там ситуация такая же или лучше на этих же пинах? именно STM32F427VG не 469

russian wrote:

Dron_Gus wrote:Вот черт. Есть какая-то линия партии по использованию другого USB?

в 407 всё-таки дискавери рулит, так что выбора USB нет. нужно смотреть, как будет вести себя STM32F427VG - будет ли там ситуация такая же или лучше на этих же пинах? именно STM32F427VG не 469

Да. Там на OTG_FS уже 6 эндпоинтов. Этого должно хватить.

Вообще че-то они кисло сделали. Самый мелкий SAMDA1 от Atmel имеет 16 ендпоинтов.

russian wrote: в 407 всё-таки дискавери рулит, так что выбора USB нет. нужно смотреть, как будет вести себя STM32F427VG - будет ли там ситуация такая же или лучше на этих же пинах? именно STM32F427VG не 469

Поизучал вопрос. CDC не обязательно именть Interrupt EP - т.е. для него достаточно Bulk In + Bulk Out. Теоретически можно сделать 3 х CDC или CDC + CDC + MSD. Какой вариант нас интересует?
Начал ковырять это. С наскоку не получилось, надо патчить имплементацию CDC.

Два порта плюс mass storage самым заманчивым вариантом будет.

А ты хочешь спросить на chibios форуме, почему они решили использовать interrupt? им так проще просто?

russian wrote:А ты хочешь спросить на chibios форуме, почему они решили использовать interrupt? им так проще просто?

Это качует из примера в пример. Почитал спеку на CDC - эта EP опциональная и используется только для уведомления хоста о изменении состояния - в нашем случает ничего не меняется. Да и во всех примерах что я диагонально изучил - никто ничего через нее не шлет.
Кстати в их же примере https://github.com/ChibiOS/ChibiOS/blob/47a8438f5b7e146294a666a3e3ed3151fba8e9b9/os/hal/src/hal_serial_usb.c#L223 .
Без int ep вроде заработало. А вот с композитным устроством пока проблемы - что-то где-то виснет.
Под виндой очень сложно отлаживать что-то USB-шное. Пока потренеруюсь под линусками, как только там заработает - будет допиливать под виндами.

Гребанный опенсурс. https://lkml.org/lkml/2012/9/9/192 . Как минимум под линуксами не взлетит. Либо надо патчить... Но, судя по тому, что 5 лет никого не волновало, никому не интересно будет.
Можно еще заиспользовать usb-serial (там по паре EP на виртуальный порт) но непонятно, что делать с дровами под винду.