Несмотря на то, что предпосылки к отставанию закона Мура от экспоненты обсуждаются ещё с 90‑х, сам закон, с рядом оговорок, справедлив и в наши дни. Это приводит к тому, что если человек поступил в университет в 2010 году, то первые микроконтроллеры STM32F1, выпущенные в середине 2007 года, имели заметные шансы не попасть в его учебные курсы. Как, впрочем, и памяти DDR3 (стандарт также вышел в середине 2007‑го). В момент же получения человеком диплома в 2015‑ом, стандарту DDR4 исполнилось бы три года, STMicroelectronics только что выпустила бы серию STM32F7 со встроенным графическим модулем, а сами STM32 уже два года как имели возможность программироваться при помощи MATLAB и Simulink, минуя код на Си (если верить рекламе).
Подобное положение вынуждает динамично актуализировать знания.
Академические курсы не всегда успевают за прогрессом. А их первоисточник — техническая документация — бывает крайне обширна. Например, базовая документация на микроконтроллеры STM32F103xB насчитывает 1252 страницы. Помимо неё имеются ещё 54 документа типа application note и десятка полтора документов других типов. Поэтому достаточно востребованным источником знаний оказываются профильные сообщества.
Для эффективного получения знаний в подобных сообществах проблема должна быть сформулирована максимально качественно. Ещё в 2001 году появилось (и было переведено на множество языков) фундаментальное руководство «Как правильно задавать вопросы на технических форумах». Представляется, что тезисы данного руководства во многом универсальны и актуальны как для сообществ программистов, так и для сообществ электронщиков, туристов, кулинаров или художников. Однако столь же универсален феномен, когда ответ на сформулированный в соответствии с духом этого руководства вопрос, оказывается не ответом по существу, а чем‑то «идентичным натуральному ответу по существу». Об этом феномене и пойдёт речь в настоящей статье.
Альманах удивительных советчиков
Заранее прошу прощения у читателей, не знакомых с электроникой за то, что для конкретики будут примеры дискуссий именно по данной теме. Надеюсь, любой специалист сможет переложить эти примеры на свою дисциплину.
Итак, представим начинающего, но старательного программиста микроконтроллеров, у которого есть проблема. Пускай для иллюстрации это будет известная ошибка, связанная с работой модуля интерфейса I2C в микроконтроллерах STM32F10xx8/STM32F10xxB.
Сама ошибка, а также длинный, но надёжный путь её решения, изложены в пункте 2.8.7 документа ES096 STM32F101x8/B, STM32F102x8/B and STM32F103x8/B medium-density device limitations. Суть ошибки в том, что при пропадании напряжения на подтягивающих резисторах интерфейса I2C, входные аналоговые фильтры модуля I2C «западают» в некоторое перманентное значение, и модуль I2C переключается в состояние BUSY, переставая реагировать на любые команды извне. Подача питания и запуск микроконтроллера богаты на всевозможные переходные процессы, характеризуемые всплесками и просадками напряжения. Поэтому в ряде случаев складывается ситуация, что модуль I2C «повисает» прямо на старте.
Проблема усугубляется тем, что элементы встроенных аналоговых фильтров имеют значительный разброс параметров. Поэтому в одних случаях проблема не проявляется вовсе, в других — достаточно небольшой задержки между включением микроконтроллера и инициализацией модуля I2C для её устранения, а иногда нужно старательно исполнить все 15 пунктов из Errata, чтобы заставить I2C заработать.
Пример кода, сбрасывающего зависший модуль I2C
Код написан для демоплаты Nucleo‑F103RB. Основная его часть сгенерирована при помощи STM32CubeIDE. Здесь будут приведены только функции main(void) и i2c_reload(void).
Выводами I2C в данном примере являются PB7 (SDA) и PB6 (SCL). Единственная кнопка на данной демоплате подключена к выводу PC13. Нажатие на неё перезагружает модуль I2C.
void i2c_reload(void)
{
const uint16_t SCL_PIN = GPIO_PIN_6;
const uint16_t SDA_PIN = GPIO_PIN_7;
GPIO_InitTypeDef GPIO_InitStruct = {0};
GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_HIGH;
// 1. Disable the I2C peripheral by clearing the PE bit in I2Cx_CR1 register
CLEAR_BIT(I2C1->CR1, I2C_CR1_PE);
// 2. Configure the SCL and SDA I/Os as General Purpose Output Open-Drain, High level (Write 1 to GPIOx_ODR)
SET_BIT(GPIOB->ODR, SCL_PIN);
SET_BIT(GPIOB->ODR, SDA_PIN);
GPIO_InitStruct.Pin = SCL_PIN|SDA_PIN;
GPIO_InitStruct.Mode = GPIO_MODE_OUTPUT_OD;
HAL_GPIO_Init(GPIOB, &GPIO_InitStruct);
// 3. Check SCL and SDA High level in GPIOx_IDR
while (!(GPIOB->IDR & (SCL_PIN|SDA_PIN)));
// 4. Configure the SDA I/O as General Purpose Output Open-Drain, Low level (Write 0 to GPIOx_ODR)
CLEAR_BIT(GPIOB->ODR, SDA_PIN);
// 5. Check SDA Low level in GPIOx_IDR
while (GPIOB->IDR & (SDA_PIN));
HAL_Delay(100);
// 6. Configure the SCL I/O as General Purpose Output Open-Drain, Low level (Write 0 to GPIOx_ODR)
CLEAR_BIT(GPIOB->ODR, SCL_PIN);
// 7. Check SCL Low level in GPIOx_IDR
while (GPIOB->IDR & (SCL_PIN));
// 8. Configure the SCL I/O as General Purpose Output Open-Drain, High level (Write 1 to GPIOx_ODR)
SET_BIT(GPIOB->ODR, SCL_PIN);
//----------------HAL_Delay(100);
// 9. Check SCL High level in GPIOx_IDR
while (!(GPIOB->IDR & (SCL_PIN)));
HAL_Delay(100);
// 10. Configure the SDA I/O as General Purpose Output Open-Drain, High level (Write 1 to GPIOx_ODR)
SET_BIT(GPIOB->ODR, SDA_PIN);
//----------------HAL_Delay(100);
// 11. Check SDA High level in GPIOx_IDR
while (!(GPIOB->IDR & (SDA_PIN)));
// 12. Configure the SCL and SDA I/Os as Alternate function Open-Drain
GPIO_InitStruct.Pin = SCL_PIN|SDA_PIN;
GPIO_InitStruct.Mode = GPIO_MODE_AF_OD;
HAL_GPIO_Init(GPIOB, &GPIO_InitStruct);
// 13. Set SWRST bit in I2Cx_CR1 register
SET_BIT(I2C1->CR1, I2C_CR1_SWRST);
// 14. Clear SWRST bit in I2Cx_CR1 register
CLEAR_BIT(I2C1->CR1, I2C_CR1_SWRST);
// 15. Enable the I2C peripheral by setting the PE bit in I2Cx_CR1 register
SET_BIT(I2C1->CR1, I2C_CR1_PE);
// reInit
HAL_Delay(10);
MX_I2C1_Init();
}
int main(void)
{
HAL_Init();
SystemClock_Config();
MX_GPIO_Init();
MX_I2C1_Init();
const uint16_t I2C_ADRESS = 0xAF;
uint8_t i2c_trans_array[2];
uint8_t data_array[]={0x0F,0x07,0x03,0x01};
const uint16_t DATA_ARRAY_LENGTH = sizeof(data_array)/sizeof(data_array[0]);
const uint32_t I2C_TIMEOUT = 10;
while (1)
{
for(int i = 0; i < DATA_ARRAY_LENGTH; i++) {
i2c_trans_array[0] = i;
i2c_trans_array[1] = data_array[i];
HAL_Delay(4);
HAL_I2C_Master_Transmit(&hi2c1, I2C_ADRESS, i2c_trans_array, 2, I2C_TIMEOUT);
}
HAL_Delay(50);
if(HAL_GPIO_ReadPin(GPIOC, GPIO_PIN_13) == GPIO_PIN_RESET)
{
i2c_reload();
}
}
}Так как данная проблема имеет аппаратную природу и никак не устраняется встроенными средствами среды разработки от компании‑производителя (точнее, генератором кода), то она может оказаться непреодолимой для начинающего программиста. И проведя некоторое время в бесплодных попытках решить проблему самостоятельно, он может обратиться в одно из сообществ с приблизительно следующим вопросом:
Добрый день!
У меня есть демоплата Nucleo‑F103RB с микроконтроллером STM32F103RBT6. Я пытаюсь запустить протокол I2C на данном микроконтроллере, чтобы записать данные в микросхему памяти 24LC00T. Но мне не удаётся выдать никакие сигналы через I2C (проверил осциллографом). Я начал с кода, который сгенерировал CubeIDE. Затем переписал всё на регистрах, удалив лишнее. Попробовал поменять номиналы подтягивающих резисторов со стандартных 4,7 кОм на 1,5 кОм и на 10 кОм. Несколько раз перепроверил назначенные пины: в режиме GPIO всё работает, в режиме Alternate Function — нет. Ничего не помогло. Кто запускал I2C на STM32F10x — подскажите, что я делаю не так?
Вот мой код:
Код на регистрах
#include "main.h"
#define GPIO_CR_CNF_AF_OUTPUT_OD 0x0000000Cu // 11: Alternate function output Open-drain
int main(void)
{
// Конфигурирование системы тактирования
RCC->CR = 0;
RCC->CR |= (uint32_t)(RCC_HSICALIBRATION_DEFAULT) << RCC_CR_HSITRIM_Pos;
RCC->CR |= RCC_CR_HSION;
while(!(RCC->CR & RCC_CR_HSIRDY));
RCC->CFGR |= (uint32_t)(RCC_HCLK_DIV1) << RCC_CFGR_PPRE1_Pos;
RCC->CFGR |= (uint32_t)(RCC_HCLK_DIV1) << RCC_CFGR_PPRE2_Pos;
RCC->CFGR |= (uint32_t)(RCC_HCLK_DIV1) << RCC_CFGR_HPRE_Pos;
RCC->CFGR |= RCC_CFGR_SW_HSI;
while ((uint32_t)(RCC->CFGR & RCC_CFGR_SWS) != (uint32_t)(RCC_SYSCLKSOURCE_HSI << RCC_CFGR_SWS_Pos));
RCC->APB2ENR |= RCC_APB2ENR_IOPBEN;
RCC->APB1ENR |= RCC_APB1ENR_I2C1EN;
// Конфигурирование выводов SDA/SCL
const uint32_t GPIO_BITS_POS = GPIO_CRL_MODE0 | GPIO_CRL_CNF0;
const uint32_t GPIO_BITS_CONF = GPIO_SPEED_FREQ_HIGH + GPIO_CR_CNF_AF_OUTPUT_OD;
const uint8_t SDA_PIN_NUM = 7;
const uint8_t SCL_PIN_NUM = 6;
GPIOB->CRL = ((GPIOB->CRL & (~(GPIO_BITS_POS << (SDA_PIN_NUM * 4)))) | (GPIO_BITS_CONF << (SDA_PIN_NUM * 4)));
GPIOB->CRL = ((GPIOB->CRL & (~(GPIO_BITS_POS << (SCL_PIN_NUM * 4)))) | (GPIO_BITS_CONF << (SCL_PIN_NUM * 4)));
// Конфигурирование I2C
const uint32_t I2C_FREQ = 100000;
I2C1->CR1 = !I2C_CR1_PE;
I2C1->CR2 = HSI_VALUE/1000000;
I2C1->TRISE = HSI_VALUE/1000000 + 1;
I2C1->CCR = HSI_VALUE / (I2C_FREQ*2);
I2C1->CR1 = I2C_CR1_PE;
// Конфигурирование адреса 24LC00T и записываемых данных
const uint16_t I2C_ADRESS = 0xAE;
uint8_t i2c_trans_array[2];
uint8_t data_array[]={0x0F,0x07,0x03,0x01};
const uint16_t DATA_ARRAY_LENGTH = sizeof(data_array)/sizeof(data_array[0]);
// Циклическая запись данных
while (1)
{
for(int i = 0; i < DATA_ARRAY_LENGTH; i++) {
i2c_trans_array[0] = i;
i2c_trans_array[1] = data_array[i];
while (I2C1->SR2 & I2C_SR2_BUSY);
I2C1->CR1 = I2C_CR1_PE | I2C_CR1_START;
while (!(I2C1->SR1 & I2C_SR1_SB));
I2C1->DR = I2C_ADRESS;
while (!(I2C1->SR1 & I2C_SR1_ADDR));
I2C1->SR2;
I2C1->DR = i2c_trans_array[0];
while (!(I2C1->SR1 & I2C_SR1_TXE));
I2C1->DR = i2c_trans_array[1];
while (!(I2C1->SR1 & I2C_SR1_TXE));
I2C1->CR1 = I2C_CR1_STOP;
for(int j = 0; j < 2000; j++);
}
}
}Если говорить про бестолковые ответы, то среди них, пожалуй, можно выделить пять оригинальных шаблонов.
Первый!
I2C — это один из самых распространённых протоколов в цифровой электронике. Поэтому модуль I2C есть буквально в каждом микроконтроллере. Вам просто нужно проинициализировать соответствующие регистры. Для STM32 есть даже кодогенератор, где и сам код писать не надо — просто выбираете нужные режимы галочками и всё!
Сообщение от Первого! обычно появляется самым первым, максимум — вторым постом. Отличительной особенностью является то, что из текста ответа ясно — отвечающий прочитал только заголовок и первую фразу.
Тут, однако, важно различать информационный и сигнальный ответы. Информационный ответ — ответ по сути.
Сигнальный же ответ призван маркировать отвечающего определённым положительным образом. В случае Первого! это нечто вроде «Эй, парни, я тоже в теме этой штуковины! Я тоже о ней слышал!». При этом сигнальная природа ответа предусматривает и сигнальность последующего диалога. Так, если сказать, что кодогенератор уже применён и с ним ничего не работает, Первый! ответит, что нужно тогда попробовать переписать код на регистрах (он знает, что такое регистры! Он — свой в доску!). Если в ответ на это сказать, что код на чистых регистрах попробован и, более того, об этом написано в первом же посте, то Первый! не воспримет это как информационный комментарий, предлагающий ему вчитываться в реплики собеседника прежде, чем писать на них ответ. Вместо этого Первый! услышит: «Пшёл вон из нашей песочницы! Ты — не один из нас!». Соответственно, он скажет вам, что вы хам, что он хотел помочь вам от чистого сердца, а вы высморкались в протянутую им руку.
Монах
О-май-гад, «Попробовал поменять номиналы подтягивающих резисторов»! А потом у нас космолёты падают! Выкинул хреноКуб и быстро пошёл читать «Хоровица и Хилла». Учи матчасть и к микроконтроллерам не приближайся, пока не дочитаешь!
Как мы знаем, имея недостаток компетенций, автор вопроса делал, что мог, чтобы решить проблему, пытаясь угадать причину.
Теоретически, в некоторых пограничных случаях изменение номиналов подтягивающих резисторов могло бы оказать позитивное влияние на проблему. А могло и не оказать.
Однако, если говорить про книгу «Искусство схемотехники» за авторством Пауля Хоровица и Уинфилда Хилла, в ней абсолютно точно нет ничего про Errata ES096. Также в этой книге нет ничего про то, как симулировать дорожки в HyperLynx, как компилировать код из Simulink в Си, как тестировать монтаж микросхем в корпусе BGA при помощи интерфейса JTAG и про много других, важных и весьма практических аспектов электроники.
Да, несмотря на популярность этой книги, в ряде случаев, совет почитать «Хоровица и Хилла» является заведомо бесплодным. Но это если рассматривать данный совет как информационное сообщение.
А он может вполне оказаться сообщением сигнальным. Не секрет, что, скажем, в веб‑разработке в среднем денег платится больше, чем в разработке под микроконтроллеры.
Однако электронщики и все причисляемые к ним обладают (или, в ряде случаев, подразумевается, что должны обладать) почётным сакральным знанием — как электроны превращаются в биты и байты. Это даёт возможность отыгрывать архетип монаха‑аскета.
Представляет ситуацию Монах так: он стоит в грубом шерстяном коричневом балахоне (в духе Gregorian) на крепостной монастырской стене. Порывистый ветер треплет его капюшон, серое облачное небо над ним подчёркивает его аскетичность. Но вдруг к воротам монастыря приближается веб‑разработчик с STM32 и Ардуино. Он видится Монаху эдаким непутёвым младшим двоюродным племянником местного князька. На нём надет пёстрый крикливый камзол (расстёгнутый и слегка сползший), а под руку он ведёт двух сельских девок. Причём в одной из рук у него ещё и кувшин с вином, половина которого уже выпита. И вот он, подойдя поближе к стене, крикливо спрашивает:
«Ээ! Так а чё там? Как внутрь‑то попасть? Девки‑и, хочу в монасты‑ырь!»
А Монах ему такой:
«Убирайся прочь, недостойный! И не возвращайся, пока не прочитаешь Священную Книгу. А после может и поговорим»
В общем, своего рода гейт‑кипинг, но с местным, электронным колоритом — вас отправляют по некоему когнитивному маршруту, но решения вашей проблемы в его конце заведомо нет. А есть якобы Просветление и Откровение.
Академист
На ваш вопрос невозможно дать какой‑то конкретный ответ. Во‑первых, вы ошибочно используете термин «протокол». В вашем случае корректно говорить про модуль интерфейса I2C. Во‑вторых, вы не указали, каким напряжением вы запитываете ваш микроконтроллер.
В рамках сигнального общения Академист создаёт себе ореол «научности». Делает он это двумя путями:
нездоровым уточнением терминологии
нездоровым уточнением значений параметров, которые в нормальной дискуссии имели бы общепринятые значения по умолчанию. Забавным примером данного подхода является миниатюра «как скопировать файл?»
Для избегания перечисления всего, принятого по умолчанию, в метрологии и физике существует регламентированное понятие «стандартные условия». Разумеется, данное понятие не охватывает все случаи, дисциплины и параметры. И периодически вместо регламента приходится довольствоваться расплывчатой традицией.
Так, если происходит обсуждение микроконтроллеров STM32F1, то обычно подразумевается питание 3,3 В, если не указано иное. Да, STM32F103RBT6 способен работать при напряжении 2,0 В. И гипотетически такое напряжение питания могло бы стать причиной подобного поведения. Однако, если автору ответа доподлинно известно о схожих симптомах при снижении напряжения питания, то в рамках информационного ответа можно так и написать:
«У меня была похожая ситуация, когда я попытался снизить напряжение питания микроконтроллера до 1,8 В. Правда, у меня был STM32L100RB. У вас напряжение питания 3,3 В или меньше?»
Почти всегда есть какое‑либо разумное ограничение любой величины, которым можно задаться прежде, чем отвечать. При необходимости следует указать это ограничение в ответе.
Абсолютно всегда можно сформулировать ответ, как рассказ об известном отвечающему случае схожих проблем при выходе того или иного параметра за некие пределы.
Однако, если цель — сигнальный ответ, а документально конкретное стандартное условие не регламентировано, то есть ли причина отказать себе в удовольствии немного погонять новенького салагу?
Бывают, разумеется, и эксцессы, когда новичок забывает сказать, что его устройство работает при +150°С, либо что он пытается передать сигнал I2C через кабель длиной 500 метров. Но очевидным абсурдом было бы в рамках информационного ответа рассматривать подобное заранее. Хотя бы потому, что такое не предугадать.
Схожая ситуация и с терминологией.
С одной стороны, новички почти всегда «плавают» в терминологии и потому их вопросы бывает сложно понять без уточнений.
С другой стороны и сама терминология — не фундаментальные физические константы, а весьма зыбкая условность.
Взять, к примеру, термин «Источник тока». ГОСТ Р 58593-2019 Источники тока химические. Термины и определения сообщает:
источник тока; ИТ: Источник электродвижущей силы (ЭДС), способный отдавать электрическую энергию во внешнюю цепь в результате протекания в нем химических или физических процессов.
Получается, что источник тока — это источник напряжения. Что же тогда — источник напряжения? :)
Или термин «Амплитуда сигнала». Для синусоиды она отсчитывается от точки равновесия до максимального значения, для меандра (прямоугольных импульсов) — от минимального до максимального значения. Из подобной неоднозначности при помощи преобразования Фурье (которое может разложить меандр в сумму синусоид) вполне можно вывести апорию не хуже, чем «Значит, я сам себе дедушка».
Или термин «частота Найквиста». Классически, данный термин применяется в контексте дискретизации аналогового сигнала. Частота Найквиста равна половине частоты дискретизации при аналого‑цифровом или цифро‑аналоговом преобразовании. Почему эта частота так важна? Если частота дискретизации в два и более раз больше, чем наибольшая частотная составляющая оцифровываемого периодического сигнала, то потерь информации при дискретизации удастся избежать. То есть частота Найквиста — наибольшая частота, которую удастся извлечь из периодического сигнала без искажений.
Однако в сфере обеспечения целостности сигнала термин «частота Найквиста» используется как некая воображаемая тактовая частота, которая образуется при передаче последовательности 0101010101010101. То есть она в два раза меньше битрейта. Так, в одном из примеров автор, в контексте работы с памятью DDR4 пишет, что «Nyquist frequency period, equivalent to 1/f».
У меня есть небольшая лингвистическая гипотеза, почему величину, не имеющую никакого отношения к дискретизации аналогового сигнала, называют частотой Найквиста.
В англоязычной терминологии частота дискретизации называется sample rate. Sample rate измеряется в семплах в секунду. Чем их больше, тем точнее преобразование.
Sample rate лишь одна из двух величин, отвечающих за качество аналого‑цифрового и цифро‑аналогового преобразования. Другая величина называется sample depth. Она отвечает за точность каждого отдельного семпла и измеряется в битах на семпл.
Если мы хотим получить некую комплексную характеристику преобразования аналогового сигнала, есть смысл перемножить sample rate на sample depth. Такое произведение называется битрейт и измеряется в битах в секунду. Он показывает какое количество информации в битах было получено за одну секунду преобразования аналогового сигнала.
У данной величины есть термин‑омоним, который показывает, сколько бит за секунду было передано по одной линии передачи. Он тоже называется «битрейт» и тоже измеряется в битах в секунду. Но он не имеет никакого отношения к аналоговым сигналам.
Теперь следим за руками.
В сфере дискретизации аналоговых сигналов применяется термин «битрейт» и весьма опосредованно связанный с ним термин «частота Найквиста».
В сфере обеспечения целостности сигнала применяется свой термин «битрейт», а это значит... что должна быть и своя «частота Найквиста»! Чему она будет равна? Ну, при дискретизации аналоговых сигналов она равна половине чего‑то‑там, значит здесь она будет равна половине битрейта.
В обычном мире подобные лингвистические параллели являются поводом для анекдотов: «Согласно врачебному заключению, заболевание затронуло не только кору, но и, так сказать, древесину головного мозга». В контексте же обеспечения целостности сигнала, «Древесина головного мозга» стала, де‑факто, общеупотребимым термином.
Мой любимый термин — «Программист на SystemVerilog». Термин‑триггер, термин‑детектор Академистов. Если вы произносите данное словосочетание, то с вероятностью 87% вам расскажут:
«На самом деле»...
...программа — это последовательность действий…
...и так как языки HDL не кодируют последовательности действий, а описывают схему соединений между блоками в ПЛИС или в цифровой микросхеме…
...то инженера, пишущего на SystemVerilog нельзя (НЕЛЬЗЯ!) называть программистом, а надо называть, к примеру, RTL‑дизайнером.
«На самом деле», называть инженера, пишущего код на SystemVerilog «Программистом на SystemVerilog» более чем корректно. И вот почему...
«На самом деле», программу на языке программирования можно написать, только если этот язык реализует императивную парадигму программирования.
К примеру, декларативный язык программирования SQL (чистый, без приставок T‑ и PL/) описывает запросы к базе данных. На нём невозможно описать последовательность действий и, следовательно, написать программу (ну, разве что на 1 апреля обернуть SQL в машину Тьюринга). Тем не менее, про программистов на SQL вполне говорят, что они программисты (вакансии «программистов SQL» на hh.ru, резюме «программистов SQL» на hh.ru).
Ещё забавнее ситуацию делает то, что в самом SystemVerilog существует большое количество императивных синтаксических конструкций. Собственно, раздел № 12 стандарта SystemVerilog IEEE1800-2017 называется «Procedural programming statements».
Кроме этого, второй абзац пункта 4.2 этого стандарта (начиная с версии IEEE1800‑2009) звучит так:
The elements that make up the SystemVerilog language can be used to describe the behavior, at varying levels of abstraction, of electronic hardware. SystemVerilog is a parallel programming language. The execution of certain language constructs is defined by parallel execution of blocks or processes. It is important to understand what execution order is guaranteed to the user and what execution order is indeterminate.
Очевидно, что на programming language пишут programmers.
На всякий случай я решил обратиться за комментарием к главному редактору IEEE1800‑2017 Шалому Берстикеру:
Я: Hello Mr. Bresticker. I am writing an article about SystemVerilog. The chapter 4.2 of the IEEE‑1800 has a phrase "SystemVerilog is a parallel programming language". May I ask you, is it ok to call an engineer who writes on SystemVerilog a "SystemVerilog programmer"? If not, why not?
Shalom Bresticker: It is OK
Представляется, что здесь срабатывают те же механизмы, что заставляют некоторых скрежетать зубами при семантически более чем выверенной фразе:
«Когда он был высокопоставленным военным моряком морфлота, он плавал в Аргентину».
Ведь, как известно, «корабли не плавают, корабли ходят». И что такое «высокопоставленный военный моряк морфлота» офицеру ВМФ тоже будет не вполне понятно.
Риторически забирая звание RTL‑дизайнера у программиста на SystemVerilog, вы лишаете его инаковости и ставите в один ряд с программистами на PHP, Delphi, Visual Basic и Logo :)
По моему субъективному и претенциозному мнению, в рамках информационного сообщения правка ошибочно применяемой терминологии, которая не влияет на суть вопроса, может идти…
...исключительно вместе с содержательной частью…
...и исключительно после содержательной части
Правка же ошибочно применяемой терминологии, которая искажает суть вопроса должна иметь форму «Если под X вы понимаете Y, то <содержательная часть>».
В противном случае, ответ приобретает черты сигнального сообщения.
Переспрашивающий
Странно, что вы выбрали 32‑битный микроконтроллер, когда для описываемой вами задачи хватило бы и 8‑битной ATmega328p. Похоже на XY‑проблему. Вы явно пропустили в вопросе какие‑то важные аспекты. Сформулируйте конкретней, какая перед вами стоит цель. Чего именно вы хотите добиться? Вполне вероятно окажется, что вам больше подойдёт память с интерфейсом SPI вместо памяти c интерфейсом I2C.
Есть гипотеза, что начинающие специалисты часто сталкиваются с так называемой XY‑проблемой (у этой проблемы даже есть свой сайт). Суть XY‑проблемы заключается в следующем. Специалист, озадаченный некой проблемой X, предполагает, что у неё есть решение Y. Как воплотить решение Y он тоже не знает, и потому пытается выяснить, как сделать Y. Но может оказаться, что Y на самом деле не является решением проблемы X. Однако, сокращая свой вопрос, специалист практически стирает все упоминания о проблеме X. В результате сообществу якобы не удастся оказать ему эффективную помощь.
Тут, правда, вот какое дело. Если отвечающий — опытный профессионал и знает, как решить хоть X, хоть Y, то для него не составит труда ответить на вопрос буквально. В строгом соответствии с положением руководства, упоминавшегося в начале статьи: «Если вопрос строится на ошибочных предположениях, любой хакер, скорее всего, даст бесполезный буквальный ответ».
Если отвечающий не является специалистом в Y, но является специалистом в X и предполагает, что дело как раз в X, он может ответить как есть. К примеру, автор вопроса спрашивает:
«Какое максимальное количество каскадов можно сделать в усилителе на биполярных транзисторах?»
Отвечающий может не иметь компетенций в конструировании микросхем. Зато он может иметь богатый опыт в использовании малошумящих операционных усилителей и предположить, что автору вопроса на самом деле нужно не совсем то, что он спрашивает. Тогда ответ будет примерно следующим:
«Если ваша цель — усилить сверхмалый сигнал, то коэффициент усиления не будет являться первостепенным параметром. Гораздо более важными окажутся шумовые характеристики вашего усилителя и устройства в целом. Если дело именно в усилении сверхмалого сигнала, я бы порекомендовал попробовать, к примеру, операционный усилитель AD797. Если вы изучаете способы получения сверхбольшой мощности сигнала, то можно посоветовать обратить внимание на радиолампы — что‑нибудь вроде ГМИ‑2Б с диаметром колбы 210 мм и воздушным охлаждением. Но следует помнить, что работа электровакууммных приборов на высоких напряжениях связана с крайне неприятным рентгеновским излучением. К тому же при работе с высокими мощностями не следует забывать и о лицензировании (а при его отсутствии — проблемах с законом). Если же вас интересует именно внутренняя схемотехника микросхем‑усилителей, то, боюсь, в нашем сообществе вы вряд ли найдёте специалистов. Ну а если речь о DIY‑проекте на дискретных транзисторах, то лично я ничем не помогу — не пробовал поставить в этой дисциплине рекорд :)»
Подобная реплика может как сама по себе оказаться ответом, так и стать конструктивным прологом к дискуссии. Она честно признаёт ограниченность компетенций отвечающего, не позиционируется как непременный ответ на вопрос автора и не пытается его ни к чему склонить.
Совсем другое дело, когда отвечающий осознаёт ограниченность своих компетенций, но, с одной стороны, не желает это публично признавать, а с другой — хочет максимально блеснуть тем, что имеет. Тогда его промежуточной целью становится убедить автора вопроса сформулировать задачу так, чтобы она наилучшим образом подходила к компетенциям отвечающего. Пускай даже это будет абсолютно не та задача, которую требуется решить автору вопроса. А окончательной целью — торжественно ответить на специально и тщательно подготовленный вопрос.
Капитан‑Википедия
I²C (IIC, рус. ай‑квадрат‑си или ай‑ту‑си, англ. Inter‑Integrated Circuit) — последовательная асимметричная шина для связи между интегральными схемами внутри электронных приборов. Использует две двунаправленные линии связи (SDA и SCL), применяется для соединения низкоскоростных периферийных компонентов с процессорами и микроконтроллерами (например, на материнских платах, во встраиваемых системах, в мобильных телефонах). Более подробно про I2C написано здесь.
STM32 — семейство 32‑битных микроконтроллеров производства STMicroelectronics. Чипы STM32 группируются в серии, в рамках каждой из которых используется одно и то же 32‑битное ядро ARM, например, Cortex‑M7F, Cortex‑M4F, Cortex‑M3, Cortex‑M0+ или Cortex-M0. Каждый микроконтроллер состоит из ядра процессора, статической RAM‑памяти, флеш‑памяти, отладочного и различных периферийных интерфейсов. Более подробно про STM32 написано здесь.
На StackOverflow есть хорошая рекомендация для озаглавливания и формулирования вопроса: качественный заголовок и формулировка вопроса должны содержать… вопрос. Но согласно примеру выше, если Капитан‑Википедия видит вопрос:
«Как при помощи X сделать Y?»
то его ответом будет:
«X — это <определение X, скопированное из Википедии>. А Y — это <определение Y, скопированное из Википедии>. Кстати, по ссылкам <ссылки на статьи Википедии про X и Y> вы можете ознакомиться с данными сущностями более подробно»
В рамках различных сообществ Q&A (Question and Answer) зачастую предусматривается голосование за качество того или иного ответа. И если подобному бесполезному и не отвечающему на вопрос ответу поставить минус, то Капитан‑Википедия отреагирует следующим образом:
«Не, а за что? Я что‑то не так сказал? Или вы считаете, что X — это не <определение X, скопированное из Википедии>? В чём, по‑вашему, мой ответ неправильный? Скажите, что, на ваш взгляд, в моём ответе является ошибкой и я тот час поправлю это»
Несмотря на существование у StackOverflow (и, соответственно, у electronics.stackexchange) флага вызова модерации «Not An Answer», по опыту, жалобы на подобного рода ответы отклоняются модерацией со словами «It seems to be OK».
По‑сути, Капитан‑Википедия занимается фармингом репутации при помощи не слишком отягощающей мозг деятельности. И так как модератор не может быть специалистом во всём, а в цитатах из Википедии написано «что‑то там вроде бы толковое, вроде бы про X и про Y», то положение Капитана‑Википедии оказывается достаточно стабильным. В результате поведенческий паттерн закрепляется, а ещё через некоторое время он получает внутренние экзистенциальные обоснования и становится частью личности. И даже прямой дополнительный вопрос:
«Вы что, не слышите себя? Как можно на вопрос, начинающийся со слова «Как», отвечать «X — это»?»
Капитан‑Википедия ответит:
«Не, я не понимаю вас, а чё такова‑то? Всегда всем нравилось, а вам сейчас — нет. Что‑то с вами не то»
Актуальна ли проблема?
Следует оговориться: грань между хорошим и плохим ответом всегда размыта.
Подобно тому, как сломанные часы два раза в сутки показывают правильное время, Монах два раза в год к месту упоминает «Хоровица и Хилла».
Академист два раза в год подскажет термин, по которому решение проблемы будет гораздо легче найти в Интернете.
Первый! своим бестолковым комментарием поднимает сползающую тему и активизирует дискуссию.
Переспрашивающий может предоставить вам легальную возможность обойти ограничение на лаконичность вопроса (главное, уметь ею пользоваться и не давать ему гнуть свою линию).
А все они вместе могут оказаться тем самым жёлтым, резиновым утёнком (только слегка говорящим), от формулирования вопросов к которому в голове спрашивающего возникает своё собственное решение проблемы.
Дискуссия с перечисленными типажами не бесполезна на 100%. Исключение составляет Монах — его действительно нужно игнорировать во всех случаях.
Если вы пишете достаточно вдумчивые реплики и получаете на них дурацкие ответы, то вы демонстрируете личную работу над проблемой. В результате к обсуждению рано или поздно может подключиться настоящий эксперт, который вам поможет.
Однако, если принять существование вышеприведённых паттернов поведения в целом как негативное явление, возможен ряд антитезисов:
Проблема не актуальна, так как Chat‑GPT скоро заменит все формы подобной профессиональной коммуникации
Подумаешь, какие‑то фрики разгоняют чепуху в своих маленьких уютных эхо‑комнатах. Проблема является некоторым неудобством, но ни в коем случае не угрозой
А что вы хотели от бесплатных ответов? Здесь, в Интернете, никто никому ничего не должен
И, забегая вперёд, в целом, я согласен с каждым из этих антитезисов. Однако, мне думается, здесь есть, что обсудить.
Chat‑GPT
Если говорить коротко, то в ответ на вопрос про I2C, приведённый в начале статьи, Chat‑GPT посоветовал перепроверить всё ещё раз — весьма обстоятельно и по пунктам, в которых действительно часто ошибаются белковые двуногие. Но затем внезапно написал:
«Рекомендуется также обратиться к форумам и сообществам разработчиков STM32, где вы можете получить поддержку от опытных разработчиков с похожими проблемами и настройками»
Поэтому я не стал уточнять, известен ли боту Chat‑GPT пункт 2.8.7 документа Errata ES096.
Пожалуй, рано или поздно GPT превзойдёт всё, что могут предложить сообщества. Но пока его профессиональные советы скорее напоминают очень вежливого Первого!.
Полный ответ Chat‑GPT
Когда у вас возникают проблемы с запуском протокола I2C на микроконтроллере STM32F103RB, есть несколько факторов, которые стоит проверить:
Настройки GPIO и альтернативной функции (Alternate Function): Убедитесь, что вы правильно настроили пины I2C как альтернативную функцию. Проверьте соответствующие регистры GPIO и AFIO для установки правильных значений функции пина.
Настройки I2C: Убедитесь, что настройки I2C правильно сконфигурированы. Проверьте регистры CR1 и CR2 I2C. Убедитесь в том, что такие параметры, как скорость передачи данных (bit rate), адрес I2C устройства и остальные параметры, сконфигурированы правильно для вашей задачи.
Правильное использование I2C: Убедитесь, что вы правильно используете функции I2C для инициализации, отправки и приёма данных. Проверьте последовательность инициализации I2C перед отправкой данных. Установите правильные флаги Acknowledge и Transfer Complete в регистре SR1 для отправки данных и контроля передачи.
Проверка подтягивающих резисторов: Убедитесь, что подтягивающие резисторы на линиях SDA и SCL представлены в рабочем диапазоне. Как вы упоминали, вы уже попробовали изменить их номиналы, но проверьте их снова. Обычно использование резисторов с номиналом 4,7 кОм является стандартной практикой.
Проверка оборудования: Убедитесь, что ваша демоплата, провода и соединения на работоспособны и не повреждены. Порой неисправности могут быть связаны с физическими проблемами, такими как обрывы или короткое замыкание на плате или в проводах.
Если вы уже проверили все эти аспекты, но проблема все еще остается, вам может потребоваться более подробная диагностика. Вы можете использовать отладчик, чтобы проверить, на каком этапе происходит сбой, или применить дополнительные методы отладки, например, включение отладочного вывода на выводную консоль для вывода отладочной информации.
В документации от OpenSTM32 и STMicroelectronics есть примеры кода и статьи, которые могут помочь вам с настройкой I2C на STM32F10x. Рекомендуется также обратиться к форумам и сообществам разработчиков STM32, где вы можете получить поддержку от опытных разработчиков с похожими проблемами и настройками.
Опасен ли дилетант с высоким социальным капиталом?
Однажды на конференции, в рамках выступления, представитель одного крупного дистрибьютора комплектующих сказал:
«Если у микросхемы, прошедшей на производстве входной контроль, всё в порядке, это ещё не значит, что микросхема годная и оригинальная. Однако, если у неё выявлено хотя бы одно расхождение с заявленными характеристиками, с высокой вероятностью будут и другие расхождения. Крайне сложно создать подделку, идентичную оригиналу во всём, кроме одного‑единственного аспекта»
Подобный подход можно экстраполировать, в том числе и на членов сообщества. Перечисленные типажи являются примерами неадекватного социального поведения, которое, как показывает практика, часто маркирует и иные странности.
К примеру, я сталкивался в разное время и в разных местах с парой инженеров, ведущих диалог строго в форме гибрида Монаха и Академиста. Кроме этого, один из них настойчиво считал, что «м» — это «мега», а «М» — это «милли».
Второй предлагал увеличить номинал выводного резистора, залитого компаундом, зачистив компаунд до контактов и подпаяв параллельно к нему ещё один резистор. Комментарии, что так мы можем лишь уменьшить общее сопротивление, но никак, ни при каких условиях не увеличить, он парировал:
«Но так же будет два резистора, а не один! Два — это же больше, чем один!»
Приведённые примеры — мелкие частности. По‑настоящему глобальным феноменом и примером масштабов, до которых может вознести человека его святая уверенность в том, что он специалист, можно считать скандально известного Сираджа Равала. Данный персонаж бросил ВУЗ, не доучившись в нём, и завёл в 2016 году свой Youtube‑блог. Поначалу он рассказывал о криптовалютах, но достаточно быстро переключился на тематику машинного обучения и искусственного интеллекта. Удачно поймав волну популярности AI/ML, он собрал порядка полумиллиона подписчиков и поверил в себя. А именно:
Объявил о запуске специального платного ($199) курса «Сделать деньги при помощи машинного обучения» для 500 человек (по итогу набилось около 1200 человек)
Решил опубликовать свою научную статью
Внезапно, некоторое количество студентов курса обнаружили, что курс состоит из кода, натасканного из Гитхаба, где этот код выложен совершенно бесплатно, и потребовали вернуть деньги. А научное сообщество сообщило, что статья является плагиатом, где «мы» оригинала заменено на «я», а ряд терминов просто выдуман. Так, вместо «Комплексного (complex) Гильбертова пространства» в статье Сираджа фигурировало «Сложное (complicated) Гильбертово пространство». Деньги возвращены не были, сейчас Youtube‑блог Сираджа насчитывает 755 тыс. подписчиков и их количество продолжает расти.
AI/ML достаточно далеки от электроники. Но сообщества в целом и отдельные его члены в частности демонстрируют схожие паттерны поведения, не столь привязанные к специализации, как бы ни хотелось закрыть глаза на это в силу профессиональной солидарности. О гораздо более близкой к электронике ситуации речь пойдёт в следующей статье.
Комментарии (57)
nikolz
20.08.2023 14:35-2"Суть ошибки в том, что при пропадании напряжения на подтягивающих резисторах интерфейса I2C, входные аналоговые фильтры модуля I2C «западают» в некоторое перманентное значение, и модуль I2C переключается в состояние BUSY, переставая реагировать на любые команды извне. Проблема усугубляется тем, что элементы встроенных аналоговых фильтров имеют значительный разброс параметров"
Что такое "«западают» в некоторое перманентное значение"?
Можно ссылку на схему этих входных аналоговых фильтров. И чуть подробнее о влиянии разбросов параметров их параметров в цифровых чипах. Очень интересно узнать что-то новое.
Прим: состояние BUSY в I2C это ноль на шине. Или Вы знаете иное?
Flammmable Автор
20.08.2023 14:35+2У меня встречный вопрос: вы прочитали пункт 2.8.7 из документа ES096, ссыклу на который я привёл в начале того абзаца, который Вы обильно цитируете?
nikolz
20.08.2023 14:35-5Отвечать вопросом на вопрос - это приём, когда человек не хочет отвечать на него.
Полагаю, Вы не поняли то, что прочитали.
«западают» в некоторое перманентное значение -это Вы тоже там прочитали.
Так зачем цитировать то, что не понимаете?
Вы выдернули из песни слова а дальше читали:
Обходной путь
Выходные данные аналоговых фильтров SCL и SDA обновляются после того, как происходит переход на линии SCL и SDA соответственно.
Переход SCL и SDA может быть принудительным с помощью программного обеспечения, настраивающего I2C I/Os в режиме вывода. Затем, как только
аналоговые фильтры разблокированы и выводят уровень линий SCL и SDA, флаг ЗАНЯТОСТИ может быть сброшен с помощью программного
сброса, и I2C может перейти в основной режим. Следовательно, необходимо применять следующую последовательность:Отключите периферийное устройство I2C, очистив бит PE в регистре I2Cx_CR1.
Сконфигурируйте SCL и SDA I/Os как выходные данные общего назначения с открытым стоком, высокого уровня (запись 1 в GPIOx_ODR).
Проверьте высокий уровень SCL и SDA в GPIOx_IDR.
Сконфигурируйте ввод-вывод SDA как выход общего назначения с открытым сливом, низкий уровень (запишите 0 в GPIOx_ODR).
Проверьте низкий уровень SDA в GPIOx_IDR.
Сконфигурируйте ввод-вывод SCL как выход общего назначения с открытым сливом, низкий уровень (запишите 0 в GPIOx_ODR).
Проверьте низкий уровень SCL в GPIOx_IDR.
Сконфигурируйте ввод-вывод SCL как выход общего назначения с открытым стоком, высокого уровня (запишите 1 в GPIOx_ODR).
Проверьте высокий уровень SCL в GPIOx_IDR.
Сконфигурируйте ввод-вывод SDA как выход общего назначения с открытым стоком, высокого уровня (запишите 1 в GPIOx_ODR).
Проверьте высокий уровень SDA в GPIOx_IDR.
Сконфигурируйте SCL и SDA I/Os в качестве альтернативной функции Open-Drain.
Установите SWRST-бит в регистре I2Cx_CR1.
Очистите SWRST-бит в регистре I2Cx_CR1.
Включите периферийное устройство I2C, установив бит PE в регистре I2Cx_CR1.
Сначала разберитесь, а не несите вздор в массы.
--------------------
Я собрал кучу схем и особенно с I2C Интерфейс банально простой и никогда ничего не залипает, если Вы понимаете, что делаете, а не исполняете роль мартышки с очками.
Flammmable Автор
20.08.2023 14:35+1О, вы прочитали пункт 2.8.7! Это - хорошо.
Следующие вопросы:
Зачем, на Ваш взгляд, нужны 15 пунктов воркэраунда, если "никогда ничего не залипает"?
Разобрались ли вы в схеме входных фильтров, которой в этой Errata нет?
Как вы понимаете фразу из этой Errata "Consequently, the I2C BUSY flag is set, and the I2C cannot enter master mode"?
nikolz
20.08.2023 14:35-3А Вы разве не увидели в моем предыдущем ответе цитату - продолжение Вашей цитаты.
Отвечаю на Ваш вопрос - прочитал.
Теперь ответьте на мой:
Покажите схему этих фильтров.
le2
20.08.2023 14:35+9в 2015 я ловил подобную проблему на STM32F4x. Ситуация проявлялась хаотично после нескольких часов работы в климокамере или во время тестов на статические разряды.
Оказалось что ошибка в... документации на I2C сороколетней давности. Если детально изучить автомат состояния, то можно обнаружить что если прилетит помеха, которую приемник I2C воспримет как синхробит, то автомат может оказаться в состоянии бесконечного ожидания следующих импульсов, которые не поступают потому что слейва ни о чем не спрашивали.
В спецификации Филипс всегда прямо указывалось что I2C шина исключительно внутриплатная. У нас же сплошь и рядом делают её межплатной.
Ситуацию разрулили программно. Просто если обнаруживаем проблемы на шине, то переводим ножки в режим GPIO (софтверно имитируем окончание передачи для слейва), а потом опять в режим I2C.Написал ли я об этому на какой-нибудь форум? Конечно же нет. Я думаю что если вы тратите на подобное больше 20 минут в неделю, вы делаете что-то не так. В том чтобы найти подобную ошибку нет ничего героического. Это проблемы производителя чипов и нужно сообщить ему. Не нужно стесняться нужно сразу садиться к нему на шею и бомбить техподдержку запросами. Они легко идут на контакт. Можно высыслать им дизайны схемы и даже свои электронные платы в их лаборатории.
gev
20.08.2023 14:35+3ловил подобное на PIC32MZEF, думал что я уже разучился =) В итоге перешли на PIC32MZEM (там этот баг устронили)
nikolz
20.08.2023 14:35-2подключаю датчики по этой шине на расстояние до 10 метров и все работает
А указанная Вами проблема решается с помощью тайма ожидания ответа.
Если за установленное время ответа нет, то делается сброс шины.
kkuznetzov
20.08.2023 14:35+3Вопрос на чём будет обучен Chat GPT. А то выйдет нейросетевой монах.
Но знающий Хоровица и Хилла наизусть.
le2
20.08.2023 14:35+3"Хоровиц и Хилл" это для меня отдельный юмор. Я встретил за жизнь только одного разработчика который как и я решал по книжке задачи. Оказалось что русский текст переводился какими-то студентами и вредителями и без заглядывания в английский оригинал решить ничего не возможно. Просто чудовищное количество ошибок.
Отсюда делаю вывод - все кто хвалит или закатывает глаза книгу не изучали, а только разглядывали картинки.
GospodinKolhoznik
20.08.2023 14:35+2ХХ в оригинале довольно легко читается. Как и вся техническая литература.
checkpoint
20.08.2023 14:35+3Спасибо, посмеялся.
I2C действительно очень своеобразная (багастая) шина и описанный эффект "залипания" (I2C hog) может быть вызван не только ведущим устройством (микроконтроллером), как описано в статье, но и любым ведомым если его схема сбороса недостаточно хорошо продумана (в большинстве случаев это RC цепочка). А так как ведомых устройств на шине бывает много, "определить кто виноват и что делать" бывает очень и очень затруднительно.
Пример из жизни. В нашем процессорном модуле RanetkaPC есть несколько шин I2C, одна из которых очень часто подвешивается при перезагрузке, да та так что сброс по питанию не всегда помогает. Долгими и упорными ночными бдениями выяснилось, что на этой шине сидит, среди прочих устройств, аудио-кодек, он-то шину и завешивает при сбросе. Проблема решилось добавлением диода Шоттки в цепь сброса аудио-кодека: от конденсатора на линию питания, для того, чтобы при отключени питания конденсатор оперативно разряжался, а не удерживал ведомое устройство в непонятном состоянии.
Flammmable Автор
20.08.2023 14:35+3Спасибо, посмеялся.
Всегда пожалуйста :)
Спасибо вам за любопытный кейс.
zurabob
20.08.2023 14:35По стандарту сброс шины возможен 9 импульсами по SCL - вы пробовали такой вариант?
Поскольку в ведомых устройствах крайне редко используется SCL stretching и еще реже возможно зависание в этом состоянии, это всегда помогает (в моих устройствах) . И возможно это более правильно, чем
22пФ на шинуШоттки. )checkpoint
20.08.2023 14:35+2К сожалению, в Linux-овом драйвере от Designware такой фичи не предусмотрено. Было бы у нас голое железо - можно было бы попробовать.
zurabob
20.08.2023 14:35Жаль, что почти нигде аппаратно не подерживается эта фича и приходится делать ногодрыгом, хотя в основном документе NXP по I2C UM10204 это рекомендуется. Помимо быстрого перевключения с возможным несрабатыванием POR, возможны еще и помехи на линии и прочее.
VT100
20.08.2023 14:35Поскольку в ведомых устройствах крайне редко используется SCL stretching
Смелое заявление...
VT100
20.08.2023 14:35В голосовании надо разрешить множественный выбор.
Flammmable Автор
20.08.2023 14:35Неа :) Из нескольких выбирайте тот единственный вариант, который подходит больше всего :)
VT100
20.08.2023 14:35Нет абсолютного совпадения, а льстить — не хочется. ;-)
Flammmable Автор
20.08.2023 14:35Нет абсолютного совпадения
Руководствуйтесь относительным :) А всё многообразие вариантов можете изложить в комментарии :)
engin
20.08.2023 14:35+1У меня есть подобная подборка диалогов экспертных сообществ обсуждающих тему на стыке того чем все они занимаются, при том что между всем этим есть темная буферная зона, которую они не пересекали, или не подозревали о наличии таковой. Смотрят на это как на НЛО. Причем они традиционно сами между собой стоят по разные стороны баррикад, это ПЛК-шники и эмбеддеры. Тема НЛО никому не понятна и у всех набор своих прутензий и критики. После демонстрации им технологии в работе, по каждому замечанию, они молчат, а монах откровенно хамит, или страсти переходят в заявления - диво дивное, прикольненько, но что с этим делать не понятно, мне оно точно не нужно, причем с изрядной долей не аргументированного сарказма.
Flammmable Автор
20.08.2023 14:35У меня есть подобная подборка диалогов экспертных сообществ
Приведите пример. Интересно почитать.
mikko_kukkanen
20.08.2023 14:35+1Интересно читать комменты на Хабре, все в духе этой публикации, причем на любую тему. Задача для любителей ML - классифицировать тех, кто на Хабре пишет. Самому часто очень хочется быть Первым!
Daddy_Cool
20.08.2023 14:35+3Есть еще один вид советчиков: ОФИЦИАЛЬНАЯ ТЕХПОДДЕРЖКА.
Их советы звучат так: "Обновите драйвер, поставьте последние обновления системы, проверьте систему на вирусы".
Пример. Существует такая звукокарта Focusrite 18i6, она всем хороша, кроме того, что... иногда подвисает. Т.е. может прекратить воспроизвоить звук на половине песне. Несколько лет толпы людей страдали, обсуждали на форумах, и рекомендовали друг другу различные способы танцев с бубном, ну там - активный USB-порт, укороченный шнур, и т.п... А техподдержка... писала то, что выше!
(Потом производитель таки выпустил новую версию драйверов и... всё стало лучше, но появилась новая неприятность - система стала иногда фризиться, а выключаешь звукокарты - и норм. Пока думаю связано с банальным перегревом).
old_bear
20.08.2023 14:35+2Программист на SystemVerilog
Я звоню в полицию! :D
На самом деле острая реакция HDL-щиков на этот термин связана не с формальной терминологией а с неиссякаемым потоком убеждённых в том, что просто подправить синтаксис С-кода до формального соответствия SV - это единственное что нужно чтобы получить работоспособный RTL.
И ладно бы они делали эту ошибку один раз, по незнанию. Но не счесть случаев, когда пациент надевает каску из фразы "у меня в симуляторе работает" и дальнейший диалог развивается по шаблону "как сварить яйцо в микроволновке". И вот как раз такие пациенты употребляют термин "программист на Верилоге" достаточно часто чтобы выработать соответствующий рефлекс у тех, кто разницу между симулятором и аппаратной реализацией отчётливо понимает по долгу службы.
sam_sil
20.08.2023 14:35+1Согласен с вами. Ведь если посмотреть не на один пункт из спецификации SystemVerilog окажется что в ней есть две части. Синтезируемое и не синтезируемое подмножество. Одно для реализации цифровых схем, другое для использования в симуляции. И конечно синтезируемое подмножество поддерживается симуляторами, но синтезатор не поддерживает преобразование несинтезируемого подмножества в цифровую логику.
И получается что есть HDL-инженеры которые в первую очередь пишут код на SV для реализации конкретного дизайна. А с другой есть верификаторы где конечно используются и классы и программные модели. И действительно верификационное окружение можно считать программным продуктом которое проверяет соответствие дизайна спецификации. Даже вот есть, например cocotb использующий python, более доступная вариация инструмента для верификации вместо SV. Но еще с кучей ограничений и более медленный!
И если программист перейдет в разработку цифровой электроники ему легче стать верификатором и делать эффективные верификационные решения, чем проектировать и писать дизайн который пойдет в чипы.
sepulkary
20.08.2023 14:35-1Какая-то мифологизация. Больше двадцати лет разрабатываю электронику, в частности, самостоятельно освоил AVR и STM32, общение на специализированных форумах всегда было крайне спокойным и информативным.
И кстати, Errata надо читать до Datasheet, на этапе выбора МК.
netch80
20.08.2023 14:35+4И кстати, Errata надо читать до Datasheet, на этапе выбора МК.
И машина времени для получения Errata из будущего должна входить в комплект оборудования любого эмбеддера.
sepulkary
20.08.2023 14:35Понимаю ваш сарказм, но не разделяю его. Я действительно читаю документацию на МК в порядке Brief - Errata - Datasheet (выборочно) - Reference Design - Reference Manual (выборочно) - App Notes. Конечно, возможна ситуация, когда МК совсем свеженький, без Errata, но надо ли закладывать такой МК в серийное изделие?
fndrey357
20.08.2023 14:35+2По моему глубокому убеждению. Чуть из другой отрасли, но все-же.
Книги, в большинстве случаев, оцениваются по следующему алгоритму: у меня было описываемое или не было. Если было - надо почитать, если не было, но может быть - тоже надо отложить и прочитать. В остальных случаях книга - фуфел.
Масса знаний есть у большинства. Большая часть возникающих вопросов - некие граничные вещи. Поэтому и начинаешь выходить за рамки личного багажа знаний. Само по себе это не плохо. А для тех, у кого эти знания основные - вызывает раздражение и иногда неадекватные ответы.
Мой личный опыт. Я веду кучу личный файликов - типа "полезности тепло", "полезности пожарка" и т.д. Куда запихиваю материалы по стыковке разных разделов, отдельные нормативные кусочки, которые следует учесть, и всякую полезность, которая может пригодится. По мере возможности - со ссылками на источник. очень помогает в сложных ситуациях разрулить и понять кто прав.
punzik
20.08.2023 14:35+2Хорошо бы теперь вопрошающих так же подробно классифицировать. Первый тип, пожалуй "Эрраты не читай, вопрос задавай" :)
Flammmable Автор
20.08.2023 14:35В рамках данной дискуссии, любопытно было бы узнать, какого типа вопросы Вы считаете достойными ответа Монахов (именно они обычно красуются фразами "Эрраты не читай, вопрос задавай")?
Просто, как было написано в самом начале статьи:
Академические курсы не всегда успевают за прогрессом. А их первоисточник — техническая документация — бывает крайне обширна. Например, базовая документация на микроконтроллеры STM32F103xB насчитывает 1252 страницы. Помимо неё имеются ещё 54 документа типа application note и десятка полтора документов других типов. Поэтому достаточно востребованным источником знаний оказываются профильные сообщества.
Именно эти причины являются основой существования Монахов. Думаю, Вы согласитесь: если некий идеальный вопрошающий прочитал
всю Википедиюкаждую эррату, каждый апноут и практически наизусть знает юзер мануал, то советы от Монахов (как и сами Монахи) ему, банально, не нужны. Потому, что при возникновении проблемы такой вопрошающий пойдёт не к "мудрому" Монаху, а в официальную техподдержку.punzik
20.08.2023 14:35+1Во-первых, мой пост был о том, что развешивать ярлыки можно с обеих сторон. И раз уж вы "пересчитали" отвечающих, было бы справедливо так же остроумно и ёмко обозвать вопрощающих.
Во-вторых, раз уж вас это так задело (о причинах можно только догадываться), отвечу по существу.
Разработчик железа в первую очередь читает даташит, во вторую - эррату, в третью - юзер мануал и аппноты. Программисту микроконтроллера желательно делать то же самое, но подробности из даташита ему обычно не очень нужны. По этому первым документом для вдумчивого чтения должна быть эррата. А уж тем более при непонятных программно-аппаратных ошибках (а в аппаратуру он уже залез, меняя номиналы подтяжек).
Хороший тон - задавать вопрос, когда доки и гугл не помогли. Оправдание объёмом мануала в 1252 страницы - не оправдание. Кто-то же их читает, раз может дать ответ на форуме. К тому же, часть про I2C страниц 20, не больше. И "каждую" эррату читать не обязательно, достаточно только ту, которая относится к микроконтроллеру. А она обычно совсем на 1252 страницы.
К сожалению, тенденция такая, что вопрошающих, но не читающих (даже не гуглящих) становится только больше.
Flammmable Автор
20.08.2023 14:35+1Во-первых, мой пост был о том, что развешивать ярлыки можно с обеих сторон.
Если говорить вашими словами, то ярлыки с той стороны развешаны 22 года назад в руководстве "Как правильно задавать вопросы на технических форумах". Я убеждён, что "было бы справедливо так же остроумно и ёмко" указать на то, что и отвечающие далеко не всегда святые.
Хороший тон - задавать вопрос, когда доки и гугл не помогли
Возвращаясь к моему вопросу: задавать вопрос кому? Официальной техподдержке или эксперту из сообщества?
Если техподдержке, то зачем нужны эксперты и сообщества?
Если эксперту, то что сверх того, что написано в официальной документации может сообщить эксперт? Свои предположения и домыслы о недокументированных особенностях того или иного изделия? А что в них ценного, в этих предположениях и домыслах, раз он не является ни разработчиком конкретного изделия, ни официальным лицом?punzik
20.08.2023 14:35+1то ярлыки с той стороны развешаны 22 года назад в руководстве "Как правильно задавать вопросы на технических форумах".
Не вижу ярлыков и осуждения в этой прекрасной статье. Только объективные рекомендации.
что сверх того, что написано в официальной документации может сообщить эксперт?
Опыт. Ведь за этим люди сидят на форумах, для обмена опытом.
И не нужно впадать в крайности. Между "прочитать эррату" и "прочитать 1252 страницы и всю Википедию" - пропасть. И отношение отвечающих в этих случаях будет совершенно разное. Одно дело не очень внимательно прочитать мануал, и совсем другое полениться придумать вопрос для Гугла.
Flammmable Автор
20.08.2023 14:35Опыт.
О-о! Здесь хотелось бы поподробнее :) Что Вы подразумеваете под опытом и чем Ваш опыт, на Ваш взгляд, может быть кому-то полезен? Хотелось бы услышать пример. Можно - реальный, можно - воображаемый.
Ну или предположим, что вы Эксперт С Опытом, а у меня возникла проблема с неким устройством. Я прочитал всю-всю-всю документацию (прежде чем заговорить с Экспертом С Опытом) - ответа не нашёл. Вопрос, зачем мне Ваш опыт? В рамках взаимной психотерапии? :) Послушать, как у вас тоже не заработало, обняться и поплакать? :)
punzik
20.08.2023 14:35чем Ваш опыт, на Ваш взгляд, может быть кому-то полезен?
А ваш? Вот конкретно эта статья несёт какую практическую ценность, кроме почесания вашего собственного ЧСВ? При этом, ваши технические статьи весьма хороши, я даже несколько в закладки добавил.
Flammmable Автор
20.08.2023 14:35При этом, ваши технические статьи весьма хороши, я даже несколько в закладки добавил.
Спасибо :) Черт побери, это всегда приятно слышать :) Можете, к слову полайкать мои две предыдущие технические статьи и поднять мне карму, раз такое дело. )))) И ещё подписывайтесь и ставьте лайки. И оставляйте Ваши комментарии )))))
- чем Ваш опыт, на Ваш взгляд, может быть кому-то полезен?
- А ваш?Я считаю свой опыт полезным в связке с умением донести его в удобочитаемой и концентрированной (сжатой) форме.
Когда мне пишут комментарии вроде
Пользуясь отладчиком, всегда была интересно: "что происходит внутри микросхемы?". БОльшая часть статей, как вы и упомянули, написана так, что терпения и желания дочитать даже до середины не хватало:)Отличная статья, все красиво нарисовано, описано буквально по шагам - очень жду продолжения цикла;)
...я понимаю, что я на верном пути.
Вышеприведённый комментарий оставлен под статьёй про JTAG. Можно сказать "Ну и зачем эта статья, ведь есть же стандарт. Нужно не лениться и прочитать (а лучше - вызубрить) его". Но я с подобным буду категорически не согласен.
Смотрите, Вы упираете на необходимость досконального чтения документации. На мой (субъективный и претенциозный) взгляд, если абсолютизировать данный подход, то в мироздании не остаётся места для профессиональных сообществ. Вся электроника, все её компоненты, все её технологи, на мой субъективный взгляд делаются людьми и для людей. Здесь нет места и для какой-то науки (науки "переднего края", разумеется). "Опыт", о котором Вы говорите, в контексте Вашей мм... гипотезы становится замкнутой в специалисте сущностью. Ну зачем нужен ваш уникальный опыт, когда есть документация и есть техподдержка?
Если у Вас есть чем подкрепить Ваши соображения - я с радостью их почитаю. Статья-то и задумывалась, как дискуссионная. Отшифруйте, что вы имеете ввиду, говоря слово "опыт". И какое место в электроники занимает этот "опыт" на Ваш взгляд.
punzik
20.08.2023 14:35Смотрите, Вы упираете на необходимость досконального чтения документации.
Нет, я упираю на хотя бы попытки её чтения. И обижаться на посылку в RTFM не стоит, если это действительно так.
если абсолютизировать
Не нужно.
И нет у меня никакой гипотезы, я просто сказал, что ярлыки - это плохо, и делить всё на чёрное и белое (монахов и каких-то там ещё сказочных персонажей) тоже неправильно. И если уж разделили одних, то делите и других, для баланса. Инь и Янь, в конце концов.
Flammmable Автор
20.08.2023 14:35И обижаться на посылку в RTFM не стоит, если это действительно так.
Вариантов получить проблему всего три:
Вы не прочитали документацию
Вы прочитали документацию, но ошиблись при реализации её положений на практике
Проблема заключается в недокумнтированной работе устройства
Во всех трёх случаях сообщество может помочь. С другой стороны, объективно, во всех трёх случаях можно обойтись без сообщества и экспертов с их ценным опытом. С третей - запросив помощь у сообщества, вы можете услышать от "эксперта", что вам можно обойтись и своими силами. Ну можно, да. Всегда можно. Абсолютно всегда. Вопрос, зачем нужны "эксперты" и подобные "ценные" мнения остаётся открытым.
И нет у меня никакой гипотезы, я просто сказал, что ярлыки - это плохо, и делить всё на чёрное и белое тоже неправильно
Я так понимаю, что от дискуссии Вы вежливо отказываетесь, переходя к тезисам "за всё хорошее". Ну ладно.
punzik
20.08.2023 14:35объективно, во всех трёх случаях можно обойтись без сообщества и экспертов с их ценным опытом
Это будет самый лучший вариант, как для одной стороны, так и для другой.
Я так понимаю, что от дискуссии Вы вежливо отказываетесь
А смысл? Всё, что хотел, я сказал в первом сообщении. Переливать из пустого в порожнее не очень хочется.
Flammmable Автор
20.08.2023 14:35Это будет самый лучший вариант, как для одной стороны, так и для другой.
Тогда при подобном подходе одна сторона (инженеры с их техническими проблемами) останется, а другую сторону (экспертные сообщества) можно навсегда закрывать за ненадобностью.
punzik
20.08.2023 14:35При обратном подходе будет то же самое. Экспертное сообщество выродится в чат чайников, т.к. эксперты устанут отвечать на вопросы, ответы на которые можно найти во второй строке поиска гугла.
А чтобы этого не было, нужно уважительно относиться друг к другу (и не развешивать ярлыки друг на друга). И это большей мере касается вопрошающего, потому что он просит об услуге, а эксперт никому ничего не должен.
[здесь должна была быть фотография дона Карлеоне]
Flammmable Автор
20.08.2023 14:35А чтобы этого не было, нужно уважительно относиться друг к другу (и не развешивать ярлыки друг на друга)
Тут вот какое дело. В упоминаемой замечательной статье "Как правильно задавать вопросы в технических форумах" есть, например, это:
Таких людей мы называем "неудачниками" ("losers") (по историческим причинам это слово иногда пишется как "lusers" - пользователи-неудачники)
Или это:
Быть грубым - нормально
Или это:
приходится безжалостно "фильтровать базар"
И я, в целом, согласен с подобной жёсткой тональностью данной статьи - сам стараюсь формулировать вопросы согласно ей. Но что прикажете делать, если вопрос был сформулирован качественно, а в ответ - полнейший мусор (к примеру, на Вас выпрыгивает Первый! )? Есть ли повод относиться к дурным советчикам как-то иначе, чем к дурным вопрошающим? На мой взгляд - нет. На мой взгляд подобные советчики вырождают сообщество в чат чайников не хуже, чем плохие вопрошающие, о которых вы говорите.
Brak0del
20.08.2023 14:35+1О-о! Здесь хотелось бы поподробнее :) Что Вы подразумеваете под опытом и чем Ваш опыт, на Ваш взгляд, может быть кому-то полезен? Хотелось бы услышать пример. Можно - реальный, можно - воображаемый.
Опыт -- набор навыков и знаний, полученных в ходе решения проблем, а также кругозор. Такое пойдёт?
Например, при поднятии сетевых интерфейсов в FPGA человек может столкнуться с широким спектром проблем, которые можно дебажить неделями. В мануале на корки, например трансиверы, конечно, в общем виде описано, куда копать. Но там полно частностей, на которые можно потратить много времени не умеючи.
А иногда ответы на вопросы лежат совсем не там, где человек ищет. И дело может быть не в человеке, а в неадекватной структуре некоторых мануалов, глюках сред разработки, ОС, ошибках разводки плат и т.д. и т.п.Всё же чужой опыт хождения по граблям способствует прогрессу, не надо его обесценивать.
Flammmable Автор
20.08.2023 14:35В мануале на корки, например трансиверы, конечно, в общем виде описано, куда копать. Но там полно частностей, на которые можно потратить много времени не умеючи. <...> И дело может быть не в человеке, а в неадекватной структуре некоторых мануалов, глюках сред разработки, ОС
Именно это я имею ввиду. Именно об этом-то я и толкую. По сути, опыт, нормальный опыт (а не вышеприведённый "киньте 22 пФ и всё починится") опирается исключительно на документацию. Кто больше знает больше документации, тот более опытен - всё просто.
Поэтому, говоря "Фуууу, даташит прочитал, а эррату не прочитал" или "Чего ты спрашиваешь здесь, почитай лучше документацию", сам говорящий, по-сути (ну вот, лично для меня), автоматически заменяет себя не то, что на Chat-GPT или даже на скрипт, а просто на лозунг. Человек-лозунг :) Пользы от него мм... я даже не знаю. Пожалуй, что - никакой.
Brak0del
20.08.2023 14:35+1Именно это я имею ввиду. Именно об этом-то я и толкую. По сути, опыт, нормальный опыт (а не вышеприведённый "киньте 22 пФ и всё починится") опирается исключительно на документацию. Кто больше знает больше документации, тот более опытен - всё просто.
Не соглашусь. Вот например корка имеет два варианта интерфейсов X и Y. Среда генерит корку под Х нормальную, а под Y -- с неправильным направлением одного порта. По документации -- всё норм, корке без разницы с какими интерфейсами её юзают. А по факту Y в этой версии использовать нельзя. Если точились на него -- переделывайте.
Или корка генерит неправильную обёртку, заменяет STD_LOGIC порты на STD_LOGIC_VECTOR(0 downto 0). Вляпавшись в это ранее, опытный человек уже будет знать, что обёртку можно исправить и всё будет работать. А не зная, первый раз придётся до этого дойти. Доки опять молчок про это.
Flammmable Автор
20.08.2023 14:35-1корка имеет два варианта интерфейсов X и Y. Среда генерит корку под Х нормальную, а под Y -- с неправильным направлением одного порта.
Формально, путь стандартен: техподдержка -> эррата -> багфикс в одном из следующих релизов. Формально, на этом пути сообщество нигде не фигурирует. В реальности вендоры регулярно заморачиваются налаживанием симбиоза с сообществом, но об этом я бы хотел написать отдельно.
An_private
Есть еще один довольно любопытный тип советчиков - практик. Человек не пытающийся разобраться в теории процесса, а решающий проблемы исключительно методом тыка. То есть для приведённого примера его совет будет примерно в стиле "попробуй на обе линии i2c повесить по конденсатору на 22 пФ. Была у меня как-то подобная проблема, решилась таким способом". Что интересно - часто это люди, действительно имеющие огромный опыт. И иногда их советы почему-то помогают. Но в большинстве случаев - либо не помогают, либо приводят к сложно предсказуемой работе.
Flammmable Автор
Да, это действительно прямо отдельный самобытный класс :)
Единственное, что я бы отметил: практик несмотря на свою анти-теоретичность зачастую действительно стремится помочь, а не показать себя при помощи сигнальных сообщений.
Tasta_Blud
и ещё отдельный тип людей: "джедаи". те, которые дают советы, но сами не (непонятно) следуют ли им. они точно знают что делать в той или иной ситуации, но обычно это приводит к следующим проблемам, решение которых они точно знают, но решение обычно всё усугубляет, и ваше общение прекращается на этапе вызова скорой.
Flammmable Автор
О-о, это вообще золотой стандарт :)
Практик, советующий "повесить 22 пф на шину", но никогда не вешавший их туда сам.
Монах, прочитавший из Хоровица и Хилла две главы и приказывающий всем прочитать их от корки до корки
Академист, оспаривающий определение термина до тех пор, пока ему не сообщают, что оно из IEC60050.
Классика.