juvf

... то нажмите ~, выскочит подсказка по горяцим клавишам. SPACE - Rotate counterclockwise. в горячих клавишах в DXP\Customize\...Shortcuts эту настройку не нашел. Выключил ПК, утром включил - всё нормально. В схематике крутиться c зажатой ЛКМ по пробелу без Ctrl. А кто-нибудь экспортирует 3Д модели ПП в Solidworks? В ад16 сохраняю в STEP, в солиде2018 открываю. При открытии на каждый объект выскакивает сообщение (см рис). В пп 100 компонентов, на каждый компонент несколько сообщений. Иногда, нажав 100500 раз "ОК" проходят все эти сообщения. Кнопки "Больше не задавать этот вопрос" или "применить ко всем" нет. После трассировки очевидно примитивов стало больше, солид через 100 таких сообщений вообще вылетает. Может экспорт в ад нужно делать хитрый? Может в СВ что-то по хитрому открывать? У кого есть опыт заброса из АД в солид?

там речь про ад16. у меня ад16, но этой галки нет

Что за флаг и где он?

Спасибо, сработало!!!

задал правила между всеми проводниками зазор 0,3мм. для некоторых футпринтов это много. как задать правило, чтобы между ножками нужного компонента или нужного футпринта было 0,2 мм? Какой синтаксис этого правила?

А с прерываниями в freertos на кортексе точно у вас всё в порядке? В двух словах... Для Cortex-M3-M4 в фрииртос есть засада: в конфиге указывается максимальный приоритет, в обработчике которого будут вызываться API фриртоса. Вроде как #define configMAX_SYSCALL_INTERRUPT_PRIORITY 191 /* equivalent to 0xb0, or priority 11. */ Т.е. у вас в конфиге указанно, что приоритет прерывания, в котором будут вызываться API не должен быть выше 11. У вас приоритет ISR таймера 7. Либо в конфиге укажите configMAX_SYSCALL_INTERRUPT_PRIORITY больше 7 (или "больше либо равно 7"), либо понижайте ISR таймера до 11.... Более точно про приоритеты сказать не могу... не помню уже... гуглите, .... тут поднималась эта тема и там расписано с точностью до запятой, что да как. ps Может у вас не в этом проблема, но описанное поведение/зависание freertos именно такое, когда в прерывании выше configMAX_SYSCALL_INTERRUPT_PRIORITY дергают API.... ртос работает... и нормально работают все прерывания, но рано или позно ртос где-то в недрах зависает. pps Это вызов АПИ с нарушением приоритета положит ось не всегда. Может раз 100-10000 нормально сработает, а потом ось ляжет. Как-то это асертом ловилось. Если не ошибаюсь в конфиге нужно ассерт определить. Он в целом тормозит ОС, но после того, как проверите правильность прерываний его можно/нужно отключить закоментировать. Вроде с ассертом при первом вызове из "неправильного" прерывания апи ось сразу встанет. И вроде это так делается /* This is the value being used as per the ST library which permits 16 priority values, 0 to 15. This must correspond to the configKERNEL_INTERRUPT_PRIORITY setting. Here 15 corresponds to the lowest NVIC value of 255. */ #define configLIBRARY_KERNEL_INTERRUPT_PRIORITY 15 #define configASSERT( x ) if( ( x ) == 0 ) { taskDISABLE_INTERRUPTS(); for(;; ); }

Ну, даешь, ядрена вошь! И олень тебе не гож? А вчерась мытарил душу: Вынь оленя да положь!.. То дай код, в нём ошибка! то новый вымыслы про стек... то внезапно код мой безразличен... то предложение проверить да проверь... то проверять там нечего... виртуоз-переобувальщик. а когда все таки проверил - вдруг проверка неугодная стала!!! аргументы кончились, понеслось что-то абстрактное, типа "кучи разных факторов" и оскорбление негативная оценка оппонента, типичное поведения.... ну вы поняли кого... вот тут вы правы, соглашусь!!! Очень удивился. memcpy() на порядок быстрее for-loop. Перепробывал с разными вариантами, с переменными размерами массива и указателями, неизвестными на этапе компиляции. в тактах процессора примерно 90 к 700(без gpio, таймеров и прочей "кучи разных факторов"). Причем оптимизация практически не влияет на memcpy(). Он всегда быстрый. Вашим for даже и не снилась такая скорость. устали вы меня.

ваш ответ - тоже априори. много слюней, воды, телепатии и всё мимо. Так ведут себя диванные эксперты. даже близко не угадали. ни одной строчки кода )))) - опять мимо ещё раз мимо. Сначала проверил, сколько времени будет установка и сброс GPIO - с -Ohs составило 300 нс в каждом тесте. Результат показанный ранее, был с учетом погрешности GPIO. Нормальные измерения длительностей делают осциллографом, анализаторам, а не внутренними таймерами. Осциллограф даст более точное измерение (тем более он поверенный), нежели внутренний таймер МК, когда частота МК на порядок меньше полосы осциллографа. И генератор МК ±вагонИтележка, по сравнению с поверенными средствами измерения. Что ваш внутренний таймер, когда система должна среагировать на внешние прерывание/событие, обработать данные и выдать признак готовности, например дернуть регистр GPIO/DMA/UART? Это реальное время и реальный мир, а не ваша Нарния ваши фантазии с таймерами. Как раз таки осциллограф даст точность в мкм, а таймер в метрах. Вы предлагаете Измерять миллиметровые расстояния линейкой с метровыми делениями - это типичный эльфо-подход. Дак посмотрите, оторвитесь от дивана и посмотрите, вместо того чтобы тут сочинения писать. Я то посмотрел.... исходный код ТС с << | j более грамоздкий в асме, нежели чем без этих лишних операторов или memcpy(). Впрочем похоже для вас это пустой звук. Так же как и о самом предмете оптимального программирования Вы не имеете никакого понятия. Оставайтесь прибывать в своих фантазиях. :laughing:

И что? Современные оптимизаторы творят чудеса. И им по-барабану Ваши жалкие потуги заменить операции индексирования на указатели и подобное - они это и сами хорошо делают, даже ещё и лучше. Так что если бы код автора не был такой кривой, результат работы оптимизирующего компилятора мог быть лучше memcpy(). попробую обязательно. Добрый день фантазёры, эльфы, а также программисты. Совсем недавно (2017-2018 год) занимался оптимизацией кода в STM8. Ручные потуги оптимизации давали очень хороший результат. Оптимизатор конечно оптимизировал код, но некоторый несложный рефакторинг давал значительно лучший результат. Может стм8 сырой? может арм действительно рулит? Проверил на арме.... собрал код ТС, улучшенный код ТС, а также просто memcpy(). В трёх случаях заполнял массив uin16_t [16] из массива uin8_t[32]. Измерял осциллографом. улучшенный код ТС выглядит так: #define SIZ 32 uint8_t dataOut[SIZ+2]; uint16_t buffer[SIZ/2]; uint8_t *p1 = (uint8_t*)buffer; uint8_t *p2 = (uint8_t*)&dataOut[0]; ... GPIO_SetBits(GPIOA, GPIO_Pin_5); //ТР2 = 1 //оптимизированный варинат ТС for(int i = 0; i < SIZ; i++) p1[i] = p2[i]; GPIO_ResetBits(GPIOA, GPIO_Pin_5); Результат - (код TC с "<<", "|", "++", "j") / (улучшенный код ТС) / (говноmemcpy() ) Не оптимизированный код дал результат 8/5/1.3 мкс с оптимизацией по скорости -Ohs результат 3/0.5/0.5 мкс кагбэ в примере всё выровнено к 4. Но серийные данные не всегда выровнены, поэтому усложнил задачу МК и приблизил к реальности, uint8_t *p2 = (uint8_t*)&dataOut[1]; получил без оптимизациии 8/5/2мкс, с оптимизацией -Ohs 3/2/1.7 мск Результат на лицо. Априори. Вот вам и наряд в не очереди современные оптимизаторы!!! ps проверял на стм32ф103, компилятор иар.

А где настройки горячих, подскажите? ps Сорри, даже не когда загуглить.

Раньше на одном ПК при перетаскивании с схемном редакторе по пробелу был поворот на 90°. На другом ПК такого нет, только при Ctrl+пробел. нашел подсказку по горячим клавишам для схемного редактора У меня работает только CTRL + SPACEBAR 1) почему не работает SPACEBAR? 2) чем отличается перетаскивание от перемещения?

Нет, не правильно. Есть задача - написать текст. Есть 2 карандаша. Один пишет, другой не пишет. Я не буду тратить время на выяснение, почему не пишет один карандаш, если я могу обойтись без него. Я другим карандашом текст напишу. Вы выяснили и устранили, почему при вкл холодильника виснет CCS? Вы замелм пролему под ковёр заменили кабель усб и продолжили работать. У меня оптимизатор ошибок не нашел. Зачем вы просили код в студию? Хотели найти в нем ошибку. Нашли? Или чтоб написать "мне ваш код безразличен"? Где я писал, что "то работает то нет"? У меня такого кода нет. Что компилятор виноват - это ваши слова, не нужно их мне приписывать. Я же говорю вы не читаете мои посты, не вижу смысла дальнейшей дискуссии с вами по этому поводу.

Допустим, гипотетически.... записал в спи-сд данные, что-то сделал пусть будет проверка for(), проверил бизи. между записью и бизи было времени достаточно для выставлдения флага бизи. нужно 1 мкс, f было 10 мкс. Код рабочий, глюков нет. Может такой код перваться прерыванием и 10 мкс могут только увеличиться.... до 100, до 200.... код от этого не упадет и всё будет работать. Гипотетически! for() { waitSpi(); spi->sd = data_out; somethinkDo(); } Допустим такой код работает без оптимизации..... включили оптимизацию и появилась ваша гонка.... опять же гипотетически.... Вот вы взяли асм.... и начали исследовать, что там не так... и нашли ГОНКУ!!! Как её убрать? не нужно сразу читать SR, а нужно подождать начало передачи. Что делать? Поставить паузу.... Т.е. поставите оптимизатор, чтоб было быстрее, и потом поставите паузу, чтоб не было гонки? Я просто отключу оптимизатор в нужном месте и всё. В таком случает я считаю нет ошибки в неоптимизированном исходном коде и нет ошибки компилятора. Есть одно - при включении оптимизатора код перестает работать. Я вам не пытаюсь доказать, что есть ошибка компилятора. я не знаю. я говорю, что при включении оптимизатора на весь код, на код без ошибок и без глюков - код может лечь. И это не ошибка кода. В чем то я с вами соглашусь.... Про цейтнот согласен, про проблему под ковром - нет. Дело в том, что проблема такая "оптимизированный waitSpi() не работает". Тут два пути: 1 - не использовать оптимизированный waitSpi(), 2 - искать причину в оптимизированном waitSpi(). Посмотрите код waitSpi - там по сути оптимизация не нужна. Там нужно указать volatile, что делается в SPL. Весь код функции - одна строчка. Я пошел по пути наименьшего сопротивления. Тоже самое можно сказать про црц и про другие случаи (не буду всё сюда валить). У меня ещё не было случаев, чтобы оптимизатор оголял ошибки в коде. Если есть ошибка в коде - она находится без всяких оптимизаторов. Горе программист, которому для нахождения ошибки нужен оптимизатор.

Вы мои посты читаете? все описания и декларации в приведённом коде. Я же говорю, вы не читаете мои посты. Смотрите код. Наверно на си не понятно, напишу на русском. CS - нет. СПИ-мастер. 1)спим секунду. если что-то и было в спи, то давно вышло. 2)готовим данные.... 3)проверяем бизи - waitSpi() 4)записываем в SPI1->DR данные. Данные пишутся в тх регистр, и потом копируются в шифтРегистр. в этот момент должен встать флаг бизи. 6)если ещё есть данные для передачи, goto 2) с момента записи в SPI1->DR до waitSpi() проходит не 1 такт цпу. Тут один поток...проверка на кол-во переданых данных, подготовка данных не быстрая, спешить не куда, всё равно ждать waitSpi().

Нет гарантии. Все места проверяются глубоким тестированием. А если компилятор оптимизатор не косячит - то нет ни какой гарантии, что нет косяков пейсателя/компилятора в других местах. Все места проверяются глубоким тестированием, стрестестами и т.п. , Это касается любого компилятора/оптимизатора, любого кода. конечно первым делом volatile. Чуть не написал "Слона не увидел", но слона нет. Во первых в даташите про это ни чего не говориться, во вторых.... сначала готовлю данные, потом их отправляю в спи, не дожидаясь завершения ..... на русском сложно писать, написшу на си sleepMs(1000); for() { //подготовка данных waitSpi(); //запись данных в спи регистр. } в waitSpi() с оптимизацией не задерживаюсь ни когда, а должен не задерживаться только первый раз. После отправки данных до чтения регистра SPI1->SR проходит много времени, но меньше, чем выход 8 бит в спи.

я же писал, данные не портятся, в фолаут не вылетаю, а црц считает с ошибкой. Я достаточно выделил памяти на стек. Без оптимизации глубины стека хватает с запасом. Если оптимизатор удвоил запросы ОЗУ на стек, то мне такой оптимизатор не нужен. :laughing: Во вторых, бывало вылазил за стек.... на разных проекта.... либо фолаут, либо данные портились. Это быстро обнаруживается. Тут идет подсчет црц, но неправильный. Ни чего не портиться и не падает.

читайте выше. там и код и чем компилирую.

так я нашел причину и устранил. )) inline void waitSpi() { while( (SPI1->SR & (uint8_t)SPI_FLAG_BSY));} - вот этот код не работает с оптимизацией в пустом хороводе. И не изредка - а всегда. 100 раз из 100. А без оптимизации работает как часы. ни каких сбоев в обмене по SPI замечено не было. У меня црц считается с ошибкой всегда, когда вкл оптимизация, не изредка, а всегда. И всегда считается правильно с отключенной оптимизацией. Нету хаотичных и внезапных сбоев.

Дальше в эту сторону дискутировать не выжу смысла. Учитесь читать исходный код. Если не на кофейной гуще гадать, а на картах Таро, то баг в ОС, на которой кросскомпиляция идет. Вот ещё пример #define __IO volatile /*!< defines 'read / write' permissions */ typedef struct SPI_struct { __IO uint8_t SR; /*!< SPI status register */ } SPI_TypeDef; ... #define SPI1 ((SPI_TypeDef *) SPI1_BASE) SPI_FLAG_BSY = (uint8_t)0x80 ... #pragma optimize=none //без прагмы waitSpi(); не дожидается выполнения inline void waitSpi() { while( (SPI1->SR & (uint8_t)SPI_FLAG_BSY));} Тут без прагмы вход в waitSpi и мгновенный выход, не зависимо от флага SPI_FLAG_BSY. ээээ.... а разве при переполнении стека программа аварийно не завершается? В моём случае с crc16_byte() идет подсчет црц, но на выходе он не вырный, падения программы нет. Програма продолжает работать, но бракует пакет по црц. Принятые данные не портятся во время работы crc16_byte() и во время работы программы в целом. Хотел подебажить crc16_byte(), но с оптимизацией код не шагается по строчками си. А без оптимизации шагается но и работает без ошибок. Что-то я не пойму.... Вот, вы же сами утверждаете, что оптимизатор может сломать работу программы написанной без ошибок. Я о том же.

Я тоже про это думал. На весь проект стоит максимальная оптимизация по размеру кода. Дебажил на уровне Си, в асм углубляться не стал. Одна строчка #pragma optimize=none давала правильную работу расчета црц. Поэтому врят-ли что-то в остальном коде не так. Времени не было искать глюк в компиляторе или ещё где.... Видимо это был 0,1%. кому интересно, компилятор IAR C/C++ for STM8 из иара 3,10,1

Аналогично!!!! А почему не слезли с этого камня? У меня один проект на нем... длинный... Считается, что ТИ держит марку, приложение ответственное, не ставить же туда ширпотребный стм, поэтому было решено F28M35. Щя на этом F28M35, как на игле, слезть не могу, железо сделано. Новый проект точно не на ТИ. ps Есть задача сделать девайс с климатом от -50°С. Есть миландр. Но с миландром наелись. Проц слабоват и поставки мягко говоря "доставляют". По полгода и более ждем. Все делают от -40. Нашел мср430 от -55. Раньше работал с мсп430, пугает ТИ, но на мсп430 нариканий нет (без CCS). Думаю на нем остановиться. Поднял эклипс с плугом для мсп430, из коробки сделал холоворд. Вроде всё гладко. Что-то можете посоветовать из камней от -50? Желательно ARM. Что-то аналогичное st32f2 или st32f4?

Что за глупость? при чем тут memcpy с отрицатеольными size_to_take? В коде ТС явно size_to_take > 0. #pragma optimize=none unsigned int crc16_byte(unsigned int crc, unsigned int data) { //const unsigned int Poly16=0xA001; unsigned int LSB; crc = ((crc^data) | 0xFF00) & (crc | 0x00FF); for (uint8_t i=0; i<8; i++) { LSB=(crc & 0x0001); crc >>= 1; if(LSB) crc=crc^0xA001; } return crc; } Такой код работает, если убрать прагму, то црц считается не правильно. Для фантазёров, видящих за рамками кода всякое ООП, перегрузку операторов, переопределение типов и прочую фуе ту.... перегрузки операторов нет, переопределений типов и чего либо ещё нет. тип unsigned int 16 бит!

Я же говорю - тут церковь какая-то, пропитанная религией ))). Если вы с таким не встречались - это не значит, что такого нет. ps Открою вам тайну, земля круглая!

Спасибо за совет.... да, это Concerto. Я тоже пишу только для арм. Это похоже на правду. На столе в офисе вообще редко зависания, раз в неделю может. На объекте раз в 10 минут бывало. ..... заметил, что с одним кабелем чаще зависает, с другим реже. Это который ещё без эклипса.... совсем древний.... или без эклипса это CodeComposer, а ССS сразу был на эклипсе. ЗАПЕЙСАЛ!!!! ножом на столе вырезал!!!

ну на конец то предметный разговор, а не "слепая вера" попробую обязательно. Это я слышал и/или знаю.... Но, во первых, современные оптимизаторы иногда портят код так, что он не работает как надо, приходится либо отключать оптимизацию полностью, либо на отдельной функции. Во вторых про потуги вы зря.... когда мой код перестал влазить в флешь, а в прерываниях стал долго задерживаться, то сделал рефакторинг - код и влез и стал быстрее работать. Одна строчка до рефакторинга была 6 машинных команд, стала 2 или 4. Убрал всякие лишние << |, на каждом участке экономил где по 10-20 байт флеша, где по 100. Морите!? О чем тут дискутировать, если вы не знаете как работает for? Если size_to_take отрицательная и i тоже знаковое, то в примере ТС в тело цикла for не разу не зайдем. Это вообще букварь Си. Да, согласен, неточность есть. Если быть скрупулёзным к явным преобразованиям, то нужно так memcpy((void*)DataBuffer, (const void*)&data_out[j], 2*size_to_take); Я не утверждаю, я всего лишь предположил, что копировать память лучше через memcpy. Если это не 8 и 16 бит, то забыли про мой совет. О чем спор? И что? в чем разница вот в таких кодах с volatile (архитектура ст первый, без перевёртывания): Вариант 1: volatile uint16_t DataBuffer[100]; volatile uint8_t data_out [1024]; uint16_t size_to_take = 100; uint8_t j = 17; for(uint16_t i=0; i<size_to_take; i++ ) { DataBuffer[i] = (data_out[j] << 8)| data_out[j+1]; j += 2; } Вариант 2: volatile uint16_t DataBuffer[100]; volatile uint8_t data_out [1024]; uint16_t size_to_take = 100; memcpy((void*)DataBuffer, (const void*)&data_out[17], 2*size_to_take); Или по вашему 1-ый вариант работать будет, а второй нет?