Intel4004

Значит, вы не поняли сути. Ага, только если ты не определил секцию, значит, это сделал кто-то другой и куда он её поместил- вопрос. Вам два раза сказали, что "Использование секции .ARM.__AT_address не требует ее определения в скаттер-файле.", но вы продолжаете талдычить свои фантазии. А ведь казалось бы, открыл любой проект, добавил в любой исходник строчку unsigned const int IWasMistaken __attribute__((section(".ARM.__AT_0x08080A00"))) = 123; , скомпилял, не трогая scatter, заглянул в map-файл и убедился, что переменная IWasMistaken лежит именно по адресу 0x08080A00. Делов на 5 минут. Но нет, некогда проверять, надо срочно нести бред в массы.

Это конечно-же не так. Использование секции .ARM.__AT_address не требует ее определения в скаттер-файле.

А секция .ARM.__AT_address тоже не работает? unsigned const int CONST123 __attribute__((section(".ARM.__AT_0x08080A00"))) = 123; https://developer.arm.com/documentation/100068/0608/compiler-source-code-compatibility/language-extension-compatibility--attributes Table 4-4 Migrating __attribute__((at(address))) and zero-initialized __attribute__((section("name"))) ARM Compiler 5 attribute: __attribute__((at(address))) ARM Compiler 6 attribute: __attribute__((section(".ARM.__at_address"))) Description: armlink in ARM Compiler 6 still supports the placement of sections in the form of .ARM.__at_address

Регистры внутри SPI драйвера. CMSIS к регистрам никакого отношения не имеет. CMSIS - это сборник интерфейсов, которые позволяют отвязать основную программу от железа. Например драйвер SPI выглядит так: typedef struct _ARM_DRIVER_SPI { ARM_DRIVER_VERSION (*GetVersion) (void); ///< Pointer to \ref ARM_SPI_GetVersion : Get driver version. ARM_SPI_CAPABILITIES (*GetCapabilities) (void); ///< Pointer to \ref ARM_SPI_GetCapabilities : Get driver capabilities. int32_t (*Initialize) (ARM_SPI_SignalEvent_t cb_event); ///< Pointer to \ref ARM_SPI_Initialize : Initialize SPI Interface. int32_t (*Uninitialize) (void); ///< Pointer to \ref ARM_SPI_Uninitialize : De-initialize SPI Interface. int32_t (*PowerControl) (ARM_POWER_STATE state); ///< Pointer to \ref ARM_SPI_PowerControl : Control SPI Interface Power. int32_t (*Send) (const void *data, uint32_t num); ///< Pointer to \ref ARM_SPI_Send : Start sending data to SPI Interface. int32_t (*Receive) ( void *data, uint32_t num); ///< Pointer to \ref ARM_SPI_Receive : Start receiving data from SPI Interface. int32_t (*Transfer) (const void *data_out, void *data_in, uint32_t num); ///< Pointer to \ref ARM_SPI_Transfer : Start sending/receiving data to/from SPI. uint32_t (*GetDataCount) (void); ///< Pointer to \ref ARM_SPI_GetDataCount : Get transferred data count. int32_t (*Control) (uint32_t control, uint32_t arg); ///< Pointer to \ref ARM_SPI_Control : Control SPI Interface. ARM_SPI_STATUS (*GetStatus) (void); ///< Pointer to \ref ARM_SPI_GetStatus : Get SPI status. } const ARM_DRIVER_SPI; И при переходе на другой процессор вам надо написать только то, что находится по ту сторону интерфейса, т.е. собственно драйвер. Или даже не писать, а подключить DFP (Device Family Pack) от вашего процессора, который содержит уже готовый драйвер (не у всех процессоров DFP содержит драйвера, как оно у STM32 я не знаю, я с ними не работаю). Повторяю: CMSIS - это не готовый драйвер, это интерфейс драйвера. Стандартизованный интерфейс, не привязанный к железу. А как будут написаны потроха драйвера - это абсолютно не важно. Можно на регистрах, можно на SPL, можно даже на HAL. Не важно. Т.е. если вы написали библиотеку поддержки индикатора ST7735 через HAL SPI драйвер - то вы автоматом привязаны к железу, при переходе на другой процессор вам придется править и эту библиотеку тоже. Если же вы работаете с индикатором через CMSIS SPI драйвер - то при переходе на другой процессор (даже другого производителя, например на атмел или филипс) - вам в вашей библиотеке индикатора ничего править не придется. Надо будет просто подключить SPI драйвер от нужного процессора (или написать, если готового нет), интерфейс у него тот-же самый, и все, что выше драйвера, прекрасно соберется и будет работать. Мой первый комментарий содержит полный развернутый ответ на исходный вопрос, но ирония в том, что чтобы этот ответ понять надо уже обладать достаточной квалификацией, при которой исходный вопрос и не возник бы. Т.ч. x893 частично прав, мой ответ можно считать троллингом. В любом случае, если вы не знаете, что такое CMSIS, с наскоку, за пять минут ничего сделать не получится. В любом случае сначала придется долго читать и изучать что такое CMSIS. Вот тут, например: https://arm-software.github.io/CMSIS_6/latest/General/index.html Если же желания тратить пару месяцев на изучение у вас нет, то единственный правильный ответ на ваш вопрос - никак.

О, вы заглянули в википедию? Похвально. Какой бред. В викистатье про CMSIS вы усвоили только первый абзац? Прочитайте всю статью. А лучше почитайте непосредственно документацию от CMSIS, например про CMSIS SPI Driver.

Ну я же говорю - вы не знаете, что такое CMSIS.

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

Примерно так: #define SPI_Driver ARM_Driver_SPI_(RTE_BOARD_ST7735_SPI_DRIVER) #define SPI_Mode (ARM_SPI_MODE_MASTER | ARM_SPI_CPOL1_CPHA0 | ARM_SPI_DATA_BITS(8) | ARM_SPI_MSB_LSB | ARM_SPI_SS_MASTER_SW) #define SPI_Baud (RTE_BOARD_ST7735_SPI_BAUD) #define SPI_Flag_Done (1<<0) #define SPI_Flag_Error (1<<1) extern const ARM_DRIVER_SPI SPI_Driver; static osThreadId_t Thread_Id; static void SPI_Handler (uint32_t event) { uint32_t Flags = 0; if (event & ARM_SPI_EVENT_TRANSFER_COMPLETE) Flags |= SPI_Flag_Done; if (event & (ARM_SPI_EVENT_DATA_LOST | ARM_SPI_EVENT_MODE_FAULT)) Flags |= SPI_Flag_Error; if (!Flags) Flags |= SPI_Flag_Error; osThreadFlagsSet(Thread_Id, Flags); } void ST7735_Initialize (void) { Thread_Id = osThreadGetId(); SPI_Driver.Initialize(SPI_Handler); SPI_Driver.PowerControl(ARM_POWER_FULL); SPI_Driver.Control(SPI_Mode, SPI_Baud); } void ST7735_Uninitialize (void) { SPI_Driver.PowerControl(ARM_POWER_OFF); SPI_Driver.Uninitialize(); } bool ST7735_Transmit (const void *buff, uint32_t buff_size) { SPI_Driver.Send(buff, buff_size); // <<<--- Вот это оно и есть, собственно HAL_SPI_Transmit #if SPI_POLLING while(SPI_Driver.GetStatus().busy); #else Flags = osThreadFlagsWait(SPI_Flag_Done | SPI_Flag_Error, osFlagsWaitAny, osWaitForever); if (Flags & SPI_Flag_Error) return false; #endif return true; } Только надо сначала написать SPI драйвер. Или подключить pack с готовым драйвером.

Ну, никто не мешает импортировать в uVision5, изучить, отладить и доработать там, а потом просто перенести изменения в проект uVision2 и собрать релиз.

Реагирует. Даблклик ЛКМ на значение, которое нужно изменить - и вызывается inplace editor. Или же ПКМ на значение, вызывается popup menu, в нем "Modify" - и вызывается окошко ввода. В обоих случаях можно вводить произвольное количество значений через запятую. upd: Мля, uVision2! Это же прошлый век... Я бы предпочел импортировать этот проект в uVision5 и не иметь лишних проблем.

1. Найти, скачать и установить Arm Compiler V5 (файл называется ARMCompiler_506_Windows_x86_b960.zip), валяется много где. 2. Подключить этот компилятор к Кейлу (тыц сюда).

Насколько я понимаю, там узкое место не в шлейфе, а в ласточкином хвосте, на который шлейф накалывают. Причем узкое место как по току, так и по механическим нагрузкам. Для одноразовой шабашки (сдать, получить деньги и быстро убежать) пойдет, для серийной продукции, которая работает годами - я бы не рискнул.

Код, который привел я в полный рост используется при рассчете CRC ZIP-файлов. Он рабочий. Рассчет CRC и таблица совпадают с тем, что нужно вам, соответственно рассчет таблицы тоже совпадает. Таблица у меня считается по полиному 0xEDB88320. 0xEDB88320 - это инвертированный полином 0x04C11DB7. Т.ч. вашему IARу подойдет или полином 0x04C11DB7 (если он сам умеет его инвертировать), или 0xEDB88320 (если не умеет). Код из первого поста и тот, что привел я - это полином 0x04C11DB7, преобразованный в 0xEDB88320, и, соответственно, рассчет CRC адаптирован под это преобразование. Тот код, где сдвиги не в ту сторону - это полином 0x04C11DB7, преобразованный в 0x82608EDB, и, соответственно, рассчет CRC адаптирован под это преобразование. В преобразованиях полиномов я не разбираюсь, поэтому подробнее не расскажу.

Не понимаю. Возможно это рассчет CRC в big-endian. Вот рабочий, проверенный код (рассчет таблицы и CRC32 по таблице):

Сгенерил таблицу, сравнил с вашей. Это самый ходовой полином для CRC32. Собственно, других я и не встречал. 0x04C11DB7, он же инвертированный 0xEDB88320