Лидеры

как же так??? Ведь: PS: Боюсь, что опять окажется что "даю совет взять камень по-толще по-дороже", но XMC4502 имеет: "Four Analog-Digital Converters (VADC) of 12-bit resolution, 8 channels each". Хотя сомневаюсь что удастся с него одного 80 каналов на 0.32MS/s. А вот с пары XMC4502 - должно получиться. Ну и по периферии, через которую можно отдать данные наружу - он богат: хоть несколько QSPI, хоть SDMMC 4-битный, хоть внешняя шина (EBU). И проще сего (имхо): 2шт.XMC4502 + TMS320C6745 со связью через параллельную шину или несколько QSPI.

На удачу ))) Выжидание требуется для МАС. PHY согласуется автоматически. По результатам согласование PHY, МАС настраивает свои регистры. Значения Half/Full duplex, 10/100 МБит. По умолчанию МАС настроен на Full Duplex и 100 МБит. PHY скорее всего у вас не гигабитный. Сейчас сеть на 10 Мбит еще умудриться найти надо. Поэтому настройка по умолчанию в подавляющем большинстве случаев подходит.

Тема себя исчерпала и была закрыта.

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

Там помимо четвертьволновой аннтенны есть еще согласователь импедансов. В классическом варианте это трансформатор, можно также сделать на П-образном LC-фильтре и т.п. Но в массовом производстве это неудобно, поэтому производители антенн делают довольно замысловатые конструции, которые в эквивалентной схеме сводятся к П-фильтру. Конечно, вы можете взять кусок провода 8.1 см и согласовать его трансформатором или П-фильтром. Однако если вы просто подрежете кусок длинного провода до настройки антенны на нужную частоту, получите практически такой же результат. По факту более длинный провод добавит индуктивность, так что уже получится неплохое согласование на нужной вам частоте. Можете попробовать в основании антенны добавить конденсатор в несколько пик на землю и настроить длину после этого. Возможно, согласование немного улучшится, однако сомневаюсь что овчинка будет стоить выделки. Насчет "длинных" антенн я вот еще что хочу сказать. В большинстве случаев производители делают "длинные" антенны ради маркетинга. Чтобы покупатель был уверен, что за свои деньги он купил "вещь", а не фигню какую-то, "недомерок". А как посмотришь на характеристики, усиление у них практически все те же 3 dBi, плюс-минус. Реально длина больше чем четверть длины волны требуется для коллинеарных антенн, обеспечивающих заметно большее усиление, чем обычный четвертьволновой штырь. Но это редкий тип антенны и стоит он отдельных денег.

Проверять надо более комплексно, например выдернуть кабель и снова подключить, сделать power/off - power onn и т.д., наблюдать не светодиод линка, а реальный обмен пакетами. При этом время и результат (успех/неуспех) с разными компьютерами, маршрутизаторами или коммутаторами на разных скоростях и настройках может быть разным. Про задержку. Почему она существует и почему она потребовалась. Существует протокол автосогласования, для того чтобы он отработал требуется время: https://en.wikipedia.org/wiki/Autonegotiation В ST некогда переписали HAL код Ethenet и сделали множество ошибок, одной из них является само построение логики: они сбрасывают PHY, инициализируют, и ждут окончания процесса автосогласования, для чего выдерживают заданную паузу. В этом у них еще и баг, так как в некоторых случаях с гигабитными линками требуемое время существенно больше, до 3сек, то есть превышает заданную ими паузу. Правильный код должен сбросить PHY, проинициализировать, и на этом инициализация должна закончиться, перенеся время ожидания в цикл, в периодическую проверку is link up.

Вот тут видели? - https://www.yaplakal.com/forum28/st/75/topic2783054.html

TOG, если длина 19 см, то возможно это не четверть волны, а 5/8L c компенсирующей реактивность индуктивностью. Можете такую попробовать сделать из рулеточной ленты.

Для тех, кто не дочитал до конца документацию, я просто оставлю это здесь: и не благодарите * @file stm32f103x6.h * @author MCD Application Team * @brief CMSIS Cortex-M3 Device Peripheral Access Layer Header File. * This file contains all the peripheral register's definitions, bits * definitions and memory mapping for STM32F1xx devices. * * This file contains: * - Data structures and the address mapping for all peripherals * - Peripheral's registers declarations and bits definition * - Macros to access peripheral’s registers hardware Надоел мне этот бессмысленный флуд и понты не по теме. HAL_SPI_Transmit() можно записать в простом и коротком виде int SPI_Transmit(SPI_TypeDef *spi, const uint8_t *buf, uint16_t size) { if(spi->SR & SPI_SR_BSY) return -1; while(size--) { while(!(spi->SR & SPI_SR_TXE)); spi->DR = *buf++; } while(!(spi->SR & SPI_SR_TXE)); while(spi->SR & SPI_SR_BSY); return 0; } uint8_t arr[10] = {1,2,3,4,5,6,7,8,9,10}; SPI_Transmit(SPI1, arr, sizeof(arr)); Всё. И завязывайте с флудом не по теме вопроса.

Регистры внутри 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 Если же желания тратить пару месяцев на изучение у вас нет, то единственный правильный ответ на ваш вопрос - никак.

Примерно так: #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 с готовым драйвером.

Да, я не знаю, что такое CMSIS, я это "не знаю" еще с 2011 года, да так и до сих пор "не знаю" 🙂 Учись, студент! (С) 🙂 А вот это: #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) - это какая-то хрень с ушами, она не в стандарте CMSIS. По уму, в стандарте заголовочника CMSIS, делается так: SPI1->CR1 = SPI_CR1_MSTR | SPI_CR1_SSM | SPI_CR1_SSI; SPI1->CR1 |= SPI_CR1_SPE; while(!(SPI1->SR & SPI_SR_TXE)); SPI1->DR = byte; Вот это - по CMSIS. А та мутотень, что вы понаписали с многочисленными передефайнами дефайнов - это самопальное творчество того, у кого очень руки чешутся всё передефайнить на свой вкус. Хотя, сия замута вносит больше путаницы, чем порядка. Есть такая категория писателей - переписать Евгения Онегина на свой лад, заменив все имена и места действия.

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

Мало ли че вы говорите. CMSIS - Common Microcontroller Software Interface Standard. Заголовочные файлы STM32 написаны в стандарте CMSIS. В обиходе это называется "писать на регистрах", то есть, непосредственное управление регистрами периферии микроконтроллера, без оберточных функций, посредством предоставленных в заголовочнике определений адресов регистров и номеров битов. Топикстартер спрашивал: как преобразовать функцию HAL_SPI_Transmit() в CMSIS? Вы ответили: SPI_Driver.Send(buff, buff_size); // <<<--- Вот это оно и есть, собственно HAL_SPI_Transmit Только надо сначала написать SPI драйвер. Так вопрос как раз и стоял в том, чтобы написать тот самый драйвер SPI. А вы, не поняв вопроса, вставили длиннющую портянку какой-то фигни, не имеющей отношения к вопросу. Вы сами то хоть понимаете, чего пишите то? Мало того, что показанные портянки, скорее всего, не от STM32, так они еще и не имеют отношения к теме вопроса.

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