Индикатор расхода топлива Опции

[SSh]

В принципе ничего не мешает сначала измерить импульс с форсунки а затем импульс с датчика скорости. Не думаю что за пару десятков миллисекунд что-то существенно изменится так, что это внесет значительную погрешность в результат измерений. Ведь и те и другие импульсы поступают непрерывно во время движения. Но надо будет предусмотреть какую-нибуть процедуру - чтоб измерения производились только начиная с какого-то значения скорости. Для этих целей команда PULSIN в принципе обеспечивает достаточно большую точность - дискретизация при 20 МГц тактировании - 2 микросекунды.
Лучших результатов можно добиться использованием прерываний, но мы-же не прецизионный частотомер мастерим? (IMG:style_emoticons/default/wink.gif)
Длительность-же "торможения" программы самой командой PULSIN можно уменьшить директивой DEFINE, хотя, повторюсь, точности для нашего конкретного случая более чем достаточно. Кстати, для более "шустрой" работы в текст программы на PBP можно вводить вставки на ассемблере.
Что касается защиты от дребезга - программно иначе как паузой эту защиту никак не реализуешь, другое дело, если эти 200 мс для нас критичны, то можно оргнизовать защиту и на аппаратном уровне. К слову, аппаратная защита тоже предполагает некоторую задержку, но эта задержка естественно никак не влияет на ход выполнения программы в МК. Опять-же, к слову, задержка в 500 мс в несколько раз превышает необходимую для защиты от дребезга паузу, но учитывая условия эксплуатации и качество мини-кнопочек - лучше перестраховаться.
Что касается задержки вывода информации на индикаторе - то тут кому как нравится... Чем меньше задержка тем больше будет "дергаться" выводимая информация. Например, при организации АЦП с 3-мя значащими цифрами после запятой, если нет задержки то последняя цифра будет прыгать так, что её невозможно будет визуально зафиксировать.
Вообщем как-то так... Хочу отметить что я не опровергаю приведенные выше доводы, просто описываю свои умозаключения. (IMG:style_emoticons/default/smile.gif)

[zhuns]

Не думаю что за пару десятков миллисекунд что-то существенно изменится так, что это внесет значительную погрешность в результат измерений. Ведь и те и другие импульсы поступают непрерывно во время движения.

Я перед собой поставил задачу: измерить и вычислить реальные параметры. Поэтому, ничего не хочу терять; тем более, что для этого не надо ничего особенного придумывать. 10 мс это очень много. Только "в прикидку": время одного оборота на ХХ составляет примерно 75мс, а на рабочих (3000 об/мин) – 10мс. Единичная потеря – ерунда, но это будет систематически. Погрешность огромная.

Что касается защиты от дребезга - программно иначе как паузой эту защиту никак не реализуешь, другое дело, если эти 200 мс для нас критичны, то …….
…..Что касается задержки вывода информации на индикаторе - то тут кому как нравится... Чем меньше задержка тем больше будет "дергаться" выводимая информация.

За 200мс прогавим примерно 3 впрыска 1 форсунки на ХХ и 10 - на раб. оборотах двигателя. А сколько их за поездку!
Я абсолютно не против указанных задержек. Их, если надо, можно увеличить хоть в 2-4 раза, но при этом не ждать в данном цикле, когда наступит это время. Ждать и работать, т.е. выполнять основную работу. Ожидание путем - подсчета количества рабочих циклов. Рабочий цикл должен быть длительностью, примерно, 10-20мс. Для этого использовать один таймер.
Надо будет все-таки поискать в Интернете, как реализована команда Pulsin.

По ходу появилась такая мысль. На форуме видел, как обсуждался вопрос улучшения вида приборов. Сам никогда не заглядывал туда. Есть ли возможность на шкале тахометра или спидометра (с обратной стороны, в том месте, где отображаются деления), "прилепить", светодиоды, т.е. сделать прогрессбар? Была бы отличная шкала с делениями!
Если этого нельзя сделать, то может быть подать сигнал на прибор (уже только на тахометр) через коммутатор. На один вход - импульсы датчика, а на второй – "свои", которые сформировать в функции расхода? Управлять не проблема. Как для меня, то тахометром пользуюсь редко. Хотя, не лишнее, когда он есть.
И последнее, Возле диагностического разъема OBD-2, есть еще беленький. Не находил конкретного ответа, что там. Читал, что для записи в EMU. Но это все равно, что сказать не знаю. Если известно, поделись, пожалуйста.

[dmitrij_b]

Сори, что влезаю в разговор.

Возле диагностического разъема OBD-2, есть еще беленький. Не находил конкретного ответа, что там. Читал, что для записи в EMU. Но это все равно, что сказать не знаю. Если известно, поделись, пожалуйста.

Известно. Точно для записи. Точнее для активации режима записи/чтения прошивки. Сами данные через основной разъем идут.

[zhuns]

Сори, что влезаю в разговор.

Ну что вы, уважаемый dmitrij_b, Это же форум, а не личная переписка. Делимся своими знаниями и мыслями.
Вы пишите Известно. Точно для записи. Но я спросил не ради любопытства, а чтобы узнать как его использовать. Если в разъеме OBD-2 известно назначение каждого контакта, то понятно, как его использовать. А беленький для меня пока темный. Уточните, пожалуйста.

[dmitrij_b]

Ну, на евролансах там единственный контакт торчит. Посему не озабочивался конкретным номером этого самого контакта.
Но пока на него не приходит сигнал, который на схеме OpenPort-а называется "Boot", читать и писать прошивку не получается.
Какой формы сигнал, с какими вольт\амперными характеристиками ответить не смогу. Не изучал настолько детально. OpenPort работает и ладно... (IMG:style_emoticons/default/smile.gif)

[SSh]

Надо будет все-таки поискать в Интернете, как реализована команда Pulsin.

Прибл. вот так. Здесь на МВ, но смысл тот-же.
http://www.mikroe.com/forum/viewtopic.php?...p;hilit=pulsein

Насчет задержки защиты от дребезга - она проявляется только при нажатии на кнопку, в остальное время программа работает без этих задержек.

Я перед собой поставил задачу: измерить и вычислить реальные параметры.

А я наоборот, не измерить а индицировать, поэтому прибор называется Индикатор... а не измеритель (IMG:style_emoticons/default/wink.gif)
Для измерения реальных параметров по-моему лучше вообще сразу считывать их с ЭБУ

Но я спросил не ради любопытства, а чтобы узнать как его использовать.

Для данного и подобных проектов - никак. Как уже отмечал Дмитрий сигнал на этом разъеме служит только для перевода ЭБУ в режим чтения/записи прошивки. Никакой информации (диагностика, логи и т.д.) по этому разъему не передается.

[zhuns]

Ну, на евролансах там единственный контакт торчит. Посему не озабочивался конкретным номером этого самого контакта.
Но пока на него не приходит сигнал, который на схеме OpenPort-а называется "Boot", читать и писать прошивку не получается.
Какой формы сигнал, с какими вольт\амперными характеристиками ответить не смогу. Не изучал настолько детально. OpenPort работает и ладно... (IMG:style_emoticons/default/smile.gif)

Понятно, спасибо

[zhuns]

Прибл. вот так. Здесь на МВ, но смысл тот-же.
http://www.mikroe.com/forum/viewtopic.php?...p;hilit=pulsein

Спасибо.

[SSh]

Была бы отличная шкала с делениями!

По-моему, переделывать тахометр в прогрессбар - плохая идея. Другое дело - смонтировать этот самый прогрессбар в другом месте, как предлагалось, в LED-расходомере ( http://forum.amadeus-project.com/index.php...ost&p=11921 ). Но тут все зависит от конструкции конкретной приборки. В моей, например, есть 2 смежных неиспользованных отсека куда в ряд помещаются 12 SMD светодиодов. На 2-м фото http://forum.amadeus-project.com/index.php...ost&p=26360 - видно, там где не установлены лампочки можно смонтировать светодиодную шкалу.

[SSh]

Прибл. вот так. Здесь на МВ, но смысл тот-же.
http://www.mikroe.com/forum/viewtopic.php?...p;hilit=pulsein

Спасибо.

Кстати, как пишет сам автор "This a blocking call". Это означает что при отсутствии импульсов программа "заткнется" на одном из двух циклов

Код

  while TestBit(port, pin) = state            ' Wait for pulses
  wend                                        ' Note that the program will stop here
                                              '   if there are no pulses
  
  while TestBit(port, pin) <> state           ' Wait for rising (falling) edge
  wend                                        ' Note that the program will stop here

[SSh]

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

[zhuns]

Вам хорошо известно, что такое допустимая погрешность. Для одних систем 10-20% - ОК!, а для других требуется не более 0,1%. Любой БК - это прибор, как раньше говорили, ширпотреб. Все выпускаемые устройства такого типа (которые в широкой продаже) никто не подвергает проверке; уверен, что даже нет какого-то нормативного документа соответствия его каким-то требованиям. Зачем лишние затраты? Это касается и обсуждаемого "проекта". Естественно, погрешностей масса. Но, если то, что можно учесть отнести к разряду- все равно никто не узнает и не проверит, и проигнорировать, то это будет самообман (для себя так считаю). В любом деле должен быть разумный компромисс.
Я в свое время занимался системами, где предел всего цикла, отводимого на все операции, включая и управление, был не более 3мс. Поэтому, даже к такому простому устройству стараюсь подойти, по привычке, с определенными, но разумными требованиями. Я же не пытаюсь для этого применить таймер с захватом, чтобы исключить время реакции на прерывание. Это все-таки полезная, но игрушка, для взрослого дяди. Разбираюсь в свободное время по мере возможностей и для удовольствия.
Вы где-то кому-то писали: "...зачем покупать простую вещь, если ее можно сделать самому? Это же приятно"! Согласен полностью. Точно также считаю. А мне еще больше приятно докопаться до деталей и учесть их. Но это уже не по теме и не сочтите это как попытку навязать свое мнение.
Реализацию команды измерения длительности импульса смотрел. Но это, так сказать, макрокоманда, реализованная простыми командами языка высокого уровня. Они даже таймер запускают не с нулевого значения (записывают 5мс), чтобы учесть задержки в логике.
Вы указывали на возможность использования данных из ECU. Я думал об этом. Но, вначале надо проанализировать, что и как там представлено У меня такого устройства нет. Поэтому и заинтересовался адаптером доступа. А попутно подумал о том, может там (в мозгах), что-то поправить. Но это уже не так просто.

[SSh]

Вам хорошо известно, что такое допустимая погрешность

Поэтому-то и пишу о всех возможных моментах возникновения таковой, мне, как я уже отмечал вполне достаточно относительных показаний.

Вы указывали на возможность использования данных из ECU. Я думал об этом. Но, вначале надо проанализировать, что и как там представлено У меня такого устройства нет.

А зачем устройство? и в сети и на этом форуме есть достаточно информации для того чтоб выяснить как происходит обмен данными с ЭБУ.
Посмотрите темы:
http://forum.amadeus-project.com/index.php...ic=3958&hl=
http://forum.amadeus-project.com/index.php...ic=3928&hl=

Кое-что есть и в этой теме и в диагностике двигателя.
И с адаптером связи - никаких проблем, все можно найти здесь-же на форуме.

[zhuns]

Спасибо. Просматривал на этом форуме и на и др. . Смутило то, что нигде конкретно не нашел, как же управлять входом boot, к которому подключают отдельный штырь на "белом" разъеме. Подключить не проблема. А вот от куда "отрастает" этот проводок - не нашел.

[SSh]

Приведу фрагмент схемы OpenPort (верхняя, не промаркированная стрелочка идет к питанию +5В)

Как видим, сигнал BOOT формируется генератором на 555 таймере, после которого стоит схема удвоителя напряжения, так называемым Charge-Pump методом. Т.е. на выходе BOOT при поступлении на таймер разрешающего уровня (Enable) просто образуется постоянное напряжение которое и переводит ЭБУ в режим записи/чтения.

[zhuns]

Приведу фрагмент схемы OpenPort (верхняя, не промаркированная стрелочка идет к питанию +5В)

Как видим, сигнал BOOT формируется генератором на 555 таймере, после которого стоит схема удвоителя напряжения, так называемым Charge-Pump методом. Т.е. на выходе BOOT при поступлении на таймер разрешающего уровня (Enable) просто образуется постоянное напряжение которое и переводит ЭБУ в режим записи/чтения.

Спасибо большое, SSh! Это же фрагмент схемы, которую вы приводили на форуме. Я не обратил внимания на то, что цепь сигнала BOOT показана, как клемма. Надо воспроизвести OpenPort.

[SSh]

Я вот только немного поразмышлял - по какой причине напряжение разрешения чтения/записи формируется из USB-шного питания? Ведь после удвоения получим прибл. напряжение бортовой сети автомобиля, так почему-бы сразу и не подавать оттуда?
Кое-какие мысли конечно есть, но пока не буду озвучивать, хочется более досконально разобраться... А у кого еще есть идеи по этому поводу?
Вечером-же, если выберу время, постараюсь прозвонить сигналы адаптера...

[zhuns]

по какой причине напряжение разрешения чтения/записи формируется из USB-шного питания? Ведь после удвоения получим прибл. напряжение бортовой сети автомобиля, так почему-бы сразу и не подавать оттуда?

Не уверен в правильности своих мыслей, но все же поделюсь (пока - это только размышления).
Управляется 555 сигналом CBUS0 FT232. По умолчанию этот выход используют для управления светодиодом, который отображает режим работы USB прем/передача. Тем самым разрешает "накачать" заряд на конденсаторе или прекратить генерацию 555 и понизить уровень сигнала BOOT. Почему не коммутировать напряжение аккум. батареи? Может потому, что 1) надо сигнал немного больше чем 12В, 2) безопаснее подать напряжение от маломощного источника (хотя и 12В можно подать через резистор).
Скоро должен получить комплектующие. После изготовления адаптера можно будет что-то посмотреть.

[SSh]

По-моему разработчики все-же руководствовались иными соображениями... Например, если в процессе записи или чтения прошивки сдернуть провод BOOT, что случится? А если просто снизить напряжение на этом разъеме с 12 до 5В?
Я честно говоря не знаю, если не ошибаюсь, читал где-то что если напряжение пропадет то мозги сгорят. А вот про уменьшение ничего не слышал...

А то можно было-бы просто сигналом с CBUS0 включать-выключать какой-нибуть ключ на p-канальном полевике.

[zhuns]

По-моему разработчики все-же руководствовались иными соображениями... Например, если в процессе записи или чтения прошивки сдернуть провод BOOT, что случится? А если просто снизить напряжение на этом разъеме с 12 до 5В?
Я честно говоря не знаю, если не ошибаюсь, читал где-то что если напряжение пропадет то мозги сгорят. А вот про уменьшение ничего не слышал...

А то можно было-бы просто сигналом с CBUS0 включать-выключать какой-нибуть ключ на p-канальном полевике.

Нашел дискуссию по схеме универсального OpenPort 1.3.

Что я понял. При неактивном 555 на выводе BOOT будет +5В - у большинства ECU машин будет такой потенциал при отсутствии подключения к нему (из разъяснения автора). Почему там создают более высокий уровень за счет 555, я не понял. Сказано, что напряжение, управляющее программированием, подается на этот контакт через резистор с целью обезопасить его от всяких случайностей. Очевидно, это связанных с не идентичностью ECU машин. Я понял, что (буквально I added an output resistance to help protect it, since the output really only needs to drive a fairly high impedance divider network in the ECU) можно понять. что сигнал призван управлять высокоомным драйвером?? сети в ECU машины.
Вообще, интересный сайт. Хотел вставить фрагмент схемы, не получилось. Позже разберусь.