galjoen

Значит, хоть CANGCON перед инициализацией и не был сброшен, похоже, скорость проинициализировалась правильно. 15 мк секунд это как раз 2 бита на скорости 125 кбод. Вроде должно работать. А терминальные резисторы имеются? Если речь идёт о инициализации после включения питания, то, на мой взгляд, это необязательно. После включения питания никакой передачи происходить не может, поэтому выключаться CAN контроллер будет мгновенно. А вот добавить в инициализацию цикл сброса всех MOb обязательно нужно, т.к. после включения питания там м.б. что угодно.

Нужно глянуть осциллографом на ноге TxCAN, у AT90CAN128 это 30-я нога. Есть ли там короткие нулевые импульсы шириной 1 бит? И доходят ли они до драйвера CAN? А AT90CAN128 то проинициализировали так, как я написал?

Видимо у вас в сети нет никого, кроме этого самого USB-CAN, поэтому никто ему ACK не отвечает, возникает ошибки Ack Error, счётчик ошибок инкрементируется, передатчик автоматически перепередаёт сообщение, и так до тех пор, пока не окажется в Error Passive. Сеть CAN не может состоять из одного устройства, а остальные, как я понял, неправильно проинициализированы.

Использую VID=PID=0. Такой VID никому выдан быть не может т.к. многие ОС, в т.ч. винда присваивают его некорректным устройствам. А драйвер ставится по классу устройства. У меня составное HID(HIDы)+MassStorage устройство. Т.е. Interrupt пересылки к HID-ам, а Bulk к MassStorage. Изохорные пока не нужны были.

Да, по форуму. Обсуждалось и неоднократно. Есть ещё вариант с делителем=7 и TQ=17. Там получается 123912 бод. А вообще, здесь принято на вы обращатся...

Вот: Тактовая частота 14745600. Связь 125000 (реально 126031) .SET CBT1=0x10; писаемое в CANBT1 (делитель=9, частота 1.6384 МГц) .SET CBT2=0x0A; писаемое в CANBT2 (Tsjw=1, Tprs=6) .SET CBT3=0x25; писаемое в CANBT3 (Tphs2=3, Tphs1=3, SMP=1) TQ=(SYN=1)+(Tprs=6)+(Tphs1=3)+(Tphs2=3)=13 Sampling Point=((SYN=1)+(Tprs=6)+(Tphs1=3))/(TQ=13)=76.92% А поиском лень было воспользоваться?

Небольшая, но у обычных smd резисторов, вместе с печатными дорожками, получается около 5 пФ. Но самое главное не в величине ёмкости, а в том, что при использовании smd невозможно защитные земли как следует развести - места не хватает. Ну и ещё у выводных металлоплёночных резисторов номиналом более 500 ом, как правило, спиралькой резистивный слой нарезан. А это увеличивает паразитную индуктивность. Но она, в этом случае, полезна. Да и вообще, ИМХО на защите от помех экономить не стоит.

L1 это продольный трансформатор, он более, чем драйвер от выгорания, процессор от сбоя защищает. Смысла нет в применении всего этого в одном корпусе - паразитная ёмкость будет больше, чем в нескольких. И разводкой её не уменьшишь и резисторы, для её уменьшения, внутрь добавить невозможно. В схеме, кстати, такие резисторы включены правильно. Только они должны выводными быть - проходная ёмкость меньше. И ещё нужно поставить выводной резистор номиналом в районе 1 кОм между RX_CAN и 6-й ногой U1. Иначе прямо на ногу проца помеха попадает.

А поиском воспользоваться? См. соседнюю тему, а в ней пост N27.

Микас Он Лине Тюнер (МОЛТ) знаю - в стандартный Микас спец прошивка заливается. И инженерный Январь - там уже и блок специальный, но потом можно в стандартный калибровки переписать. А так-же все Корветы таким свойством обладают. Но не думаю, что вам это особо нужно. Это для спорта, а так достаточно просто калибровки иметь возможность изменять.

mpsz - это для карбюратора актуально, а тут инжектор. И с теорией там негусто... А вот МПДГ оттуда можно использовать. Фактически это ГБО-3, только названием отличается. Т.е. ГБО, поддерживающее стехиометрический состав смеси по Узкополосному Датчику Кислорода (УДК). В т.ч. с подключением к имеющемуся УДК. Хотя МПДГ вроде как и к Широкополосному ДК можно подключить, но сам ШДК дорогой.

Один из вариантов - задерживают сигнал с ДПКВ на оборот. Т.е. немного меньше оборота. Вот на это меньше искра то раньше и возникнет. Это вариант подойдёт, т.к. в вашем бензомозге диагностики по ускорению коленвала всё равно нет... Пропан медленно горит только при малом цикловом наполнении. Т.е. увеличивать УОЗ нужно только при малых нагрузках (цикловых наполнениях), но обычно вариатор не имеет никакой информации о нагрузке двигателя. Хотя мог бы - по времени бензовпрыска, например. Поэтому жел-но не ставить вариатор, а изменить калибровку в бензомозге. Но программы для изменения калибровок в вашем ЭБУ я не знаю. Но в самодельном устройстве это можно сделать без проблем. А вообще, рекомендую почитать профильные форумы. Лично мне чиптюнер нравится. Там и CTP 2.15 от автора скачать можно.

Вместо того, чтобы заниматься рассуждениями и догадками, рекомендую скачать бесплатный CTP 2.15 и почитать хелп... Механически двигать ДПКВ не надо. Для этого существуют системы называемые "Вариатор зажигания" - поиск рулит. Подключаются к ДПКВ, а сами эмулируют его сигнал. Т.е. в бензомозг идёт сигнал не с ДПКВ, а с этого вариатора. А таблицу зависимости сдвига угла от оборотов можно изменять как угодно, но только до тех пор пока ошибка по ДФ не вылезет. Но на старых системах там запаса полно. Alt.F4, если вам этим интересно заниматься, то рекомендую заменить родной бензомозг на что-то типа Января 5.1 или 7.2 или Микаса 5.4 или 7.1, подправить его калибровки с помощью CTP 2.15 и установить ГБО4 (с распределённым впрыском). ГБО4 рекомендую BRC. Более бюджетный вариант - ГБО3 (стехиометрия по ДК). Можно даже МПДГ ради интереса поставить.

Там, на сколько я в куре, 11 бит ID. Т.е. их всего 2048. Не будут каждому блоку ID раздавать. Даже в J1939, где 29 бит ID, в каждом PGN (ID) несколько SPN (полей в сообщении). Да и вообще, мультипакетом это дело может слаться, например.

:07: Вы бы хоть немного описание протокола CAN почитали - тогда многие вопросы сами-собой отпадут.

Мне кажется, что при малой мощности вполне пригоден. Понятно, что материал сердечника нужен магнитомягкий, или как это правильно называется? Ну чтобы остаточное намагничивание минимальное оставалось. Индукция в сердечнике может меняется только от этого значения до насыщения, т.е. в 2 раза меньше, чем в трансформаторе. Половину времени дроссель энергию запасает, половину отдаёт. Т.е. уже из-за этого сердечник у дросселя д.б. в 4 раза больше, чем у трансформатора той же мощности/частоты. Ну и что, мощность ведь совсем невелика. А в кол-ве деталей явный выигрыш.

2 Microwatt Меня тоже эта тема заинтересовала т.к. из-за лени в подобных случаях ставлю TMA0505S. Да и с преобразователями давным-давно дела не имел. Так что м.б. задам глупый вопрос: А не проще ли, при такой маленькой мощности, будет сделать не трансформатор, а 2-х обмоточный дроссель? Вроде как деталей меньше получается - на вторичной стороне использовать стабилизатор на стабилитроне - КПД ведь не волнует.

К тому, что нужно о расширении думать. А с CAN-ом в автомобилях - это всего лишь пример. Ну не хотели его сразу использовать, по причине дороговизны или ещё по каким, на таки потом всё равно пришлось. И затрат в итоге больше. Так и тут - не стоит из-за сегодняшней копеечной экономии лишать систему расширяемости. Согласен, но только в том случае, если систему в принципе возможно построить на модбасе. Т.е. нерасширяемой. А если понадобится ещё один мастер, и чтобы мастера в одной сети работали и друг-другу не мешали. Или не один мастер, а несколько? По аналогии с автомобилем - систему кондиционирования в прицепе добавили, или систему контроля давления в шинах, или ещё один двигатель. Сейчас просто блоки управления на общую шину вешаются и всё. А если бы там модбас был? Ещё несколько витых пар параллельно тащить?

+1 У всех грузовиков и автобусов сейчас только CAN. До 2006 г. выпуска ещё J1708 встречалось, а сейчас вообще ничего, кроме CAN нет. У легковых тоже доля CAN-а стремительно приближается к 100%. Автомобильные интерфейсы на базе UART (типа K-Line) и со своим протоколом (типа J1850 - кстати, урезанный CAN напоминает) последние дни доживают - только в старых ЭБУ, которые ради экономии ставят на новые машины, и встречаются. Сейчас уже фактически стандарт, что все устройства (двигатель, АБС, КПП, кондиционер и т.д.) в одной сети живут. А скоро и юридически это закрепят. Тогда только CAN и останется. Ну м.б., конечно, что-нибудь получше CAN-а придумают, но на сегодняшний день я ничего такого не видел. Это я к тому, что стали те старые интерфейсы тормозом. Из-за них кучу лишнего железа автодиагностам держать приходится. А в своё время, когда эти интерфейсы внедряли, наверное, тоже об экономии думали. А уж в новых разработках модбас, который уж 10 лет назад похоронить нужно было, использовать - это просто смешно.

Это что за документ? CAN в т.ч. и беспроводной (радио) бывает... Офф. Только не подумайте, что я фанат CAN-а. Протокол как протокол. Но модбас с ним даже рядом не стоит.

Живет CAN на оптике. Какие там проблемы то? Элемент 2-И добавить?

В моей таблице (вроде как от CIA) так: 1 Мбод - 30 м 500 кбод - 100 м 125 кбод - 500 м 20 кбод - 2500 м 10 кбод - 5000 м Но реально не проверял. Из интереса попробовал 1 мбод на 100 м - работает без ошибок при 2-х устройствах. Если 3-е посередине с 50 см усами - пошли ошибки. Но это более, чем 3-х (!) кратное превышение.

Что то мы залезли в теорию, причём выясняется как теоретически правильно называется связка UART+драйвер RS485 (UART+485). Думаю, для практиков, а начинающие здесь это практики, это не представляет интереса. Поэтому предлагаю обсудить связку UART+драйвер CAN как базу для создания маленькой сети. Это будет гораздо интереснее. А уж как это будет называться - не так важно. Пусть будет UART+11898, если ни у кого нет возражений. На мой взгляд, именно такая связка наиболее оптимальна для создания маленькой сети т.к.её стоимость незначительно выше (драйвера одинаковой "брендовости" дороже на $0.3) чем UART+485, а по свойствам (мультимастерность, приоритеты, эхо-контроль и т.д.) она приближается к CAN. Я так вообще не могу найти ни одного недостатка у UART+11898 по сравнению с UART+485. Если в том же модбасе заменить все драйвера RS485 на CAN-овские всё продолжит работать как ни в чём не бывало...

Не совсем понял, что тут называется интерфейсом, а что протоколом. Похоже под интерфейсом понимается физический уровень, т.е. драйверы. Если так, то у CAN (стандартного, 2-х проводного) драйвер проще и лучше, чем у 485. По крайней мере, там не может возникнуть случая, когда один драйвер тянет шину в 1, а другой в 0, и те девайсы, что ближе к первому, воспримут состояние на шине как 1, а ко второму - 0. Да и послушать шину чтобы сравнить, что там реально происходит с тем, что он отправил, девайс не может. Т.е. может, конечно, но толку нет - всё равно совпадёт. Да и проводов к драйверу меньше - при гальваноразвязке актуально. Даже если теряется 100% пакетов?

По заказу одной из известных фирм сделал прибор, подключающийся на их 485 шину (с протоколом типа модбаса), слушающий и пишуший весь трафик вместе с паузами на встроенную флеш. Вообще, это что-то типа чёрного ящика, но ради интереса посмотрел лог с весьма ответственного объекта при нормальной работе. Так багов там немеряно. Вообще удивительно - как всё работает.