esaulenka

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

Если передавать в бинарном виде, это всего 3*2(у вас же <=16 бит АЦП?)*6000 = 36kbyte/sec. В 115200 не лезет, но в мегабитный UART с бааальшим запасом на любые протоколы. Правда, не уверен, что вы сможете перепосылать ошибочные данные - только выкидывать битые. Ну да ладно. У меня другой вопрос - что такое while (cs.cbInQue) { ... и зачем оно тут? Достаточно ж вроде верхнего цикла. Ещё вопрос. Вы можете поменять софт отправителя, чтобы просто слал байты по кругу? У вас потери всегда на стыке вызовов Read() (и всегда ли?) или возможны другие варианты? Ещё вопросы: SetCommMask() / ClearCommError() из цикла убирать пробовали? Кажется, так делать не обязательно. И вообще, чем вам QSerialPort не угодил?

А вы пробовали? Лет пять назад я собирал статику Qt5 на MSVC. Не могу сказать, что я суперкрутой программист под win32, но подбор всех ключей, чтобы оно нормально собралось и не пыталось затащить всякие webengine, занял несколько дней. Может, с mingw будет проще, но что-то я сомневаюсь... Информация на тот момент в тамошней вики была слегка устаревшая и противоречивая. Что, впрочем, можно понять - те, кому это нужно (и можно), могут и техподдержку спросить, у них уплочено.

Ну вот и получили гадание на кофейной гуще... Попробуйте лучше погадать на map-файле, там хоть будет видно, что сколько занимает.

Для начала понять бы, что именно у вас там такое большое. По опыту - всякие "излишние" фичи стандартной библиотеки занимают десяток кБ, не больше. Я пользовался этим рецептом: (что-то не могу найти его где-нибудь на гитхабе...) Но, повторюсь, магической экономии сотни килобайт он не даст, надо разбираться, что вы такое сделали. У меня прошивки в 300 килобайт ни разу не получались. Хотя не один год старался, писал 🙂

Требования опишите, пожалуйста. Потому что эмбеддед нынче - от атмеги и младших STM (тогда -fno-exceptions -specs=nano.specs ) до Qt (хех, Qt тоже без exceptions работает). И мерять исходный размер файла библиотеки, который потом урежется в 20 раз линкером, занятие странное... Чисто для затравки. Можете погуглить "embedded standard template library". Но как по мне, какая-то странная штука. Современная STL удобнее, безопаснее (в том смысле, что лучше протестирована). При наличии ограничений на использование динамической памяти в ней достаточно примитивов, которые работают без new/delete.

(просто пофлудить) а вы понимаете, зачем оно там? модуль U-blox там внизу, зачем ещё что-то?!

@ev_zubkov, если вам ещё актуально. 1) кажется, у вас сборка идёт в несколько потоков. Поэтому сообщения о компиляции tx_trace_XXX.c - к делу не относятся, старт компиляции tx_thread_system_suspend.c, в котором, собственно, и содержится ошибка, чуть выше. 2) в этом самом system_suspend используется макрос TX_LOWEST_SET_BIT_CALCULATE. В старших cortex-m он разворачивается в две ассемблерные команды - clz и rbit (вот оно). В cortex-m0 таких команд нет, и нужна отдельная функция (кажется, отсюда). Ваша задача - найти, откуда компилятор притащил неверный tx_port.h. 3) .s файл - временный, ассемблерный результат обработки си-шного исходника (ну там же по пути очевидно же).

вот, прямо как специально для к вашему вопросу статья подоспела: https://blog.willemmelching.nl/carhacking/2022/11/08/rh850-glitch/ (я мимо проходил, подобным не занимался и браться не хочу)

В стародавние времена Borland делал свой собственный компилятор. В какой-то момент (уже когда всё это поделие стало RAD'ом) они стали поняли, что рынок хочет всяких MacOS/Win64, и включили в свою IDE творчески допиленный clang. Под win32, насколько я помню, можно собирать любым компилятором, под остальные платформы - только clang'ом. Насколько их версия отличается от оригинального, я не разбирался.

Я не настоящий сварщик, но в файле KV5XP144M240RM.pdf в разделе UART сказано 5. UART0 and UART1 contain 8-entry transmit and 8-entry receive FIFOs 6. All other UARTs contain a 1-entry transmit and 1-entry receive FIFOs (чуда с огромными FIFO не случилось). У вас в регистре UARTx_PFIFO что записано? Насколько я понял изначальный вопрос, в данном случае не важна скорость работы прерывания. Его можно вовсе запретить, и все 128 переданных байт якобы должны лечь в аппаратное FIFO.

Самое смешное, что в STM32F1xx и STM32F4xx поведение DMA при разных PSIZE/MSIZE принципиально разное. В F1xx DMA добивает нулями (или обрезает), количество транзакций чтение/запись одинаковое. Более новые DMA умеют склеивать и разрезать данные, количество транзакций будет разное. Возможности переключать это поведение не предусмотрено.

@taraserker, буду исходить из предположений, что у вас F103 (хотя указывать точно, с чем вы работаете - дело полезное). Первое, 15.4 TIMx registers Refer to Section 2.2 for a list of abbreviations used in register descriptions. The 32-bit peripheral registers have to be written by words (32 bits). All other peripheral registers have to be written by half-words (16 bits) or words (32 bits). Read accesses can be done by bytes (8 bits), half-words (16 bits) or words (32 bits). т.е. по 8 бит туда писать нельзя никоим образом. Второе, 15.1 TIM2 to TIM5 introduction The general-purpose timers consist of a 16-bit auto-reload counter driven by a programmable prescaler. т.е. прескалер/каунтер/капча-компэйр регистры имеют размер 16 бит, и писать в старшую часть что-то кроме нулей не надо (я никогда не проверял, как оно работает. Подозреваю, просто игнорируется). В описании DMA есть некая мутная фраза, как устроена передача в APB (таймеры висят на APB) Addressing an AHB peripheral that does not support byte or halfword write operations When the DMA initiates an AHB byte or halfword write operation, the data are duplicated on the unused lanes of the HWDATA[31:0] bus. So when the used AHB slave peripheral does not support byte or halfword write operations (when HSIZE is not used by the peripheral) and does not generate any error, the DMA writes the 32 HWDATA bits as shown in the two examples below:  To write the halfword “0xABCD”, the DMA sets the HWDATA bus to “0xABCDABCD” with HSIZE = HalfWord  To write the byte “0xAB”, the DMA sets the HWDATA bus to “0xABABABAB” with HSIZE = Byte Assuming that the AHB/APB bridge is an AHB 32-bit slave peripheral that does not take the HSIZE data into account, it will transform any AHB byte or halfword operation into a 32-bit APB operation in the following manner:  an AHB byte write operation of the data “0xB0” to 0x0 (or to 0x1, 0x2 or 0x3) will be converted to an APB word write operation of the data “0xB0B0B0B0” to 0x0  an AHB halfword write operation of the data “0xB1B0” to 0x0 (or to 0x2) will be converted to an APB word write operation of the data “0xB1B0B1B0” to 0x0 For instance, to write the APB backup registers (16-bit registers aligned to a 32-bit address boundary), the memory source size (MSIZE) must be configured to “16-bit” and the peripheral destination size (PSIZE) to “32-bit”. Я никогда не проверял это утверждение (насколько помню, регистры таймера во всех заголовках описаны как 32-битные). Но вам ведь тоже никто не мешает установить PSize=32bit, MSize=8bit (см. табличку в описании, данные будут дополнены нулями).

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

Работает. На мелких проектах. Но "просто пересобрать" какой-нибудь Qt - так себе развлечение. Да и в современный интернет на XP выйти - то ещё развлечение (можно, конечно, тащить все свои библиотеки, как Firefox и Chrome, и не пытаться пользоваться системными, но хочется, всё-таки, жить попроще...). Дааа, незавидные "перспективы микроэлектроники в России"... :-) Первые же ссылки (https://github.com/kentosama/m68k-elf-gcc под линукс, https://sourceforge.net/projects/mingw-gcc-68k-elf/ под винду) - не помогают? Или прям свежая-новая версия необходима?

Вы невнимательно читаете. До указателя на uint16_t разговор ещё не дошёл. Компилятор не видит объявление указателя P8DataMas (вторую строчку из приведённого кода). Зато видит третью строчку, но из-за устаревшей 50 лет назад магии считает, что эта переменная имеет тип по умолчанию - int (см. варнинг). А присвоить int'у указатель без явного приведения не может (это уже ошибка, на которой компиляция останавливается). А как он хранится в памяти в том или ином МК ? Одинаково они хранятся, и в том МК, и в ином CPU.

Вот объяснение, почему так нельзя делать в C++: https://isocpp.org/wiki/faq/ctors#ctor-initializer-order Там, правда, почему-то сказано, что "компилятор может выдавать предупреждение". Проверил на gcc нескольких версий и на MSVC - все отказываются это компилировать. В случае C - да, конечно, компилятору проще сделать константный массив и в момент инициализации memcpy'ить его в нужное место.

Если быть точным, то в C++20 добавили только designated initializers (как это по-русски? назначенный?..) для структур. Для массивов, как в исходном вопросе, поддержки нет (я невнимательно слежу за развитием языка, но вроде б эту фишку и не обсуждали для добавления в последующие стандарты). Также в C++ есть ограничение, что члены структуры должны инициализироваться в том же порядке, как они расположены в самой структуре (с C можно было инициализировать как угодно).

Первый вариант - так исторически сложилось с незапамятных времён (а дальше - стандарт соблюдает обратную совместимость). Второй вариант - неявное преобразование типов сознательно запретили, из соображений, что оно противоречит общей идее С++ о строгой типизации. Подробнее можно прочитать в предложении о введении такой инициализации: https://www.stroustrup.com/N1919-initializer_lists.pdf Только не спрашивайте, как это всё работало до 2005 года ;-) (точнее, 2011, оно попало в стандарт C++11).

Ну, вот, например. Это, конечно, правила для ДРУГОГО языка, но ознакомиться с мыслями умных людей стоит. У меня гораздо чаще возникает задача "найти, кто в эту переменную пишет, и кто где читает". Проблемой "найти все локальные переменные в функции" я, наверное, ни разу в жизни не занимался. И вот для этого чем ближе переменная к месту использования, тем лучше.

Начиная со стандарта 1999 года, этого ограничения больше нет, переменные можно (и, согласно правилам хорошего тона, нужно) объявлять в месте использования.

Вам всё ещё актуально? Не понял, что вы делаете. Насколько вижу, отправление из вашего контроллере (что за контроллер-то?) работает, в канвайзе видно 378-е сообщение. Кто тогда отправляет 379-е ? То сообщение, которое вы пытаетесь принять, кто отправляет? Как оно выглядит? (тут неочевидная штука - свои сообщения контроллер не видит). Также проблема может быть в настройках фильтра. Мне очень лень разбираться, что там навертели в кубе. Покажите значения регистров кана (хоть картинками из отладчика) И да, следите пожалуйста за форматированием кода. Кривые отступы не очень помогают пониманию...

В стародавние времена проект жил на сорсфорже, если я ничего не путаю. И в 3-й версии там есть ARM7 && IAR. В 4-ю оно уже не попало (некому перетаскивать было?..) https://sourceforge.net/projects/scmrtos/files/scmrtos/

Если вы про mifire (судя по упоминанию телефона), то там как-то сложно всё. У меня есть в закладках https://mysku.ru/blog/ebay/41849.html хотел скопировать ключ от нашего подъезда, но руки так и не дошли (особенно после выяснения кода от этого домофона).

Ну ок. Своим мнением о велосипедостроении я поделился, больше мне выковыривать из носа нечего. Поль-зо-ва-тель? Конечный? Он слова-то LFSR не знает. У нас же типа "безопасность через скрытность", как оно там внутри устроено, никому рассказывать нельзя. Тут @Vasily_ как-то упоминал, что дамп атмеги стоит несколько сотен баксов. Я не проверял. Ну, вам просто к сведению. Спор, постоянно скачущий с бузины на киевского дядьку, пошёл на очередной круг. Ещё раз напомнить, что вы зачем-то мешали сложность подбора полинома и сложность подбора ключа? Мне надоело, спасибо за беседу.