esaulenka

Проще было б ссылку на оригинал дать: https://www.ti.com/seclit/ug/slyw038b/slyw038b.pdf

Это ещё в 7.что-то-там было: до старта шедулера счётчик вложенности критических секций работает неправильно, по выходу из крит. секции прерывания не разрешаются. Когда искал, куда зарепортить баг, нашёл официальное объяснение, зачем оно так. Меня это не устроило, локальная копия FreeRTOS работала с поправленным значением этого счётчика.

Ну так дело именно в запрещении/разрешении TXE, а не магических пассах с ClearPending. И прерывание возникает при пустом буфере, и сбрасывается только его заполнением. Это в документации написано, можно ничего самостоятельно не изобретать.

У меня тоже нестабильно работало. Подумал-подумал, и решил, что бит сброса I2C в периферии не просто так. Все ожидания - не while (), а циклы с таймаутом. При превышении таймаута - сброс периферии и повторная попытка (до трёх штук). Работает, на помехи в линии и прочие тыканья пинцетом по контактам реагирует адекватно.

Если получится поделить/умножить эти 13,1072 на такие целые числа, чтобы получить ровно 48, то USB работать будет. SD, очевидно, какие-то отклонения не помешают.

Хост может как вызывать set report / get report (это control endpoint), так и писать/читать отдельные interrupt endpoint. С моим грандиозным опытом писания под ПК получается понять это только USB-сниффером; в документации на всевозможные библиотеки этого почему-то не пишут.

Там написано, что помехи бывают не только указанная в этом топике "86 вольт", но и короткие импульсы в пару сотен вольт (в грузовиках обещают аж до киловольта), и отрицательные выбросы, и переполюсовка, и просадки напряжения 5..6 вольт (на 12-вольтовых машинах). Защититься от этого одним единственным преобразователем "с транзистором на 100500 вольт"... Мне кажется, не лучшая идея. Разрывать массу в автомобильных приложениях - очень плохо. Датчиков "сухой контакт" там мало; что входы, что выходы - все привязаны к массе. Впрочем, сама идея хорошая, надо её только "перевернуть".

Господа, прочитайте, наконец, ГОСТ 28751 или ISO7637-2. Вместе, вслух, хором. А только потом придумывайте линейники (с минимальным!! падением 12 вольт), какие-то странные импульсники на 60 вольт, лишь бы защиту не ставить. Там помимо этого стовольтового (100! не 86!) импульса есть ещё несколько... неприятных моментов. Тут можно только посоветовать купить паяльник. Не менее важная штука в нашем деле, чем пара томов по мета-программированию :-)

А в курсе, что подобные слова надо либо предварять фразой "мне Рабинович по телефону напел", либо приводить результаты тестирования?

Принцип "работает - не трожь" никто не отменял. Измерить, какой ток был со штатным блоком, и сделать примерно так же. Нареканий "загадился контакт на карбюраторе" я не помню (хотя - я не специалист по карбюраторам "зубил" :-) ). Ну а если этот новый "ЭБУ" цепляется параллельно со штатным, так вообще заморачиваться не стоит.

Буквально на прошлой неделе в соседней теме обсуждали портирование на IAR. Если вдумчиво подойти, должно нормально взлететь. Там есть странные особенности (типа генерации "на лету" заголовка с регистрами), свой стартап, но ничто не мешает пользоваться своим (или штатным кейловским).

Мы обсуждаем автомобильное устройство. Люди, которые обслуживают автомобили, отлично умеют менять эти "куски проволоки". Другой вопрос, как им вдолбить в голову, что 20-амперный "кусок проволоки" сюда ставить КАТЕГОРИЧЕСКИ нельзя?.. Гм. А покажите, пожалуйста, какое-нибудь серийное автомобильное устройство с таким источником питания. Получается, никто, кроме Вас, автоэлектронику делать не умеет?

Нафиг-нафиг это HAL. В случае "что-то пошло не так" разобраться в этом наслоении абстракций довольно сложно. Судя по слухам "в HAL используется Keil RTOS", "HAL поддерживается только в Keil" и т.д., это не только моя проблема :-) Библиотеки уровня "подрыгать ножкой" и "включить ШИМ" пишутся под конкретные требования на коленке за полчаса. Заодно и виновный во всех косяках доступен :-) PS что присутствующие подразумевают под CMSIS, я не понял. Есть CMSIS core - набор функций/макросов для доступа к ядру и его периферии (NVIC, например). Это есть, и это удобно. А идея "все производители чипов напишут единообразный CMSIS Driver API" не взлетела. Я, во всяком случае, не видел. http://www.arm.com/products/processors/cor...ce-standard.php

Так кризис жеж! Можно сделать что-то похожее из россыпи. У TI аппноут на эту тему есть.

... а у M0-не-плюс - 2.33 по тем же заявлениям (ссылка, оригинал сходу не нашёл). Видимо, ARM рассматривала сферический процессор в вакууме, с бесконечно быстрой шиной. Одно слово - попугаи... PS посмотреть на попугаи других процессоров можно здесь (кнопка "search")

"Западный" ISO 7637-2 обещает выброс до 87 вольт. Он на пол-вольта "жеще", чем ГОСТ 28751 :-) Кстати, обратите внимание: эта величина указана не от нуля, а от номинального питания (13.5 вольт). Стовольтовые преобразователи в природе существуют, но стоят совсем много. И схема там нетривиальная получается, чтобы худо-бедно работало и при 5 вольтах, и при 100. Почитать пару-тройку тем в разделе "автоэлектроника", там готовые решения уже предложены. А если железка "для себя", можно просто задумываться над просьбами "дай прикурить". Хотя бы свой двигатель при этом не заводить...

У меня нескромное предложение: перед тем, как что-то делать, изучить инструмент. Потому что Вы даже не удосужились заглянуть в эту "библиотеку"... Там английским языком написано: /*=============================================================================== =============================================== Функция вывода строки, расположенной во flash-памяти микроконтроллера ================================================================================ ==============================================*/ void LCD_Putsf(flash char *str, int x, int y, int t_color, int b_color, char zoom_width, char zoom_height); Количество аргументов считайте самостоятельно.

Руслан, Ваш ответ - единственный "в тему". Остальные опять понты кидают... Автору темы предлагаю почитать... википедию , там неплохая подборка ссылок. И ещё очень-очень рекомендую scmRTOS. Всё просто и понятно, и документация - просто "на отлично".

Это называется "хобби". Попыток продавать ЭТО я не очень понимаю, но как способ размять мозг - почему бы и нет?

Ничего не понял. Данные из датчиков попадают в два разных массива, переключение между массивами - по команде с ПК. Два этих процесса не синхронизированы. Так почему же оно почти всегда работает? :-) Кто такой BuffUART[2] вообще неясно. Если он нигде не анализируется, на выполнение программы влиять он не должен никак.

Э-э... а ЛЮБЫХ ДРУГИХ мосфетов под рукой не было? Даже не из соображений, что для задачи "моргать диодом" это явный перебор, а просто потому, что "переключение по сигналам 0 и 5 вольт" тут работать не будет. Если подобрать правильные транзисторы (волшебное слово - logic level mosfet), всё будет работать. А если у Вас ещё и источник тока будет работать как источник тока, то ток через светодиод будет 70 мА. PS по характеристике транзистора видно, что если пропустить через него 2.2 ампера, на нём упадёт 0.7 вольта. А ещё по ней видно, что он откроется при 6..7 вольтах. Для надёжности делают больше, например 10 В, но никак не 5 В.

Первый признак любимых граблей эмбеддера: слово "прерывание" есть, а слова "волатайл" - нету.

Вообще-то там так и написано, что Контроллер CAN работает в обычном режиме ( НЕ Listen only Mode).

Можно у этого товарища спросить. Батарейки, подозреваю, одинаковые. http://www.parts4garmin.ru/product/1893789/ или http://www.parts4garmin.ru/product/1532351/

1. проверить, как себя ведёт плата, если её запитать, а потом перезапустить процессор (замыканием ноги reset, без всяких отладчиков) 2. сделать какой-нибудь вывод в консоль ошибочных ситуаций. Для CAN'а, скажем - не вошёл в режим конфигурирования, не вышел из него. Что с регистром статуса до передачи, после...