Jump to content
    

jcxz

Свой
  • Posts

    13,133
  • Joined

  • Last visited

  • Days Won

    31

Everything posted by jcxz


  1. И как предлагаете ток потребления от ионистора отделять от его тока утечки?
  2. Интересно - все тут чукчи-писатели что-ль? ТС в самом начале вроде ясно написал: +-10V
  3. 1. МК с АЦП с ШИМ + 2 ключевых транзистора + RC. 2. МК с АЦП и с ЦАП + ОУ. Только один корпус - вряд-ли получится. Хотя-бы 1 транзистор нужен.
  4. Это ещё ерунда. Хуже что она не позволяет контролировать переполнение буфера. И не позволяет перегрузить функцию записи выходного потока символов на пользовательскую. А семейство printf это всё умеет. PS: Бесконтрольный sprintf (без контроля переполнения) имхо - моветон.
  5. Зачем их исправлять если они у вас и так разные?
  6. Если гора не идёт к Магомету, то может Магомету пойти к горе? Если нельзя отказаться от линуха и он обязательно нужен, то может тогда заменить контроллер на такой, в котором есть подходящая периферия, которая позволит реализовать нужную диаграмму работы SPI? (и при этом не мешать работе линуха на нём же). Или хотя-бы есть отдельное ядро, которое можно выделить исключительно для эмуляции SPI?
  7. Так в том то и проблема, что у ТС не IAR. С IAR-ом всё просто - в свойствах подключения эмулятора указываешь нужный серийный номер и IAR работает только с этим эмулятором. Т.е. - с J-Link-ами так точно работает. ST-Link я уже давным-давно не использовал, может с ним есть какие-то проблемы. Но все ST-Link-и следовало уже давно заменить на J-Link-и (или хотя-бы перешить). PS: Меняем Кубепрограммер на IAR, а ST-Link-и на J-Link-и. И получаем стабильную и безглючную работу хоть с пятью устройствами одновременно.
  8. Серийный номер нужно смотреть не в кубепрограммерах, а в свойствах USB-устройства (дескрипторе USB). Так как именно сер.номер USB используется при энумерации системой. А там видимо USB-сер.номера одинаковые (раз конфликтуют). И не факт, что после изменения сер.номера в кубепрограммере, USB-сер.номер изменится.
  9. Ещё раз - читайте описание CPU. Что такое режим ARM, что такое THUMB, что такое THUMB2. В Cortex-M есть только Thumb2. И 32-битные и 16-битные инструкции - это всё Thumb2. Точно ли так? Уверены? Если да, то нужно проверить - что загружено в R0 перед "BX R0". Загружен адрес начала __main? Каково значение младшего бита R0? Должно быть == 1. Опять-же: Перед функцией Reset_Handler не видно включение режима THUMB. Похоже там режим ARM, а значит в R0 возможно грузится адрес с битом_0 == 0 (режим ARM). И возможно поэтому происходит HF. Добавьте перед Reset_Handler директиву THUMB. И ещё раз: Прочитайте что такое режим THUMB и что такое режим ARM. PS: И научитесь вставлять в сообщения текст исходных кодов, а не картинки. Кнопка для этого есть здесь в редакторе. Также научитесь корректно цитировать. Чтобы отвечающим вам хотелось вообще отвечать.
  10. Вы смешиваете понятия "программа не компилируется или компилируется с ошибками" (п.1) с понятием "программа выполняется неверно" (п.2) Это писать бессмысленно, так как у Cortex-M нету других режимов кроме Thumb2. Что именно делаете и как выполняете - тоже ничего не понятно. Пошагово? Если да - то как? С заходом в функции или без? Если с заходом в функции (как и нужно делать), то должны были дойти до указанных мной выше багов в коде. В вашем случае надо выполнять пошаговое выполнение с заходом в функции (не знаю как это в Кейле называется, но должно быть). На первом вашем скриншоте. В смысле "не вы"? А кто писал эту "программу"? Кто надумал писать в CellAddr, объявленную в const-памяти? Ещё раз: смотрите ваш же первый скриншот. На нём видно куда идёт переход. Переход идёт за пределы вашего кода. Скорее всего это (выполнение чего-то за пределами кода) и вызывает HF. Хотя идея писать во флешь командой STR - тоже так себе идея. PS: Если не знаете ассемблера, то наверное сначала нужно изучить хотя-бы его основы? Хотя бы прочитать в описании системы команд - что именно делают написанные вами команды CPU? Нет? Проблема у ТС не в SystemInit (чтобы она не содержала), а в его __main.
  11. А расскажите нам - как написать программу для МК без "жёсткой привязки к конкретному процессору и/или архитектуре"? Прям можете на си написать программу, которая будет выполняться скажем на LPC1758 и на STM8L151 и на TMS320VC5502??? Пример в студию! ЗЫ: Априори - все программы, которые пишутся для МК, на любом языке, имеют "жёсткую привязку к конкретному процессору и/или архитектуре".
  12. Вы понимаете что вам пишет компилятор? И понимаете где находится "попытка перейти к __main"? Зачем вы в начале main пытаетесь записывать 10 по адресу 0x08000288? Ведь это область флешь и писать туда нельзя. И что такое "B ." - понимаете? Зачем вы так делаете? Очевидно в последней строчке происходит переход за пределы "программы" и соответственно - улёт в HF.
  13. Я могу. И писал ранее. На DSP. DSP по архитектуре и системе команд кратно сложнее ARM-а. Если сомневаетесь - почитайте например про ядро TMS320VC55xx. ARM по сравнению с ним - детский сад. И не я один - даже здесь на форуме есть люди, умеющие писать на ассемблере. Сейчас нет необходимости писать полностью на ассемблере на ARM (по-крайней мере у меня). Но есть проекты, где имеются asm-функции на несколько сотен команд. И не "вставки", а полноценный ассемблер. Потому как на си там просто невозможно реализовать - слишком глупы современные си-компиляторы, не хватит быстродействия. ТС-у помогать бесполезно. Да и ранее он писал, что хочет писать не на ассемблере, а в машинных кодах.
  14. Там написано, что от момента подачи питания до первого доступа к регистрам должно пройти не менее 167мсек. А верхняя граница не указана. Это значит, что её нет. Значит и после ваших 0.5 сек задержки и даже после 5 сек задержки, чип может быть ещё не готов к обращению к регистрам. А значит ваш код работать не будет. Там есть куча разных регистров. Значения которых вам (как разработчику) должны быть известны. А значит нет никаких проблем не тупо ждать неизвестно сколько времени, а ждать читая такой регистр.
  15. Все 3 фазы очень полезно измерять. В качественных и ответственных проектах по ним делают контроль что: Ia+Ib+Ic=0. Если не так - детектируется состояние аварии (возможно обрыв/отказ одного из датчиков тока). Конечно не точно равенство, а с некоторой допустимой погрешностью. Когда хотят сэкономить, то могут конечно эту формулу использовать для вычисления 3-го тока. Но надёжность и безопасность при этом страдает.
  16. Я уже привёл здесь факты (не голословные утверждения, не пустой наброс на вентилятор) - лог компилятора с множеством ошибок оптимизации. Теперь ваша очередь: укажите какие ошибки оптимизации вы там видите? (а там их много) Я разве где-то утверждал такое??? Приведите пожалуйста цитату. Это где такой изначальный разговор был? Потрудитесь заглянуть в начало темы. Опять передёргиваете.
  17. "С любой прошивкой" у меня сейчас в одном проекте работает HC-05 (или 06) на 921600 бод без каких-либо FC (только три провода: RX/TX/GND). Иногда там выплёвывается до нескольких КБ за раз в модуль на передачу (точно не измерял сколько). И каких-либо пропусков или потерь я не замечал. PS: Вот только что попробовал - захват лога соединения с HTTPS-сервером https://radio-streams.kaztrk.kz/qazradio/qazradio/icecast.audio (через этот BT у меня передаётся лог работы на ПК): Размер этого лога = ~7КБ. Время его передачи видно с левой стороны картинки. Искажений (из-за потерь байтов) сами видите - не заметно. Всё стройно. Делайте выводы.
  18. Что за "варианты" которые нужно обязательно помнить программисту на ассемблере? О чём вы? Пишу на асме для ARM-а частенько. Так как мне нужно писать не только код, рисующий кнопочки и моргающий лампочками (как некоторым тут). Но частенько нужно писать и тяжёлый вычислительный код. На пределе возможностей CPU. Никаких проблем с простейшей системой команд ARM не имею. Когда писал на DSP, количество инструкций было в разы больше, чем у ARM и заковыристее в разы. И то как-то умудрялся писать намного лучше компилятора. Да ладно?? Прям полтора года?!! Любите же вы набросить на вентилятор! Умелый программист на асме (имеющий голову на плечах чтобы не только в неё есть) даже сейчас в большинстве случае напишет код лучше компилятора. Типичный код - вряд-ли в разы лучше (просто некуда так оптимизировать). Но вот какой-то специализированный код, связанный с цифровой обработкой сигналов или какими-то сложными вычислениями - умелый асм-программист запросто может и в несколько раз лучше написать. PS: Эта тема (о непобедимости компиляторов) тут поднимается уже неоднократно. И поднимается почему-то программистами, которые на асме и не писали-то никогда. И они с пеной у рта доказывают, что это невозможно. Потому что они сами этого не умеют. Но я уже ранее приводил примеры алгоритмов, которые си-компилятор реализует в разы хуже умелого асм-программера. Потрудитесь полистать форум. Если вы не умеете писать лучше компилятора (тупой железки между прочим), то это именно вы и не нужно обобщать на всех. Человек умеющий думать и не ленящийся это делать, и готовый тратить время на саморазвитие, в большинстве случаев напишет код лучше си-компилятора. Чтобы это понимать, достаточно хоть иногда заглядывать в листинги си-компиляторов. Там сразу видно, насколько оптимальнее можно написать асм-код если писать его самостоятельно. PPS: Чтобы не быть голословным, приведу пример простейшей функции: //Вычисляет длину UTF-8 строки в символах и байтах. //Вызывает TRAP_UTF8 при некорректном формате UTF-8 строки. //return: мл.32бита - длина в символах; ст.32бита - в байтах. u64 StrlenUtf8(void const *str) { u8 const *s = (u8 const *)str - 1; uint c, i, n = 0; for (; c = *++s; n++) { if (!(i = __CLZ(~((u32)c << 24)))) continue; if ((i -= 2) > 2u) trap(TRAP_UTF8, (u32)str); n += i + 1; do if (*++s >> 6 != 2) trap(TRAP_UTF8, (u32)str); while ((int)--i >= 0); } return n | (u64)((u32)s - (u32)str) << 32; } Вот что получилось у IAR-а на максимальной балансной оптимизации: u64 StrlenUtf8(void const *str) { _Z10StrlenUtf8PKv: (+1) 00000000 0xB430 PUSH {R4,R5} 00000002 0x4603 MOV R3,R0 u8 const *s = (u8 const *)str - 1; 00000004 0x1E5C SUBS R4,R3,#+1 uint c, i, n = 0; 00000006 0x2200 MOVS R2,#+0 00000008 0x4619 MOV R1,R3 0000000A 0xE015 B.N ??StrlenUtf8_0 for (; c = *++s; n++) { if (!(i = __CLZ(~((u32)c << 24)))) continue; ??StrlenUtf8_1: (+1) 0000000C 0xEA6F 0x6000 MVN R0,R0, LSL #+24 00000010 0xFAB0 0xF580 CLZ R5,R0 00000014 0xB17D CBZ.N R5,??StrlenUtf8_2 if ((i -= 2) > 2u) trap(TRAP_UTF8, (u32)str); 00000016 0x1EAD SUBS R5,R5,#+2 00000018 0x2D03 CMP R5,#+3 0000001A 0xBF24 ITT CS 0000001C 0x2016 MOVCS R0,#+22 0000001E 0xDF01 SVCCS 0x1 n += i + 1; 00000020 0x1C68 ADDS R0,R5,#+1 00000022 0x1882 ADDS R2,R0,R2 do if (*++s >> 6 != 2) trap(TRAP_UTF8, (u32)str); ??StrlenUtf8_3: (+1) 00000024 0xF814 0x0F01 LDRB R0,[R4, #+1]! 00000028 0x0980 LSRS R0,R0,#+6 0000002A 0x2802 CMP R0,#+2 0000002C 0xBF1C ITT NE 0000002E 0x2016 MOVNE R0,#+22 00000030 0xDF01 SVCNE 0x1 while ((int)--i >= 0); 00000032 0x1E6D SUBS R5,R5,#+1 00000034 0xD5F6 BPL.N ??StrlenUtf8_3 } ??StrlenUtf8_2: (+1) 00000036 0x1C52 ADDS R2,R2,#+1 ??StrlenUtf8_0: (+1) 00000038 0xF814 0x0F01 LDRB R0,[R4, #+1]! 0000003C 0x2800 CMP R0,#+0 0000003E 0xD1E5 BNE.N ??StrlenUtf8_1 return n | (u64)((u32)s - (u32)str) << 32; 00000040 0x1AE1 SUBS R1,R4,R3 00000042 0xBC30 POP {R4,R5} 00000044 0x4610 MOV R0,R2 00000046 0x4770 BX LR ;; return } Вы видите его косяки? Нет? А я вижу. И довольно много. А значит аналогичную функцию на асме я могу написать лучше (короче и быстрее). И это простейшая функция. Без какой-либо цифровой обработки. А с увеличением размера и сложности функций по моим наблюдениям - неэффективность си-компилятора быстро растёт.
  19. Модуль может быть и древний, но прошивки внутри может иметь разные. И что именно и как написано в конкретной прошивке конкретного модуля - совершенно неизвестно. Поэтому вряд-ли возможно оценить его пропускную способность. Только на свой страх и риск. Чтобы что-то оценивать не наугад, нужно иметь CRC (или хеш) прошивки вашего модуля, и именно для него искать инфу.
  20. Это где такие правила утверждены и кем? Глупость. Это называется: Разложить себе самому грабли на ровном месте. Когда переполнения стека начнут портить данные в куче. И поиски такой проблемы могут быть весьма длительными. Любая ошибка должна проявляться как можно сильнее. Чтобы быстро быть обнаруженной. А не заметаться под ковёр. А значит самое разумное - расположить стек в самом начале ОЗУ. Чтобы при переполнении стека шло обращение за пределы ОЗУ и вызывало срабатывание защиты MPU или MMU (если таковой блок имеется).
  21. Наверное в том, что где-то ранее ТС писал, что он пишет в маш.кодах. И это вроде как не шутка.
  22. Нет. Где угодно, где захочет ведомый. Хоть на каждом бите. Но я бы тоже посоветовал проверить подтяжки и ёмкость и длину проводов как советовали выше.
  23. Если вы уже действительно осваивали какой-то контроллер (именно осваивали контроллер, а не мурзилки типа куба к нему), то не понятно - что именно вызывает затруднения? Очевидно (как и в случае с любым другим контроллером) - первым делом нужно зайти на сайт производителя и скачать даташит и мануал к нему. Для пробы - зашёл на nxp.com и за пару минут нашёл и скачал "i.MX RT1050 Processor Reference Manual". Описание IOMUXC в нём имеется.
  24. Вы в вышеприведённую таблицу смотрели? Поняли что там написано?
×
×
  • Create New...