PheeL

rr = *(int*)≪

Господа, вы извините, конечно, но вот я читаю уже не первую страницу данной темы и никак понять не могу, вы постоянно упираете на HAL, но ведь там же есть ещё и LL (Low Layer)! Более того, Cube позволяет в настройках проекта переключать генерацию кода в этот API (LL). А там практически всё, что вы так любите - прямое обращение к регистрам периферии, только с вменяемыми названиями функций и регистров, чтобы можно было потом код _читать_ и поддерживать, а не в битах спотыкаться. Да, конечно, там тоже есть свои нюансы (как пример - настройка секвенсора в АЦП), но их значительно меньше (на мой взгляд) чем в HAL. И, естественно, вы не сможете сделать на LL всё. Например, драйвер FLASH там отсутствует, как-минимум для линейки F3. А для F7 там вообще нет поддержки большей части мощной периферии (SDMMC, USB, DCMI, LTDC, ETH и др.). Но, вы собрались её всю программировать руками? Простите, USB, где в документации 10 страниц одного _перечисления_ регистров! Могу пожелать только много времени, удачи и усердия. P.S. Для простой периферии на STM32 используйте LL и будет вам счастье. Для мощной - решайте сами.

Настроить DMA на приём?

Кстати, просветите насчёт сниппетов, пожалуйста. Насколько я понял ST отказалась и от них тоже, заменив на HAL Low Level Drivers. Это макро-обёртки над регистрами периферии которыми пользуется верхний уровень самого HAL, но если для каких-то драйверов он избыточен и не применяется, то позволяется напрямую пользоваться этими макросами. Причём, поскольку это тоже относительно новое веяние, то например для F4 серии их я не заметил, хотя в HAL для других линеек они присутствуют.

Это для всей линейки STM32F10xxx. В PM0075 на странице 17 написано следующее: "Pages 0-3 (for low- and medium-density devices), or pages 0-1 (for high-density and connectivity line devices) are automatically write-protected. The rest of the memory can be programmed by the code executed from the main Flash memory (for IAP, constant storage, etc.), but it is protected against write/erase (but not against mass erase) in debug mode or when booting from the embedded SRAM." Сам на эти "грабли" наступил недавно. На STM32L1 код самодельного загрузчика обновляется с установленой защитой (первого уровня. Но она там тоже с "нюансами"), а на STM32F1 уже нет. FLASH-контроллер выдаёт WRPERR бит на попытку стирания этих первых страниц. А без защиты всё ок.

Есть галочка "C/C++ Compiler -> Language 1 -> Multi-file Compilation", но она точно не использует все ядра и применение у неё немного другое. Не уверен, что у IAR компилятор многопоточность поддерживает.

Вопрос: При подключении USB Flash накопителя в порт физически подключённый к USB OTG HS микроконтроллера, в отладчике вижу, что устройство определяется, происходит подключение(конечный автомат драйвера переходит в состояние Connect), верно читается VID/PID устройства, но не проходит этап энумерации. Хотя на OTG FS всё штатно (устройство подключается и работает без сбоев). Включение\выключение VBUS происходит верно, напряжение во включенном состоянии 5.2(В). Исходные данные: IAR 7.10 (Optimizations None). Все настройки проекта пока не буду перечислять, их много и я почти уверен, что проблема не в них. CMSIS 4.0.1 STM32Cube Firmware 1.3.0 STM32 HAL Driver 1.1.0 STM32 USB Host Library 2.2.0 Далее, статическая конфигурация и код инициализации: //USB Host #define USBH_ENABLED 1 #define USBH_FS_ENABLED 0 #define USBH_HS_ENABLED 1 //USBH Classes #define USBH_HID_ENABLED 1 #define USBH_MSC_ENABLED 1 /*---------- -----------*/ #define USBH_MAX_NUM_ENDPOINTS 4 /*---------- -----------*/ #define USBH_MAX_NUM_INTERFACES 10 /*---------- -----------*/ #define USBH_MAX_NUM_CONFIGURATION 1 /*---------- -----------*/ #define USBH_KEEP_CFG_DESCRIPTOR 0 /*---------- -----------*/ #define USBH_MAX_NUM_SUPPORTED_CLASS 2 /*---------- -----------*/ #define USBH_MAX_SIZE_CONFIGURATION 255 /*---------- -----------*/ #define USBH_MAX_DATA_BUFFER 512 /*---------- -----------*/ #define USBH_DEBUG_LEVEL 0 /******************************************************************************/ Status USBH_Init_(void* args_p) { const OS_UsbhHd* usbh_hd_p = (OS_UsbhHd*)args_p; Status s = S_OK; usbh_fs_hd_p = (USBH_HandleTypeDef*)usbh_hd_p->usbh_fs_hd; usbh_hs_hd_p = (USBH_HandleTypeDef*)usbh_hd_p->usbh_hs_hd; // Interface #if (1 == USBH_FS_ENABLED) if (USBH_OK != USBH_Init(usbh_fs_hd_p, USBH_UserProcess, USBH_ID_FS)) { return s = S_HARDWARE_FAULT; } #endif // USBH_FS_ENABLED #if (1 == USBH_HS_ENABLED) if (USBH_OK != USBH_Init(usbh_hs_hd_p, USBH_UserProcess, USBH_ID_HS)) { return s = S_HARDWARE_FAULT; } #endif // USBH_HS_ENABLED // Class #if (1 == USBH_HID_ENABLED) #if (1 == USBH_FS_ENABLED) if (USBH_OK != USBH_RegisterClass(usbh_fs_hd_p, USBH_HID_CLASS)) { return s = S_HARDWARE_FAULT; } #endif // USBH_FS_ENABLED #if (1 == USBH_HS_ENABLED) if (USBH_OK != USBH_RegisterClass(usbh_hs_hd_p, USBH_HID_CLASS)) { return s = S_HARDWARE_FAULT; } #endif // USBH_HS_ENABLED #endif // USBH_HID_ENABLED #if (1 == USBH_MSC_ENABLED) #if (1 == USBH_FS_ENABLED) if (S_OK != drv_usbh_v[DRV_ID_USBH_FS_MSC]->itf.Init(usbh_fs_hd_p)) { return s = S_HARDWARE_FAULT; } if (USBH_OK != USBH_RegisterClass(usbh_fs_hd_p, USBH_MSC_CLASS)) { return s = S_HARDWARE_FAULT; } #endif // USBH_FS_ENABLED #if (1 == USBH_HS_ENABLED) if (S_OK != drv_usbh_v[DRV_ID_USBH_HS_MSC]->itf.Init(usbh_hs_hd_p)) { return s = S_HARDWARE_FAULT; } if (USBH_OK != USBH_RegisterClass(usbh_hs_hd_p, USBH_MSC_CLASS)) { return s = S_HARDWARE_FAULT; } #endif // USBH_HS_ENABLED #endif // USBH_MSC_ENABLED return s; } /******************************************************************************/ Status USBH_Open(void* args_p) { Status s = S_OK; usbhd_stdin_qhd = (OS_QueueHd)args_p; #if (1 == USBH_FS_ENABLED) if (USBH_OK != USBH_Start(usbh_fs_hd_p)) { return s = S_HARDWARE_FAULT; } #endif // USBH_FS_ENABLED #if (1 == USBH_HS_ENABLED) if (USBH_OK != USBH_Start(usbh_hs_hd_p)) { return s = S_HARDWARE_FAULT; } #endif // USBH_HS_ENABLED return s; } /******************************************************************************/ void HAL_HCD_MspInit(HCD_HandleTypeDef* hhcd) { ... ... else if(hhcd->Instance == USB_OTG_HS) { __GPIOB_CLK_ENABLE(); __GPIOD_CLK_ENABLE(); __GPIOE_CLK_ENABLE(); /**USB_OTG_HS GPIO Configuration PB12 ------> USB_OTG_HS_ID PB13 ------> USB_OTG_HS_VBUS PB14 ------> USB_OTG_HS_DM PB15 ------> USB_OTG_HS_DP */ GPIO_InitStruct.Pin = GPIO_PIN_12|/*GPIO_PIN_13|*/GPIO_PIN_14|GPIO_PIN_15; GPIO_InitStruct.Mode = GPIO_MODE_AF_PP; GPIO_InitStruct.Pull = GPIO_NOPULL; GPIO_InitStruct.Speed = GPIO_SPEED_LOW; GPIO_InitStruct.Alternate = GPIO_AF12_OTG_HS_FS; HAL_GPIO_Init(GPIOB, &GPIO_InitStruct); GPIO_InitStruct.Pin = GPIO_PIN_3; GPIO_InitStruct.Mode = GPIO_MODE_OUTPUT_PP; GPIO_InitStruct.Pull = GPIO_NOPULL; HAL_GPIO_Init(GPIOE, &GPIO_InitStruct); GPIO_InitStruct.Pin = GPIO_PIN_13; GPIO_InitStruct.Mode = GPIO_MODE_INPUT; GPIO_InitStruct.Pull = GPIO_NOPULL; HAL_GPIO_Init(GPIOB, &GPIO_InitStruct); HAL_GPIO_Init(GPIOD, &GPIO_InitStruct); /* Peripheral clock enable */ __USB_OTG_HS_CLK_ENABLE(); /* Peripheral interrupt init*/ HAL_NVIC_SetPriority(OTG_HS_IRQn, OS_PRIORITY_INT_MIN, 0); HAL_NVIC_EnableIRQ(OTG_HS_IRQn); } /******************************************************************************/ USBH_StatusTypeDef USBH_LL_Init (USBH_HandleTypeDef *phost) { ... ... else if (phost->id == USBH_ID_HS) { hcd_hs_hd.Instance = USB_OTG_HS; hcd_hs_hd.Init.Host_channels = 8; hcd_hs_hd.Init.speed = HCD_SPEED_FULL; hcd_hs_hd.Init.dma_enable = DISABLE; hcd_hs_hd.Init.phy_itface = HCD_PHY_EMBEDDED; hcd_hs_hd.Init.Sof_enable = DISABLE; hcd_hs_hd.Init.low_power_enable = DISABLE; hcd_hs_hd.Init.vbus_sensing_enable = ENABLE; hcd_hs_hd.Init.use_external_vbus = ENABLE; /* Link The driver to the stack */ hcd_hs_hd.pData = phost; phost->pData = &hcd_hs_hd; HAL_HCD_Init(&hcd_hs_hd); USBH_LL_SetTimer (phost, HAL_HCD_GetCurrentFrame(&hcd_hs_hd)); } Весь остальной низкоуровневый код реализации драйвера взят из примеров (они все одинаковые, сгенерированные оболочкой Cube), проектов в STM32 Firmware.

Ну, например, как вот здесь в разделе "Download". upd. Я не понимаю, судя по сайту для вашей платы должен быть доступен набор ПО из: Неужели в комплекте даже диска никакого не шло?

Возможно вы действительно приобрели не совсем подходящий для вас DevKit. Я являюсь обладателем MarS Board от Embest. На ней выведена площадка под разъём JTAG (PLLD1.27-10). Мне его любезно припаяли, а я интереса ради попробовал загрузить и исполнить файл из ОЗУ простенькую тестовую программу через SEGGER J-Link v8.0 и IAR7.10. На этом DevKit'е установлен Dual вариант SoC i.MX6 , но IAR (там есть конфигурация конкретно под этот вариант чипа) в отладчике выводит информацию о регистрах только одного из них. Как переключиться на второе и возможно ли это в принципе в этой версии IDE я пока не знаю. Ничего интересного больше не скажу, т.к. брал плату для экспериментов с Linux и Android.

Если очень нужен Ethernet, можно поступить так: http://zaozmi.ru/catalog/servoprivod/spsh.html + http://zaozmi.ru/catalog/ethernet_can_shluz.html

Каждый из элементов enum - это int. Так что если машинное слово 32-х разрядное, то всё верно.

Господа, чтобы не изобретать очередной велосипед, обращаюсь к "коллективному разуму" специалистов с просьбой навести на готовую спецификацию\реализацию протокола удволетворяющего следующим формальным требованиям: Цели протокола. Обеспечение надёжной доставки пакетов по заданному маршруту в пределах сетевого сегмента из приборов/интеллектуальных датчиков содержащих в себе программируемый микроконтроллер уровня не ниже Atmel AVR Mega8. Основные требования. Надёжная доставка (с подтверждением (квитированием)). Одноранговая (или гибридная?) сеть. Маршрутизация в пределах сетевого сегмента. Без установки соединения. Пакетная коммутация. Фрагментация\дефрагментация (сетевой или канальный уровень?). Дуплексный обмен. Управление потоком. Минимальный размер заголовка относительно полезной нагрузки кадра. Возможность формирования кадров для потоковых интерфейсов (Byte stuffing). Работа через интерфейсы: Ethernet, USB, CAN, SPI, I2C, UART(RS-232, Bluetooth), RS-485. Ограничения. Не гарантируется соблюдение "реального времени". Не подходит для трансляции высоко-нагруженного (аудио\видео) трафика. Особенности реализации. Язык реализации — ANSI C.

Хочу посоветовать обратить внимание на систему сообщений в QNX. Я сейчас не готов предметно обсуждать возможность использования формата применяемых там сообщений для IPC как универсального протокола обмена через различные аппаратные интерфейсы, но возможно стоит взглянуть на заложенные там идеи (тем более, что документация отличная). Во всяком случае я сам планирую более детально это изучить когда буду чуть более разгружен на работе.

Вы забыли упомянуть, что это всё надо делать только под Линуксом, потому что микро-РТОС для таких задач совершенно не подходят, т.к. для них нет готовых коммуникационных стеков и драйверов! )

Конкретно для этого случая есть в наличие тоже стандартная memove();

Спасибо. В принципе я услышал всё, что хотел по данному вопросу. Подводя итог можно выделить два основных пути решения проблемы: 1) Дополнительная сигнальная линия с вариантами использования как индикации готовности от слева мастеру, так и в интвертном режиме, когда хост является слейвом. А-ля RTS/CTS/DTR/DSR. Предположительно заведён на аппаратное прерывания хост устройства. Лучший вариант если есть такая аппаратная возможность. 2) Поллинг мастером слейва. Мастер периодически либо постоянно выставляет запрос на данные от слейва тактируя шину в ожидании сигнального байта/пакета готовности обмена. Чисто программный вариант. Степень загрузки основного ядра контроллера мастер устройства при обмене зависит от настроек периферии, а также от наличия аппаратных возможностей для разгрузки основного ядра хост устройства(SPI+DMA+IRQ).

Интересует, какие есть варианты протокола обмена по шине SPI, когда Master и Slave разные по производительности устройства, и необходимо на принятие пакета от мастер-устройства выдавать пакет подтверждения об успешном приёме(т.е. как минимум проверить crc пакета. иными словами, мастер тактирует шину, а слейв ещё не готов отдать ответ). А также вариант, когда слейв исполняет команду и должен сигнализировать мастеру о готовности передачи пакета с данными. Пока есть только вариант с дополнительной сигнальной линией индикации от слейва к мастеру. Есть ли програмный вариант протокола обмена по синхронным шинам для решения подобных проблем?

В таком случае программист поворачивает свой широкоэкранный монитор на 90° и говорит, что у него код функции помещается на экране целиком )

Отвечаю сам себе - да, существует! Смотреть в документы CD00264379.pdf, CD00167594.pdf. При использовании ПО предоставляемой фирмой разработчиком, в частности STDFU Tester, DFUse Demonstrator, убедиться, что бинарный файл слинкован с таблицой векторов _единым_блоком_ т.к. после загрузки в SRAM при исполнении ПО операции "Leave Dfu Mode" используется начальный адрес _поледнего_ загруженного бинарного блока! Если вы на базе исходников делаете загрузку через DFU протокол сами, то там проще, т.к. есть аргумент с адресом запуска в команде выхода из загрузчика.

Не хотелось создавать отдельный топик, поэтому спрошу здесь, посколько вопрос по теме. Существует ли возможность с помощью DFU-bootloader'а загрузить и исполнить пользовательский код размещённый в SRAM? Если да, то тогда будем углубляться в детали.

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

Не уверен в деталях, это лучше написано в документации, но насколько помню, передача автоматически заканчивается с отправкой последнего байта из CANMSG заданного значением в CANCDMOB. Посмотрите, пожалуйста, описание. Насчёт сценария с бесконечной отправкой подсказать не могу. Возможно вы ставите в тупик контроллер шины который не получает подтверждение о доставке пакета и повторяет посылку?

Да, действительно, он только Read. Значит эту команду можно игнорировать. Код частично достался в наследство, я не сильно вчитывался ) Прошу прощения, забыл #define указать. #define CH_TxENA 0x40

Это код как раз для AT90CAN128 на передачу данных в настроенный канал(в данном случае первый). Вас непосредственно интересуют две последние строчки. CANPAGE = (1 << 4); CANIDT2 = (U8)(msg_id << 5); CANIDT1 = (U8)(msg_id >> 3); CANCDMOB = size; if (NULL != data_p) { if (DLC_MAX >= size) { while (size--) { CANMSG = *data_p++; } } else { D_LOG_MDL(D_LOG_WARNING, "data overflow!"); return ERR_OVERFLOW; } } CANSTMOB = 0; while (HAL_BIT_CHECK(CANGSTA, TXBSY)); CANEN2 |= (1 << 1); /* channel 1 enable */ CANCDMOB |= CH_TxENA; /* emission enabled */

А почему бы не сделать из него библиотеку и подключать её к проекту?