Arlleex

Hi! Clear bit in register reg &= ~(1 << bpos); reg - register, bpos - bit position. Your code is correct too.

На вкладке 'Pack' там галочку уберите, у меня с ней такая же шляпа, не стал разбираться что ей не нравится, да и пофиг как-то.

На top/bottom annular ring есть, а это внутренние плейны, на которых все рисуется несколько иначе (в негативе)... Ну, в общем. Созвонились с технологом, сказали сделают. Всем спасибо!

Да просто в Резоните мне такое делали на ура. В целом, я понимаю, что это хреновая практика. Но хотелось просто узнать, чем это вредно технологически.

Приветствую! Допустимо ли делать вот так? Или шлак? Ну, то бишь, на внутреннем слое полигон частично огибает и подключается к металлизации отверстия под разъем.

Можно.

Ууу, печаль, спасибо. Но в целом, дабы было понятно - это тупейшая защита от дяди с программатором и мыслью "а вдруг?". Если клонированием озаботятся другие ребята, немного шарящие, они найдут способ стырить прошивку. А тут даже проще будет новую написать. Я же делаю защиту от банальных прохиндеев. Сейчас у них даже проблемы с прошивкой по вылизанным методикам возникают, так что уровень там совсем низкий. Но тем не менее. Да, Value Line серия. Level 2 не хочу, мало ли чего при эксплуатации еще будет.

Приветствую. Что-то почитал я документацию и опечален немного. Мне в одном девайсе надо реализовать загрузчик для обновления ПО. Девайс на STM32F030. Этот МК построен на ядре Cortex-M0, в котором отсутствует регистр VTOR, вследствие чего приходится изобретать. Короче, из-за отсутствия VTOR и механизма сдвига таблицы прерываний в принципе, я копирую ее в начало ОЗУ. Ну а затем, собственно, через SYSCFG-регистры делаю memory-remap на ОЗУ. Коряво, но другого выбора нет. Фиг с ним, работает. Теперь вот что. Хочу облегчить труд прошивальщиков, а именно - чтобы они в STLink Utility тупо прошили загрузчик и никакие байты опций не выставляли. Загрузчик после первого старта должен сам себя защитить, установив биты защиты от записи на свои сектора Flash. И еще кое-чего по мелочи сделать. Кроме того, после прошивки клиентского кода, загрузчик должен, по-хорошему, установить защиту от чтения. Но фигушки, похоже. При снятии ранее установленной защиты от чтения, вся Flash будет очищена. То есть и загрузчик тоже потрется. Это минус первый. Второй минус - читаю RM на МК, вижу (стр. 55) Ранее я писал, что в SYSCFG надо будет выставить руками биты memory remap - то есть контроллер будет думать, что загрузка идет с ОЗУ. Получается, на этом МК написать надежный загрузчик с возможностью защиты пользовательской прошивки от чтения не возможно? До реального железа доберусь на неделе, пока что доку просматриваю. P.S. На первый вопрос отвечаю сам себе - в RM есть табличка (стр. 56), из которой ясно, что под Level 1 я могу читать, стирать и писать любые сектора Flash. Но из этой же таблички видно, что при загрузке из ОЗУ (и также под Level 1) контроллер должен вывалиться в Hard Fault...

Сейчас даже сам себя носом ткну, где об этом написано. Спасибо =)

Коллеги, приветствую! Подскажите пожалуйста, если у меня в регионе размещено 2 секции, их реальный порядок размещения может отличаться от описанного в файле скрипта? Вот мой скрипт LR_IROM1 0x08000000 0x00010000 { ER_IROM1 0x08000000 0x00010000 { *.o (RESET, +First) *(InRoot$$Sections) .ANY (+RO) .ANY (+XO) } NVRAM 0x20000000 UNINIT 0x000000B8 { *.o (.intvec) *.o (.dfuflg) } RW_IRAM1 0x200000B8 0x00001F48 { .ANY (+RW +ZI) } } У меня должен быть кусок в ОЗУ начиная с адреса 0x20000000 для таблицы векторов (44 слова), и 2 слова для флага обновления ПО. Расположил секции в естественном порядке - сначала .intvec, затем .dfuflg. В коде объявил static volatile struct { u8 str[8]; }DFU __attribute__((section(".dfuflg"), zero_init)); static volatile u32 VTblApp[44] __attribute__((section(".intvec"), zero_init)); Но в map-файле вижу .dfuflg 0x20000000 Section 8 hw.o(.dfuflg) DFU 0x20000000 Data 8 hw.o(.dfuflg) .intvec 0x20000008 Section 176 hw.o(.intvec) VTblApp 0x20000008 Data 176 hw.o(.intvec) что есть немного не то, что я хотел. Что теперь, 2 региона отдельных создавать?

Возьмите ручку и на листочке нарисуйте цепочку XOR-элементов, образующих Ваш полином. Возьмите начальное значение, равное вычисленному CRC по массиву. Задвигайте побитово такое же значение - на последнем бите результат схлопнется в 0. Хотя должно быть понятно и так, что X XOR X == 0. Ну и ради прикола можете накидать программку, которая по 16 битам будет проверять все вариации начального значения и задвигаемого полуслова. Это будет даже не математически, а практически выверенным поведением

ИМХО, это не имеет большого смысла, особенно учитывая периодичность возникновения прерываний. Но стоит отметить, что я, бывает, циклически тоже обрабатываю - но это больше в случае, когда на периферии висит аппаратный FIFO. КМК, когда прерывания от периферии забивают бОльшую часть времени CPU, стоит подумать о разгрузке, например, тем же DMA. Да и в целом: ну зациклим мы проверку while(cr & sr & USART_SR_RXNE) { ... } якобы в надежде, что при большой плотности данных есть шанс снизить риск потери байта. Однако, когда мы зайдем в такой же цикл опроса TXE (ниже по коду) - в этот момент может сновать возникнуть RXNE. И мы уже не обработаем его в текущем ISR. Мы выйдем из него и зайдем снова. И где тогда выгода, если даже при циклической обработке можно терять байты? Потери в любом случае будут связаны с загрузкой CPU, скоростью приема и передачи байт и их взаимными соотношениями.

Двойное считывание в Вашем случае лишь прикрывает последствия бага, спрятанного где-то еще. С UART-ами там все четко Мой обработчик (скелет) для приема/передачи UARTISR() { u32 sr = PUART->SR; u32 cr = PUART->CR1; if(cr & sr & USART_SR_RXNE) { u8 b = PUART->DR; ... } if(cr & sr & USART_SR_TXE) { u8 b; ... PUART->DR = b; ... if(EndTx) DisTxIrqUART(); } } Никаких двойных считываний и все работает как положено.

Это Вы к чему написали? Вот тут будут во Flash, например? void func(u32 k) { const u32 i = k * 5; ... }

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