Перейти к содержанию
Поиск
    

amiller

Участник
 Профиль  Обзор контента

  • Постов

    202

  • Зарегистрирован

  • Посещение

  • Победитель дней

    1

 Тип контента 

Сообщения, опубликованные amiller

  1. Опубликовано · Пожаловаться

    Вопрос в том, на что это повлияет...

    Был зафиксирован случай, когда при питании VDD и VDDA от разных стабилизаторов, отключалось питание BackUp области и RTC регистров у STM32F105 при наличии батарейки.

    После установки между питаниями двустороннего диода, проблема исчезла.

    Поэтому можно сказать, что если питание на МК подается не в соответствии с документацией, это может приводить к сбоям во внутренней логике управления питанием. А это уже может привести к непредсказуемым последствиям в работе любой периферии. К сожалению...

     

  2. Опубликовано · Пожаловаться

    По завершении цикла DMA счетчик передач становится = 0, и чтобы зациклить процесс приходится разрешать прерывание от DMA и в нем переинициализировать управляющие слова основной и альтернативной структур DMA-канала. В принципе, это не фатально, в моем случае прерывание возникает раз в 500 мкс, но в примерах для STM32, что я встречал, прерывания не используются - только инициализация и всё...

    В STM32 в настройках DMA есть специальный бит "CIRC" (Circular Mode), который как раз и отвечает за этот функционал. Ищите аналог у Вашего контроллера.

  3. Опубликовано · Пожаловаться

    Нужно сбросить в двух tiny2313 фьюзы до заводских настроек. Может у кого есть параллельный программатор или FUSEBIT DOCTOR? Проживаю в Минске.

    Но ведь tiny2313 всегда стоила в районе одного доллара, нет? Для таких процессоров любая возня с программатором себя не оправдывает.

    Проще выпаять и выкинуть, заменив новыми.

     

  4. Опубликовано · Пожаловаться

    ТС присматривался к видеограбберу значит 8 бит ему похоже достаточно (можно даже логарифмирование сделать из 12 в 8, а не просто отбросить младшие разряды), и если уж понижать fps до 39 то тогда эти 39МБайт/c можно и через USB2 попробовать пропихнуть, без ухищрений с usb3. и для этого взять готовую плату lpclink2 за 20$.

     

    и ещё придётся делать свою плату под это, ради единственного устройства, а корпуса у lpc4370 не самые приятные, особенно если 32х разрядные шины из него вытаскивать, а не просто входы АЦП и USB.

    и вот тут я вообще никакой радости по сравнению с готовой redpitaya не вижу.

    Действительно пока я считаю, что 8бит (256 градаций серого) в изображении достаточно. По крайней мере предыдущее устройство работало именно в таком режиме.

    Если сравнивать:

    lpc4370 - с одной стороны уже опробованный способ реализации. С другой стороны всё на грани фола и без запаса. Кроме того значительную часть времени придётся потратить на проектирование железа без гарантии успеха.

    redpitaya - приятно удивила по параметрам. Как то мимо меня прошла. Присмотрюсь повнимательнее. По возможностям похоже то, что доктор прописал. Насколько быстро удастся её освоить...

     

  5. Опубликовано · Пожаловаться

    Попробуйте подойти к вопросу с другой стороны. Не существует электронных микроскопов, которые давали бы честные 1024х1024 50 Гц.

    У нас не совсем микроскоп, хотя принцип работы тот же.

    Я допускаю, что заказчик не совсем понимает, что ему нужно, но стоит на своем.

    И у меня два пути:

    1. На имеющемся железе реализовать примерно 256х256 50Гц, а недостающие пикселы нарисовать. Это я всегда успею сделать.

    2. 2 вариант - попытаться обеспечить честное разрешение.

    Пока самым перспективным вижу использование платы видеозахвата. Так как изделие эксклюзивное, то цена не особо беспокоит.

    То что касается разверток, то пока провел эксперименты с видеокартой.

    С синхроимпульсами всё в порядке. Строчная развертка тоже выглядит отлично, красивая пила. Правда в сигнале присутствуют импульсы гашения во время обратного хода луча, но для строчной развертки это скорее даже плюс.

    А вот то что в кадровой развертке присутствуют импульсы гашения, это скорее минус. Маловероятно, что простыми способами удастся как то управлять длительностью или амплитудой этих импульсов.

    Но тем не менее что-то получилось, можно пробовать дальше. Если не прокатит, то уж 50кГц пилу не так сложно сделать и на контроллере. В крайнем случае уменьшить количество пикселов а потом подфильтровать.

    То что касается системы отклонения, то проблема решаемая. Сейчас обеспечивается пилообразный ток вполне приличного качества на частоте 5кГц (с 10% обратным ходом).

    И понятен путь, как разогнать отклонялку до 50кГц.

    По аналоговой части видеоусилителя тоже всё достижимо.

     

  6. Опубликовано · Пожаловаться

    Ничего не понял.. ТЗ непонятно. А так да, СТМ в видео делать нечего, есть спецпроцы, та же серия DaVinchi у TI. Хотя то, что вы описали - тут наверное все проще, ибо никакой "обработки" вообще не узрел

    С одной стороны просто, так как на нижнем уровне обработка не предполагается, а вынесена на верхний уровень.

    С другой стороны нужно оцифровать аналоговый сигнал и передать на комп изображение в 1 млн. пикселов с частотой 50Гц.

    По принципу действия:

    Есть отклоняющая система для электронного луча, которая формирует растр. Луч сканирует образец. Строчная и кадровая развертка представляют собой пилообразные сигналы.

    Датчик улавливает отраженные электроны. Выходное напряжение датчика пропорционально профилю поверхности образца.

    Далее полученное изображение нужно отобразить на экране монитора и записать на носитель.

    Если это всё можно сделать на МК, то буду рад, если предложите варианты.

    Пока я увидел только один вариант, который описал ранее.

    Из обработки предполагается реализация: изменение контрастности и яркости, фильтрация с целью шумоподавления.

  7. Опубликовано · Пожаловаться

    Стоит задача:

    В области электронной микроскопии реализовать формирование строчной и кадровой развертки для системы отклонения и обработку видеосигнала с максимальными параметрами 1024х1024 50Гц.

    Предыдущий вариант системы работал с максимальным разрешением 480х480 10Гц и был реализован на STM32F437.

    Развертки были сделаны на внешних ЦАП (SPI). Оцифровка изображения на встроенном АЦП в dual mode (примерно 2,5 мегасемпла).

    Видеобуфер во внешней памяти и на комп данные предавались без предварительной обработки через Ethernet на комп, где и отображалась картинка.

    Так как практически всё делалось через DMA, то в контроллере оставалась ещё уйма свободного времени для фоновых задач.

    Но по новому ТЗ скорость обработки надо увеличить в 20 раз, что нереально в такой конфигурации.

    Пока на ум приходит только следующее:

    1. С помощью видеокарты с аналоговым выходом и поддерживающей HD качество формирую пилообразные развертки (сигналами цветности) и синхроимпульсы.

    2. Развертки через усилители подаются на систему отклонения, а синхроимпульсы подмешиваются к сигналу с датчика изображения (яркости).

    3. Сформированный видеосигнал подается на плату видеозахвата, поддерживающую соответствующее качество.

    В теории должно сработать.

    Вопрос: может быть есть специализированные контроллеры, девайсы, которым по зубам эта задача?

    Или может есть совсем другое решение, до которого я не смог додуматься?

  8. Опубликовано · Пожаловаться

    т.е. у вас не бывает так, что написал сразу хорошо программу, сдал и она тебя не беспокоит. У вас только так, потом пилить, пилить и пилить?

     

    Не знаю, как у Вас, а у меня поддержка проектов в основном - это изменение функционала по пожеланиям клиентов.

    Т.е. девайсы продаются своим чередом, но у клиентов (как старых так и новых) изредка возникает желание что-то изменить в функционале.

    Прибыль мы получаем от продажи устройств. А поддержка ПО позволяет расширять продажи.

    По запросам клиентов формируется новая версия ПО, которую они могу взять с сайта и самостоятельно обновить программу в устройстве.

     

    А теперь давайте представим, у "AlexandrY" около 50 проектов на контроле. Если по каждому из них возникает потребность что-то изменить хотя бы раз в год, каждую неделю перед службой поддержки ставится новая задача.

    У меня тоже около 10 проектов в поддержке, поэтому представляю, что это такое.

  9. Опубликовано · Пожаловаться

    В STM32F достаточно жесткие требования по выбору кварцевого резонатора на 32768.

    Как то надеяться на устойчивую работу генератора можно если: выбран нужный резонатор, правильно выбраны нагрузочные емкости, разводка цепей кварца в соответствии с рекомендациями.

    Если кварц с большой собственной емкостью, то удаление нагрузочных емкостей для устойчивости запуска может помочь. Но частота убежит больше чем на 100ppm.

    Если источник питания нарастает медленно, то убедитесь, что в момент включения LSE у вас уже номинальное напряжение. Попробуйте вставить задержку на 100мсек перед инициализацией RTC. (Не любит генератор пониженное напряжение при первом старте).

    Предполагаю, что в STM32L всё может быть ещё хуже из за пониженного потребления.

    Поэтому ищите AN по кварцевому генератору для своего контроллера и внимательно его изучайте.

     

  10. Опубликовано · Пожаловаться

    Ну делают такие вещи много на чем, а RPi я хочу за нормальный сетевой стек. Насчет "будет виснуть из-за флуда" непонятно - сетевой драйвер захлебывается в промискуитетном режиме, что ли? видел пару самоделок, торчаших в довольно забитую корпоративную сеть -- такого вроде не было. Уж скорее он будет терятьпакеты, чем виснуть, не?

     

    Реле времени на 5 минут... думал об этом, конечно. Цифровое будет подвержено помехам, аналоговое электронное в общем тоже -- там же компаратор. Остается механика, пневматика и прочая экзотика. В общем, я был бы рад обойтись без этой детали, если получится.

     

    Про вылет программы интересно. В общем да, контроля четности нет, рано или поздно сбойнет. И регулярными перезагрузками делу не помочь. Правда, шансов что перекинется именно ячейка с условием, которое я проверяю -- немного. а от накопления мелких сбоев регулярная перезагрузка поможет.

    Похоже Вы собираетесь свой кондиционер в космос запускать...

    Есть же простые проверенные решения для микроконтроллеров, называются - внешний WDT. микросхем таких полно, стоят едва ли больше 50 центов и предназначены специально для работы в условиях помех. Если включать в соответствии с APNotes, то вероятность сбоев только недалеко от эпицентра взрыва.

    Вы же вероятно на своей малине ножками можете дергать? Пока дергаете, всё хорошо, как по каким то причинам перестали - автоматический сброс через заданное время.

    А вообще для реализации надежного управления критичными устройствами должны применяться технические решения соответствующего класса.

    И маловероятно, что в этот круг входят Raspberry или Arduino. А если это поделки на уровне хобби, то надо срочно уменьшать уровень паранойи.

     

     

  11. Опубликовано · Пожаловаться

    Простой совет:

    Забудьте про всякие HAL, Cube, CMSIS и тому подобное. Зачем Вам разбираться с багами индусов?

    Если Вы пишите код для какой то периферии, то нужно знать, как эта периферия работает.

    И перед написанием кода нужно по крайней мере один раз прочитать раздел раздел 15 "General-purpose timers (TIM2 to TIM5)" из документа "RM0008".

    Там ответы на все Ваши вопросы. Кроме Вас в Вашем коде ошибки вряд ли кто найдёт. Навскидку варианты:

    Где то в другом месте программы повторно инициализируются используемые ноги процессора.

    Вы просто забыли в программе осуществить вызов представленных функций для настройки таймера.

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

    Там меньше десятка регистров, в которые при настройке нужно записать нужные значения.

    Разберитесь один раз и у Вас будет собственный код настройки таймеров, в котором Вам будет всё понятно и который можно будет портировать под разные проекты. Под STM вообще без проблем.

     

  12. Опубликовано · Пожаловаться

    Т.е. логика работы выглядит так?:

    DMA постоянно гонит данные в буфер, без остановки, когда у нас есть свободное время, мы начинаем анализировать этот самый FIFO буфер на совпадение.

    Звучит быстро и просто, проверяем 64 байта на совпадение и обрабатываем.

    А что будет если байт 200, или больше? Что если большой, как говорится, payload? А если система комманд исчисляется десятками? Проверять несколько раз буфер на все соответствия?

    Мне кажется это расточительно по ресурсам, хочется ловить из потока нужные данные, и тратить на это минимум времени просто проверяя заголовок сразу в известном месте - в начале буфера.

    Чисто логически FIFO правильное решение, но это очень много времени на проверку всего потока.

    Не совсем понимаю, в чём Вы видите проблему.

    1. Есть кольцевой буфер.

    2. Есть процесс "писатель" - DMA с своим указателем на память.

    3. Есть процесс "читатель" - функция анализа потока, со своим указателем.

    4. В каждом сеансе чтения читаются только те принятые байты, которые были приняты с момента предыдущего сеанса.

    5. Размер буфера выбирается достаточным для конкретных условий.

    6. Процесс "читатель" обычно ищет в потоке заголовок пакета. Затем по заголовку определяет длину пакета и ждёт, пока будет принято нужное число байт. После получения полного пакета - анализ и обработка.

    7. Если используется протокол на базе временных интервалов, например ModBus RTU, то по фиксации паузы в потоке можно инициализировать указатели на кольцевой буфер.

    И всё, ничего сложного, и нет лишних затрат времени CPU.

  13. Опубликовано · Пожаловаться

    Бывали такие случаи с STM32F4XX.

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

    При этом микросхема начинала потреблять лишний ватт мощности и грелась.

    Остальная периферия функционировала нормально. Возможно можно полечить инициализацией этих пинов на вход, не пробовал.

    Но факт, что в таком случае потребление резко возрастает. Может у Вас тоже что-то подобное произошло.

  14. Опубликовано · Пожаловаться

    Задержки при 2х стороннем обмене, фрагментация в усб драйвере и еще мелкие нюансы, которых нет в реальном уарте...

     

    По теме - в таких простейших случаях использую hex-передачу, т.е. код 0 передаю как 00 (в ASCII коде) 255 - как FF.

    прием аналогичен, все символы, кроме диапазона 0-F - ошибка. Конец строки - 0x0A или 0D.

    Вы пишите о мелких нюансах реализации виртуального COM-порта, а с другой стороны считаете возможным передавать данные простейшим потоком, который и протоколом то назвать язык не поворачивается.

    Считаю обязательным и по крайней мере очень желательным:

    1. Забыть о передаче данных без защиты хотя бы двухбайтной CRC.

    2. Не заморачиваться с отдельными реализациями протоколов для Fullduplex и Halfduplex. Всегда есть большая вероятность, что понадобится использовать RS485 или другой полудуплексный интерфейс.

    3. Если нет опыта в реализации, то лучше сразу смотрите в сторону стандартного протокола, например Modbus RTU. Избежите детских проблем при разработке своего протокола и не понадобится клиентам/партнерам/коллегам объяснять преимущества своего уникального протокола.

    4. Ну а если всё же решите пройти по пути создания своего протокола, рекомендую прочитать про SLIP (как уже советовали), а также поиметь хотя бы малейшее представление о уровнях взаимодействия открытых систем, классификации, которая лежит в основе любых обменов данными.

  16. Опубликовано · Изменено пользователем amiller · Пожаловаться

    Конечно. Формировать сигнал CS таймером.

    Вот блин, слона то я и не приметил. А так как синхронизация DMA идёт также от таймера, то попасть в нужный момент времени может оказаться вполне реальным. И даже на одну из разведенных ног CS можно замапить выход таймера, а на вторую придётся перемычку пробросить. Но это всё равно проще инвертора.

    Правда есть одно сомнение: В этом кристалле каналы DMA довольно активно используются. Если произойдёт задержка, то можно не попасть таймером в нужный момент времени. Нужно уложиться в допуск 25 нсек примерно. Вероятно получится, что то мне подсказывает, что DMA занимает шину гораздо меньше времени.

    А программно точно не получится?

    P.S.: Если наплевать на TI mode, то жестких временных интервалов и нет. Можно выставлять CS одновременно с евентом для DMA, а снимать с некоторым запасом на все возможные задержки. Вполне живой вариант.

    Спасибо.

  17. Опубликовано · Пожаловаться

    Возникла проблема:

    Есть плата с контроллером STM32F437ZGT6. На этой же плате находятся два цапа DAC8581 с интерфейсом SPI, на которые нужно слать 16-битные данные с частотой примерно 2,3МГц. Каждый ЦАП подключен к своему каналу SPI, данные загружаются в SPI посредством DMA.

    Чтобы ЦАП принимал данные, в начале каждого сеанса связи ему нужно дергать ногой /CS.

    Соответственно, исходя из скорости обмена, это нужно делать аппаратно.

    Но выяснилось, что в режиме мастера SPI дергает этой ногой только один раз, а потом держит этот вывод в активном состоянии до отключения интерфейса.

    И единственный режим, когда SPI правильно дергает ногой NSS, - это так называемый TI mode. Но есть одна проблема - в этом режиме невозможно изменить полярность и фазу тактовых импульсов.

    И оказалось, что несмотря на то, что режим называется TI mode, полярность импульсов у него строго противоположна полярности импульсов, требуемых ЦАПу, который родом из Техаса.

    Тактовая частота интерфейса установлена 42МГц, т.е. близка к максимально возможной.

    Если тактовые импульсы чуть задержать, например с помощью конденсатора, то интерфейс работает нормально. Но такое решение является нестабильным и температурно-зависимым, так как работа интерфейса зависит от скорости нарастания двух фронтов, данных и тактов.

    Если инвертировать сигнал SCK с помощью внешнего быстрого логического инвертора, то интерфейс работает нормально на этой частоте.

    post-80612-1464762677_thumb.jpgpost-80612-1464762685_thumb.jpg

    Вопросы: Есть ли какой нибудь способ обойтись без внешнего инвертора? Может быть я чего то недопонял в настройках интерфейса? Есть у кого положительный опыт аппаратного управления NSS?

     

  18. Опубликовано · Пожаловаться

    Мечты, мечты... По факту мы имеем сплошь и рядом кодирование элементарных вещей (катриджи, модемы, аккумуляторные сборки, автоэлектронику).

    Про мечты согласен. Но мечтатели находятся с обоих сторон.

    Например производители принтеров наверное мечтают, чтобы по опустошению картриджа (зачипованого кстати) клиент всегда покупал новый картридж.

    Однако мы заправляем их по пять и более раз.

    Сотовые компании мечтают, чтобы купив залоченный телефон, мы годами сидели на невыгодном тарифе. Однако мы легко разлочиваем телефоны и используем их так, как хотим.

    Автопроизводители мечтают, чтобы мы пользовались официально купленными адаптерами и их сервисным ПО. А мы покупаем адаптер в китае за 5 баксов, а ПО взламываем.

    И так далее и тому подобное. Чем востребованнее продукт, тем проще найти решение.

    Все попытки ввести абонентскую плату за пользование изделием обычно соседствуют с попытками получения сверхприбыли. Это означает, что идея копирования устройства или взлома ПО является коммерчески привлекательной.

    А если не гнаться за сверхприбылью, а продавать изделие за разумную, экономически обоснованную цену, то опасности копирования можно или избежать вообще, или сильно затормозить возможных конкурентов.

    Так что реальность сурова также и для тех, кто продавая клиентам продукцию, намеревается потом всю жизнь с них деньги собирать и в пачки складывать.

    У меня были случаи, когда приходилось по просьбам клиентов выводить на российский рынок копии (функциональные) продуктов известных брендов.

    Потом они (бренды) вынуждены были в разы понижать цены, делать скидки, но уже поздно, свою долю рынка мы получили. Импортозамещение, - так сказать.

    А если бы ценник сразу был адекватный, у нас бы и мыслей не возникло лезть в эту нишу.

     

     

     

     

  19. Опубликовано · Пожаловаться

    Забавно, как "знатоки" уже заранее знают, что никому устройство с таким механизмом шифрования не нужно, и что оно не является уникальным и т.д., и т.п. Так вот - есть немало областей, где такой механизм применим и ноу-хау является действительно уникальным. Просто навскидку - разблокировка телефонов и модемов, доступ к контроллеру аккумуляторов ноутбуков или счетчикам в катридже принтера. И да, владелец информации продает время работы такого устройства, или число использований или иным образом ограничивая использование такой вот машинки для печатания денег.

    Речь идёт скорее не о " знании", а о внутреннем неприятии такого подхода на уровне железа. И я думаю, что это преобладающая общественная точка зрения, за исключением отдельных индивидуумов, которые с маниакальным упорством продвигают такую бизнес модель.

    Подумайте о том, какое отношение потребителей к тем компаниям, которые реализуют такие бизнес модели. Это касается, и провайдеров сотовой связи и производителей принтеров и т.п. Если Вам всё равно, что будут думать о Вас Ваши клиенты, то изобретайте очередную "машинку для печатания денег".

    Но не забывайте, что живёт такая бизнес модель только до появления конкурента без подобных заморочек или до элементарного взлома системы кодирования. И чем более востребован продукт, тем быстрее это произойдёт, независимо от количества усилий, которые Вы потратили на защиту.

     

  20. Опубликовано · Пожаловаться

    Да это понятно, только переключение каналов софтовое - одна строка на Си или штук пять команд на ассемблере. Если проц работает на 80МГц - совсем ничто.

    Софтовое переключение каналов АЦП - это что-то из древности, когда других возможностей не было, тип старых Атмег.

    Неслучайно реализация блоков АЦП становится всё сложнее и сложнее, значит это кому-то нужно.

    Не забывайте, что при отработке аппаратной последовательности измерений, когда Вы забираете очередной результат (неважно по прерыванию, или посредством DMA), уже идёт следующее преобразование, без пауз.

    Когда Вы захотите обеспечить 1-2 миллиона преобразований в секунду, терять время на программное переключение каналов не получится.

     

  21. Опубликовано · Изменено пользователем IgorKossak
    бездумное цитирование     · Пожаловаться

    1. В данном проекте и данном примере плюсы не использовались, версию компилятора IAR уже приводил в начале. Думаю, что это роли не играет, более важным является уровень оптимизации - none.

    2. Вы как то слишком уж своеобразно привели примеры для демонстрации своих слов:

    while(1);
printf("hello world");

    Действительно warning будет.

    while(temp1 != ~temp2);
printf("hello world");

    Аналогичного предупреждения не будет, хотя компилятор настолько уверен в ненужности этого кода, что спокойно его выбрасывает, включая while.

    Примерно к 50 сообщению мы уже разобрались, что если включить remarks, то сообщения компилятора будут, хотя и несколько другие.

    Думаю, что уже нет никакого смысла обсуждать конкретную проблему, послужившую поводом для этой дискуссии.

    Увлекательное обсуждение уже давно сместилось даже не в область обсуждения действий компилятора, а в область обсуждения стандарта языка Си.

    Хотя количество сообщений косвенно говорит о том, что и поведение компилятора вызвало много вопросов и в консерватории (стандарте) не всё гладко.

  22. Опубликовано · Пожаловаться

    А если так в icf файле (IAR):

    define symbol __region_EEPROM_start__ = 0x08006000;	/*   4кбайт =  2 сектора */
define symbol __region_EEPROM_end__   = 0x08006FFF;

define region EEPROM_region = mem:[from __region_EEPROM_start__   to __region_EEPROM_end__];

place in EEPROM_region   { readonly section my_eeprom };

  23. Опубликовано · Пожаловаться

    для установки CAN timing лучше использовать CubeMX или программки вроде CAN-калькуляторов

    Тут наверное следует добавить: Если опыта маловато или документацию плохо изучили или принципы работы CAN туманны...

     

  24. Опубликовано · Пожаловаться

    Где-то вы не договариваете. Тот код, что вы привели с локальными переменными, с позиции современных

    компиляторов является "мертвым" кодом и может быть выкинут безо всяких предупреждений даже на низших

    уровнях оптимизации.

    Поверьте, ничего я не "не договариваю". В топике я разместил код в таком виде, в каком проблема (на мой взгляд))

    воспроизводилась, и с которой я столкнулся. Я считал что этого достаточно, так как легко можно проверить.

    Затем, в сообщении 53 я привел законченные примеры кода и результат компиляции IAR.

    Вопрос, как и тема раздела в целом, касается исключительно IAR. Причём на уровне оптимизации - None.

    Причём я по прежнему считаю, что логика формирования предупреждений у IAR страдает.

    1. Переменные 16 битные - код выбрасывается без предупреждений. Вроде мы обосновали, что это логично.

    2. Переменные 32 битные - код присутствует, хотя он в этом случае он не менее бессмысленный.

    Хотя здесь может быть такой аргумент: Две 32 битные переменные имеют право сравниваться, а компилятор заранее

    не обязан предсказывать результат.

    3. В случае "if (true) continue;" предупреждение есть, хотя результат ещё более определен, чем в первом случае.

    Для меня лично (по результатам обсуждения) логично бы выглядело наличие предупреждения и в первом пункте.

    Но видимо это уже связано с многопроходностью компилятора (код выбрасывается на уровне, когда предупреждения

    уже не формируются).

    Наверное нельзя это оценивать однозначно как хорошо или как плохо. Просто надо иметь в виду, что такая ситуация

    возможна и больше обращать внимание на такие неявные на первый взгляд особенности языка и действий компилятора.

     

×
×
  • Создать...