Sergey_Aleksandrovi4

@Arlleex По прошествии 3х лет с открытия этой темы, удалось достигнуть желаемого? Состоялся переход с Си на C++?

Приём называется "stack painting" (окраска стека). Анализировать % использования стека можно не только в отладчике, но и программно. Бывает полезно при длительном тестовом прогоне оборудования.

Совсем забыл поставить точку в этом вопросе. Эксперимент прошёл успешно. По-колхозному: без делителя и последовательного резистора, кинул провод напрямую с генератора (вывод МК) на OSC_IN чипа. Ничего не сгорело, чип исправно тактировался внешним источником. Единственное, не проконтролировал энергопотребление.

Благодарю за ответы. По поводу чипа: секрета особого нет, как и нет смысла про него рассказывать. Вопрос концептуальный. О таком делителе речь? Не пойму идею. C1 отрежет постоянную составляющую меандра, C2 завалит фронты. Я думал о резистивном делителе, но, как заметил Plain, при питании от одного источника это будет излишним. Полистал даташиты на ночь глядя, наткнулся на АЦП от TI. Разрешают тактировать и так, и эдак без каких-либо настроек в регистрах АЦП. Резистор 50 Ом, как понимаю, от "звона" отражённого сигнала (вроде бы эти резисторы непосредственно у выхода источника сигнала рекомендуют ставить, а не со стороны приёмника). В общем, как приедут запасные чипы (чтобы без "железа" не остаться), проведу эксперимент, отпишусь о результатах.

Здравствуйте. Работаю с микросхемой, требующей для тактирования внешний кварцевый резонатор. По-классике: выводы OSC_IN, OSC_OUT, кварц и два нагрузочных конденсатора на землю. Есть желание затактировать её от внешнего генератора. По аналогии с микроконтроллерами STM32 и AVR, где допускается как использование резонатора, так и внешнего синхро-сигнала. Однако, в документации на чип нет ни слова про такую возможность. Более того, в МК при работе от внешнего генератора требуется вручную указывать в соответствующих регистрах опцию "работа от внешнего генератора": Fuse-биты CKSELx в AVR или бит RCC_CR_HSEBYP в STM32. В моей микросхеме таких настроек нет. Предполагаю, что в большинстве случаев внутренний генератор построен по схеме Пирса, и от подачи внешнего прямоугольного сигнала ему поплохеть не должно. Но опять-таки, смущает необходимость явно указывать о факте внешнего тактирования в МК. Самый простой вариант - подпаяться к чипу и проверить. Но, может кто-нибудь здесь поделится мыслями по поводу затеи. PS С производителем чипа связался, но ответа нет уже 3 неделю.

В силовые цепи блоков питания телевизоров иногда устанавливают предохранители :) Внутри блоков питания ЗУ для телефонов их редко можно увидеть. Максимум Fuse Trace (печатный проводник) Кто-то фото внутренностей обсуждаемой розетки выложил. Есть там защиты от перенапряжения, от КЗ? Не силён в силовой электронике, не буду ничего комментировать. Ко всему прочему пластик корпуса может быть горючим. Плюс традиционный "китайский" монтаж (цитата из отзыва) Я бы не оставлял это устройство работать в непрерывном режиме 24/7.

@slanted спасибо, впервые узнал про преобразование типов при предупреждении "implicit declaration". По поведению точно оно: тип int в AVR 16-битный, возвращается через регистры r24:r25. И один из способов проверки int-величины на 0 может осуществляться как раз с помощью команды or r24, r25. Ваш совет помог, но не сразу. Все инклуды были прописаны, предупреждение об implicit declaration не было, перекомпиляция не убирала ошибку. Однако после того, как выполнил Clean Solution и полностью пересобрал проект - картина изменилась. Все проверки bool-результатов выполняются посредством правильной команды and r24, r24 (хотя я так и не понял почему не используют tst или cpi) Спасибо за помощь и за ликбез.

Здравствуйте. Снова я со своими AVR-ками. Пишу загрузчик в gcc (Atmel Studio 7). Отладил алгоритм в основной секции ROM при -Og оптимизации, перенёс в область загрузчика, но ужал по код по размеру: оптимизация -Os. Посыпались глюки. Стал разбираться. Возвращаемые функциями bool-результаты в ряде случаев всегда интерпретируются вызывающим кодом как true. Копнул глубже. Функции возвращают bool-результат через регистр r24 т.к. тип bool однобайтный: объявлен как unsigned char проверил это с помощью sizeof(bool)==1. В asm-листинге вижу как функции заносят корректное значение в r24 перед выходом, пока всё отлично. НО в вызывающем коде проверка bool-результатов на true/false производится 2 экзотическими способами: 1) and r24, r24 2) or r24, r25 Второй вариант и создаёт ошибку, т.к. в r25 зачастую лежит мусор отличный от нуля. В паре мест я видел что перед вызовом функции r25 обнуляется, но обычно - нет, и кроме того через r25 в функцию передаётся аргумент. Я изрядно позабыл avr-asm, но вроде бы логично было использовать специально-предназначенные cpi r24, 0 или tst r24. Ладно, возможно чего-то не понимаю. Нашёл пока лишь единственный способ побороть этот глюк - добавил ассемблерные вставки перед возвратом false. Но это лютые костыли кмк. asm volatile ("clr r25" ::: "memory"); Может быть кто сталкивался с подобным поведением компилятора и знает более элегантные пути обхода? Допускаю, что сам мог где-то в опциях компилятора не указать какой-нибудь волшебный gcc-шный ключ.

Вы слишком высоко оценили мои способности :D Линуксовый мир мне чужд, на банальную сборку одного лишь libiconv по инструкции ушла большая часть рабочего дня. И дело ещё в другом. Все эти исходники должны компилироваться на "ванильных" сборках Atmel Studio. Т.е. если разработчик после меня захочет что-то поправить в коде, то он просто скачает и установит дистрибутив студии с сайта и откроет в ней мой проект, а не будет рвать на себе волосы в надежде собрать рабочий тулчейн из исходников. Было бы дело в одной лишь dll библиотеке, её можно бы было положить в репозиторий с проектом и написать readme как и куда её подключать. По этой же причине отказался от идеи что-либо править руками в make-файле, пусть автоматически генерируется по настройкам из GUI студии. Поэтому буду писать поддержку юникода. По флэш-памяти у меня, грубо говоря, ограничений нет.

Конкретно с этим процессором не работал, но, вспоминая опыт годичной давности - никакой "магии" при управлении ADAU с внешнего МК не было. Описание регистров должно быть в даташите, I2C тоже вполне тривиальный интерфейс. Sigma Studio с отладчиком (у меня был недорогой китайский клон с aliexpress) крайне полезна тем, что управляя через графический интерфейс можно видеть какие биты в каких регистрах затрагиваются, там окошко с консольным "выхлопом" есть. Документация их мне крайне не понравилась. Да и много очень настроек, в голове не удержать. А вот через Sigma Studio отлаживаться было гораздо проще. Даже на их форуме EngineerZone в одной из тем посвящённых ADAU инженер от AD рекомендовал устанавливать этот пакет чтобы в полной мере прочувствовать все особенности чипа.

Тоже малоприменимо, спасибо за совет. У меня в устройстве GUI в которое потребовалось добавить поддержку нескольких языков. Хочется видеть в исходниках именно текст в том виде, в котором он выводится на экран. Если строковые константы будут записаны "крякозябрами" или через подобные литералы, то управлять и модифицировать проект в дальнейшем будет проблематично. Разве что оставлять после каждой строки комментарий в человекочитаемом виде. Но это на потом, если с юникодом не получится.

Нет, только строковые литералы (строковые константы), текст исходников по-прежнему должен быть в ASCII. Изначально была идея прогнать текст через внешние редакторы чтобы получить 8-битные символы, но "крякозябры" в исходниках не допустимы.

В качестве оффтопа спрошу. Как давно и почему вдруг Micro Cap стал вдруг беплатным? Сколько помню студенческие годы, всегда carck.exe в папке с дистрибутивом присутствовал)

Присоединяюсь к совету обновить ПО, наверняка баг какой-то. Для обновления из окна программы нажмите на иконку в правом верхнем углу (три горизонтальные черты) и выберите пункт Check for updates... Вот так выглядит последняя версия, в режиме stream все настройки устанавливаются корректно. Обратите внимание, в новых версиях появилась функция автоматического перезапуска захвата (у Вас в старой версии такой нет в интерфейсе). По сути похожа на осциллограф в ждущем режиме, возможно она Вам подойдёт. Прибор отличный. После его приобретения перестал использовать осциллограф при работе с цифровыми устройствами. Осциллограф использую только для исследования аналоговых сигналов и питания. И в качестве PS на будущее. Подобного рода устройства очень критичны к качеству USB-кабеля. Штатный должен быть хорошим, по крайней мере мне от китайцев отличный достался. Если начнутся проблемы с потерей связи - первым делом меняйте кабель. upd! Так у Вас же анализатор не подключен, ёлки-палки (сообщение Unconnected в заголовке окна). Программа в режиме симуляции запустилась. Поэтому и не реагирует на настройки.

Странно конечно, что мой вариант объявления переменной, но с квалификатором volatile, оказался нерабочим. Я этим способом пользовался в нескольких проектах для объявления массива констант в загрузчике. Была включена оптимизация кода по размеру, уровень не вспомню за давностью лет. Основное приложение обращалось к ним исключительно по указателю. Сам загрузчик к этим переменным никак не обращался.

Когда работал в IAR, то для подобных целей использовал директиву #pragma location = addr И обязательно указывал директиву __root при объявлении переменной чтобы линкер гарантированно её не выбросил. Попробуйте такой вариант: #pragma location = 0x080E0000 __root const uint32_t key_appl = 0x03020100;

Попробуйте факт окончания передачи отслеживать по двум флагам: первично по TXE и лишь вторично по BSY. Уже не вспомню, но были какие-то "приколы" с BSY-флагом в F1xx семействе. void foo(bar) { GPIOB->ODR &= ~GPIO_ODR11; //..... while (!(SPI1->SR & SPI_SR_TXE)); while (SPI1->SR & SPI_SR_BSY); GPIOB->ODR |= GPIO_ODR11; } upd BSY устанавливается с задержкой. Т.е. факт начала передачи отслеживаете по TXE==0. Он становится '0' сразу же после записи слова данных в SPI_DR. После первого такта SCLK, когда слово из временного буфера выгрузилось в сдвиговый регистр, флаг TXE становится '1' и в дело вступает BSY, который к этому времени гарантированно установился в '1'. В общем в RefManual почитайте, сейчас нет времени в это окунаться.

Отпишусь, что ли по результатам: безуспешно. В Path никаких упоминаний Atmel Studio не было. Нашёл топик в котором человеку так же понадобился libiconv в составе avr-gcc http://we.easyelectronics.ru/JustMoose/pro-gcc-i-kodirovki.html. Он, в свою очередь, нашёл собранный под windows avr-gcc с поддержкой libiconv. Правда, avr-gcc там старый: 4.9.2 против последнего 5.4.0. https://andybrown.me.uk/2015/03/08/avr-gcc-492/ Установил ради интереса - преобразование кодировок работает. Изучил в hex-редакторе тело файлов avr-gcc.exe из состава Atmel Studio и из сторонней сборки. Штатный из состава студии про библиотеку libiconv-2.dll даже не знает в отличие от стороннего. При этом строки с ключами -finput-charset= и -fexec-charset= в нём присутствуют. Не удивительно, что у меня ничего не вышло при подсовывании dll в директорию тулчейна. Предположу, что в коде компилятора при обнаружении ключа запроса преобразования кодировки срабатывает "заглушка", она останавливает сборку с ошибкой. Затея с самого начала была обречена на провал. Придётся что-то придумывать с декодированием текста в UTF-8 силами самого МК. xvr, спасибо за содействие.

@xvr, спасибо что откликнулись. exe.exe - глаз замылился под вечер. Впрочем и после правок не помогло, удалил этот вызов из makefile. Директория в которую я размещал .exe и .dll как раз и является директорией Си-тулчейна. Или Вы про тот PATH, который в настройках "переменных среды" Windows?

Здравствуйте. Синопсис. Потребовалось поиграться с кодировками текста в исходниках проекта. В gcc это делается ключами компилятора -finput-charset=UTF-8 -fexec-charset=cp1251 За преобразование кодировок отвечает утилита iconv из библиотеки libiconv. Она отсутствует в стандартной сборке "из коробки" Atmel Studio 7, хотя сам компилятор эти ключи понимает и пытается обрабатывать. Скачал исходники libiconv https://www.gnu.org/software/libiconv/#downloading, собрал под Windows с помощью mingw. На выходе получился исполняемый iconv.exe и его библиотека libiconv-2.dll. Само по себе приложение запускается. Скопировал оба файла в директорию тулчейна \Atmel Studio 7\7.0\toolchain\avr8\avr8-gnu-toolchain\bin т.е. туда, где лежат все исполняемые exe-файлы: avr-gcc.exe, avr-size.exe и др. Проблема. Не знаю как сообщить студии что у неё теперь есть недостающая библиотека libiconv. Нашёл в make-файле упоминания exe-файлов, попробовал вручную прописать путь к iconv.exe. Не помогло, студия сообщает об его отсутствии. Возможно надо было какие-то ключи ещё указать. Перерыл все возможные настройки среды и проекта, не нашёл где бы можно было путь к утилите прописать. Изучил внутренности SW4STM32 - System Workbench for STM32 (из того-же gcc-зоопарка) чтобы сделать по аналогии, он с ключами -finput и -fexec проект собирает без ругани. Не нашёл в недрах директорий ни exe, ни dll относящихся к libiconv. Вопрос. Кто-нибудь имеет опыт или знает, как к Atmel Studio подключать дополнительные утилиты? По правильному пути я иду или для поставленной задачи надо весь тулчейн пересобирать-перекомпилировать?

Переменная period объявлена с квалификатором volatile? Ещё такой тупой совет. Сделайте в обработчике прерывания инверсию какого-либо свободного GPIO выхода и посмотрите логическим анализатором на то, как и когда вызывается обработчик при захвате сигнала.

Здравствуйте. Ветка форума посвящена трассировке, но у меня вопрос по схематику. При копировании любого из объектов: компонента, порта, вывода компонента, текста с помощью перетаскивания мышью с зажатым Shift фокус выделения остаётся на исходном объекте. Во всех других программах, коими довелось пользоваться, новый объект всегда становится активным (выделенным) после копирования. Есть ли какая-нибудь секретная настройка в Preferences переключающая фокус при копировании?

@turnon , на каком дизайне топологии земляного полигона в итоге остановились? Сбои HSE резонатора исчезли?

Вектор прерывания у модуля I2C один, следовательно и функция-обработчик будет одна, на все возможные события. Для мастер-передатчика надо будет обрабатывать следующие события (* я с I2C на F4xx семействе не работал, могут кое-где соврать). Следовательно в основной программе инициировали передачу посредством старт-условия, занялись другими делами. Сгенерировалось прерывание, в обработчике анализируете флаги статусного SR1, SR2. SB флаг установлен - шлёте байт адреса и выходите из обработчика. На следующей итерации установленный флаг ADDR укажет на то, что пора передавать данные (потребуется статическая переменная-счётчик количества байт). Как всё передадите в обработчике сгенерируете состояние "стоп". Это в своей сути и есть конечный автомат. Не буду вдаваться в теорию множеств и графов, я её не знал и забыл. В общих словах. У автомата есть устойчивые состояния: формирование старт-условия, передача I2C адреса, передачи I2C байта... Грубо говоря, все выражения внутри циклов while() в Вашем коде: где программа чего-то ждёт. А ждёт она входные сигналы - те флаги регистра SR1 проверкой которых занят МК внутри циклов. Т.е. для состояния "передача I2C адреса" входной сигнал s = I2C1->SR1 & I2C_SR1_ADDR. Если !s, автомат продолжает находиться в этом состоянии, s - выполняется функция перехода F (передача первого байта) и автомат оказывается в состоянии "передача I2C байта". В случае использования прерываний автомат обслуживается аппаратными средствами МК. То же самое можно сделать и программно. Я делаю, обычно на операторе switch. Каждая метка - состояние автомата. И периодически вызываете полученную функцию где-нибудь, в main() например. void i2c_tx_fsm(void) { static int state = 0; //ЛУЧШЕ В ВИДЕ enum с "говорящими" именами // Idle state case 0: //-состояние if (data_to_transmit) //-проферка входного сигнала { //-функция перехода I2C1->CR1 |= I2C_CR1_START; ///START I2C I2C_CR1_START state = 1; } break; // Wait start condition case 1: //-состояние if (I2C1->SR1 & I2C_SR1_SB) //-проферка входного сигнала { //-функция перехода I2C1->DR = (device_address<<1); ///SEND ADDRESS to DATA register state = 2; } break; // Wait Address send case 2: ....... default: satte = 0; break; } Читаемости коду такие конструкции не прибавляют, но это плата за однопоточность.

Что за компилятор то у Вас такой страшный что Вы его боитесь? Уверен, что через пару лет разработки Вы перечитаете своё сообщение и так же, как я, улыбнётесь. Чтобы уйти от блокирующего кода Вам могут помочь аппаратные средства МК: прерывания, DMA; программные средства: операционная система, машина состояний (конечный автомат). Прерывания, пожалуй, самый простой из доступных способов. И ещё, совет. Избегайте "магических чисел" при работе с регистрами периферии МК. Используйте макроопределения битов из файла "stm32F407xx.h" для своего процессора. Например для строки I2C1->CR1 |= 0x01; ///PE: Peripheral enable I2C1->CR1 |= I2C_CR1_PE; ///PE: Peripheral enable Будет легче читать код и искать ошибки