awolfman
Продвинутый
Двигатель заводить не обязательно.
Добавлено спустя 9 мин. 28 сек.
filazaza, а вы откуда?
- Добро пожаловать на форум умных покупателей! Присоединяйтесь к нашей уютной компании и участвуйте в обсуждениях – Регистрация
Добавлено спустя 9 мин. 28 сек.
filazaza, а вы откуда?
F
filazaza
Новичок
- Регистрация
- 26 Окт 2014
- Сообщения
- 9
- Баллы
- 0
дело в том что машину завести не получается проблема в датчике ... как раз этим устройством и нужно узнать температуру входящего воздуха ... на холодную ее завести очень тяжело но можно это надо за насиловать стартер .. чего делать не хочется ..но если завести то потом на горячую заводится без проблем .. уже была такая проблема .. с датчиками .. мне надо с помощью прибора отбраковать датчики по возможности ..
Добавлено спустя 1 мин. 7 сек.
Москва
F
filazaza
Новичок
- Регистрация
- 26 Окт 2014
- Сообщения
- 9
- Баллы
- 0
Возможно ...да хотел подешевле чтоб это все дело вышло ... би би в принципе не горит сделать .... да и на авито ..если брпть почштучто то от 500 руб меньше цен нет ...
Рена
Продвинутый
Ну и ценник в биби -
1139.05р.
:-o
Может кому пригодится... :unknown:
Вот ссылки на рабочие девайсы на PIC18F25K80
239,62 руб
459,18 руб.
И USB $ 7.99
Фото железа Wi-Fi:
Фото железа :
:-o
Может кому пригодится... :unknown:
Вот ссылки на рабочие девайсы на PIC18F25K80
239,62 руб
459,18 руб.
И USB $ 7.99
Фото железа Wi-Fi:
Фото железа :
Л
лурик
Начинающий
Интересно а какой больше потребляет в простое-вайфай или блютуз?
F
filazaza
Новичок
- Регистрация
- 26 Окт 2014
- Сообщения
- 9
- Баллы
- 0
Рена
Продвинутый
У этого козла не берите, там чип CH340T
F
filazaza
Новичок
- Регистрация
- 26 Окт 2014
- Сообщения
- 9
- Баллы
- 0
filazaza:
И USB $ 7.99
У этого козла не берите, там чип CH340T
Так и что этот чип дает или не дает...
F
filazaza
Новичок
- Регистрация
- 26 Окт 2014
- Сообщения
- 9
- Баллы
- 0
ясно ....
F
filazaza
Новичок
- Регистрация
- 26 Окт 2014
- Сообщения
- 9
- Баллы
- 0
Привет народ, есть кто из Москвы ?? если да , то есть ли возможность дать потестить адаптер версии 1.5 взамен на время могу дать свой версии 2.1.. рабочий ..
T
TheDrive
Новичок
Мне опять отдали "что-то" не рабочее. На этот раз китайский ELM327.
Вариант Bluetooth в синем полупрозрачном корпусе "среднего размера", с наклейками Super USB, значком блютуз и надписью Supports all OBDII protocols.
Девайс, видимо, выпущен в самом конце 2012г. (самая свежая микруха 5012, самая старая нижняя плата - начало 2012). Ну и проблема с ним как у большинства "пострадавших" тут в прошлом году - напрчь не принимает ни один PIN. Опробованы все возможные комбинации кодов найденный в нете и по нескольку раз каждая, а также еще куча "простых" вариантов, два андроид аппарата - Самсунг GT2 на 4.2х и старый аппарат, тоже на квалкоме на 2.2х. Бесконечные передергивания девайса из разъема и еще куча опытов. Не гонял пока только на ПК, просто потому что ноут в машину тащить не охота, а качественное питание дома еще не сделал. Проблема на 99% проистекает из прошивки, причем не самого адаптера (т.е. PIC), а прошивки блютуза. Либо код специально сделали "секретным", либо из-за кривизны прошивки банально происходит некая рассинхронизация протокола обмена (или кодировки данных).
Вывод такой следует из того простого факта, что адаптер ведет себя с завидным постоянством, мигает 1 раз красным диодом при подаче питания (забегая вперед скажу что он там один всего в этой модели), после чего стабильно находится клиентами под корректным именем OBDII, нормально обменивается даннми до момента аутентификации и выдает всегда статус ошибки.
Девайс собран на процессоре PIC18F2580 (прошивка пока неизвестна, по году видимо 1.5), CAN интерфесе MCP2551 и Блютуз контроллере Hanlynn HL1009E.
Для того чтобы локализвать какая часть логики отвечает за пин код и, соотв, проблемы с ним надо понимать общую теорию построения подобных устройств. Процессор управляет основной логикой работы устройства, преобразует данные, получая AT команды с COM порта и передавая их автомобилю по шине K-Line или CAN (через аппаратный кодировщик CAN MCP2511). Питание схемы обеспечивается от бортовой сети автомобиля по линии 12-14В путем преобразования и стабилизации напряжения в схеме из мелких простых элементов (реализованной на нижней плате).
Надо понимать, что основной процессор взаимодействует с пользователем (клиентским ПО) исключительно через COM порт. Каким образом этот COM порт в системе образуется ему дела нет. Поэтому и схемы то всех адаптеров аналогичные (и прошивки одинаковые за исключением версий и изменений внесенных вломщиками или сторонними разработчиками). Мы можем использовать простой стандартный аппаратный COM порт (который ныне почти вытеснен из современных компьютеров). В этом случае нам понядобится лишь преобразователь логических уровней (стандартный COM порт ПК имеет уровни до 12В, тогда как подобная "мелкая" электроника уже давно работает у TTL уровнями - до 5В, а последнее время до 3.3В. Для этого в схему включается простенькая микросхема типа MAX232 или MAX3232 или их аналоги.
Чтобы обеспечить надежное проводное соединение под широко распространенный стандарт USB вместо MAX232 некий, гораздо более сложный преобразователь, уже не уровней, а интерфейса аппаратной передачи данных с COM порта (с TTL уровнями) в процессоре адаптера на "понимаемый" современными компьютерами порт USB. Данную довольно сложную микросхему уже можно назвать контроллером. Широкую популярность завоевали микросхему серии FT232, показывающме лучшую стадильность работы в самых разных режимах как с аппаратной стороны, так и со программной поддержки (т.е. драйвера). Несколько менее надежными (особенно подделки), но неплохими считаются контроллеры серии PL2303. Есть еще контроллеры серии CP2102 и иные. Примечателен тот факт, что со стороны компьютера управляющая переходником программа-драйвер организует фактически обратное преобразование логики работы, создавая виртуальный (с т.з. программирования) COM порт, просто потому, что под данный, самый древний из "ныне живущих" тип порта разработано огромное количество методов работы и готовых программ и библиотек. Кроме того в конечном итоге программа общается именно с ком портом в процессоре ELM327 и должна использовать соотвествующие методы работы с таким типом порта. Поэтому программист, который пишет программу под на адаптер фактически даже "не замечает" что на каком то этапе данные идут через USB, поскольку на программном уровне он работает с COM портом процессора адаптера через виртуальный COM порт компьютера.
Для чего столько тех подробностей спросите Вы?
Неспроста...
Когда производители задумались о беспроводной передаче данных, были разработаны различные методы передачи этих данных на физическом уровне. Там, где требуются большие скорости используются сложные, дорогие решения. Но ведь есть задачи простые, не требующие больших ресурсов и затрат. Для таких задач в конце 90х придумали стандарт блютуз. В рамках данного стандарта различные протоколы (наборы правил), предназначенные для передачи различных типов данных с различниыми целями называются профили. И одним из первых профилей стал конечно же интерфейс COM порта. Порт конечно же опять виртуальный, ведь никаких проводов между беспроводными устройствами и вовсе нет!
Программист в компьютере общается с виртуальным COM портом, который организует в данном случае еще более сложная структура - низкоуровневый драйвер конкретной микросхемы Блютуз адаптера и т.н. стек протоколов блютуз - сложное громоздкое ПО, "для всех случаев жизни" связанных с передачей данных по блютуз, которое Вы ставите на свой компьютер после установки блютуз адаптера.
С т.з. нашего ELM адаптера все несколько проще - в адаптере не нужна большая ОС и подлдержка всех протоколов, ведь платка блютуз в ELM прищзвана выполнить всего одну функцию (поддерживать один профиль) - обеспечить обмен данными (в объеме необходимом в рамках этого профиля) между физическим COM портом основного процессора ELM и блютуз адаптером в компьютере. Прогамма в компьютере - точно также не общается ни с каким "блютузом", а общается с виртуальным COM портом, который организовывает стек блютуз для данной ОС.
Ни программа в процессоре ELM, ни программа в компьютере, которая к этому процессору обращается могут вообще ничего не знать о том, что данные гдето там идут без проводом через какие то там блютузы.
Если все так просто откуда же проблемы?
а проблемы проистекают из того, что не все разработчики промежуточных интерфейсов качественно делают свою работу (это еще оч мягко сказано). Кто-то где то не вполне грамотно, не в полном соотвествии со стандартом написал какой-то код. В итоге в какой то момент данные могут потеряться, обмен ими рассинхрнизироваться, данные начнут приходить не те, которых ждут "на том конце" или не в тот момент. Хорошо если хоть обработка ошибок нормально работает, а то ведь соединение можеи и зависнуть, когда одна сторона бесконечно ждет какието данные, которые уже никогда не появятся, поск они потерялись ранее. После этого пользователю останется только сделать аппаратный сброс или снять питание со схемы. С такими явлениями мы часто сталкиваемся и уже привыкли.
Для того чтобы обеспечить некоторую безопасность передаваемых через доступные всем (в опред радиусе) радиоволны, а также просто чтобы все устройства в округе не стали бесконечно "ломиться друг другу в гости с вопросом нет ли чо для меня интересненького передать?" Была введена процедура сопряжения блютуз устройств. Ведь именно пользователь (пользователи) знает какое устройство он хочет соединить с каким и с какой целью.
Данная процедура не имеет вообще никакого отношения к тому, какие данные после сопряжения будут по этому беспроводному интефейсу передаваться. Выполняется она на уровне как раз системного ПО, отвечающего за наладку этого соединения как такового. Со стороны компьютера в стек входит соотв программа сопряжения, которая слушает какие устройства в радиусе действия "о себе рассказывают" ("всем подряд") и предлагает пользователю с ними соединиться. Иной вариант - пользователь предписывает программе самой "начать рассказывать всем" в радиусе действия, что она хочет готова соединиться, а те устройства ей отвечают (или не отвечают в соотв с настройками владельцев).
Чтобы сопрячь устройства пользователь (и) загоняет оба в редим сопряжения, и когда они друг друга увидят предписывает им "запариться" (от англ pair - спаривание). В этот момент устройство "которое ждет гостей" запрашивает у этих "гостей" пароль доступа (пин), чтобы "незваные гости" не вломились на место "званых".
В нашей ситуации ELM при подаче питания, мождет делать только одно - ждать подключения клиента и выполнять его инструкции - сам по себе он ничего другого делать и не может ибо ему просто некуда передавать данные для передачи которых он и разработан.
Основной процессор "сидит" и ждет, когда на его COM появятся запросы пользвателя. С физической точки зрения непосредственным клиентом для енго является контроллер блютуз ибо именно он к физическому COM порту процессора и подключен. Контроллер же блютуз сразу при включении входит в режим сопряжения и ждет когда к нему "в гости" "постучится" клиент. Если постучится ранее "запаренный" клиент, то он сразу ключ доступа и введет автоматом, без запроса его у пользователя (ключ там более длианный и стойкий к взлому чем пин из 4 цифр, обмен ключами как раз и происходит при первом спаривании, но это уже избыточные тех подробности за рамками данной проблемы).
Из данной логики следует что к основному процессору мы и обратиться то не можем пока контроллеры блютуз не установят соединение (ситуация аналогична случаю, когда мы еще не вставили кабель в разъем физического порта).
Со стороны ELM сопряжением занимается исключительно собственная программа блютуз контроллера.
Хранится эта программа может либо в т.н. масочном ПЗУ (намертво вшита вместе с остальной схемой на этапе производства микросхемы), либо в перезаписываемой флеш памяти, как внутри микросхему, так и во внешней отдельной микросхемы (внешняя микросхема тоже, кстати, может быть масочной, но таких решений я не видел уже десятки лет).
Полноценного даташита (инструкции для разработчика) на HL1009 нигде нет. Сама компания видимо уже вообще развалилась ибо сайт их давно сдох. Нашел коротенький даташит (что-то вроде презентации), где микросхема в общих чертах описана (для потенциальных клиентов) на английском и чуть более подробный на китайском. Флеша в ней, похоже, нет. Предусмотрен ROM (видимо масочное ПЗУ) размером всего 2КБ. И вся программа в такой маленький объем умещается. Есть еще 16 + 2 КБ оперативки (т.е. энергозависимой памяти где осуществляются все "рабочие" рассчеты). Программа скорее всего пишется на заводе "одна на всех" (хотя может быть и переделана под заказ конкретного клиента), а сикросхема, согласно опиаснию может использоваться для производства мышек, клавиатур, гарнитур и иных несложных устройств. Пин может зраниться в основной прошивке контроллера (тех самых 2КБ вместе с кодом), но реалии таковы, что под каждого мелкого заказчика пришлось бы производить сложную и дорогую перенастройку станка, что, мягко говоря, не очень выгодно.
С другой стороны заказчик обычно хочет внести свои изменения в конечно устройство, например чтобы клавиатура определялась хотябы с названием производителя а не как некое устройство на все случаи жизни. Для этого в схему включают маленькую дополнительную микросхему EEPROM. Данная память является энергонезависимой, выдерживает очень много циклов перезаписи (миллионы в отличие от флеш памяти), но имеет обычно крохотный объем и стоит при этом оч дешево.
И такая микросхема припаяна рядом с блютуз контроллером, на его же плате. У меня по-моему чтоит 24C128, что недвусмысленно говорит о ее емкости в 128байт. Удивительно, что возможность использования EEPROM, даже не упоминается а даташите на контроллер.
Вот там то скорее всего ПИН код и хранится. правда не известно в каком виде, он может быть в виде бинарных байт, текста или как то закодирован. Там же харнится название OBDII, названия спаренных устройств и ключи с ними обмена, какие то иные настройки (именно блютуз соединения!).
Отпавиать конечно не охота, но если по другому не выгорит, то придется.
Прогамматор для чтения или записи данного типа микросхем можно самому спаять. Схемы оч простые из неск элементов, соединяются на физический COM или LPT порт и к ним есть куча программ для работы с ними.
На форуме я видел фотки адаптеров, где еепром не впаян. Люди удивлялись как оно тогда работает.
Объясню. В основной прошивке в контроллере переменные, значения которых могут зраниться в EEPROM в обычно любом случае инициализируются к неким стандартным значениям. Например ПИН код может быть всегда равен 0000 (если не найден EEPROM). В этом случае, скорее всего, все будет работать, но каждый раз спаривание придется выполнять заново после снятия питания с адаптера, поскольку сохранить даже ключи спаривания будет негде и при снятии питания они сотрутся из оперативки.
Исходя из этой логики достаточно сдуть феном этот еепром и адаптер начнет "париться" со стандартным ПИНом (0000 или 1234), но "парить" придется при каждом выткании в обд.
Но не забываем, то что я написал в начале. Помимо нестандартного пина в еепром причиной может быть некая ошибка в прошивке блютуза или в стеке блютуз андроида или их "несовместимость" (в тч в в программе спаривания от Андроида), поск. я читал отзывы, что OBD авто доктор, включающий в себя свою процедуру спаривания, у некоторых людей нормально спаривал блютуз, но только для себя (т.е. в общие системные настройки Андроида он ключи спаривания не вносил, и для этого, скорее всего, нужен был бы Рут, который есть не у всех).
Вариант Bluetooth в синем полупрозрачном корпусе "среднего размера", с наклейками Super USB, значком блютуз и надписью Supports all OBDII protocols.
Девайс, видимо, выпущен в самом конце 2012г. (самая свежая микруха 5012, самая старая нижняя плата - начало 2012). Ну и проблема с ним как у большинства "пострадавших" тут в прошлом году - напрчь не принимает ни один PIN. Опробованы все возможные комбинации кодов найденный в нете и по нескольку раз каждая, а также еще куча "простых" вариантов, два андроид аппарата - Самсунг GT2 на 4.2х и старый аппарат, тоже на квалкоме на 2.2х. Бесконечные передергивания девайса из разъема и еще куча опытов. Не гонял пока только на ПК, просто потому что ноут в машину тащить не охота, а качественное питание дома еще не сделал. Проблема на 99% проистекает из прошивки, причем не самого адаптера (т.е. PIC), а прошивки блютуза. Либо код специально сделали "секретным", либо из-за кривизны прошивки банально происходит некая рассинхронизация протокола обмена (или кодировки данных).
Вывод такой следует из того простого факта, что адаптер ведет себя с завидным постоянством, мигает 1 раз красным диодом при подаче питания (забегая вперед скажу что он там один всего в этой модели), после чего стабильно находится клиентами под корректным именем OBDII, нормально обменивается даннми до момента аутентификации и выдает всегда статус ошибки.
Девайс собран на процессоре PIC18F2580 (прошивка пока неизвестна, по году видимо 1.5), CAN интерфесе MCP2551 и Блютуз контроллере Hanlynn HL1009E.
Для того чтобы локализвать какая часть логики отвечает за пин код и, соотв, проблемы с ним надо понимать общую теорию построения подобных устройств. Процессор управляет основной логикой работы устройства, преобразует данные, получая AT команды с COM порта и передавая их автомобилю по шине K-Line или CAN (через аппаратный кодировщик CAN MCP2511). Питание схемы обеспечивается от бортовой сети автомобиля по линии 12-14В путем преобразования и стабилизации напряжения в схеме из мелких простых элементов (реализованной на нижней плате).
Надо понимать, что основной процессор взаимодействует с пользователем (клиентским ПО) исключительно через COM порт. Каким образом этот COM порт в системе образуется ему дела нет. Поэтому и схемы то всех адаптеров аналогичные (и прошивки одинаковые за исключением версий и изменений внесенных вломщиками или сторонними разработчиками). Мы можем использовать простой стандартный аппаратный COM порт (который ныне почти вытеснен из современных компьютеров). В этом случае нам понядобится лишь преобразователь логических уровней (стандартный COM порт ПК имеет уровни до 12В, тогда как подобная "мелкая" электроника уже давно работает у TTL уровнями - до 5В, а последнее время до 3.3В. Для этого в схему включается простенькая микросхема типа MAX232 или MAX3232 или их аналоги.
Чтобы обеспечить надежное проводное соединение под широко распространенный стандарт USB вместо MAX232 некий, гораздо более сложный преобразователь, уже не уровней, а интерфейса аппаратной передачи данных с COM порта (с TTL уровнями) в процессоре адаптера на "понимаемый" современными компьютерами порт USB. Данную довольно сложную микросхему уже можно назвать контроллером. Широкую популярность завоевали микросхему серии FT232, показывающме лучшую стадильность работы в самых разных режимах как с аппаратной стороны, так и со программной поддержки (т.е. драйвера). Несколько менее надежными (особенно подделки), но неплохими считаются контроллеры серии PL2303. Есть еще контроллеры серии CP2102 и иные. Примечателен тот факт, что со стороны компьютера управляющая переходником программа-драйвер организует фактически обратное преобразование логики работы, создавая виртуальный (с т.з. программирования) COM порт, просто потому, что под данный, самый древний из "ныне живущих" тип порта разработано огромное количество методов работы и готовых программ и библиотек. Кроме того в конечном итоге программа общается именно с ком портом в процессоре ELM327 и должна использовать соотвествующие методы работы с таким типом порта. Поэтому программист, который пишет программу под на адаптер фактически даже "не замечает" что на каком то этапе данные идут через USB, поскольку на программном уровне он работает с COM портом процессора адаптера через виртуальный COM порт компьютера.
Для чего столько тех подробностей спросите Вы?
Неспроста...
Когда производители задумались о беспроводной передаче данных, были разработаны различные методы передачи этих данных на физическом уровне. Там, где требуются большие скорости используются сложные, дорогие решения. Но ведь есть задачи простые, не требующие больших ресурсов и затрат. Для таких задач в конце 90х придумали стандарт блютуз. В рамках данного стандарта различные протоколы (наборы правил), предназначенные для передачи различных типов данных с различниыми целями называются профили. И одним из первых профилей стал конечно же интерфейс COM порта. Порт конечно же опять виртуальный, ведь никаких проводов между беспроводными устройствами и вовсе нет!
Программист в компьютере общается с виртуальным COM портом, который организует в данном случае еще более сложная структура - низкоуровневый драйвер конкретной микросхемы Блютуз адаптера и т.н. стек протоколов блютуз - сложное громоздкое ПО, "для всех случаев жизни" связанных с передачей данных по блютуз, которое Вы ставите на свой компьютер после установки блютуз адаптера.
С т.з. нашего ELM адаптера все несколько проще - в адаптере не нужна большая ОС и подлдержка всех протоколов, ведь платка блютуз в ELM прищзвана выполнить всего одну функцию (поддерживать один профиль) - обеспечить обмен данными (в объеме необходимом в рамках этого профиля) между физическим COM портом основного процессора ELM и блютуз адаптером в компьютере. Прогамма в компьютере - точно также не общается ни с каким "блютузом", а общается с виртуальным COM портом, который организовывает стек блютуз для данной ОС.
Ни программа в процессоре ELM, ни программа в компьютере, которая к этому процессору обращается могут вообще ничего не знать о том, что данные гдето там идут без проводом через какие то там блютузы.
Если все так просто откуда же проблемы?
а проблемы проистекают из того, что не все разработчики промежуточных интерфейсов качественно делают свою работу (это еще оч мягко сказано). Кто-то где то не вполне грамотно, не в полном соотвествии со стандартом написал какой-то код. В итоге в какой то момент данные могут потеряться, обмен ими рассинхрнизироваться, данные начнут приходить не те, которых ждут "на том конце" или не в тот момент. Хорошо если хоть обработка ошибок нормально работает, а то ведь соединение можеи и зависнуть, когда одна сторона бесконечно ждет какието данные, которые уже никогда не появятся, поск они потерялись ранее. После этого пользователю останется только сделать аппаратный сброс или снять питание со схемы. С такими явлениями мы часто сталкиваемся и уже привыкли.
Для того чтобы обеспечить некоторую безопасность передаваемых через доступные всем (в опред радиусе) радиоволны, а также просто чтобы все устройства в округе не стали бесконечно "ломиться друг другу в гости с вопросом нет ли чо для меня интересненького передать?" Была введена процедура сопряжения блютуз устройств. Ведь именно пользователь (пользователи) знает какое устройство он хочет соединить с каким и с какой целью.
Данная процедура не имеет вообще никакого отношения к тому, какие данные после сопряжения будут по этому беспроводному интефейсу передаваться. Выполняется она на уровне как раз системного ПО, отвечающего за наладку этого соединения как такового. Со стороны компьютера в стек входит соотв программа сопряжения, которая слушает какие устройства в радиусе действия "о себе рассказывают" ("всем подряд") и предлагает пользователю с ними соединиться. Иной вариант - пользователь предписывает программе самой "начать рассказывать всем" в радиусе действия, что она хочет готова соединиться, а те устройства ей отвечают (или не отвечают в соотв с настройками владельцев).
Чтобы сопрячь устройства пользователь (и) загоняет оба в редим сопряжения, и когда они друг друга увидят предписывает им "запариться" (от англ pair - спаривание). В этот момент устройство "которое ждет гостей" запрашивает у этих "гостей" пароль доступа (пин), чтобы "незваные гости" не вломились на место "званых".
В нашей ситуации ELM при подаче питания, мождет делать только одно - ждать подключения клиента и выполнять его инструкции - сам по себе он ничего другого делать и не может ибо ему просто некуда передавать данные для передачи которых он и разработан.
Основной процессор "сидит" и ждет, когда на его COM появятся запросы пользвателя. С физической точки зрения непосредственным клиентом для енго является контроллер блютуз ибо именно он к физическому COM порту процессора и подключен. Контроллер же блютуз сразу при включении входит в режим сопряжения и ждет когда к нему "в гости" "постучится" клиент. Если постучится ранее "запаренный" клиент, то он сразу ключ доступа и введет автоматом, без запроса его у пользователя (ключ там более длианный и стойкий к взлому чем пин из 4 цифр, обмен ключами как раз и происходит при первом спаривании, но это уже избыточные тех подробности за рамками данной проблемы).
Из данной логики следует что к основному процессору мы и обратиться то не можем пока контроллеры блютуз не установят соединение (ситуация аналогична случаю, когда мы еще не вставили кабель в разъем физического порта).
Со стороны ELM сопряжением занимается исключительно собственная программа блютуз контроллера.
Хранится эта программа может либо в т.н. масочном ПЗУ (намертво вшита вместе с остальной схемой на этапе производства микросхемы), либо в перезаписываемой флеш памяти, как внутри микросхему, так и во внешней отдельной микросхемы (внешняя микросхема тоже, кстати, может быть масочной, но таких решений я не видел уже десятки лет).
Полноценного даташита (инструкции для разработчика) на HL1009 нигде нет. Сама компания видимо уже вообще развалилась ибо сайт их давно сдох. Нашел коротенький даташит (что-то вроде презентации), где микросхема в общих чертах описана (для потенциальных клиентов) на английском и чуть более подробный на китайском. Флеша в ней, похоже, нет. Предусмотрен ROM (видимо масочное ПЗУ) размером всего 2КБ. И вся программа в такой маленький объем умещается. Есть еще 16 + 2 КБ оперативки (т.е. энергозависимой памяти где осуществляются все "рабочие" рассчеты). Программа скорее всего пишется на заводе "одна на всех" (хотя может быть и переделана под заказ конкретного клиента), а сикросхема, согласно опиаснию может использоваться для производства мышек, клавиатур, гарнитур и иных несложных устройств. Пин может зраниться в основной прошивке контроллера (тех самых 2КБ вместе с кодом), но реалии таковы, что под каждого мелкого заказчика пришлось бы производить сложную и дорогую перенастройку станка, что, мягко говоря, не очень выгодно.
С другой стороны заказчик обычно хочет внести свои изменения в конечно устройство, например чтобы клавиатура определялась хотябы с названием производителя а не как некое устройство на все случаи жизни. Для этого в схему включают маленькую дополнительную микросхему EEPROM. Данная память является энергонезависимой, выдерживает очень много циклов перезаписи (миллионы в отличие от флеш памяти), но имеет обычно крохотный объем и стоит при этом оч дешево.
И такая микросхема припаяна рядом с блютуз контроллером, на его же плате. У меня по-моему чтоит 24C128, что недвусмысленно говорит о ее емкости в 128байт. Удивительно, что возможность использования EEPROM, даже не упоминается а даташите на контроллер.
Вот там то скорее всего ПИН код и хранится. правда не известно в каком виде, он может быть в виде бинарных байт, текста или как то закодирован. Там же харнится название OBDII, названия спаренных устройств и ключи с ними обмена, какие то иные настройки (именно блютуз соединения!).
Отпавиать конечно не охота, но если по другому не выгорит, то придется.
Прогамматор для чтения или записи данного типа микросхем можно самому спаять. Схемы оч простые из неск элементов, соединяются на физический COM или LPT порт и к ним есть куча программ для работы с ними.
На форуме я видел фотки адаптеров, где еепром не впаян. Люди удивлялись как оно тогда работает.
Объясню. В основной прошивке в контроллере переменные, значения которых могут зраниться в EEPROM в обычно любом случае инициализируются к неким стандартным значениям. Например ПИН код может быть всегда равен 0000 (если не найден EEPROM). В этом случае, скорее всего, все будет работать, но каждый раз спаривание придется выполнять заново после снятия питания с адаптера, поскольку сохранить даже ключи спаривания будет негде и при снятии питания они сотрутся из оперативки.
Исходя из этой логики достаточно сдуть феном этот еепром и адаптер начнет "париться" со стандартным ПИНом (0000 или 1234), но "парить" придется при каждом выткании в обд.
Но не забываем, то что я написал в начале. Помимо нестандартного пина в еепром причиной может быть некая ошибка в прошивке блютуза или в стеке блютуз андроида или их "несовместимость" (в тч в в программе спаривания от Андроида), поск. я читал отзывы, что OBD авто доктор, включающий в себя свою процедуру спаривания, у некоторых людей нормально спаривал блютуз, но только для себя (т.е. в общие системные настройки Андроида он ключи спаривания не вносил, и для этого, скорее всего, нужен был бы Рут, который есть не у всех).
ars89
Продвинутый
Всем здрасти)))
Кто подскажет Renault Logan 2014, есть ELM 327 с кнопкой включения блюпуп на корпусе. Не могу подключить к ЭБУ, с телефоном соединяется с прогой тоже а вот с ЭБУ нехочет(((( перепробовал много прог. Может кто подскажет, что делать?
Спасибо.
Кто подскажет Renault Logan 2014, есть ELM 327 с кнопкой включения блюпуп на корпусе. Не могу подключить к ЭБУ, с телефоном соединяется с прогой тоже а вот с ЭБУ нехочет(((( перепробовал много прог. Может кто подскажет, что делать?
Спасибо.
P
palza
Новичок
- Регистрация
- 26 Янв 2015
- Сообщения
- 2
- Баллы
- 0
купил елм327(белый)блютуз. на чери тиго фл работает без проблем. пробовал на приоре и на калине, не видит эбу ни каким ракурсом. программ с плей маркета туеву тучу скачал, результат один с моим чериком работают почти все, а вот с тазами ни одна, есть одна которая просит тип эбу, но что мне пол машины разобрать чтобы эбу посмотреть????
P
palza
Новичок
- Регистрация
- 26 Янв 2015
- Сообщения
- 2
- Баллы
- 0
ну как бы там и некуда вводить модель и год, тупо запрашивает тип блока и все
P
pugapuga
Новичок
- Регистрация
- 17 Янв 2015
- Сообщения
- 2
- Баллы
- 0
Такая же проблема как и у ars89,Renault Logan 2012 ,ELM 327 блюпуп 2.1. Не могу подключить к ЭБУ,соединяется с прогой тоже а вот с ЭБУ нехочет , пробовал на Хонде,тоже не пошло.МАС адрес 66:....Что можете посоветовать?
Live
