Tokes

Не нашёл решения изящнее, чем взять первый свободный пин, посадить его на D- и в коде написать следующее: GPIO_InitTypeDef GPIO_InitStruct; GPIO_InitStruct.Pin = GPIO_PIN_6; GPIO_InitStruct.Mode = GPIO_MODE_OUTPUT_PP; GPIO_InitStruct.Pull = GPIO_NOPULL; GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_HIGH; HAL_GPIO_Init(GPIOB, &GPIO_InitStruct); __disable_irq(); HAL_GPIO_WritePin(GPIOB, GPIO_PIN_6, GPIO_PIN_SET); uint32_t i; for(i = 0; i < 10000; i++); HAL_GPIO_WritePin(GPIOB, GPIO_PIN_6, GPIO_PIN_RESET); GPIO_InitStruct.Mode = GPIO_MODE_INPUT; HAL_GPIO_Init(GPIOB, &GPIO_InitStruct); __enable_irq(); Вообще хотел обойтись минимальной кровью, т.е. без задействования какого-либо пина и всё не мог понять, почему не работает управление пином, если инициализирован USB. В даташите потом почитал, что "As soon as the USB is enabled, these pins are connected to the USB internal transceiver automatically." То есть чтобы это порешать надо было деинициализировать USB, потом заново.... В общем, если будет решение лучше - с удовольствием почитаю @Вуйко , спасибо за участие )

Здравствуйте. CUBEMX + CUBEIDE + PUTTY + STLINK V2 Есть blue pill. Создал новый проект в CUBEMX. Включил там USB как COM порт. Завёл приём сообщений (модифицировал static CDC_Receive_FS функцию). Всё хорошо работает ровно до тех пор, пока в CUBEIDE не нажимаю F11 (build + flash + debug). После этого необходимо руками вытаскивать и засовывать кабель, чтобы можно было продолжать пользоваться терминалом. В то же время достаточно коснуться контакта "USB-" - и происходит тот самый желанный реконнект, после которого достаточно нажать restart session в терминале и всё продолжает работать нормально. Вопрос - как сделать программно, чтобы при старте устройство ("com port" или "usb com emulator") само себя "переподключало"?

@Falconist , не могли бы вы подсказать, где про это можно подробнее почитать? Если ориентироваться по документации, то какой параметр смотреть? Input common mode voltage range? Переводится как "диапазон входного напряжения общего режима", но в даташите на ту же TL072 указано значение плюс-минус 11 Вольт. Не понятно, как этим пользоваться. В наличии есть LM393 - у него открытый коллектор - это даже хорошо. В общем надо знать, какой параметр в даташите отвечает за то, что можно сравнивать где-то от 1-1,5 Вольт, а где-то -0,3. Подскажите, пожалуйста. Вы верно угадали, питание однополярное, под землёй я подразумевал минус питания.

Здравствуйте. Проблема в том, что вроде как если на неинвертирующем выходе (+ который) будет меньшее напряжение, чем на инвертирующем (-) - выход ОУ должен притянуться к земле. Я же сегодня у друга наблюдал картину, что неинв. вывод (номер 3 у TL072 и 062, несколько штук которых мы пробовали) если притянут к земле, а на инв. (вывод 2 тех же ОУ) напряжение больше - на выходе ОУ (1 вывод тех же микросхем) почти пять Вольт. Питается ОУ от 7805. А если напряжение на неинв. выводе чутка поднять - выход сваливается в ноль, как и должно быть. Поясните, пожалуйста, почему так происходит?

Моя проблема около трёх страниц назад решилась, когда начал использовать драйвер шины. Всё чётко, практически без задержек, работает как часы. Код не менял, только поставил драйвер. За STM32 - я так понимаю, что лучше в начале поработать с голыми регистрами, а потом уже юзать разные библиотеки. Ибо, зная по себе - хрен бы я что мог нормально отладить, если бы того же ассемблера не знал, а сразу сел на Си писать. Свисток для прошивки камня заказал. Думаю, что надо начать с "привет мир по-микроконтроллерски", то есть помигать светиком. Я так понял там целое приключение после AVR будет. Настроить тактирование, убрать сброс с портов IO, настроить их на выход и включить мигалку. Кстати, пока ресет модуля активен - его настраивать можно? А если после настройки модуля дать ресет кратковременно - он в дефолт сбросится? Дочитаю книгу про это ядро, что на русском есть - сяду курить опорный мануал и даташит. А там, наверно, ветку создам, что ли, там попробую конкретные вопросы задавать, а то тут только дай волю - за свои инструменты будут ложить друг друга на лопатки

@MasterElectric , надо ловить посылку CANbus, и в нужный момент давать АСК. @mail_robot , а что такое ppm? Только ребят, не надо начинать вот этото всего. Просто дайте пруфы на то, что так можно или нельзя. Взаимный срач это нифига не здорово. Решил просвятиться немного, почитал пару смежных тем, типа И знаете что? Там только срач. Не хотелось бы и здесь начать читать такое. Нахрен надо! Пруфы чётко по делу - и всем будет счастье. Наверно. Ну правда, не начинайте Возникли вопросы: 1. Я так понял - HAL, SPL, CMSIS - это всё библиотеки, облегчающие работу с STM32. А в чём принципиальная разница между ними? Можно про преимущества и недостатки каждой? 2. Есть плата для ардуино с STM32 на борту. Брал год назад где-то, но до сих пор руки не доходили, а тут жутко интересно стало, что да как. Собственно вопрос - если я напишу некий код в НЕ Arduino IDE - как мне этот код можно в эту плату запихать? Просто USB интерфейса достаточно будет или надо исключительно через UART/SWD и прочее? 3. Наткнулся на статейки DI_HALTa про STM32 - а есть ещё что-то подобное? Он-то пишет хорошо, но мало. Документацию на инглише проглотить мне будет не так просто, как хотелось бы. Я понимаю, что надо, и буду читать, но это вообще ни разу не быстро По изучению ответов возникнет ещё порция вопросов. Или если такой подход - не тру, может, есть какая годная литература, покрывающая большинство вопросов начинающих о знакомстве с Cortex © ?

@ruhi , интересный вариант тоже, обдумаю. По поводу опечатки - у меня всё верно. Читаем внимательно: определённый флаг сбрасывается записью единицы в соответствующий бит соответствующего регистра - это по документации. Представьте ситуацию, где в регистре, например, TIFR установлено несколько флагов. А мы берём эти несколько флагов, проводим с ними операцию ИЛИ и записываем все эти флаги вместе с установленным в этот же регистр. Что произойдёт в итоге? Правильно - вместо какого-то конкретного мы сбросим все установленные флаги, которые были установлены в единицу на момент операции ИЛИ. Дальше, Clock Prescale Register - я так понял позволяет на ходу подключать прескалер к тактовому генератору? Я даже не знал, что в этом МК такое можно Не пользовался этим регистром, поэтому, подозреваю, этот прескалер отключён. Иначе бы я не получал точных временных выдержек. @mail_robot , я тут почитал. Хочу себе феррари Есть у меня в запасах платка, типа для ардуино, там F103 серия. Скачал референс мануал, а так же даташит на эту серию. Сходу разобраться не получилось. Там указана максимальная тактовая в 72 МГц, так же где-то читал недавно, что порты IO не могут на такой частоте работать. Это так? Ну и другой вопрос - я эту платку смогу использовать где-то кроме как в среде ардуино, которую я так не перевариваю?

@IMXO , про задержку NOPами подумаю, спасибо за идею. Но на дешёвых AVR я, похоже, упёрся в потолок. Давно смотрю на STM32, но как подумаю, сколько там всего...

@IMXO , посмотрел. В даташите это время, если я всё верно понял равно четырём тактам осциллятора: В дизассемблере проход по этим двум командам ветвления плюс переход на начала цикла занимает 6 инструкций, некоторые по два такта за инструкцию Пусть будет 10. Итого, по идее, максимум должно быть в самой плохой ситуации 10+4+10 - 24 такта. При тактовой в 24Мгц это 1 мкс. А у меня как будто всё в самом худшем случае, а то и ещё хуже, как в Беларуси ) @Геннадий , а если сюда ещё прерывания добавить, пока перейдёт на старт ПП прерывания, пока всё это сохранит/вытащит из стека, потом возврат... - это будет точно дольше, чем такая конструкция в данной ситуации. Хотя я уже ни в чём не уверен Ладно, а кто-нибудь видит способ выйти из ситуации победителем?

Есть код такого плана: while (1){ if (TIFR & (1 << TOV0)){ // if timer overflow run_timer4us(); ON; OFF; resetTOV0; // reset overflow flag } if (GIFR & (1 << INTF0)){ // if pin level change run_timer6us(); ON; OFF; ON; OFF; resetINTF0; // reset INTF0 interrupt } } Т.е. в бесконечном цикле идёт опрос двух флагов. Первый - на переполнение таймера, второй - на смену лог. уровня пина PD2. Контроллер ATtiny 2313A. Всё вроде бы не плохо, если бы не одно но. В логике цикла заложена такая штука, что если произошла смена лог. уровня - таймер взводится на 6 мкс (чтобы попасть на середину следующего бита в передаче), а если смены за 4 или 6 мкс не наблюдалось - значит мы как раз на середине принимаемого бита. Но иногда переполнение с 4 мкс наступает раньше, чем должно, а событие по смене уровня отрабатывается потом. Никаких прерываний не используется, ON, OFF - макросы для своего рода дебага в железе типа PORT_LED |= (1 << LED_PIN). run_timerXus() - inline функции с одной строкой TCNT0 = fUs4, где fUs4 - константа, ресеты тоже макросы типа resetTOV0 TIFR &= (1 << TOV0). Картина того, что иногда идёт не так: Сверху - принимаемый сигнал - внизу - результат работы команд ON/OFF в условиях. Тут видно, что вторая смена уровня отрабатывается позже, чем переполнение таймера в 4 мкс, хотя измеритель показывает, что прошло как раз 6 мкс. А вот как оно должно быть по задумке: То есть отрабатывается смена логического уровня и через 6 мкс уже срабатывает переполнение. Но даже это время отклика меня несколько смущает. Сам уровень вроде давно поменялся, а условие только где-то через микросекунду а то и больше срабатывает. Есть вероятность, что фронты/спады недостаточно крутые, пока нечем посмотреть, но это не критично. Критична именно ситуация на первом фото. Как такое вообще может произойти? P.S. Прерывания не использую, потому что с ними вообще не успеваю, период 4 мкс, кварц 24 (!) МГц стоит, (на 20 под рукой не было), константы есть под оба варианта, но это уже другая история

Скажите, пожалуйста, все ли переменные, значение которых может измениться в прерывании нужно помечать словом volatile? Может, есть какие-то устоявшиеся правила на этот счёт?

В официальной документации протокола я нашёл что-то типа этого: CRC SEQUENCE The frame check sequence is derived from a cyclic redundancy code best suited for frames with bit counts less than 127 bits (BCH Code). In order to carry out the CRC calculation the polynomial to be divided is defined as the polynomial, the coefficients of which are given by the destuffed bit stream consisting of START OF FRAME, ARBITRATION FIELD, CONTROL FIELD, DATA FIELD (if present) and, for the 15 lowest coefficients, by 0. This polynomial is divided (the coefficients are calculated modulo-2) by the generator-polynomial: X15 + X14 + X10 + X8 + X7 + X4 + X3 + 1. The remainder of this polynomial division is the CRC SEQUENCE transmitted over the bus. In order to implement this function, a 15 bit shift register CRC_RG(14:0) can be used. If NXTBIT denotes the next bit of the bit stream, given by the destuffed bit sequence from START OF FRAME until the end of the DATA FIELD, the CRC SEQUENCE is calculated as follows: CRC_RG = 0; // initialize shift register REPEAT CRCNXT = NXTBIT EXOR CRC_RG(14); CRC_RG(14:1) = CRC_RG(13:0); // shift left by CRC_RG(0) = 0; // 1 position IF CRCNXT THEN CRC_RG(14:0) = CRC_RG(14:0) EXOR (4599hex); ENDIF UNTIL (CRC SEQUENCE starts or there is an ERROR condition) After the transmission / reception of the last bit of the DATA FIELD, CRC_RG contains the CRC sequence. Я с трудом могу переложить это на Си. Помогите допилить этот вариант, пожалуйста unsigned int CRC_RG = 0; // initialize shift register while (CRC SEQUENCE starts or there is an ERROR condition) { CRCNXT = NXTBIT ^ CRC_RG(14); CRC_RG(14:1) = CRC_RG(13:0); // shift left by CRC_RG(0) = 0; // 1 position if (CRCNXT) CRC_RG(14:0) = CRC_RG(14:0) ^ 0x4599); }

@Vascom , не могли бы вы пояснить, почему он опущен в числе, а в формуле указан? @dev , вставил я в этот код свои данные - uint8_t data[] = { 0xF0, 0x7D, 0x7D, 0x00, 0x00, 0x00, 0xF0, 0xFF }; , на выходе получилось другое число - 0x3E58. Что никак не похоже на 0x72FC. p.s. пробовал инвертировать, т.е. считать с 8 по 1 байт - всё равно не то.

В процессе ремонта всяких аудиосистем, в том числе с усилителями на двухполярном питании часто сталкивался с аудиопроцессорами PT2322. Возможно, вам подойдёт эта микросхема. Она достаточно дешёвая.Правда, шестиканальная, но вместе в процессором PT2323, добавив четыре усилителя можно превратить систему в целый домашний кинотеатр Описание микросхем по ссылкам ниже. http://pdf.datasheetcatalog.com/datasheets/70/499857_DS.pdf http://pdf.datasheetcatalog.com/datasheets/105/493266_DS.pdf

Здравствуйте. Отчаялся найти хорошее пояснение с примерами как считать CRC CAN frame. Ранее с CRC не сталкивался. Пишут, что вот это: x^15 + x^14 + x^10 + x^8 + x^7 + x^4 + x^3 + 1 - есть полином, он же многочлен CRC-15 конкретно для CAN шины. Есть у меня кадр CAN сообщения от SOF до EOF. Какие именно я должен взять данные и что конкретно я должен с ними сделать. Возвращаясь к полиному. Пишут, что HEX его - 0x4599. То есть в бинарном представлении 0100 0101 1001 1001. Я вижу, что все "x" в степени соответствуют их порядковому номеру справа-налево. Кроме x^15. Он тут равен нулю. Так что значит всё же эта запись, как её читать правильно? Например, конкретный пакет с уже посчитанным CRC: DATA, 0x0CF00400, 0x8, 0xF0 0x7D 0x7D 0x00 0x00 0x00 0xF0 0xFF, 0x72FC, ACK Дайте информацию, пожалуйста, как конкретно эта CRC получилась.